Forwarding breaks SPF because the message arrives from the forwarder's IP address, which your SPF record does not list. DKIM usually survives because its signature travels with the message, unless the forwarder changes the signed content. ARC is an experimental protocol that lets intermediaries record what they saw before altering a message.
Why SPF fails on a forward
SPF checks whether the connecting IP is authorized to send for the MAIL FROM domain. When alumni@college.example forwards your message to a personal mailbox, the final receiver sees a connection from the college's server, and that IP is not in your SPF record.
RFC 9989 uses this very example. A bank sends mail to an address that relays to another mailbox. On delivery, the message "will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA", while DKIM signatures "will generally remain valid in these relay situations."
RFC 7208 itself notes that mailing lists and forwarders rewrite or reuse the envelope sender in ways that interact with SPF. Some forwarders rewrite the MAIL FROM so SPF checks the forwarder instead, which helps SPF but breaks DMARC alignment for SPF.
Why DKIM mostly survives
A DKIM signature covers selected headers and the body, and travels in a header. A plain forward leaves both unchanged, so the signature still verifies against your public key in DNS.
It breaks when the intermediary changes what was signed. A mailing list that adds a subject tag or a footer will invalidate the signature. Some lists also rewrite the From header to keep DMARC passing, a workaround RFC 9989 says is now established practice.
What this means for DMARC
DMARC passes if either SPF or DKIM aligns. A forward that breaks SPF but keeps DKIM still passes DMARC. That is why RFC 9989 says domains publishing p=reject must apply valid DKIM signatures and must not rely only on SPF.
So, for every sending service you control:
- Make sure DKIM signs with your domain and aligns.
- Do not depend on SPF alone for important streams.
- Read your aggregate reports for override reasons trusted_forwarder and mailing_list. They show receivers choosing not to penalize known indirect mail.
What ARC adds
Authenticated Received Chain, in RFC 8617, lets each handler add its own authentication assessment to a message, wrapped in a DKIM-like signature. A later receiver can see that the message passed authentication at the first hop before the forwarder changed it, and may choose to trust that. It uses three headers: ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal.
Two cautions. RFC 8617 has Experimental status. And ARC does not oblige a receiver to accept the message. The receiver decides whether to trust the forwarder that sealed the chain. Yahoo's sender page recommends that senders who forward email implement ARC.
If you run a forwarding service or a mailing list, ARC is worth reviewing. If you are a plain sender, DKIM with alignment is your protection.
Quick check
Should I add my forwarders to my SPF record?
No. You cannot list every recipient's forwarding server, and each include costs part of your 10 lookup budget. Rely on aligned DKIM.
Sources
- RFC 7208, Sender Policy Framework
- RFC 8617, The Authenticated Received Chain (ARC) Protocol
- RFC 9989, DMARC
- RFC 9990, DMARC aggregate reporting
- Yahoo Sender Hub, sender requirements
Last reviewed: 19 October 2026.
