How email forwarding can break DMARC

You’ve got a list of all the sources you’re sending from, and you’ve made sure they are all set up with DKIM and SPF. So why aren’t you seeing 100% alignment when your DMARC report comes through?

Here is how you might first spot the problem. In this screenshot from DMARC Digests, the 'Health' section gives you a quick overview of how each sending source has been categorised: a green tick is a known source, a green arrow pointing towards the right is a forward, and a red x is unknown.

As a sender, you can be pretty sure you set everything up correctly, but then your report shows that SPF didn’t pass and the Return-Path header domain doesn’t match the From domain. 

The likely culprit here is forwarding.
...are you ready to go down this rabbit hole with us?  

How forwarding affects DKIM and SPF #

Emails are forwarded all the time, and when this happens, sender and header information doesn’t always get updated accordingly, which in turn has a different impact on DKIM and SPF authentication.

• DKIM authentication verifies that the message itself hasn’t been altered in transit; that means it’s usually able to withstand forwarding, and you won’t see it break so much as long as the content and certain mail headers [such as Subject, From, To, Date] are preserved. If not, the DKIM signature becomes invalid.

• SPF verifies the mailserver’s sending IPs and domains, so 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.
  
  (Remember: SPF is a way for domain owners to authorize which hosts (IPs) can use their domain in the Return-Path for outgoing email. When forwarding a message, you're telling your own mail host to send to a new recipient that the original sender didn't intend to deliver to. Since you're now responsible for bounces and other delivery issues to this new recipient, your mailserver should re-write the Return-Path to use your own domain—but if your host/IP tries to use the same Return-Path address as the original sender, SPF for that domain won't validate that.)

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 Google’s quirks that can result in alignment issues.

What can you, as a sender, 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 caused by forwarding.

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: if one breaks due to a forward, the message still passes DMARC.

The other good news is that many receivers are clever and can identify forwarded emails—and deliver them even if DMARC fails.

To make that happen, receivers such as Gmail and Outlook can perform what we call a“policy override”. Let’s say 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 DMARC alignment.

In other words: If an inbox provider knows that an email was forwarded, they might ignore your DMARC rules and deliver your emails anyway. If you’re using DMARC Digests, we’ll display policy overrides like this:

In the example above, you can see that Google overrode postmarkapp.com’s reject policy, which would have resulted in the messages not being delivered at all.

Because of ARC*, Google was able to see that these messages were forwarded, so it instead quarantined them—which usually means the messages were sent to the recipient’s quarantine/spam folder.

*Mailbox providers have an easier time spotting forwarded emails thanks to another clever email authentication standard: 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.