Forwarded Emails Going to Spam? Why Forwarding Breaks SPF & DMARC

Why forwarding breaks SPF

SPF lets a domain publish which servers may send its email. When a customer at example.com emails you, their server is on example.com's SPF list, so your mailbox accepts it. When your mailbox then forwards that email to Gmail, Gmail sees it arriving from your provider's server, claiming to be from example.com. Your server is not on example.com's list, so SPF fails.

Google says this plainly in its best practices for forwarding email to Gmail: forwarding can affect authentication, and forwarded messages often fail SPF. That is why it recommends senders always set up DKIM as well.

For background on the three records, see our guide to SPF, DKIM and DMARC for emails going to spam.

Why DMARC fails too, and when it does not

DMARC passes if either SPF or DKIM passes and the domain it checked matches the visible From address. Since forwarding breaks SPF alignment, DKIM becomes the only route. A DKIM signature is a seal over the message headers and body. If the forwarder changes anything covered by the seal, it breaks.

Google lists actions that break DKIM on forwarded mail: changing the body, adding footers or disclaimers, and modifying the Subject or other signed headers such as To, Cc, Date and Message-ID. Mailing list software that adds "List]" to subjects and security gateways that append warnings are common culprits. Our guide to [DKIM signature failures covers the other causes.

SRS and ARC: what they fix and what they do not

Two technical fixes exist. Neither is a complete answer.

• SRS (Sender Rewriting Scheme) changes the hidden envelope sender to an address at the forwarding domain, so SPF is checked against the forwarder and passes. Microsoft 365 applies SRS to automatically forwarded messages, including mailbox forwarding, inbox rule redirects and groups with external members (Microsoft: SRS in Microsoft 365). But Microsoft states that SRS does not fix DMARC, because the rewritten domain does not match the visible From address.
• ARC (Authenticated Received Chain), described in experimental standard RFC 8617, lets each forwarder record the authentication results it saw before passing the message on. A receiving provider that trusts that forwarder can use those results instead of failing the message. Microsoft says ARC is implemented in Microsoft 365. Whether a receiver honours ARC is its own decision.

Google's recommendations for anyone running a forwarding service match this: rewrite the envelope sender to your forwarding domain, keep DKIM intact by not modifying messages, filter spam before forwarding so your domain's reputation is not damaged, and consider a separate domain or IP for forwarding.

Microsoft 365's external forwarding block (error 5.7.520)

Microsoft treats automatic forwarding to outside addresses as a security risk, because attackers who take over a mailbox often set up a hidden rule to copy every email to themselves. Microsoft's outbound spam policy has three settings for automatic external forwarding (Microsoft: control external email forwarding):

• Automatic - System-controlled (the default). Since 2021 this means forwarding is off for new tenants and for tenants that were not actively using it.
• On - automatic external forwarding is allowed.
• Off - automatic external forwarding is blocked and the sender gets a bounce.

When forwarding is blocked, the bounce reads: "5.7.520 Access denied, Your organization does not allow external forwarding." Turning forwarding back on for everyone is rarely wise. If one person truly needs it, an admin can create a separate outbound policy for just that user. Our guide to what to do when business email is hacked explains why hidden forwarding rules are one of the first things to check after a compromise.

Better alternatives to auto-forwarding

Most forwarding exists because someone wants to see work email somewhere else, or several people need one inbox. Both have cleaner solutions.

Copying business email to personal accounts also matters for data protection. Client personal data that sits in a staff member's private Gmail is outside your control, and you cannot delete it when they leave.

If you must forward: how to reduce the damage

Sometimes forwarding is the only practical option, for example from an old domain you are retiring or to an external accountant's system. In that case:

1. 1

   Forward from a modern provider

   Microsoft 365 and Google Workspace apply sender rewriting and ARC. Basic forwarding at a registrar or old hosting panel often does neither.

2. 2

   Do not modify forwarded messages

   Turn off footers, disclaimers and subject tags for forwarded mail so DKIM signatures stay intact.

3. 3

   Filter spam before forwarding

   Forwarding spam damages your domain's reputation at Gmail and Outlook. Only forward what passes your own filters.

4. 4

   Make sure your own domain is fully authenticated

   Your SPF should include every service that forwards for you, and DKIM should be on for your domain.

5. 5

   Tell the recipient to mark false positives

   In Gmail, marking a forwarded message as not spam, and adding the work address under Send mail as, helps future delivery.

6. 6

   Review forwarding rules regularly

   List all forwarding rules every quarter and remove any that are no longer needed, especially for leavers.

Once your own domain is in order, move your DMARC policy towards enforcement, as covered in our guide to DMARC none, quarantine and reject.

Do it yourself or get help?

Finding and removing forwarding rules, and setting up shared mailboxes instead, is admin console work most office managers can do with a guide. Diagnosing why particular forwarded messages fail needs a look at message headers to see which check broke.

Our Emails Land in Spam Fix (S$249) reviews SPF, DKIM and DMARC for your domain, checks forwarding rules and external forwarding settings, and moves teams from forwarding to shared mailboxes or delegation where that fits better.