DMARC Fails After Forwarding or on Mailing Lists: Why and How to Fix It

Quick answer

DMARC passes only when SPF or DKIM passes for a domain aligned with the From address. Forwarding and mailing lists break both routes:

• SPF: a forwarder sends the message on from its own servers. If it keeps your MAIL FROM, SPF fails because its IP isn't in your SPF record. If it rewrites MAIL FROM to its own domain (SRS), SPF can pass, but for the forwarder's domain, which doesn't align with your From domain.
• DKIM: a plain forward leaves the message alone, so your DKIM signature usually still verifies. Mailing lists that add a subject tag or a footer, strip attachments or re-encode the body change signed content, and the signature fails.

So forwarded mail passes DMARC only through an intact DKIM signature with your domain, and list mail usually fails unless the list rewrites the From address or the final receiver trusts the list's ARC seal. The fixes, by who can make them:

1. Domain owner (you): DKIM-sign every message with your own domain, use your DMARC aggregate reports to find forwarders and lists, and don't jump to p=reject on a domain whose users post to mailing lists.
2. Forwarder or list operator: rewrite the envelope sender, don't modify signed content (or rewrite From to the list's own domain and sign with it), and add ARC.
3. Receiver: in Microsoft 365, add the services that modify your inbound mail as trusted ARC sealers.

Why forwarding breaks SPF alignment

SPF checks the envelope sender (MAIL FROM, also called Return-Path or 5321.MailFrom) against the IP address that connected. RFC 7960, the IETF's write-up of interoperability issues between DMARC and indirect email flows, describes what forwarding does to it:

• If the forwarder keeps the original MAIL FROM, SPF fails unless the forwarder is an authorized part of the original sender's infrastructure.
• If the forwarder replaces MAIL FROM with its own domain, SPF might pass, but alignment with the From domain fails.
• If MAIL FROM is empty (bounces and other delivery notifications), SPF uses the forwarder's HELO name, which is likely in a different organizational domain, so SPF may pass but doesn't align.

In every case SPF can't give DMARC a usable result, and RFC 7960 concludes DKIM must be relied on. RFC 9989, the May 2026 Standards Track DMARC specification that obsoletes RFC 7489, gives the example of a bank writing to jones@alumni.example.edu or finance@association.example, addresses that relay to a real mailbox elsewhere: the relayed copy will most likely fail SPF unless the relay rewrites MAIL FROM, while DKIM signatures generally remain valid.

Typical forwarders are alumni and professional-association aliases, role addresses, a user's mailbox forwarding or inbox rule to a personal account, Sieve redirects, mail flow rules that redirect to an external address, and groups with external members. RFC 7960 notes that alias providers usually have no administrative relationship with the original sender, so a fix can't depend on one: you can't list every forwarder in your SPF record.

Why mailing lists break DKIM

A mailing list receives a message and reposts it to its subscribers. RFC 7960 lists the changes lists commonly make, any of which invalidates a DKIM signature:

• a tag prepended to the Subject, such as [team-list];
• a footer added to the body with unsubscribe or admin instructions;
• MIME parts removed, or the message converted to plain text;
• the body encrypted to each recipient with PGP or S/MIME;
• banned words rewritten, or moderator commentary added.

Relaxed canonicalization is designed to tolerate trivial whitespace and folding changes, so it doesn't save the signature from any of these. The DKIM l= length tag would let a footer be appended, but RFC 7960 notes that lists usually do more than append and that l= is seldom used because of the security risk described in RFC 6376 section 8.2. Receivers report the result as dkim=fail, often with a comment such as body hash did not verify (a footer or body change) or signature did not verify (a subject tag or other header change); the wording varies by receiver. To confirm which, see DKIM body hash did not verify and DKIM signature did not verify.

The fallout is more than junked mail. RFC 7960 and RFC 9989 describe two operational effects: subscribers at receivers that enforce DMARC may not get posts from members whose domain publishes p=reject, and the list software may read those rejections as dead addresses and suspend or unsubscribe the subscribers.

From rewriting: how mailing lists work around DMARC

Once a list has changed a message, the author's domain can't pass DMARC, so list software rewrites the From header to a domain the list controls. RFC 9989 section 7.4 says mailing list software has all adopted such workarounds: some use the list's address, others a per-author address such as bob=example.com@user.somelist.example for bob@example.com. RFC 7960 section 4.1.3.3 lists the options a list operator has:

• Rewrite From to the list's address, or to an address in the list's domain that forwards back to the author. The author's name usually goes in the display name, and Reply-To can carry the author's address. A third variant, breaking the domain with a suffix such as .invalid, can cause problems because some receivers check that the From domain is valid.
• Wrap the original message as a message/rfc822 attachment sent from the list address. Many email clients, especially on mobile, display this badly.
• Don't modify the message (no subject tag, no footer), so the author's DKIM signature stays valid.
• Refuse posts or members from domains with a DMARC policy other than p=none.

After a From rewrite, the receiver evaluates DMARC for the list's domain, so those messages pass or fail on the list's own SPF and DKIM and no longer count against your domain. RFC 9989 Appendix A.6 adds that some intermediaries treated pct=0 as a signal to rewrite From. The new t=y (test mode) tag replaces that: it asks receivers and intermediaries to apply any special handling they have, such as rewriting From, and to apply one level below your published policy (quarantine instead of reject, none instead of quarantine).

ARC: carrying the original results across the hop

ARC (Authenticated Received Chain, RFC 8617, July 2019) is an Experimental RFC. Each ARC-enabled intermediary adds an ARC Set of three headers sharing one instance number i= (1 to 50):

• ARC-Authentication-Results (AAR): the authentication results the intermediary saw when the message arrived;
• ARC-Message-Signature (AMS): a DKIM-style signature over the message as it leaves, which should cover the intermediary's own changes;
• ARC-Seal (AS): a signature over the ARC headers, carrying the chain validation status in cv= (none on the first set, pass on later ones).

The next receiver validates the chain. RFC 8617 section 7.2.1 says a DMARC processor MAY, as a matter of local policy, accept the authentication results in a valid chain when deciding whether the message is DMARC compliant. That is also the limit of ARC:

• it never makes DMARC pass by itself; each receiver decides whether to trust a sealer, and RFC 8617 tells receivers to treat every sealer with suspicion so that bad actors can't seal spam to help it through;
• a chain whose validation fails must be treated the same as a message with no chain;
• it only helps if the forwarder or list actually seals, and RFC 8617 warns that many intermediaries will keep modifying messages without adding ARC;
• RFC 9989 says that, as of its publication, none of the methods for letting lists work without rewriting From, ARC included, have become widely used.

This excerpt from the example in RFC 8617 Appendix B shows the pattern. The list (i=1) saw everything pass; the final receiver sees SPF, DKIM and DMARC fail but a passing ARC chain, with the list's own message signature broken by a later change:

ARC-Authentication-Results: i=1; lists.example.org; spf=pass
    smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
    header.i=@d1.example; dmarc=pass
...
Authentication-Results: clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))

The RFC's example dates from 2015 and uses 512-bit keys, below the 1024-bit minimum RFC 8301 sets for signers; only the result pattern matters. When ARC influences a DMARC decision, RFC 8617 says the receiver MAY show it in aggregate reports as reason local_policy, with a comment listing the chain status, each sealer's domain and selector and the original IP (the RFC's example starts arc=pass as[2].d=d2.example).

Microsoft 365: trusted ARC sealers and SRS

Mail coming in. When a service modifies messages before they reach Microsoft 365 (a third-party filtering gateway or a mailing list, for example), Microsoft says SPF fails because of the new source IP, DKIM fails because of the content change, and DMARC fails because of both. Microsoft's answer is trusted ARC sealers:

1. Find the sealer's domain: send a test message through the service to a Microsoft 365 mailbox, open the headers (in Outlook: File > Properties > Internet headers), find ARC-Seal: and note its d= value. Microsoft stresses that this is the vendor's signing domain, not your organization's domain.
2. In the Microsoft Defender portal go to Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings (Rules section) > ARC, and add the domain. Or use Exchange Online PowerShell:

   Get-ArcConfig
   Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"

   -ArcTrustedSealers replaces the whole list, so include every sealer you want to keep.
3. Allow up to 30 minutes, then send a new test. In the last ARC-Authentication-Results header, arc=pass with oda=1 means the previous sealer is trusted; in Authentication-Results, compauth=pass reason=130 means the trusted sealer's results overrode the DMARC failure (see Microsoft 365 compauth reason codes).

Microsoft says to add only legitimate, required services that regularly modify your inbound mail, because a compromised sealer could pass spoofed messages. ARC overrides DMARC authentication failures only; it doesn't bypass spam or bulk filtering, anti-spam policy actions, mail flow rules or Safe/Blocked sender lists. If the service doesn't seal at all (arc=none), ARC can't help; Microsoft's alternatives include Enhanced Filtering for Connectors for a gateway in front of Microsoft 365.

Mail going out. When a Microsoft 365 mailbox forwards mail to an external address, the Sender Rewriting Scheme (SRS) rewrites the MAIL FROM address, never the From address people see. It applies to mailbox (SMTP) forwarding, Inbox rule redirection, mail flow rule redirection, groups with external members, mail contact and mail user forwarding, and on-premises mail relayed through Exchange Online. In Microsoft's example, a message from bob@fabrikam.com to john.work@contoso.com, forwarded to john.home@adatum.com, leaves with MAIL FROM john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com and From still bob@fabrikam.com.

Microsoft is explicit that SRS doesn't fix DMARC for forwarded mail: SPF may pass for the rewritten address, but it doesn't align with the From domain. The only reliable way for DMARC to pass is a DKIM signature with the From domain that stays intact all the way to the final destination; otherwise a sender with p=reject may see forwarded copies rejected. Microsoft also notes that ARC is implemented in Microsoft 365, and that messages which fail SPF when they first arrive can leave through the relay pool, skipping SRS, from IP addresses that aren't in Microsoft 365's SPF record.

Gmail and Google Workspace

Google's Best practices for forwarding email to Gmail asks administrators who forward mail to Gmail to:

• change the envelope sender to reference the forwarding domain, and make sure that domain's SPF record includes all servers or services that forward for it;
• avoid breaking DKIM: don't modify the Subject or other DKIM-protected headers (including To, Cc, Date and Message-ID), don't let third-party software modify or re-encode the body, don't modify MIME boundaries, and don't expand recipients with LDAP;
• add an X-Forwarded-For: or X-Forwarded-To: header so receiving servers know the message was forwarded;
• filter spam before forwarding it, because forwarded spam that recipients report hurts the forwarding domain.

Google says Gmail doesn't automatically authenticate forwarded messages that previously passed authentication; it does its own check, and for frequently spoofed domains it enforces strict authentication requirements. It recommends that senders always set up DKIM as well as SPF, because forwarded messages often fail SPF. When Gmail itself forwards through an unverified forwarding configuration, it sends from *.unverified-forwarding.1e100.net servers that are deliberately left out of Google's SPF record, doesn't add authentication to unauthenticated messages, and points receivers to ARC to check a forwarded message's authentication status. Google's bulk-sender alignment rule is written for direct email; the Google pages we checked don't describe a trusted-sealer list or other admin setting for forwarded mail in Gmail.

What you can do as the domain owner

1. Sign everything with DKIM using your own domain. It is the only authentication that survives plain forwarding, and RFC 9989 makes it a requirement for strict policies: domains that publish p=reject MUST NOT rely solely on SPF and MUST apply valid DKIM signatures. Check each platform that sends as you (Microsoft 365, Google Workspace, marketing, ticketing, billing) with the DKIM Checker; see DKIM for Microsoft 365, the Google Workspace guide and the DMARC alignment guide for third-party senders.
2. Make signatures harder to break. RFC 7960 suggests relaxed canonicalization, signing a limited set of header fields, standards-compliant headers and common body formats, and converting the message to quoted-printable or base64 before signing so relays don't re-encode it. Don't use l=: it lets anyone append content to your signed mail.
3. Read your aggregate reports before tightening policy. Forwarded mail typically shows up as rows from IP addresses you don't recognise, with SPF failing (or passing for someone else's domain) and DKIM still passing; list traffic tends to show both failing. RFC 7489 notes that reports also cover mail forwarded to domains that weren't on the original recipient list, which is why reports can arrive from receivers you never mailed directly. When a receiver overrides your policy it can add a reason: RFC 7489 defines forwarded, trusted_forwarder, mailing_list, local_policy, sampled_out and other; RFC 9990 keeps trusted_forwarder, mailing_list, local_policy and other, drops forwarded and sampled_out, and adds policy_test_mode. The DMARC Report Analyzer flags those reasons and counts messages that passed through DKIM only.
4. Avoid p=reject surprises. RFC 9989 section 7.4 says domains that host users who might post to mailing lists SHOULD NOT publish p=reject. If you want it anyway, first publish p=none for at least a month, then p=quarantine for an equally long period, and compare the results in your reports; after that, have users not post to Internet mailing lists or tell them their participation may be hindered. RFC 7960 adds that senders can use separate domains with different DMARC policies for direct mail and for mail likely to be forwarded, though abusers tend to target all of a brand's active domains. While testing, t=y asks receivers to apply one level below your published policy.
5. Know what you can't control. Receivers decide. RFC 9989 says they must not reject messages solely because of p=reject and, without other knowledge and analysis, must treat such failures as if the policy were p=quarantine. It also admits that in practice few receivers mitigate indirect mail, and that list mail with an unmodified From is frequently rejected because of p=reject. You can't make someone else's forwarder rewrite the envelope, keep your signature intact or add ARC; you can make sure your own signature is there and survives.

What the forwarder or list operator can do

• Rewrite the envelope sender to your own domain (SRS or an equivalent scheme) and cover your forwarding servers in that domain's SPF record. RFC 7208 Appendix D notes that bounces then come back to you and have to be passed on to the original sender. This makes SPF pass, but not align, so it protects your reputation and bounce handling rather than the author's DMARC result.
• Don't modify signed content. RFC 7960 suggests adding header fields instead of changing existing headers or bodies (for example to mark a message as possible spam), not "fixing" non-compliant headers, and rejecting harmful messages instead of modifying them. A list that drops its subject tag and footer keeps the author's DKIM signature valid.
• If you must modify, rewrite From. Use an address in the list's domain, keep the author's name in the display name (without anything that looks like an email address or domain name), put the author's address in Reply-To if replies should go to them, and DKIM-sign with the list's domain so the new From aligns.
• Add ARC. Seal after your last modification so the ARC-Message-Signature covers your changes. RFC 8617 says sealing is always safe: properly adding an ARC Set doesn't damage an existing chain, and sealing a message you didn't modify doesn't hurt it.
• Don't unsubscribe people over DMARC bounces. RFC 7960 says list managers shouldn't act on bounces caused by authentication failures, and recommends reading the enhanced status codes. RFC 7489's example rejection text is 550 5.7.1 Email rejected per DMARC policy for example.com, but receivers word their rejections differently.

How to tell forwarding is the cause

1. Get the full headers of a copy that reached the final mailbox and paste them into the Email Header Analyzer.
2. Follow the Received hops from the bottom up. A hop through a server that is neither yours nor the recipient's (an alias provider, a list server, a filtering gateway) is the forwarder.
3. Read the final Authentication-Results. spf=fail, or smtp.mailfrom showing the forwarder's domain (Microsoft 365 forwards carry +SRS= in that address), means SPF was lost on the hop. dkim=fail after a list hop means content changed. header.from showing the list's domain means the list rewrote From.
4. Look for ARC-Seal headers: d= names the sealer, cv= is the chain status, and the i=1 ARC-Authentication-Results shows what the first intermediary saw. In Microsoft 365, arc=pass with oda=1 and compauth=pass reason=130 mean a trusted sealer's results were used.
5. Compare with a copy sent directly. If the direct copy passes DMARC and only the forwarded copy fails, your records are fine; the fix is DKIM survival, the forwarder's setup or ARC trust at the receiver, not your SPF record.

Verify the fix

1. Check your policy, rua report address and any t= tag with the DMARC Record Checker.
2. Confirm every sending platform publishes a working key with the DKIM Checker, and check SPF, DKIM, DMARC and MX together with the Email Deliverability Checker.
3. Send a test through the forwarder or list to a mailbox you control and read it in the Email Header Analyzer: dkim=pass with header.d in your domain means your mail now survives plain forwarding.
4. Watch a few weeks of reports in the DMARC Report Analyzer before moving to p=quarantine or p=reject, paying attention to the forwarding and mailing-list findings and the DKIM-only passes.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Check your policy with the DMARC Record Checker, build a new record with the DMARC Record Generator, confirm signing with the DKIM Checker and check everything at once with the Email Deliverability Checker. Read forwarded copies with the Email Header Analyzer and find forwarders and lists in your reports with the DMARC Report Analyzer. Related guides: DMARC fail with SPF pass (alignment), Microsoft 365 compauth=fail, DKIM body hash did not verify, DKIM signature did not verify, DMARC for Microsoft 365, Gmail 550 5.7.26 and Outlook.com 550 5.7.515.

FAQ

Why does DMARC fail only when my email is forwarded?

The forwarder sends the message on from its own servers, so SPF fails for your envelope sender, or passes only for the forwarder's domain if it rewrites the envelope, and that domain doesn't align with your From address. DMARC can then pass only through a DKIM signature with your domain that the forwarder didn't break, so sign all mail with DKIM using your own domain.

Does SRS fix DMARC for forwarded email?

No. The Sender Rewriting Scheme rewrites the envelope sender so SPF can pass and bounces go back through the forwarder, but the new envelope domain belongs to the forwarder and doesn't align with the From domain. Microsoft says the only reliable way for forwarded mail to pass DMARC is a DKIM signature with the From domain that stays intact to the final destination.

Should I publish p=reject if my users post to mailing lists?

RFC 9989 says domains that host users who might post to mailing lists should not publish p=reject. If you still want it, publish p=none for at least a month and p=quarantine for as long again, compare your aggregate reports, and tell users their list participation may be affected.

What is ARC and does it fix DMARC failures from forwarding?

ARC (RFC 8617, an Experimental RFC) lets each forwarder or list record the authentication results it saw and seal them with a signature. A receiver may, as local policy, use a valid chain from a sealer it trusts to override a DMARC failure, but nothing forces it to, and it only helps when the intermediary actually seals the message.

How do I add a trusted ARC sealer in Microsoft 365?

Find the d= value in the service's ARC-Seal header, then add that domain in the Microsoft Defender portal under Email Authentication Settings on the ARC tab, or run Set-ArcConfig -Identity Default -ArcTrustedSealers with every sealer domain you want, because the parameter replaces the list. After up to 30 minutes, look for arc=pass with oda=1 and compauth=pass reason=130 in a new message.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.