Email sender spoof: how to spot and stop it

How to tell whether a message is a sender spoof

You confirm a sender spoof by reading the receiving server's own authentication results, not the visible message. Two layers of checking apply: signals a reader can see without leaving the message, and the headers underneath it.

Start with what is visible, because many forgeries expose a mismatch before you open the full source:

• Read the domain character by character. Look for a swapped letter, a different suffix, or the real brand name placed inside someone else's domain.
• Compare the display name with the full address. A familiar name can sit beside an unrelated mailbox.
• Check whether the sending domain is plausible for the claimed organization.
• Inspect the destination of each link without opening it. The visible label can differ from the actual destination.
• Treat changed payment details, unexpected urgency, and first-time requests as reasons to verify through a separate contact path.

Start with the dmarc= result because DMARC tests alignment with the visible From domain. A message can pass SPF for the attacker's own domain and still fail DMARC for the brand it is impersonating.

Two more signals sit outside the authentication results. SMTP servers prepend Received: trace fields, so read from the earliest record added by infrastructure you trust and work upward. Earlier sender-supplied lines can be forged. Also check whether Reply-To: points somewhere different from From:. That mismatch is not proof of spoofing, but it tells you where a reply would go. An email header analyzer can parse these fields and authentication results for the message you provide.

If the message carries a link, resolve it before opening it. A phishing link checker or a URL reputation check follows redirects and tests the destination without exposing your device.

Common issues when verifying a sender

Four situations account for most of the confusion when a result does not match what the message looks like.

Why does mail from a real contact fail SPF or DKIM?

Forwarding changes the SMTP client seen by the final receiver, which can break SPF. A mailing-list server can also modify signed content and break DKIM. Do not treat one failure as proof of forgery. Read the full DMARC result and the trusted Received: path, then confirm through a separate channel when the request is sensitive.

Why does a message pass authentication but still feel wrong?

Mail from a genuinely compromised mailbox authenticates correctly, because it really was sent by an authorized account. Authentication cannot help here. Fall back to behavioral signals: an unusual request, manufactured urgency, a change of payment details, or a reply address that does not match. When the request involves money, verify by phone regardless of what the headers say.

Can link text be trusted when the domain looks right?

Visible link text and even a hovered domain can be disguised with redirects and shorteners. Check the destination with a tool rather than by clicking.

How do I tell whether my own domain is being spoofed?

A single message tells you about one message. For a domain-wide view, read DMARC aggregate reports, covered under "What to check next" below.

When the answer changes

The right response depends on what is being impersonated and what evidence you have.

If the message uses your exact domain in the visible From: field, DMARC is the domain-level control that applies. Start by inventorying real sending systems and confirm that each important mail path has an aligned SPF or DKIM pass. Then use DMARC reports to identify mail sources that still fail and remediate them before moving to a stronger policy.

If the message uses a similar domain or only copies a person's display name, DMARC for your domain cannot directly prevent it. RFC 9989 explicitly limits DMARC's direct protection to specific forms of exact-domain spoofing.

If a message came from a legitimate but compromised mailbox, it may authenticate successfully. A DMARC pass validates authorized use of the author domain for that message. It does not make a claim about the message's safety, content, or the account holder's intent. Investigate suspected account compromise through the affected mail system and identity provider.

For a recipient, treat an unexpected request for money, credentials, or sensitive information as suspicious even when the sender name looks familiar. Google's phishing guidance advises people to avoid interacting with suspicious requests and verify through an established, independent contact method.

Worked example: what DMARC can establish

This illustrative example shows a message claiming to be from yourdomain.com. Do not copy these values into a production configuration. Your sending service generates the real authentication details.

From: Billing <billing@yourdomain.com>
Authentication-Results: receiver.example;
  spf=fail smtp.mailfrom=mailer.example;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

The message can pass DMARC because DKIM passes with header.d=yourdomain.com, which aligns with the visible From: domain. The failed SPF result does not by itself make DMARC fail when aligned DKIM passes.

Authentication-Results is a receiver-added field that records authentication assessments. RFC 8601 defines its syntax and trust model: use the result added by the receiving system you trust, not a similarly named header injected earlier in transit.

Use this decision rule:

• An exact visible From: domain plus an aligned SPF or DKIM pass means DMARC can pass.
• An exact visible From: domain with no aligned SPF or DKIM pass means DMARC fails when the receiver evaluates DMARC.
• A DMARC failure can trigger the domain owner's published request, but it does not prove every receiver rejected the message.
• A passing result does not rule out a compromised authorized sender.

What to check next

Start with the evidence you actually possess.

If you are a domain owner, inspect the public DMARC record for the exact domain used in the visible From: field. Then verify each production sending path in four layers:

• DNS: query the authoritative DNS service and a public resolver for the intended SPF, DKIM, and DMARC records.
• Vendor: confirm that each sending service shows its domain authentication as complete.
• Message: send a real message through each production path and inspect the trusted receiver's Authentication-Results.
• DMARC: review aggregate reports after they accumulate to find sources and alignment failures.

If you received a suspicious message, preserve it for your security team or report it through your mail provider. Do not reply, open attachments, or use the message's contact details to verify it. If the message appears to come from a known contact, use an existing phone number, chat channel, or address book entry instead.

A public email security score check can help you inspect exposed domain controls. It cannot establish the production sending path, a receiver's private filtering decision, or whether a particular message was spoofed.

Review the broader email security controls

Stopping sender spoofs requires more than a published record. Use the email threats learning hub to place DMARC, SPF, DKIM, user reporting, and account security in the same operating plan, and what an email security gateway is for where an inbound product fits alongside them.

Check your email security score

A guide or public score cannot prove that every sender is aligned, repair a compromised mailbox, or guarantee inbox placement.