Forwarders present a special set of challenges for email authentication. In this article, we'll discuss some common problems and offer possible solutions.

Before we talk about the problems that forwarders can cause for DMARC, it's important to understand what we mean when we use the term "forwarder".

While it's true that a person reading an email and then passing it along to a friend or colleague is forwarding the message, it's not this kind of forwarding that can cause issues with DMARC. Instead, when we say "forwarder" we're referring to an automated process where a message routes through at least one intermediary host before reaching its final destination. Common examples of such forwarders are:

The point with all of these is that the forwarding must be automated in order to potentially cause issues with DMARC.

DMARC relies on two underlying authentication protocols - SPF and DKIM. A DMARC pass verdict requires that only one of the two pass, but that the passing protocol(s) also possess a quality known as "domain alignment", where the checked domain is similar, or in some cases identical, to the domain in the visible From header. Unfortunately, forwarders can cause one or both of these checks to fail for mail that would easily pass if it were routed directly from its source to its destination.

SPF is what's known as a path-based authentication protocol. With SPF, a domain owner declares the server and networks that are authorized to send mail using that domain. When the mail arrives at its destination, the SPF record of the domain in the Return-Path is checked, and if the contents of that record authorize the connecting IP to use the domain, then SPF passes for that message.

This works just fine for direct mail, but problems can occur when server A originates a message that passes through intermediary B on its way to destination C. When that message arrives at destination C, the connecting IP address will be that of intermediary B. Since it's quite likely that the domain owner will only have authorized server A to use its domain, intermediary B's IP address won't be found in the domain's SPF record, and so SPF will fail.

Unlike SPF, DKIM is a content-based authentication protocol. When a message is said to have passed DKIM validation checks, that means that the validator has been able to ascertain that the message was not altered between the time that the DKIM-Signature header was inserted and the message made it to its destination. While it's less common for forwarders to break DKIM than for them to break SPF, it can happen; all it takes is any changes to the message content.

The most common case of a forwarder altering a message and thus causing DKIM validation to fail is with mailing lists, many of which add a footer or other information about the list, how to unsubscribe, etc., to each message. Other forwarders might alter the subject line or similar, but the key point here is that any changes made to the text of the message before forwarding it to its destination can cause DKIM validation to fail.

While the problems that forwarders can cause for SPF and DKIM, and by extension DMARC, are well known and understood, there is at present no silver bullet solution to prevent all of them. There are strategies to mitigate some of the risks, and there are technologies under development to deal with the problem as a whole, but those technologies are not yet widely adopted. Nevertheless, we'll discuss what options are available and offer our hope that one or more of them will solve the problem for you.

Since SPF is much more likely to break due to forwarding than DKIM, making sure all of your mail is DKIM signed is the easiest way to mitigate most risk with forwarding. When it's DKIM signed with your domain and reaches its destination, it's still got a good chance of getting a DMARC pass, especially if the message isn't altered by the forwarder.

The Authenticated Received Chain (ARC) is an email protocol designed with the problem of forwarding in mind. ARC provides a way for an intermediary host to record results of authentication checks it performed on a message, and those results can then be inspected at the next hop, especially if that hop's checks result in failures for SPF or DKIM.

ARC is designed to work like this:

ARC is not yet widely implemented, in part because the problem of deciding whether or not to trust ARC header sets is not easily solved, but the email community, including Valimail, is hard at work trying to solve this problem.

Since DMARC is keyed to the domain in the visible From header in messages, and since mailing lists can cause DMARC to fail in the cases where they function as forwarders who alter message contents, a solution to the problem is for the mailing list administrator to configure the list to use the list's address as the visible From header rather than that of the original poster. Not all mailing list administrators will be receptive to this idea, since their subscribers might prefer to see the poster as the visible From, chiefly because it helps the subscriber decide whether or not to read a given post, but it's worth asking nonetheless. You can also point the mailing list admin to ARC if they're unwilling to do the header rewriting.

It's worth noting here that there are techniques for forwarders to use to rewrite the Return-Path header too, changing the domain with the goal of such rewriting to be getting an SPF pass at the next hop. While the SPF pass is nice, because it changes the domain, it doesn't get us any closer to a DMARC pass, since DMARC requires not only a pass but also domain alignment between the Return-Path domain and the visible From domain.

While it goes against Valimail's general philosophy on such matters, until there's a foolproof solution to the problem, there will be times when a domain has a significant portion of its mail passing through forwarders and failing authentication checks, with those failed checks causing mail to not be delivered. While what qualifies as "significant" here is in the eye of the domain owner, if none of the other solutions offered above work for you, then making sure your DMARC policy is no stronger than p=quarantine should ensure that DMARC failures don't result in failed deliveries.

Note that with p=quarantine, DMARC failures might still result in some wanted mail being routed to the recipients' spam folders, but at least it'll be accessible to them in ways that they can retrieve it without too much trouble.

While only a relatively small volume of mail is handled by forwarders on a daily basis, depending on your domain's sending profile, authentication that breaks due to forwarding can have a large impact on you. In this article, we've talked about the common causes of forwarding problems and offered some solutions to mitigate the risk. We hope you find them useful should you need them.