Seeing phishing email that appears to come from your domain is alarming, but it does not automatically mean your mailbox or website was hacked. Attackers can place a familiar domain in the visible From field unless receiving providers can verify authentication and apply your DMARC policy. Treat the report as both a security incident to investigate and a reason to check your domain’s public email controls.
Preserve the evidence first
Ask the recipient for the complete original message or headers. Record the visible From address, return-path, sending IP, recipient, date, links, attachments, and whether anyone replied or entered credentials. Do not click the message links to investigate. The headers reveal whether it actually passed SPF, DKIM, or DMARC and whether it originated from infrastructure you operate.
Separate spoofing from account compromise
Mailbox compromise often leaves evidence in the sent folder, forwarding rules, sign-in history, or unusual mailbox activity. Simple spoofing often originates from unrelated infrastructure and merely uses your name in the From field. Both require action, but the response differs. If an account may be compromised, reset credentials, revoke sessions, check forwarding rules, and involve your mail administrator immediately.
Check SPF, DKIM, and DMARC
SPF authorizes designated sending systems. DKIM signs mail so receivers can validate it. DMARC tells receivers how to handle mail that claims to be your domain but fails aligned SPF and DKIM. Start with our guides to checking SPF, checking DKIM, and checking DMARC. A record existing is not enough: legitimate senders must pass and align.
Move toward enforcement safely
If DMARC is at p=none, reports can show who sends as your domain while receivers still make their own handling decisions. After inventorying legitimate senders, move through quarantine and eventually reject when evidence supports it. Do not jump to reject while a billing, support, or marketing system still fails alignment. Read the DMARC policy guide for a safe rollout.
Communicate and monitor
Warn affected staff or customers through an established trusted channel when appropriate, using clear instructions not to reply, pay, or share passwords. Keep a record of impersonation reports, review DMARC reports, and recheck after any vendor change. Run Beacon’s free domain check to see the public SPF, DKIM, and DMARC signals attackers and recipients can see.
What not to do
Do not publish a restrictive DMARC policy simply because one phishing message was reported. First identify your legitimate systems and test their alignment. Do not ask recipients to forward suspicious messages to a personal inbox, and do not change DNS repeatedly while you are still collecting headers. A measured response gives you useful evidence while reducing disruption.
Escalate when credentials may be involved
If anyone entered a password, immediately reset it through the normal account page, enable MFA, and review active sessions. If money or banking details were involved, contact the financial institution using a trusted number. Preserve the original message and timeline for your provider or incident responder.
Make customers harder to fool
Use consistent sending domains, never request passwords by email, and publish clear support contact information on your website. Those habits make unusual messages easier for customers to recognize and report.
Build a repeatable response
Give staff a simple route to report impersonation, preserve the original headers, and identify the person who can review DNS and mail-provider evidence. Record the visible sender, affected recipient, links, payment requests, and whether any credentials were entered. Consistent incident records make recurring abuse easier to recognize and help distinguish a spoofed display name from a compromised internal account.
Review after every sender change
New email tools, agencies, or return-path domains can alter alignment. Recheck public records and fresh message headers after each launch. The strongest protection is not merely publishing DMARC once; it is keeping the sender inventory and policy aligned with how the business actually communicates.