Should I add my recipient's forwarding server to my SPF record?

No. You cannot know every address that forwards your mail, and each include you add spends part of a budget capped at ten DNS lookups, so the attempt tends to break SPF for everybody. Use DKIM instead: a signature from your own domain survives a plain forward, and one aligned check is all DMARC needs.

Can I move DMARC to p=reject if forwarded mail fails SPF?

Yes, once every system that sends as your domain signs with a DKIM key that aligns with your From domain. DMARC needs one aligned identifier, not both, so forwarded mail keeps passing on DKIM. The rows to resolve before you tighten the policy are the ones where SPF and DKIM both fail.

Who has to set up ARC, me or the forwarder?

The intermediary that modifies the message: the mailing list, the forwarding service, the gateway. You cannot add ARC headers to somebody else's hop, you can only document where the chain breaks and ask. On the receiving side you can tell Microsoft 365 to trust a specific ARC sealer, and Gmail already reads the chain when it is there.

Email forwarding breaks SPF: fix it with DKIM, SRS or ARC

A client called about invoices. Their customers were receiving them without trouble, except for one, whose accountant never got a single file. The bounce notice they eventually forwarded to us said the message failed SPF. Nothing had changed on their side: same Workspace tenant, same SPF record, same mailbox sending the same invoices all week. The difference was one extra hop. The accountant's address was an old one at a former employer that quietly relays everything to a personal Gmail account, and SPF does not survive that trip.

This is the most common false alarm in deliverability work. The symptom looks exactly like a broken DNS record, so people rewrite the record, then rewrite it again, and the failures continue because the record was never the problem.

What forwarding changes, and what it leaves alone

Every message carries two sender addresses. The envelope sender is the MAIL FROM that one server announces to the next during the SMTP conversation, also called the return path or the 5321.MailFrom. The From: header is the one the reader sees, the 5322.From. SPF has nothing to do with the second one. It takes the domain in the envelope sender, looks up that domain's SPF record, and asks a single question: is the IP address connecting right now on the list?

Plain forwarding keeps both addresses and changes the IP. The forwarding server re-sends your message from its own infrastructure while still claiming your domain in the envelope. The receiver at the far end then does precisely what SPF asks of it: it fetches your record, finds your Google or Microsoft includes, does not find the forwarder anywhere in them, and returns a fail. Google's own documentation is blunt about this. Forwarded messages often fail SPF, and they do so even when SPF is set up correctly for the domain, because of the way the forwarding server forwards.

Why DKIM usually survives, and the two things that kill it

DKIM is attached to the message rather than to the connection. The signature sits in a header and covers the body plus a chosen set of headers, so it travels with the message instead of being recalculated at every hop. Forward the message without touching it and the signature still verifies at the far end. That is why Google tells senders that DKIM matters especially for mail that gets forwarded.

Two things break it. The first is modification. A mailing list that appends an unsubscribe footer, or prefixes the subject with the list name, changes the exact bytes the signature covered, so the body hash no longer matches and DKIM fails. The second is absence: a message your domain never signed in the first place. That is still common with invoicing systems, CRMs, booking tools and scan-to-email devices that send through their own infrastructure and were never given a key.

DMARC passes when one of the two aligns

This is the part that settles most of these calls. DMARC does not need both checks to pass. It needs one authenticated identifier that passes and whose domain aligns with the domain in the From: header. RFC 9989, the DMARC standard published in May 2026 that replaced RFC 7489, keeps that either-or structure and defaults both alignment modes to relaxed, which means the organizational domain has to match rather than the exact name.

So a forwarded message that shows spf=fail dkim=pass, with a signature from your own domain, is a DMARC pass. Nothing is broken. Forwarding took SPF out of the picture and DKIM carried the message anyway, which is the design working the way it was meant to. A message that shows spf=fail dkim=fail is a different conversation, and the next question is which of the two DKIM problems above you have.

Read one forwarded message before you touch DNS

We ask for one thing: the full headers of a single message that genuinely failed, copied out of the mailbox at the end of the chain. Not the DMARC report, not a screenshot of the DNS panel. The headers carry the whole route. The Authentication-Results line near the top shows what the final receiver concluded. The Received: lines, read from the bottom up, show every hop, including the forwarder nobody mentioned on the call. The DKIM-Signature header shows which domain signed, in its d= tag.

Three questions answer themselves once you have that: was the message forwarded, did DKIM survive, and does the signing domain align with the From: domain. Paste the headers below and you get the same three answers without walking the chain by hand, and there is a longer walkthrough in how to read email headers when a message goes to spam.

Three forwarding situations, three different jobs

A recipient forwards your mail. An old address at a previous job, a role account that fans out to three people, a personal Gmail fed by a work one. You do not control that forwarder and you never will. Your lever is making sure DKIM is present and unbroken, so DMARC passes without SPF.
A mailing list or a group sits in the middle. Here the message is modified on purpose, so DKIM fails by design rather than by accident. The fix belongs to whoever runs the list, and the mechanism is ARC.
A gateway forwards mail into your own domain. A filtering appliance, an old server, another provider sitting in front of Google Workspace. This one is yours to fix, and the fix is a setting rather than a DNS record.

What we fix on the sending side

Sign everything with DKIM, from every sender. We build the inventory first: the mail platform, the invoicing software, the CRM, the online store, the helpdesk, the printer in the corner. Each one that sends as your domain gets its own key or its own CNAME pair. A sender nobody remembered is the usual reason one stream keeps failing after forwarding while the rest are fine.
Check alignment, not just the presence of a signature. A signature whose d= points at the vendor's own domain verifies happily and does nothing for your DMARC result, because it does not align with your From: domain. That distinction is the whole subject of our notes on alignment at the big marketing platforms.
Leave SPF out of it. You cannot enumerate the world's forwarders, and every include you add spends part of a budget that is capped at ten DNS lookups, which is its own failure mode once you cross it. We have written separately about getting back under the ten lookup limit. Chasing forwarder IP addresses is how domains end up there.
Read the failures correctly. A forwarding row is not an attacker, and treating it as one costs weeks of work on records that were already right.

What gets fixed at the forwarder

Two mechanisms exist for this, and both live with the intermediary rather than with you.

The first is the Sender Rewriting Scheme. The forwarder rewrites the envelope sender to an address in a domain it controls, so the receiver at the far end evaluates SPF against the forwarder, where the connecting IP is authorized, and SPF passes. Microsoft 365 does this for applicable messages leaving to external recipients, and since August 2023 it also uses the scheme for mailbox forwarding rather than the forwarding mailbox's own address. It touches only the envelope sender; the From: address shown in the mail client is left alone.

The second is ARC, the Authenticated Received Chain defined in RFC 8617. An intermediary records what it saw before it changed anything, in three headers: ARC-Authentication-Results for the verdict at that hop, ARC-Message-Signature over the message as it stood, and ARC-Seal over the chain so far. The far end can then see that a message failing now was passing when it entered the chain. Google asks forwarding services, mailing lists and inbound gateways to add these headers, and applies the logic in both directions: if a forwarded message passes SPF or DKIM at the last hop but the chain shows it failed earlier, Gmail treats it as unauthenticated. On the receiving side, Microsoft 365 lets you name trusted ARC sealers, identified by the d= value in the ARC-Seal header, so mail modified by a service you trust stops failing.

Neither one is yours to deploy. When a client's mail keeps failing through a single intermediary, we can document the chain, show the operator where it breaks, and ask. The better use of the hour is usually making DKIM solid on your own side, because that works without anyone else's cooperation.

When the gateway is in front of your own domain

This one we can fix outright, and it is the case people miss. If mail reaches your Google Workspace users through something else first, Gmail is judging the last machine it talked to, which is your own gateway, not the sender. The inbound gateway setting exists for this: you list the gateway's IP addresses and turn on the option to detect the external IP automatically. Gmail then reads the Received: headers for the first public IP that is not in your gateway list and uses that address for SPF and for spam evaluation. With the option off, Gmail checks only one hop back. One caution from the same page: an address entered in the inbound gateway configuration will not also be added to an email allowlist.

What the reports will keep showing

Forwarding rows never go away. Your aggregate reports will always contain some mail from IP addresses you do not recognise, failing SPF, passing DKIM, and that is what healthy forwarding looks like from the inside. Our guide to reading DMARC aggregate reports covers how to tell those rows from the ones worth worrying about.

The consequence for policy: forwarding is not a reason to stay at p=none. Once every sender signs with an aligned DKIM key, forwarded mail keeps passing on DKIM, and a move to quarantine and then reject does not put it at risk. Resolve the rows where both checks fail before you tighten the policy. Those are almost never forwarders; they are a sender nobody told you about.

How Guanacos Tech helps

Most of the work here is diagnosis rather than configuration. We take one failing message, read the chain, and say which of the three situations you are in, then fix what is yours to fix: the senders with no DKIM key, the signatures that verify but do not align, the gateway setting that makes Gmail judge the wrong machine. Our email deliverability consulting for small business runs that diagnosis first and shows you the headers it is based on. If your mail works until someone forwards it, book a 30 minute call and bring one bounce notice with you.

Your mail passes SPF, until someone forwards it: what breaks and what we fix first