Key takeaways
- Forwarding almost always breaks SPF, because the forwarding server is not in your SPF record.
- DKIM usually survives simple forwarding, which is why DKIM alignment is essential.
- Mailing lists that change the subject or add footers can break DKIM too.
- ARC lets trusted intermediaries pass on original authentication results.
- Make sure DKIM is aligned for every stream before moving DMARC to reject.
In this guide
- The forwarding problem in one picture
- Why SPF cannot survive forwarding
- When DKIM breaks too
- How this shows up in DMARC reports
- How to protect forwarded mail
- What mailing lists do about DMARC
- Forwarding versus spoofing: how to tell them apart
- Common forwarding scenarios and outcomes
- What to tell subscribers who miss emails
- How receivers use ARC in practice
- Checklist before moving to p=reject
- Frequently asked questions
The forwarding problem in one picture
Imagine you send a newsletter to anna@university.example. Anna set her university address to forward everything to her personal Gmail. Here is what happens:
- Your platform delivers the email to the university's mail server. SPF and DKIM pass. DMARC passes.
- The university server forwards the message to Gmail. Now the server connecting to Gmail belongs to the university, not to your platform.
- Gmail checks SPF against your domain. The university's server is not in your SPF record. SPF fails.
- Gmail checks DKIM. If the message was not modified, your signature is still valid. DKIM passes, and if it is aligned with your From domain, DMARC passes.
That last step is the whole story. Forwarding almost always breaks SPF. Whether your email survives depends on DKIM.
Why SPF cannot survive forwarding
SPF checks the IP address of the server that connects to the receiver, against the list of servers authorized by the domain in the envelope sender. A forwarder is a new server in the chain. You cannot list every forwarder in the world in your SPF record, and you should not try.
Some forwarders use SRS (Sender Rewriting Scheme), which rewrites the envelope sender to the forwarder's own domain so that SPF passes for the forwarder. That helps the forwarder's reputation, but it does not make SPF align with your From domain. For DMARC, SPF is still not aligned.
When DKIM breaks too
Simple forwarding keeps the message intact, so DKIM survives. Problems start when an intermediary changes the message:
| Intermediary action | Effect on DKIM | Typical example |
|---|---|---|
| Forwards without changes | DKIM still passes | Personal auto-forward, alias services |
| Adds a tag to the subject line | DKIM fails (subject is signed) | Mailing lists adding "[List name]" |
| Adds a footer to the body | DKIM fails (body hash changes) | Discussion lists adding unsubscribe text |
| Rewrites links or attachments | DKIM fails | Some security gateways |
| Rewrites the From address | DMARC evaluated for the list's domain instead | Mailing lists with DMARC mitigation |
When both SPF and DKIM fail, DMARC fails. If your policy is p=reject, the final receiver may reject the message, even though you sent it legitimately.
How this shows up in DMARC reports
In your aggregate reports, forwarding looks like this: an IP address belonging to a university, an internet provider or a mailing list service, a small number of messages, SPF failing, and DKIM usually passing. When DKIM also fails on these sources, check whether they are mailing lists that modify messages. My guide on reading DMARC reports shows how to sort these sources from real spoofing.
Many small sources, SPF fail, DKIM pass: forwarding, nothing to do. Unknown sources, SPF fail, DKIM fail, and your domain in the From: either a modifying mailing list or spoofing. Look up the IP owner to decide.
How to protect forwarded mail
1. Make DKIM aligned on every stream
This is by far the most important step. Every service that sends with your domain must sign with your domain (d=yourbrand.com), not only with its own. If your marketing platform signs only with its own domain, forwarded newsletters will fail DMARC. See how to find and check your DKIM selector to verify each sender.
2. Keep emails stable in transit
You cannot control what mailing lists do, but you can avoid things that encourage modification, such as attachments that security gateways tend to rewrite. For newsletters, this is rarely an issue.
3. Prefer ~all over -all on sending domains
With -all, some receivers reject a forwarded message on the SPF result alone, before checking DKIM. With ~all, they continue to DKIM and DMARC. Details in SPF softfail vs hardfail.
4. Benefit from ARC
ARC (Authenticated Received Chain) lets an intermediary record the authentication results it saw when the message arrived, and sign that record. The final receiver can then decide to trust those results if it trusts the intermediary. Gmail, Microsoft and many large mailing list services support ARC. As a sender, you do not configure anything: ARC is added by intermediaries. It is one more reason why mail with solid authentication at the start survives better.
5. Tighten DMARC gradually
Move from p=none to quarantine and then reject only after checking that forwarded mail mostly passes through DKIM. You can use pct= to apply the policy to a share of mail first. Enforcement is also needed for BIMI.
What mailing lists do about DMARC
Discussion lists face a real problem: when a member with a strict DMARC domain posts, the list redistributes the message with modifications, and receivers may reject it. Most modern list software handles this with one of two methods:
- From rewriting: the From address becomes the list's address, for example "Anna via List Name", so DMARC is evaluated for the list's domain.
- No modification: the list stops adding subject tags and footers, so the original DKIM signature survives.
If your team posts to industry mailing lists and messages get lost after you enforced DMARC, this is usually the reason. Ask the list administrator which method they use.
Forwarding versus spoofing: how to tell them apart
| Signal | Probably forwarding | Probably spoofing |
|---|---|---|
| Source IP owner | University, ISP, known mail provider, list service | Unrelated hosting, random networks |
| DKIM result | Pass with your domain | Fail or missing |
| Volume pattern | Small, steady, follows your campaigns | Bursts unrelated to your sends |
| Geography | Matches your audience | Often unrelated to your audience |
Common forwarding scenarios and outcomes
| Scenario | SPF | DKIM | DMARC (with aligned DKIM) |
|---|---|---|---|
| Subscriber forwards old work address to Gmail | Fail | Pass | Pass |
| Alumni address forwarding to a personal mailbox | Fail | Pass | Pass |
| Discussion list adds "[List]" to the subject | Fail | Fail | Fail, unless ARC is trusted or From is rewritten |
| Security gateway rewrites links | Pass or fail | Often fail | Depends on the gateway; many handle it internally |
| Alias service (privacy relay) | Fail or rewritten | Pass | Pass |
The table shows why DKIM alignment is the single most important protection. Without it, every row would end in a DMARC failure.
What to tell subscribers who miss emails
If a subscriber says your emails stopped arriving after you enforced DMARC, ask two questions: does their address forward to another mailbox, and do they receive your emails through a mailing list? If yes, ask them to subscribe with their final address directly. It is the simplest fix, and it improves engagement data too.
How receivers use ARC in practice
When a message arrives with ARC headers, the receiver checks the chain of signatures left by each intermediary. If the chain is valid and the receiver trusts the intermediary that added it, it can use the authentication results recorded at the first hop, when your message still passed SPF and DKIM. If the intermediary is unknown or the chain is broken, ARC is ignored and normal DMARC evaluation applies.
ARC therefore helps most with large, well-known intermediaries such as major mailing list services and mailbox providers. It is not a guarantee, which is why your own DKIM alignment remains the foundation.
Checklist before moving to p=reject
- Every legitimate sender signs DKIM with your domain
- DMARC reports show forwarders mostly passing through DKIM
- No important mailing list modifies your messages without From rewriting
- SPF ends with
~allon main sending domains - Quarantine tested for a few weeks before reject
- Bounce reports monitored for 550 5.7.26 errors after each change
Forwarding failures are not a reason to avoid DMARC enforcement. They are a reason to make DKIM bulletproof first. For the bigger picture, see SPF, DKIM and DMARC explained.
Frequently asked questions
Why does forwarding break SPF?
SPF checks the server that connects to the receiver. After forwarding, that server belongs to the forwarder, not to you, so it is not in your SPF record.
Does DKIM survive forwarding?
Yes, as long as the forwarder does not change the signed parts of the message. Simple forwarding keeps DKIM intact.
What is ARC?
Authenticated Received Chain is a standard that lets intermediaries such as mailing lists record the authentication results they saw, so the final receiver can take them into account.
What is SRS?
Sender Rewriting Scheme rewrites the envelope sender during forwarding so SPF can pass for the forwarder. It does not create DMARC alignment for your domain.
Should I avoid p=reject because of forwarding?
No, but prepare for it. With DKIM aligned on all your streams, most forwarded mail still passes DMARC. Read your reports first, then tighten gradually.
