How forwarding can break DMARC

Ready to go down this rabbit hole? Let’s go! You’ve got a list of all the sources you’re sending from, and you’ve made sure that they are all set up with DKIM and SPF. So when your DMARC report comes through, why aren’t you seeing 100% alignment? Why does it show that the Return-Path header domain doesn’t match the From domain? You’re pretty sure you set everything up correctly. The likely culprit here is forwarding.

How exactly are DKIM and SPF affected?

I’m glad you asked! Emails are forwarded all the time and when this happens, sender/header information doesn't always get updated accordingly. DKIM authentication verifies that the message itself hasn’t been altered in transit. That means it’s usually able to withstand forwarding as long as the content and certain mail headers are preserved. If not, this causes the DKIM signature to become invalid. 

Since SPF verifies the mailserver’s sending IPs and domains, it’s much more common to see SPF break as different mailservers process the message en route. This usually involves the forwarder modifying the Return-Path domain, resulting in SPF becoming unaligned. For emails to be aligned under SPF for DMARC, both the basic SPF check needs to pass and the domains in the From and Return-Path headers must match. Check out our dive into some of the quirks Google has which can result in alignment issues. 

DMARC only requires that either DKIM or SPF pass, not both. This is why it's important (where possible) to have both DKIM and SPF set up as if one breaks due to a forward, the message still passes DMARC

What can you do about this?

You might be wondering, especially if you have a p=quarantine or p=reject DMARC policy, what you can do to stop your legitimate emails going to spam or being blocked because of alignment issues. There isn’t a surefire way to prevent this, but the good news is that DMARC only requires that either DKIM or SPF pass, not both. This is why it's important (where possible) to have both DKIM and SPF set up as if one breaks due to a forward, the message still passes DMARC. 

Receivers such as Gmail and Outlook can also perform what we call a“policy override”.  Let’s say that you have a p=reject policy and DMARC fails due to both DKIM and SPF breaking. When a receiver has some other information available that allows them to validate the message is genuine, they can override your DMARC policy and accept the email, regardless of the DMARC alignment. For forwarded emails, this information is often an ARC result. 

Authenticated Received Chain (or ARC) is a standard that allows authentication results to be added to the message headers when an email is forwarded, so that the end receiver can determine whether the original message was authenticated or not. 

All this chatter about forwarding might have you asking "How can I even be sure that misalignment is because of forwarding and not down to spoofing?" That's a very valid question and we've also written a bit about how you might be able to tell the difference.

p=none sounds a lot easier…

Maybe so, but we believe that everyone's DMARC goal should be to eventually move to a"reject" policy, since it's the single way to ensure only fully authorized mail is ever delivered from your domain. Take the time to identify all your sending sources and ensure they are all fully authenticated first as switching to a"reject" or"quarantine" policy before you've done this will mean some legitimate mail doesn't get delivered.