Blog · Dmarc
What Causes Forwarded Email to Fail DMARC (And What to Do About It)
Forwarded emails frequently fail DMARC validation -- even when the original sender has perfectly configured SPF, DKIM, and a valid DMARC record. If you have ever seen DMARC failures in your aggregate reports for mail you do not recognize, forwarded messages are a common culprit. Here is exactly why it happens and what you can do about it.
Why Forwarded Email Fails DMARC
DMARC requires alignment between two things that are easy to confuse: the envelope sender (the address your mail server uses during SMTP delivery, checked against SPF) and the From header (the address your email client displays, which is what DMARC checks for alignment).
When a forwarding server receives your message and forwards it to the final recipient, the forwarding server becomes the new envelope sender. The original SPF check no longer applies. From the final recipient's mail server perspective, the connecting server is the forwarding service, not your original sender -- and the forwarding service is almost certainly not listed in your SPF record.
This breaks SPF at the forwarding step.
DKIM is more complicated. A DKIM signature is attached to the message by the original sending server and covers the exact message content and headers. Whether that signature survives forwarding depends on what the forwarding server does:
- Some forwarders modify the message body or headers (adding list headers, changing the subject line, adding footers). Any modification breaks the original DKIM signature.
- Some forwarders forward the message as-is, preserving the original DKIM signature. In this case, the signature is still valid -- but DMARC alignment still fails. DMARC checks whether the domain in the DKIM signature matches the domain in the From header. A valid
example.comDKIM signature does not help if the forwarding server has re-routed the envelope and the From domain no longer aligns.
The structural problem is this: DMARC was designed to ensure that the organization shown in the From header actually authorized the server that delivered the message. Forwarding routes mail through servers that were not authorized by the original sender. That is not a bug -- it is the intended protection. The side effect is that legitimate forwarded mail fails.
The Three Forwarding Scenarios That Break DMARC
Not all forwarding is the same. Here is how three common scenarios differ.
Simple email redirect. You set up a rule that forwards all mail from work@example.com to personal@gmail.com. The forwarding server is your email provider. SPF breaks because the forwarding server is not in example.com's SPF record. DKIM may survive if the message is forwarded unchanged. Alignment fails because the envelope sender and From header no longer match.
Mailing list re-sending. When you subscribe to a mailing list, the list server receives your message and re-sends it to all subscribers. The list server becomes the envelope sender. Most major list servers (Google Groups, Mailman, Listar) preserve the original From header instead of rewriting it to their own domain. SPF breaks because the list server is not in the original sender's SPF record. DKIM may or may not survive depending on whether the list server modifies the message. Alignment fails.
Email alias services. Services that forward notifications from third-party platforms (Kickstarter, LinkedIn, airline confirmations, retail notifications) typically send from their own servers on behalf of the original service. The envelope sender is the alias service, not the original brand. If the original brand has a strict DMARC policy, these forwarded notifications can fail DMARC at your mail gateway.
What Is ARC and Why It Is Not a Complete Fix
ARC (Authenticated Received Chain) was designed to help forwarded mail survive authentication checks. Each intermediate server in the forwarding chain adds a header recording the authentication results from the previous hop. The idea: when the final recipient's mail server receives the forwarded message, it can see "this message was authenticated as example.com at the first hop, then forwarded through server B, then server C."
Google, Microsoft, and other major mailbox providers look at ARC results when making spam and delivery decisions. However, ARC does not create a DMARC pass. The message still formally fails DMARC alignment. ARC simply gives the receiving server additional context to decide whether to deliver the message anyway. For most forwarding scenarios, ARC helps with delivery but does not fix the underlying authentication failure.
SRS: The Only Real Fix for Forwarding You Control
SRS (Sender Rewriting Scheme) is the only mechanism that makes forwarded mail pass SPF at the next hop. The forwarding server rewrites the envelope sender to use its own domain, so SPF passes for the forwarding step. The original sender information is encoded in a redirect path or stored in a header for bounce handling.
SRS works when you operate the forwarding infrastructure yourself. Postfix, Exim, and other common MTAs can be configured to use SRS. The forwarding service becomes the authorized SPF sender for that delivery, and the original sender information is preserved in a way that allows bounces to be routed back correctly.
SRS does not work when a third-party service handles the forwarding. If Gmail is forwarding your work email to a personal account, you cannot implement SRS on Google's forwarding infrastructure. The failures are upstream of your control.
How to Identify Forwarding Failures in Your DMARC Reports
If you monitor DMARC aggregate reports (via an rua tag in your DMARC record), forwarding failures show up with a recognizable pattern: the From domain in the failure report is a legitimate sender you know, but the envelope sender and connecting IP belong to a forwarding or mailing list server. This is different from actual spoofing, where the From domain is being impersonated without any connection to the sender.
DMARCFlow parses aggregate reports and highlights forwarding-related failures alongside other authentication failures. This matters because forwarded mail failures are not spoofing -- they are an expected side effect of how DMARC was designed. DMARCFlow helps you distinguish between the two so you are not chasing false positives.
When you see unexpected DMARC failures from a known sender, checking whether those failures correspond to forwarding infrastructure rather than spoofing attempts is one of the first things to do. The failure report contains the connecting IP, which you can look up to determine whether it belongs to a known forwarding or mailing list service.
What to Do When Forwarding Is Causing DMARC Failures
The answer depends on who controls the forwarding:
If you operate the forwarder: configure SRS on your forwarding software. Postfix, Exim, and other common MTAs support SRS through external libraries or built-in features.
If a third party forwards mail on your behalf: contact the service and ask whether they implement SRS or ARC for forwarded mail. If they do neither, the failures are structural and may not be fixable without changing services.
If you manage a mailing list: implement ARC to improve delivery, consider switching to a list server that rewrites From headers to its own domain, or use a mailing list service that handles DMARC compatibility automatically.
If you receive forwarded mail and see authentication failures: the problem is upstream. The sending domain's DMARC policy is too strict for the forwarding path being used. You can contact the sender and explain the issue, or route forwarded mail through a service that handles ARC and SRS.
Frequently Asked Questions
Is it normal for forwarded emails to fail DMARC?
Yes. DMARC was designed to prevent spoofing, and forwarding changes the authentication path. Some DMARC failure on forwarded mail is expected.
Does forwarding always break DMARC?
Not always, but it usually does. SPF breaks in most forwarding scenarios because the forwarding server is not in the original sender's SPF record. DKIM can survive if the forwarding server does not modify the message, but alignment still fails because the envelope sender no longer matches the From header domain.
Can you forward mail without breaking DMARC?
SRS is the only mechanism that makes forwarded mail pass SPF for the next hop. ARC helps with delivery but does not create a formal DMARC pass. In practice, most forwarding scenarios cause at least one authentication mechanism to fail DMARC alignment.
Does DMARCFlow show forwarding-related DMARC failures?
Yes. DMARCFlow parses the auth results in DMARC aggregate reports and can flag when SPF or DKIM failures correspond to forwarding patterns rather than actual spoofing attempts. This distinction matters for triaging DMARC reports correctly.