Why does forwarded mail fail DMARC?

When a message is forwarded, a server that is not the sender's passes it on. SPF then fails for the sender's domain, because the sender's SPF record does not list that server. DKIM survives if the forwarder leaves the message as it was, and the mail still passes DMARC. The mail fails when the forwarder changes the message, as many mailing lists do, or when the sender never signed it with DKIM for its own domain. So two people can fix it: the sender, by signing every message with DKIM, and whoever runs the forwarding address, by leaving the messages unchanged.

What happens to a forwarded message

Say you send an invoice from you@example.com to info@customer.example, and that address forwards everything to a mailbox at Gmail. Gmail receives the message from the forwarding server, not from yours.

• SPF checks whether the server that delivered the message may send for the domain in the envelope sender, the bounce domain. The forwarding server is not in your SPF record, so SPF fails. A forwarder that rewrites the envelope sender to its own domain makes SPF pass, but for its domain, not yours, so DMARC cannot count it.
• DKIM is a signature inside the message, so it travels with it, and it still verifies when the signed parts arrive unchanged. Google lists what breaks it on the way: changing the MIME boundaries, the subject or the body, re-encoding the message, and changing headers the signature covers, such as To, Cc, Date and Message-ID.

DMARC passes when SPF or DKIM passes for your domain. After a forward, only DKIM can. Microsoft says the same about Microsoft 365's own forwarding: it changes the envelope sender, and DKIM survives if the body is not modified.

What happens to a message that fails depends on your policy. Under p=none nothing changes. Under p=quarantine or p=reject, forwarded mail that fails may land in spam or be refused with a bounce. What does my bounce message mean? explains the codes. Cloudflare says so about its own forwarding service: "Due to the nature of email forwarding, restrictive DMARC policies might make forwarded emails fail to be delivered."

If you send the mail

You cannot list in your SPF record every server that might forward your mail. DKIM is the part you control.

• Sign every source with DKIM for your own domain. Each service that sends as your domain needs your domain in its DKIM signature, not its own: custom DKIM. Mail that passes on SPF alone passes DMARC until someone forwards it. Set up DKIM for a sending service has the steps.
• Expect some mailing-list mail to fail. A list that adds a footer or tags the subject breaks DKIM, and nothing on your side changes that. A mailbox provider that recognises list mail may deliver it anyway and say so in its report.

What it looks like in your reports

A DMARC report shows forwarded mail in two ways. When DKIM survived, the row passes DMARC with SPF failed. When both failed, the mailbox provider may deliver the message anyway and add the reason to the row:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>trusted_forwarder</type>
  </reason>
</policy_evaluated>

RFC 9990 names two reasons that fit: trusted_forwarder for a forwarder the mailbox provider knows, and mailing_list. Reports in the older RFC 7489 format may also say forwarded.

Mailmoni reads these rows for you. A source whose DKIM passes while SPF fails gets a sentence that names forwarding as one cause. A row with one of these reasons gets a sentence saying the mail was forwarded, or came through a list, and that there is nothing to fix on your side. Forwarded and mailing-list mail fails DMARC shows each sentence. Forwarded mail does not have to hold back a stricter policy either: the readiness rule counts a source only when it carries enough of your mail.

If you run the forwarding address

You may run one without thinking of it: a work address that forwards to a personal mailbox, an alias at your domain host, or a routing service such as Cloudflare Email Routing. The mail you forward comes from other people's domains, and their DMARC policies decide what happens to it. Google's best practices for forwarding email to Gmail name what you can change:

1. Leave the message as it arrived. No footer, no tag in the subject, no re-encoding. The sender's DKIM signature stays valid, and that signature is what carries forwarded mail through DMARC.
2. Change the envelope sender to your forwarding domain, and list your forwarding servers in that domain's SPF record. The Sender Rewriting Scheme (SRS) does this. Cloudflare's Email Routing works this way and leaves the From header as it was. SPF then passes at the destination, for your domain rather than the sender's, so DMARC still rests on the sender's DKIM.
3. Say that the message was forwarded, with an X-Forwarded-For: or X-Forwarded-To: header.
4. Stop spam before you forward it. Google warns that if recipients mark forwarded messages from your domain as spam, future messages from your domain are more likely to be marked as spam too.

Some forwarders also add ARC (Authenticated Received Chain) headers. In Cloudflare's words, ARC "allows intermediate email servers, such as forwarders, to attach a record of the original authentication results". The receiving side decides whether to trust them. If the mail is forwarded into Microsoft 365, its admin can add the forwarding service as a trusted ARC sealer, which Microsoft calls the preferred way to accept legitimate mail that fails DMARC.

None of this rescues mail that the sender never signed with DKIM for its own domain. That mail fails at every forwarder, and only the sender can change it. Point them to the sender's part of this guide.

If your forwarding service lets you change none of this, add the original mailbox to your mail app and read it there instead of forwarding it. Mail that is not forwarded does not meet the problem.