All Collections
Email Service Providers FAQ
Forwarders and Mailing Lists
Problems You May See Due to Forwarders and What To Do
Problems You May See Due to Forwarders and What To Do

General issues regarding email forwarders and how to handle them

Updated over a week ago


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

What Is A Forwarder?

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:

  • A server that hosts a mailing list. Messages are addressed to the list, and the mailing list server forwards a copy of the message to every list subscriber's mailbox provider.

  • User accounts that are configured by rule to automatically forward the message to another mailbox controlled by the mailbox holder. While there are many different permutations of this sub-class of forwarder, three of the most frequently seen are:

    • College alumni addresses, such as [email protected] which forwards automatically to [email protected]

    • Anonymous mailing services, used by people who don't want to provide their real email address in sign up forms

    • Regular mailbox holders who control two or more mailboxes and want all mail from one automatically forwarded to another.

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

How Can Forwarders Present Challenges for 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.

Forwarders and SPF

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.

Forwarders and DKIM

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.

What Can Be Done to Prevent DMARC Failures with Forwarders?

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.

DKIM Sign All Your Email Using Your Domain

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.

Ask The Forwarder To Implement ARC

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:

  • Server A generates a message and passes it to intermediary B

  • B performs SPF, DKIM, and DMARC checks on the message (all of which presumably pass) and records the results, along with the domains checked for each, in a specific set of headers in the message.

  • B then forwards the message with the new header to C

  • C performs SPF, DKIM, and DMARC checks on the message. If DMARC still passes, great, but if all fail, C can then look for an ARC header set

  • If C finds an ARC header set and trusts B to record correct information in the header set, then C can treat the message as if the authentication checks still passed, based on B's say-so, rather than C's own results.

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.

Ask The Mailing List Administrator To Rewrite The From Header

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.

Stop At "p=quarantine"

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.

Did this answer your question?