How do email forwarding and DMARC policies affect email delivery and reporting?

Key findings

• DMARC reports: They provide information on emails received with your domain in the From: address that were not authenticated by you, including those broken by forwarding.
• Authentication breakdown: Email forwarding often breaks authentication, leading to unauthenticated mail appearing in DMARC reports. This is a common and expected occurrence.
• Vanity domains: Users forwarding emails from vanity domains (e.g., to Gmail, Yahoo, Outlook accounts) frequently cause DMARC authentication failures.
• Policy impact: A p=none DMARC policy typically does not affect mail delivery, but stricter policies like p=quarantine or p=reject would prevent delivery of unauthenticated forwarded emails.
• Internal vs. forwarded mail: Small numbers of your sending IPs in DMARC reports might indicate authentication issues, whereas forwarded mail will show the forwarder's IP.

Key considerations

• Monitoring DMARC reports: Regularly review your DMARC aggregate reports to understand how your emails are being processed, especially noting instances of authentication failures due to forwarding. This data is critical before deciding to enforce DMARC.
• Policy adjustment: Start with a p=none policy to gather data without impacting delivery. Only gradually transition to p=quarantine or p=reject once you have a clear understanding of your legitimate email flows and any potential forwarding issues. Learn more about safely transitioning your DMARC policy.
• Authentication alignment: Aim for DMARC-aligned authentication where the 822.From, 821.From, and DKIM d= domains are all aligned. This best practice minimizes legitimate DMARC failures, even if not strictly required for a p=none policy. For more, see the DuoCircle guide on DMARC and deliverability.
• Distinguishing issues: Learn to differentiate between authentication failures due to legitimate forwarding and those caused by misconfiguration or malicious spoofing.

Key opinions

• Initial confusion: Marketers frequently express confusion when their DMARC reports show unknown IPs and domains, often realizing later these relate to customer forwarding.
• DMARC reports clarify: The reports become clearer once the impact of email forwarding on authentication failures is understood.
• Low authenticated volume: It's common for marketers to see a surprisingly low number of their own sending IPs in DMARC reports, indicating that much of their legitimate traffic might be forwarded and failing authentication checks in transit.
• Stricter policies and forwarding: There is a general concern that stricter DMARC policies could prevent forwarded newsletters from reaching inboxes.
• Header domain confusion: Some marketers suspect that differing 5321.From and 5322.From addresses might confuse spam filters, impacting deliverability.

Key considerations

• Understanding DMARC reports: Marketers need to effectively interpret DMARC reports to identify legitimate forwarding activities versus potential spam or phishing.
• Policy choice: While a p=none policy offers flexibility for forwarded emails, marketers should still strive for better DMARC alignment.
• Impact on internal mail: Consider how a stricter DMARC policy might affect internal email deliverability and G Suite aliases, which often involve forwarding.
• Balancing security and forwarding: A domain owner needs to weigh the benefits of DMARC enforcement against the expected failures from legitimate forwarding, as noted by Amazon SES.

Key opinions

• DMARC report purpose: The primary goal of DMARC reports is to inform you about emails using your domain in the From: address that did not pass your specified authentication (SPF, DKIM) checks.
• Common report content: A significant portion of DMARC report content for correctly authenticated senders will be either legitimate mail whose authentication was broken in transit (e.g., by forwarding) or malicious spoofing.
• Forwarding breaks authentication: Various forms of email forwarding commonly break authentication, leading to these forwarded messages appearing in DMARC reports as unauthenticated.
• Vanity domain forwarding: Users forwarding emails from custom (vanity) domains to popular webmail accounts (Yahoo, Gmail, Outlook) often results in broken authentication, making this a normal occurrence in reports.
• IP address significance: If your own sending IP appears in a DMARC report as unauthenticated, it indicates an issue with your own authentication setup. If authentication breaks in transit (e.g., due to forwarding), the report will show the IP of the forwarder.
• Policy enforcement: Switching from p=none to p=quarantine or p=reject would mean that unauthenticated forwarded emails currently appearing in reports would no longer be delivered.
• DMARC alignment: Achieving DMARC-aligned authentication (where 822.From, 821.From, and DKIM d= are in the same domain) is aspirational and beneficial, but not a mandatory requirement as long as you're not enforcing a strict DMARC policy.

Key considerations

• Data collection with p=none: Utilize a p=none DMARC policy initially to gather crucial information on how your emails are being handled, including how forwarding affects authentication, before implementing a more restrictive policy.
• Troubleshooting internal issues: If your legitimate sending IPs appear as unauthenticated in DMARC reports, prioritize investigating your own SPF and DKIM signing processes, as this suggests a configuration issue on your end. For troubleshooting, refer to how to troubleshoot DMARC failures.
• Foreseeing policy impact: Be aware that moving to p=quarantine or p=reject will likely result in legitimate forwarded emails failing delivery or going to spam, which is an expected outcome of DMARC enforcement.
• Spam filter interaction: Experts generally doubt that differing 5321.From and 5322.From headers directly confuse spam filters, implying other factors are more influential in spam placement. This is contrary to some marketers' beliefs, as discussed by SpamResource.

Key findings

• DMARC and forwarding: Email forwarding can significantly impact DMARC policies, frequently leading to challenges in email deliverability and authentication failures, as noted by GoDMARC.
• Authentication breakdown reasons: The primary reason for DMARC failures with forwarding is the mismatch that occurs when the forwarding server alters the email, causing SPF and DKIM checks to fail alignment, as documented by 101domain.
• Policy effect on delivery: If a DMARC policy is set to reject and an email fails DMARC (e.g., due to forwarding), the recipient's server will not deliver the email, according to DuoCircle.
• DMARC report purpose: DMARC reporting involves tracking how emails sent from your domain are handled by recipient servers, providing insight into both legitimate and unauthorized uses of your domain, as explained by DuoCircle.
• Other deliverability factors: Factors beyond DMARC configuration, such as mistyping email addresses, spam filtering, and sender reputation, can also affect email delivery, according to the NSF.

Key considerations

• Anticipating forwarding failures: Email forwarding is an expected source of failures visible in DMARC aggregate reports. Domain owners must account for this when setting DMARC policies, as advised by Amazon SES.
• Strategic policy implementation: It is crucial to configure DMARC policies to allow for forwarded emails if this is a common practice for your users, particularly when moving to enforcement. IT Supply Chain offers insights.
• Balancing security and deliverability: DMARC helps prevent phishing, but its strictness can inadvertently cause delivery issues for legitimate forwarded mail, requiring careful balancing during policy configuration.
• Holistic view: Beyond DMARC, a comprehensive approach to email security includes understanding DMARC's role alongside SPF and DKIM, which are key components of a robust email security solution, as highlighted by Bitsight.