Can someone spoof my email address even with DMARC?

The short answer

Yes, in one specific, well-defined situation: when someone forwards your mail through their own server and the forwarder re-envelopes the message under their own domain. DMARC cannot prevent this because the forwarded message technically originates from the forwarder, not from your domain. This is not a DMARC vulnerability. It is a known consequence of how email forwarding works.

In every other common scenario, a properly configured p=reject policy stops external spoofing of your domain cold.

What DMARC actually protects

DMARC sits on the receiving side of an email transaction. It checks whether the domain in the RFC 5322 From header (the address users see in their mail client) aligns with the domain that sent the message -- the RFC 5321 Mail From domain, also called the envelope sender.

When a message passes SPF, DKIM, and DMARC alignment, the receiving server has verified three things:

1. The sending server is authorized to send for the envelope sender domain (SPF)

2. The message was signed by the domain's private key and the signature verified (DKIM)

3. The domain in the From header matches at least one of those first two domains (alignment)

If all three pass and your policy is p=reject, a receiver will reject direct spoofed mail -- mail that arrives from an unauthorized server claiming to carry your domain in the From header. This covers the vast majority of impersonation attacks.

Where DMARC has a blind spot: forwarding and re-enveloping

Here is the scenario people run into.

User A at example.com sends an email to User B at gmail.com. User B has their Gmail account set to automatically forward all mail to User C at yahoo.com.

When Gmail receives the original message from example.com, it is a legitimate, properly authenticated message. Gmail then forwards it to Yahoo on behalf of User B. From Yahoo's perspective, Gmail is now the sending server. Gmail's envelope sender domain appears in the RFC 5321 Mail From. The From header still shows example.com, but the envelope is gmail.com.

Yahoo checks SPF for gmail.com -- passes. DKIM for gmail.com -- passes. DMARC alignment: gmail.com (envelope) versus example.com (From header) -- these do not match. DMARC fails.

Yahoo may reject the message or flag it, even though the original sender had full valid authentication. The From header shows example.com because that is where the user wants replies to go. The envelope is gmail.com because Gmail is the new sender.

This is not spoofing in the attack sense. It is a forwarding side effect. But the outcome looks similar: a message with your domain in the From header arrives and appears to come from you, even though you did not send it through your own infrastructure.

The mailing list problem

Mailing lists amplify this. When you subscribe to a mailing list and someone posts to the list, the list server typically repackages the message:

- The original From header is preserved (shows the real sender)

- The list server rewrites the envelope sender to itself (so bounces go to the list, not the original sender)

- The list server may add its own DKIM signature or strip the original one

For the original poster's DMARC to pass through the list, the list server would need to maintain alignment: either re-sign with the original domain's DKIM key, or ensure the From header domain matches the list's own envelope. Most public mailing lists do neither, because maintaining DMARC alignment for thousands of senders is operationally complex.

The result: a genuine email from a real sender, with their real domain in the From header, fails DMARC at the receiver because the mailing list broke the alignment chain. This is a long-standing known problem. RFC 6377 documents it; BCP 194 provides operational guidance. It remains unsolved at scale.

Reply-to manipulation: when the From header is real but the reply goes elsewhere

DMARC does not check the Reply-To header at all. An attacker who compromises an account or sends through a legitimate SMTP server can set the From header to your domain (which passes DMARC because the sending infrastructure is legitimate) while setting the Reply-To to a different address they control.

When the recipient hits reply, their mail client sends to the Reply-To address, not the From address. DMARC never sees this happen -- it only checks what happens at delivery time, not what happens when someone hits reply.

This is technically not spoofing in the DMARC sense. The From header is authentic. The attack works because DMARC was never designed to police reply paths.

What this looks like in practice

Here is a concrete example from a DMARC aggregate report scenario:

You run a p=reject policy. Your daily aggregate report shows a spike in authentication failures -- messages that appear to come from your domain but are failing DMARC alignment. Your first instinct might be: someone is spoofing my domain.

Before treating this as an incident, check the envelope senders in the failure rows. If the envelope senders are gmail.com, yahoo.com, outlook.com, or a known mailing list server, the failures are almost certainly forwarded mail, not spoofing. The From header shows your domain because the original sender used your domain. The envelope shows the forwarding service because that service re-enveloped the message.

This distinction matters. A real spoofing attack shows up as failures from IP addresses you do not recognize, sending for your domain without authorization. Forwarded mail shows up as failures from major consumer mail providers you do recognize.

How to tell the difference between forwarding and actual spoofing

Look at your aggregate report data:

SignalForwardingSpoofing Envelope sender domainMajor consumer provider (gmail.com, yahoo.com, outlook.com)Unknown or self-hosted Sending IPBelongs to the forwarding providerUnaffiliated IP, often in a cloud range Volume patternCorrelates with your own sending patternsSudden spike without obvious cause DKIM result in reportOften none or temperror on forwarded messagesConsistent none

Aggregate reports will never give you full packet-level details, but the envelope sender domain and sending IP in the report are usually enough to classify the majority of failures as forwarding or spoofing.

What actually stops spoofing that DMARC cannot catch

For reply-to manipulation: there is no protocol-level fix. User training is the practical control. Teach users to check the reply-to address when it differs from the From address, especially in high-value conversations involving finance or executive teams.

For forwarding: there is no universal DMARC-level fix for third-party forwarding. Some major forwarders have begun applying best-current-practice rules that attempt to preserve original authentication results, but this behavior is not universal across all providers. If your users rely on consumer mail forwarding, expect to see forwarding failures in your aggregate reports and know how to interpret them.

For mailing lists: the long-term fix is for mailing list operators to implement RFC 8617 (Authenticated Received Chain, ARC), which preserves the original authentication chain through forwarding and list handling. ARC is not yet widely deployed by public mailing lists, but it is the standards-based solution to the problem.

How DMARCFlow helps

DMARCFlow processes aggregate reports and surfaces the forwarding versus spoofing distinction automatically. Rather than manually reviewing failure rows and cross-referencing envelope sender domains, you get a clear breakdown: here are the failures from known forwarding providers, here are the failures from unknown IPs, here is what changed in the last 30 days.

For teams that do not have a dedicated mail operations person, this distinction is the difference between knowing your domain is actually protected and spending time investigating a non-incident.

If you are currently reviewing DMARC reports manually and treating all failures as potential incidents, DMARCFlow can reclassify those incidents correctly and surface only the ones that actually need investigation.

The most direct way to understand what is actually happening with your domain's email authentication is to process a full 30-day aggregate report with DMARCFlow and look at the envelope sender breakdown. That single view tells you more than a month of manual spreadsheet analysis.

---

FAQ

Does p=reject stop all spoofing of my domain?

No. It stops direct spoofing -- mail sent from unauthorized servers claiming your domain in the From header. It does not stop forwarding side effects, mailing list repackaging, or reply-to manipulation.

Why do I see my own domain in the From header of a forwarded email?

Because the original sender used your domain in the From header. When the forwarder re-envelopes the message, the From header is preserved. The From header is not what DMARC checks -- it checks the relationship between the From header and the envelope sender.

Can mailing lists break my DMARC?

Yes. Most mailing lists rewrite the envelope sender to themselves and may strip or replace the original DKIM signature. This breaks DMARC alignment for the original sender. The sender is not being spoofed -- their mail is being forwarded through a system that does not maintain DMARC compatibility.

Does DMARC check the Reply-To header?

No. DMARC does not check Reply-To at all. If someone sends you mail with your domain in the From header and a different address in Reply-To, DMARC will likely pass because the sending infrastructure is legitimate. The attack is in the reply path, not the delivery path.

How do I tell the difference between forwarding and actual spoofing in my aggregate reports?

Check the envelope sender domain. If it is a major consumer provider (gmail.com, yahoo.com, outlook.com) and the sending IP belongs to that provider, it is almost certainly forwarding. If the envelope sender domain is unknown or self-hosted and the sending IP is not affiliated with any known provider, it is more likely spoofing.

What can I do about forwarded mail causing DMARC failures?

Nothing at the protocol level, unless you control the forwarder. At the report analysis level, you can distinguish forwarded mail failures from real spoofing failures automatically using DMARCFlow, so you stop chasing false positives.