DMARC forwarding and policy overrides explained

Email forwarding is the most common reason for unexpected DMARC failures. Understanding how it works helps you avoid blocking legitimate mail when you enforce your DMARC policy.

Why forwarding breaks authentication

When someone sets up email forwarding (e.g., old@company.com forwards to personal@gmail.com), the forwarding server creates a new SMTP connection to deliver the message. This breaks SPF because:

• SPF checks the connecting server's IP
• The forwarding server's IP isn't in your SPF record
• SPF was designed for direct delivery, not forwarded mail

DKIM usually survives

Unlike SPF, DKIM signatures are part of the message itself. If the forwarding server doesn't modify the message, the DKIM signature remains valid. This is why DKIM is the more reliable authentication method for forwarded mail.

Policy overrides

DMARC reports sometimes show that a message failed authentication but was delivered anyway. This happens because receivers can apply local policy overrides:

• Forwarding detected — the receiver recognizes the message was forwarded and delivers it despite SPF failure
• Mailing list — the receiver knows the message came from a mailing list and adjusts accordingly
• Trusted forwarder — the forwarding server is on the receiver's trusted list
• Local policy — the receiver's spam filter or policy engine overrides the DMARC disposition

These overrides are at the receiver's discretion — you can't control them. They explain why some failing messages still get delivered.

What this means for enforcement

• Don't panic about forwarding failures in p=none mode — they're expected
• When moving to p=quarantine or p=reject, some forwarded mail will be affected
• Ensure DKIM is set up for all your senders — it's the best defense against forwarding-related failures
• Consider that some receivers will override your policy for forwarded mail — this is normal and generally helpful

ARC (Authenticated Received Chain)

ARC is a newer standard that preserves authentication results across forwarding hops. When a trusted forwarder adds ARC headers, the final receiver can verify that the original message passed authentication before forwarding. Major providers (Google, Microsoft) support ARC, but coverage is not universal.