A subscriber signs up for your newsletter with her work address. She leaves that company two years later and sets up a forwarding rule so mail sent to her old address lands in her personal Gmail. Your newsletter goes out. Your SPF fails because the forwarding server is not in your SPF record. Your DKIM might also fail because the forwarding server rewrote the subject line or added a footer. DMARC marks the message as failed. Gmail sees a DMARC failure on a message from a sender with a published p=quarantine policy. The message drops to spam.
She never sees your content. You never know why. And nothing in your own authentication setup is wrong.
The Authentication Chain Problem
SPF and DKIM were designed for direct sender-to-receiver delivery. They were not designed for a world where messages regularly transit through intermediate servers that rewrite headers, modify content, or forward on behalf of recipients.
Forwarding breaks SPF because the forwarding server becomes the new sender. The receiving mail server checks whether the forwarding server's IP is authorized in your SPF record, sees it is not, and marks SPF as failed. DKIM survives simple forwarding but breaks when intermediate servers modify the message: mailing list managers that add footers, security gateways that rewrite URLs, forwarding rules that prepend "Fwd:" to subjects. Any modification invalidates the DKIM signature.
This created a real problem. DMARC enforcement was supposed to stop phishing. Instead, it was also breaking legitimate mail that passed through mailing lists, forwards, and corporate relay servers. The standards body needed a way for intermediate servers to say "this message was authenticated when I received it, and I am vouching for that chain even though my modifications have broken the original signatures."
That is ARC: Authenticated Received Chain.
What ARC Actually Does
ARC was finalized in RFC 8617 and has been gradually adopted across major providers since 2018. It works by having each intermediate server add three headers to the message:
- ARC-Authentication-Results: captures the authentication state the intermediate server observed when it received the message.
- ARC-Message-Signature: a DKIM-like signature over the message as the intermediate server is forwarding it.
- ARC-Seal: a signature over the other two ARC headers, sealing the chain.
Each intermediate server adds its own instance of these three headers. A message that passes through two mailing lists and one security gateway ends up with three sets of ARC headers. The final receiver can then walk back up the chain and see "this message originally passed SPF and DKIM at the first hop, and each subsequent hop added its signature attesting to that fact."
If the final receiver trusts any of the intermediate servers that signed the ARC chain, it can accept the message as authenticated even though SPF and DKIM both fail at the final hop. This is how Gmail delivers legitimate mailing list messages without DMARC breaking them.
Why Most Senders Never Think About ARC
The typical sender cannot do anything about ARC. You do not add ARC headers. Your ESP does not sign ARC headers. ARC is strictly a protocol for intermediate servers: mailing list managers, forwarders, security gateways, and anything else that receives mail and then retransmits it.
As an original sender, your role is to send mail that is cleanly authenticated when it leaves your infrastructure. SPF aligned. DKIM signed. DMARC policy published. That is all you control. What happens when a recipient forwards your mail or subscribes with an address that forwards, that is in someone else's hands.
This is why ARC does not show up in most deliverability discussions. The advice is usually "set up SPF, DKIM, DMARC, BIMI" and nothing about ARC. For 90 percent of senders, that is correct. But for the other 10 percent, and for anyone trying to understand why legitimate mail sometimes fails, ARC is the missing piece.
Who Needs to Care About ARC as a Sender
Three categories of sender need to understand ARC deeply.
The first is mailing list operators. If you run a Google Group, a Mailman list, a discussion forum that relays messages, or any kind of list server, you are an intermediate in someone else's authentication chain. Your list server needs to sign ARC headers when forwarding messages. If you are using modern list software, this is built in. Older installations may not support ARC at all, which means any DMARC-enforcing domain that sends to your list will have its messages rejected by downstream members. This was the single most common cause of the "DMARC broke mailing lists" crisis in 2018 to 2020. ARC was the solution.
The second is corporate security gateways. Mimecast, Proofpoint, Barracuda, and similar platforms receive mail on behalf of their customers, scan it, and then deliver it to the customer's mail servers. If the gateway modifies the message (adding warning banners, rewriting URLs, scanning attachments), DKIM breaks. The gateway needs to add ARC headers so the customer's mail server (and the end recipient's client) can trust the authentication that happened before the gateway modified the message.
The third is anyone running custom forwarding infrastructure. This is less common but exists in places like membership organizations that provide @memberdomain.org addresses that forward to wherever the member works, or universities that maintain lifetime alumni forwarding addresses. These organizations are intermediate servers in the authentication chain and should be signing ARC headers on outgoing forwarded mail.
How Gmail Uses ARC
Gmail was one of the earliest adopters of ARC and has the most public-facing documentation about how they use it. The short version: Gmail uses ARC to make delivery decisions on messages where SPF and DKIM fail but an upstream hop attests to successful authentication.
Google maintains a trust list of ARC-signing domains. If a message arrives at Gmail with a broken SPF/DKIM but a valid ARC chain signed by a domain Google trusts, Gmail will treat the message as if it had passed original authentication. This trust is not automatic. It is earned by having a consistent history of signing ARC headers honestly (not claiming authentication for messages that did not actually authenticate at the original sender).
For the original sender, this creates an indirect benefit. If you send to subscribers whose addresses forward through a major provider (most corporate IT services, most consumer forwarding services, most mailing list platforms), the ARC chain is likely to be preserved and Gmail is likely to deliver your mail. If your subscribers' addresses forward through obscure or dated infrastructure that does not sign ARC, you are at the mercy of how the receiver handles broken authentication.
There is nothing you can do about that as a sender except to note it in your deliverability monitoring. If you see a specific forwarding domain repeatedly failing DMARC and landing in spam, you can sometimes contact the IT team at that domain and ask whether they support ARC. Most of the time the answer is "we do not know," which tells you what you need to know.
What Senders Can Actually Do
Given that ARC is primarily a relay-side protocol, what can a sender do?
First, understand the forwarding profile of your list. DMARC aggregate reports show source IPs. If you see a cluster of IPs from a consumer forwarding provider, or from a corporate mail gateway, you know those recipients are forwarding. You cannot fix their authentication, but you can prioritize DKIM alignment (which survives most forwarding) over SPF alignment (which almost never does). We covered why this matters in our post on SPF and DKIM dual alignment.
Second, keep your list clean. Recipients who have moved on and left autoforwarders set up often have low engagement rates. They never open. They never click. They are eroding your sender reputation without providing any value. Running regular email verification and sunsetting unengaged contacts after a defined period will remove much of the forwarding overhead that creates authentication headaches.
Third, make your authentication bulletproof on the sending side. ARC can only vouch for what the intermediate server observed. If your message arrives at the intermediate server with failed SPF and unsigned DKIM, the ARC chain will attest that the message was never authenticated. That actively hurts you. Senders who authenticate cleanly get the benefit of intermediate ARC signing. Senders who do not, do not.
Fourth, for the largest volume senders, consider directly monitoring ARC behavior. This is not something most tools expose. A few enterprise platforms (Valimail, Red Sift, Abnormal Security) can report on ARC signing in aggregate report data. If you have the volume and budget, this visibility is useful. For everyone else, the indirect signal (what percentage of your forwarded mail lands in the inbox) is what you track.
A Common Myth About ARC
I hear senders say "ARC replaces SPF and DKIM." It does not. ARC is a supplementary protocol. It only helps when the mail needs to transit through intermediate servers that break authentication. Mail sent directly from you to the final recipient does not benefit from ARC because there are no intermediate hops to sign.
A related myth is that publishing an ARC record or configuring ARC on your outbound ESP does something. ARC has no DNS record in the way SPF or DMARC do. There is no "ARC for senders" setting. If you find documentation claiming there is, it is wrong or it is referring to something adjacent (like outbound relay signing for a gateway that happens to be operated by the sending organization).
The one edge case where a sender operates as their own relay is when a large enterprise sends through their own internal mail gateway. In that case, the gateway is both the sender and an intermediate, and it should be signing ARC headers on its outbound mail if that mail will transit through further intermediaries downstream. This is advanced. Most readers are not in this situation.
What to Monitor in Your Reports
Your DMARC aggregate reports include a source IP for every reported message. For messages that pass authentication at the original hop, you see clean pass results from the ESP or mail server that actually sent the message. For messages that were forwarded, you see pass or fail results from the intermediate server that received and forwarded the message.
A practical monitoring approach: group your source IPs by whether they belong to known forwarders. Google's forwarding infrastructure is well documented. Major corporate gateways are recognizable by reverse DNS. Mailing list servers usually identify themselves. Track the percentage of your total volume that transits through these categories of infrastructure. If the percentage is rising over time, you have more forwarding risk and should prioritize DKIM alignment. If the percentage is falling, your list quality is improving and ARC is less of a concern.
This kind of report reading is tedious but worth doing quarterly. Most deliverability issues at the long tail come from forwarding, and understanding how much forwarding your list actually involves is the first step toward addressing it.
Contrarian Take: Do Not Worry About ARC If You Are a Small Sender
I said earlier that ARC matters for about 10 percent of senders. The other 90 percent do not need to think about it. If you are sending to direct subscribers with consumer mailboxes (Gmail, Yahoo, Outlook), and you have clean SPF and DKIM, you will rarely hit ARC-related issues. The major receivers handle the forwarding cases well and ARC is doing its job quietly in the background.
Where I see small senders get derailed is when they read about ARC and decide they need to configure it. They start googling. They find dated documentation. They email their ESP asking for ARC setup. They waste two weeks chasing a problem they do not have.
Get your SPF right. Get your DKIM right. Publish a DMARC policy. Run list hygiene. If you hit a specific forwarding-related deliverability issue and you have ruled out the usual suspects from our guide on email in spam folder reasons, then look at ARC. Not before.
How ARC Changes Spam Filtering in 2026
The interesting 2026 development is that receivers are starting to use ARC signals to inform reputation scoring, not just authentication decisions. Gmail will treat a domain that consistently signs ARC honestly as more trustworthy than one that does not. Yahoo is building similar logic into their sender hub scoring.
This matters for intermediate server operators more than for pure senders. If you run a mailing list, a security gateway, or a forwarding service, your ARC signing behavior is now part of your reputation. Honest, consistent signing is rewarded. Inconsistent or dishonest signing can land you on a trust blocklist that is almost impossible to recover from.
For a pure sender, the indirect impact is that forwarded mail is now more likely to be delivered to the inbox than it was in 2022. This is good. The tradeoff is that the forwarding infrastructure you depend on is accumulating reputation of its own. If a major corporate gateway loses trust with Gmail, every sender whose mail transits through that gateway will see a drop in deliverability to Gmail users behind that gateway. You cannot control this and you probably cannot even detect it until your reports show it. Another reason to keep your sending fundamentals clean: so you recover fast when something outside your control breaks.
What to Do This Week
If you are a sender, this post is an education exercise rather than an action list. You probably will not make any changes to your own infrastructure as a result of reading it. What you can do is look at your aggregate reports with fresh eyes. Notice which IPs represent forwarders. Notice which percentage of your volume transits through intermediate servers. Understand that some percentage of your delivery issues come from infrastructure you do not control, and that the fix is usually "make the sending fundamentals cleaner" rather than "configure something new."
If you run a mailing list, a forwarder, or a security gateway, check whether your software signs ARC headers. If it does not and there is an upgrade path, upgrade. If there is not, consider migrating to software that does. ARC is no longer optional for responsible intermediate operators in 2026, and the downstream consequences of not signing are now real.
The next time a subscriber tells you they never received your newsletter, and you confirm it was sent and authenticated correctly on your end, consider that their mailbox probably forwards through infrastructure you know nothing about. There is a whole layer of mail plumbing between you and your subscriber. ARC is one of the few tools that keeps that plumbing honest.