ARC Email: Why Forwarded Emails Fail DMARC and How to Fix It

You set up SPF, DKIM and DMARC, your reports look clean, and then a customer says your emails bounce when they reach their old university address, or a supplier's mailing list keeps rejecting your posts. Forwarded email is the most common reason legitimate mail fails DMARC. This guide explains exactly why forwarding breaks authentication, how ARC (Authenticated Received Chain) helps receivers trust forwarded mail, how to configure trusted ARC sealers in Microsoft 365, and what you should change on your own domain.

If you need a refresher on the basics first, start with DMARC explained.

Why forwarded emails fail DMARC

DMARC passes when either SPF or DKIM passes and the domain it authenticated aligns with the domain in the visible From address. Forwarding attacks both checks in different ways.

SPF breaks on almost every forward

SPF checks whether the server that delivered the message is authorised to send for the envelope sender's domain (the MAIL FROM, also called the Return-Path). When a message is forwarded:

1. You send from you@yourcompany.com through Microsoft 365. SPF passes at the first hop.
2. The recipient's server, say old-address.edu, forwards it to their Gmail account.
3. Gmail sees the message arriving from the university's server, which isn't in your SPF record.
4. SPF fails, or passes for the forwarder's domain rather than yours. Either way, it no longer aligns with your From domain.

Some forwarders use the Sender Rewriting Scheme (SRS) to rewrite the envelope sender to their own domain. That makes SPF pass, but for the forwarder's domain, so it still doesn't align for DMARC. SRS stops the forward bouncing on SPF alone. It doesn't rescue DMARC.

DKIM survives, unless the message is changed

DKIM is a cryptographic signature over the message body and selected headers. It doesn't care which server delivered the message, so a plain, unmodified forward keeps a valid DKIM signature. This is why DKIM is the half of DMARC that matters most for forwarded mail.

DKIM breaks when an intermediary changes signed content. Google's forwarding guidance lists examples that break DKIM, including changing the Subject, the MIME boundaries, and the To, Cc, Date or Message-ID headers. Common culprits:

When both SPF alignment and DKIM fail, DMARC fails. If your domain publishes p=reject, the final receiver may reject a perfectly legitimate message.

Mailing lists are the hardest case

Mailing lists usually modify messages and resend them from their own servers, so both checks fail. Many list servers work around this by rewriting the From address (for example, "Jane Smith via Trade Association list@association.org"), which avoids DMARC failure but changes how the message looks.

The new DMARC standard, RFC 9989 (published May 2026), is direct about this. In its interoperability section it says domains whose users post to mailing lists "SHOULD NOT" publish p=reject, and that receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy". Without other evidence, it says receivers should treat a failure as if the policy were quarantine.

What ARC is and how it works

ARC, the Authenticated Received Chain, is defined in RFC 8617 (July 2019). It lets each server that handles a message record what authentication looked like when the message arrived, then sign that record so later servers can verify it hasn't been tampered with.

Each participating intermediary adds three headers, numbered with an instance tag i= (from 1 up to a maximum of 50):

A simplified example of what you might see in a forwarded message's headers:

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc-2026;
  cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc-2026;
  h=from:to:subject:date; bh=...; b=...
ARC-Authentication-Results: i=1; mx.forwarder.example;
  spf=pass smtp.mailfrom=yourcompany.com;
  dkim=pass header.d=yourcompany.com;
  dmarc=pass header.from=yourcompany.com

The final receiver sees SPF and DKIM fail now, but can read a sealed statement from forwarder.example saying "when I received this, it passed DMARC". If the receiver trusts forwarder.example, it can deliver the message despite the current failure.

ARC is evidence, not a free pass

Two points are easy to miss:

• ARC is not a trust framework. RFC 8617 says ARC "does not make any assessment" of whether the handlers it identifies are trustworthy. A spammer can add a valid ARC seal to anything. What matters is whether the receiver chooses to trust that specific sealer.
• ARC is still not universal. RFC 9989 calls ARC "a prominent example" of methods to make mailing lists work with DMARC, but notes that none of them had become widely used when it was published.

So ARC helps most where a large receiver has explicitly decided to trust a known intermediary. That's exactly what Microsoft 365's trusted ARC sealers feature does.

How to configure trusted ARC sealers in Microsoft 365

Microsoft recommends trusted ARC sealers when inbound mail is regularly modified by a legitimate service before it reaches your Microsoft 365 mailboxes: a third-party security gateway, a mailing list service or a forwarding service. Microsoft calls this the preferred approach over allow-listing when legitimate forwarded mail fails DMARC.

Step 1: Find the sealer's domain

1. Send a test message through the intermediary to a Microsoft 365 mailbox.
2. Open the headers (in Outlook: File > Properties > Internet headers, or paste them into Microsoft's Message Header Analyzer).
3. Find ARC-Seal: and note its d= value.

The sealer domain is the vendor's domain, not yours. Microsoft's documentation warns that adding your own domain is a common mistake.

Step 2: Add it in the Defender portal

Go to security.microsoft.com > Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > ARC, select Add, enter the domain from the d= value and save. Microsoft says to allow up to 30 minutes for the change to take effect.

Or use Exchange Online PowerShell:

# See what is configured now
Get-ArcConfig

# Set trusted sealers (this REPLACES the existing list)
Set-ArcConfig -Identity Default -ArcTrustedSealers "vendor-one.com","vendor-two.com"

-ArcTrustedSealers replaces the whole list, so include any existing sealers you want to keep.

Step 3: Confirm it's working

In the delivered message's last ARC-Authentication-Results header, look for arc=pass and oda=1. In the last Authentication-Results header, compauth=pass reason=130 means Microsoft 365 used the trusted ARC result to override a DMARC failure.

If messages still land in Junk Email, remember that ARC only overrides authentication failures. It doesn't bypass spam filtering, bulk filtering or your mail flow rules. Only add vendors you actually use: Microsoft notes that an unnecessary trusted sealer increases your attack surface.

What about Google Workspace and Gmail?

Google's admin documentation doesn't describe a trusted ARC sealer list like Microsoft's, so Workspace admins can't configure one in the same way. Google's sender guidelines FAQ also notes that "DMARC alignment isn't required for forwarded or mailing list messages" under its bulk sender requirements, which acknowledges that forwarded mail often can't align.

What Google does document for people who forward mail to Gmail:

• Set up SPF and DKIM on your domain, because forwarding often fails SPF, and DKIM is what survives.
• Don't modify DKIM-signed content when forwarding.
• Add an X-Forwarded-To: or X-Forwarded-For: header so Gmail can identify forwarded mail.
• Change the envelope sender to the forwarding domain and include forwarding servers in that domain's SPF record.

Google also says "Gmail doesn't automatically authenticate forwarded messages that previously passed authentication". It runs its own checks. If you route inbound mail through a third-party gateway before Gmail, configure Google's inbound gateway setting. Google states that Gmail doesn't enforce the sender's DMARC policy for messages arriving from a configured inbound gateway.

What domain owners should do

You can't control every forwarder your mail passes through, but you can make your mail as forwarding-resilient as possible.

1. DKIM-sign every message with your own domain. This is the single most effective step. A plain forward keeps a valid, aligned DKIM signature, so DMARC still passes. Check every service that sends as you: Microsoft 365, Google Workspace, your CRM, invoicing software and newsletter platform. Our DKIM checker confirms a selector is published.
2. Don't rely on SPF alone. If a sender only passes DMARC through SPF, every forward will fail.
3. Read your DMARC aggregate reports. Forwarded mail shows up as rows from unfamiliar IPs where SPF fails but DKIM passes. Microsoft's documentation describes mailing list IPs with all checks failing as normal for forwarded mail. Don't add forwarders to your SPF record to "fix" this. Our guide on how to read DMARC reports shows what to look for.
4. Move to enforcement in stages. Start at p=none, then p=quarantine, then p=reject, checking reports at each stage.
5. Think before using p=reject if staff post to mailing lists. RFC 9989 recommends against it for domains whose users post to lists. Options include staying at p=quarantine, asking list operators to enable From rewriting or ARC, or using a separate domain or subdomain for list participation.
6. Send bulk mail from a subdomain with its own DKIM key, so forwarding issues with newsletters don't affect your main domain.
7. If you run forwarding, behave well. Don't modify messages, add an X-Forwarded-To header, use SRS where your mail server supports it, and if you operate a gateway or list server, enable ARC sealing.
8. If you receive mail through an intermediary on Microsoft 365, add it as a trusted ARC sealer.

Use our free DMARC checker (free account required) to confirm your domain publishes a v=DMARC1 record and see whether its policy is monitor-only or enforced. For SPF, DKIM, DMARC, MTA-STS and BIMI in one place, use the email deliverability checker, or run a free website audit to check email authentication alongside the rest of your site.

Frequently asked questions

Why does forwarding break SPF but not DKIM?

SPF checks the IP address of the server that delivered the message, and a forwarder's server isn't in your SPF record. DKIM is a signature over the message content, so it stays valid wherever the message travels, as long as nobody changes the signed parts.

Does ARC fix DMARC failures automatically?

No. ARC records the original authentication results and seals them, but the receiving server decides whether to trust the sealer. Microsoft 365 uses ARC results only from sealers an admin has added to its trusted list, and only to override authentication failures, not spam filtering.

Do I need to add ARC records to my DNS?

Not as a domain owner who only sends mail. ARC is added by intermediaries such as forwarders, mailing lists and gateways, which publish their own keys. Your job is to DKIM-sign your mail with your own domain.

Should I add the forwarding server to my SPF record?

No. You'd be authorising a third party's server to send as your domain, and you'd quickly run into the 10 DNS lookup limit. Rely on DKIM to carry DMARC through forwarding instead.

Is p=reject a bad idea if we use mailing lists?

It can cause problems. RFC 9989 says domains whose users post to mailing lists should not publish p=reject. Many businesses stay at p=quarantine, or use a separate domain or subdomain for list participation.

Sources

• RFC 8617: The Authenticated Received Chain (ARC) Protocol
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: Configure trusted ARC sealers
• Microsoft Learn: Set up DMARC to validate email in Microsoft 365
• Google Workspace Admin Help: Best practices for forwarding email to Gmail
• Gmail Help: Email sender guidelines FAQ
• Google Workspace Admin Help: Set up an inbound mail gateway