Why Your Domain Can Still Be Spoofed Even With SPF, DKIM, and DMARC

The scenario that confuses every email administrator

You have SPF configured. You have DKIM configured. You have DMARC configured and set to reject. Then someone reports that a forged email appeared to come from your domain. SPF passed. DKIM passed. The email still arrived.

The confusion comes from a common misconception: SPF, DKIM, and DMARC do not all check the same part of an email message. Each protocol protects something different. Understanding which header each one touches is the key to understanding why spoofing can still happen.

Which header each protocol actually checks

SPF validates the MAIL FROM domain, not the From: header.

When a mail server receives a message, it checks SPF against the "MAIL FROM" envelope domain (also called the Return-Path). This is the bounce address. SPF asks: is the connecting server's IP address authorized to send for this envelope domain?

The From: header is a different field entirely. An attacker who connects directly to the destination mail server can put any From: header they want in the message while using their own MAIL FROM domain. SPF will pass because the connecting server is authorized for the attacker's own envelope domain.

DKIM validates message integrity, not sender identity.

DKIM adds a cryptographic signature to specific email headers and the message body. A valid DKIM signature means the signed content was not altered after the message was signed. It does not say anything about whether the From: header belongs to the signer.

An attacker can send an unsigned email with a forged From: header. Or they can strip the DKIM signature from a legitimately signed message and resend it. DKIM validation fails because the signature is missing or altered, not because the From: is forged.

DMARC alignment is the check that actually closes the gap.

DMARC requires that either the SPF-verified MAIL FROM domain or the DKIM-verified signing domain matches the From: header domain. This is the step that SPF and DKIM alone skip. A message fails DMARC when neither the SPF-aligned MAIL FROM nor the DKIM-aligned signing domain matches the From: domain. That is the condition that should block a spoofed email.

How the direct send attack works

The direct send is the most common way domain spoofing succeeds despite all three protocols being configured. Here is the sequence:

1. The attacker sets up a server with SMTP access.
2. The attacker crafts an email with your domain in the From: header. No DKIM signature is added.
3. The attacker connects directly to the destination mail server (MX), bypassing third-party mail relays.
4. The target MX receives the connection from the attacker's server IP. The attacker's server presents its own MAIL FROM domain.
5. SPF check: the attacker's server IP is authorized for the attacker's own MAIL FROM domain. SPF passes.
6. DKIM check: no DKIM signature is present. Result is neutral or none.
7. DMARC check: From: domain does not match the MAIL FROM domain (no SPF alignment). No DKIM signature for the From: domain (no DKIM alignment). DMARC fails.

If your DMARC policy is set to reject, this email gets blocked at the destination. DMARC worked. You only find out it happened if you are receiving and reviewing your DMARC aggregate reports.

Why administrators think DMARC failed when it did not

When a forged email arrives despite DMARC configuration, the cause is almost always one of the following:

DMARC is set to none (p=none). This is the most common reason. Administrators configure DMARC for monitoring, plan to switch to reject later, and then forget to update the policy. With p=none, destination mail servers take no action on DMARC failures. The spoofed email arrives without resistance.

The receiving server does not enforce DMARC. DMARC only works when the destination mail server checks the policy and acts on the result. Many servers do not enforce DMARC, particularly smaller providers or internal mail systems.

The spoofing uses a trusted intermediate. If the attacker compromises a mailing list server, marketing automation platform, or shared MTA that is already authorized by your SPF record, the sending IP is authorized by SPF. If that platform signs with its own DKIM key rather than yours, DKIM alignment fails. DMARC reject should still block it, but only if the policy is reject and the destination enforces it.

How to find direct send spoofing in your DMARC reports

Your DMARC aggregate reports (sent to your RUA address) contain records of every message that reaches a participating destination mail server and triggers a DMARC check. These patterns indicate direct send spoofing:

DMARC failures from IPs you do not recognize. If your own mail servers are your only legitimate senders, any DMARC failure from an unknown IP is a potential spoofing attempt. Group failures by From: domain to identify which of your domains is being targeted.

DKIM "none" combined with SPF "pass" from non-owned IPs. This means the connecting server passed SPF for its own MAIL FROM domain, but no DKIM signature was presented for the From: domain. This is the direct send signature in your reports.

High failure volume from many different source IPs targeting the same From: domain. Mass spoofing campaigns use botnets or large SMTP relay networks. Your DMARC reports will show failures from dozens or hundreds of different source IPs in a short window.

From: domain is yours, MAIL FROM domain is not. This is the clearest indicator. Someone is sending email with your From: header from a server you have not authorized.

DMARCFlow processes these reports automatically and alerts you when new unknown source IPs appear in DMARC failures, when unexpected DKIM results cluster around your domains, or when failure volume spikes for a domain that normally sends cleanly. Instead of parsing XML reports manually, you get structured alerts that surface the patterns above.

What to do if you see evidence of spoofing

Confirm your DMARC policy is set to reject (p=reject) for the affected domain. If it is still set to p=none, update it. p=none gives attackers a free pass and defeats the purpose of having DMARC at all.

Identify the source IPs from your DMARC reports and evaluate whether they belong to any legitimate sending infrastructure you forgot to authorize. Internal mail gateways, legacy MTS systems, and third-party platforms sometimes send from IPs not covered by your SPF record. Fix those configuration gaps so they do not obscure real attacks.

If you confirm active spoofing against your domain, check whether the attack is targeted or part of a mass campaign by looking at the source IP distribution. A small number of IPs suggests a targeted attempt. Hundreds of IPs suggests an automated campaign.

For high-value domains that are regularly spoofed, consider implementing MTA-STS to force recipient servers to use encrypted SMTP connections, which makes direct send attacks harder to execute undetected.

FAQ

Can SPF prevent domain spoofing?

No. SPF validates the MAIL FROM (Return-Path) envelope domain, not the From: header. An attacker can use any From: header while sending from an SPF-authorized server for their own envelope domain.

Does DKIM prevent someone from sending as my domain?

Only if the attacker also has access to a DKIM signing key for your domain. A valid DKIM signature means the signed content was not altered; it does not confirm the From: header belongs to the legitimate sender.

What does direct send spoofing look like in DMARC reports?

Look for DMARC failures where the From: domain is your domain, the source IP is not your own mail server, DKIM result is "none," and the MAIL FROM domain belongs to someone else.

How does DMARC stop direct send spoofing?

DMARC requires the From: domain to align with either the SPF-verified MAIL FROM domain or the DKIM signing domain. Direct send attacks fail this alignment check because the attacker uses their own MAIL FROM and no DKIM signature for the target domain.

My DMARC is set to reject but spoofed email arrived. Why?

The destination mail server may not be enforcing DMARC, or the email may have been sent to a domain that does not participate in DMARC reporting. DMARC only works when the receiving server enforces it.