Can an Email Be Spoofed When SPF, DKIM, DMARC Pass?

Yes. And it happens more often than most people realize.

The scenario that triggers this question: You have SPF configured correctly. DKIM is signing every outbound message. DMARC is at p=reject. And then someone inside your organization receives an email that appears to come from their own address. The headers show no obvious errors. SPF passes. DKIM passes. The person is alarmed and suspects a breach.

This is not a configuration failure. The records are doing exactly what they are designed to do. The gap is in understanding what they actually validate.

## The Three Sender Addresses Email Authentication Does Not Merge

Most email security documentation treats sender identity as one thing. It is three things, and conflating them is the root cause of most confusion.

The Envelope-From (RFC 5321 Mail From). This is the address the mail transfer protocol uses during the SMTP conversation. It is invisible to most email clients and rarely shown to users. SPF validates this address.

The Header-From (RFC 5322 From). This is the address the recipient sees in their email client as the sender. This is the address users act on. DMARC validates this address.

The DKIM-Signed domain. The domain in the DKIM signature's d= tag. DKIM validates that the signed content was not altered after leaving the sending server. The signing domain does not have to match the Header-From domain.

These three do not automatically refer to the same entity. SPF checks whether the sending server is authorized for the Envelope-From domain. DKIM checks whether the message was signed by the domain in the d= tag and not tampered with. Neither cross-checks whether that domain is allowed to use the Header-From address. That is DMARC's job.

## How DMARC Alignment Works

DMARC adds the step that SPF and DKIM skip individually: it checks whether the authenticated domain actually matches the Header-From domain.

For DMARC to pass, one of the following must be true:

- SPF aligned: The Envelope-From domain matches the Header-From domain, and SPF passes for that domain.

- DKIM aligned: The domain in the DKIM signature's d= tag matches the Header-From domain, and the signature verifies.

If SPF passes for `mailer.servicedomain.com` but the Header-From says `billing.example.com`, there is no alignment and DMARC fails. If DKIM signs `mailer.servicedomain.com` but the Header-From says `billing.example.com`, there is no alignment and DMARC fails.

This is the core design. DMARC is a layer on top of SPF and DKIM that closes the gap between sending infrastructure and the display address. Without alignment checking, an attacker can send mail through any authorized third-party service and use any From address they choose.

## Why Spoofed Emails Still Arrive When Authentication Appears Clean

Here is the most common real-world scenario:

An attacker creates an account on a marketing platform, CRM, survey tool, or productivity app. These services send email on behalf of their customers and control the From address freely. The service's SPF record covers its own infrastructure. Its DKIM key signs the message. SPF passes. DKIM passes.

The attacker sets the Header-From to `ceo@yourcompany.com`. The receiving server processes this and sees: SPF pass for `mailer.servicedomain.com`, DKIM pass for `mailer.servicedomain.com`, DMARC alignment fail because neither the Envelope-From nor the DKIM domain matches `yourcompany.com`.

With p=reject, the message should be blocked.

But many receiving servers do not enforce DMARC strictly. Some exempt categories of bulk senders. Some only apply DMARC checks after other filtering decisions are already made. Some receive high volumes and apply the policy inconsistently. The result is that some fraction of spoofed mail reaches inboxes even when your DMARC policy is correctly set to reject.

This is why aggregate reports matter. They show you the full picture of who is sending mail claiming to be from your domain, including messages that pass individual authentication checks but fail alignment.

## What the Headers Actually Show

When you examine a spoofed message, the authentication headers often look clean at first glance. A typical authentication result block from a receiving server looks like this:

Authentication-Results: mx.example.com;
  dkim=pass header.d=servicedomain.com;
  spf=pass (mailer) smtp.mailfrom=servicedomain.com;
  dmarc=fail (p=reject) header.from=yourcompany.com

The pattern here is specific and instructive: SPF pass, DKIM pass, DMARC fail. The From header shows your domain. The sending infrastructure is the attacker's chosen service.

The SPF pass is correct. That service is authorized to send mail for `servicedomain.com`. The DKIM pass is correct. The message was signed by that service and was not tampered with. The DMARC fail is correct. Neither the Envelope-From domain nor the DKIM domain is aligned with `yourcompany.com`.

The message passed two checks that were designed for a different domain. It failed the check that validates the From address. Whether the receiving server blocked it depends on whether it enforces DMARC failures strictly.

## How to Detect Spoofing of Your Domain

The only reliable method is DMARC aggregate reports. These are XML reports sent by receiving servers to the mailto address in your DMARC record. They show:

which sending IPs are transmitting mail claiming to be from your domain
what SPF, DKIM, and DMARC results each IP produces
the volume of mail from each source
whether aligned failures are appearing at scale

Without aggregate reports, you find out about spoofing when someone inside your organization receives a complaint from a customer or partner. With aggregate reports, you see the pattern before your users do.

This is where DMARCFlow earns its place. DMARCFlow collects aggregate reports from all major receivers, normalizes them, and presents the data by receiver so you can track which platforms are accepting aligned failures from your domain. You can spot a new sending source you do not recognize, or see that a high-volume receiver is silently allowing aligned failures to pass, without manually parsing XML.

The alternative is building your own parsing pipeline for DMARC reports. For most teams, that pipeline never gets built, and the reports sit unread in a mailbox.

## What to Do After You Detect Spoofing

Once you know the sending sources, there are two categories:

Legitimate vendors. A third-party service is sending mail with your From address. Either require them to DKIM-sign on your domain, or require them to use a subdomain you control for From addresses so alignment naturally fails and you can track the volume.

Malicious spoofing. You see spoofing from IPs you cannot identify, and your DMARC policy is at p=reject. The receiving servers are not enforcing your policy. Options include reaching out to those receivers to encourage enforcement, tightening your sending infrastructure to reduce the surface area for spoofing, or moving From addresses to a subdomain that you fully control.

The broader principle is that SPF, DKIM, and DMARC protect the connection between the sending server and the From domain. They do not prevent someone from sending mail through a legitimate service while claiming to be you. Application-layer sender authentication, such as signed commits for code or authenticated routing for sensitive transactions, addresses what email authentication cannot.

## FAQ

Can SPF alone prevent email spoofing?

No. SPF validates the Envelope-From domain and the sending server IP. It does not check or validate the Header-From address that users see in their email client. An attacker can send from an SPF-authorized server and set the From address to any value they choose.

Can DKIM alone prevent email spoofing?

No. DKIM validates that the message content was not altered after signing and that the signing domain authorized the message. The signing domain in the d= tag does not have to match the Header-From domain. An attacker can DKIM-sign a message using their own domain while freely setting the From address to any value.

Does DMARC at p=reject stop all spoofing?

No. DMARC at p=reject instructs receiving servers to reject messages that fail alignment. Many receivers enforce this strictly, but some do not. DMARC dramatically reduces spoofing but does not eliminate it, particularly at receivers that do not fully enforce the policy.

Why did I receive a spoofed email from my own address?

You received mail that appears to come from your address because the sending server was authorized to send mail for the domain it used in the Envelope-From. Your SPF, DKIM, and DMARC records apply to your own sending infrastructure, not to every mailer that sets your domain in the From field. The From field is set by the sending application, not validated by your DNS records.

How do I detect spoofing attempts against my domain?

DMARC aggregate reports show which sending IPs are transmitting mail claiming to be from your domain, including IPs you do not recognize and aligned failures from sources you do control. Without these reports, you typically learn about spoofing only from downstream complaints. DMARCFlow collects and normalizes aggregate reports across all major receivers so you can identify spoofing patterns early, before users report them.