ARC (Authenticated Received Chain) Explained

ARC email authentication is a mechanism that lets each server handling a message record and cryptographically sign the authentication results it observed, so a later server can judge the message on the whole chain of evidence rather than only on what it sees at the last hop. It exists because forwarding routinely breaks SPF and DKIM, and ARC gives receivers a way to keep legitimate forwarded mail flowing without abandoning DMARC.

What ARC email authentication actually is

ARC stands for Authenticated Received Chain. It is defined in RFC 8617 and its purpose is narrow: preserve authentication verdicts across intermediaries.

When a message passes through a forwarder, mailing list, ticketing system or alias, the receiving server at the end sees a message that may have failed SPF and DKIM — not because the sender did anything wrong, but because the message was relayed. ARC lets each hop in that path attach a signed record of what it saw, so the final receiver can look back and see that the message authenticated cleanly at an earlier point.

Three things ARC is not:

• It does not replace SPF, DKIM or DMARC. It sits on top of them and reports on them.
• It does not whitelist a sender. A valid ARC chain is evidence, not permission.
• It is not a deliverability guarantee. It addresses one specific failure mode: forwarded mail that fails authentication.

ARC is a receiver-side trust signal. Adoption is voluntary, and not every mailbox provider evaluates ARC headers when making a filtering decision. Your job as a sender is to make sure the underlying authentication is correct in the first place — the SPF, DKIM and DMARC setup check walks through that.

Why forwarding breaks SPF and DKIM

The problem ARC solves is mechanical, and it helps to see exactly where each check fails.

SPF validates the envelope sender against the IP address that connected to the receiving server. When a mailbox forwards a message, the connecting IP belongs to the forwarder, not to the original sender. The original sender's SPF record does not authorize the forwarder's IP, so SPF fails.

DKIM validates a cryptographic signature over selected headers and the message body. It survives forwarding only if those parts are untouched. Mailing lists that append a footer, prefix the subject line with a tag, or rewrite headers invalidate the signature. The message is then unsigned as far as the final receiver is concerned.

DMARC builds on both. It checks whether the domain that passed SPF or DKIM aligns with the domain in the From header, then applies the published policy. A message that passed DMARC at the original delivery can fail DMARC at the forwarded destination, because both underlying checks failed there.

This shows up in ordinary situations: a university alumni address forwarding to a personal mailbox, a corporate catch-all alias routing to a team inbox, a mailing list redistributing to subscribers, a helpdesk system ingesting mail, or a "forward to a friend" link. In every case the sender's authentication is intact at the origin and broken at the destination.

How ARC works, hop by hop

ARC adds three headers per participating hop, and each hop increments an instance number so the sets can be ordered.

The first intermediary that supports ARC adds instance i=1 with all three headers. The next adds i=2, and so on. The seal is the important part: because each seal covers the ARC headers that came before it, a later hop can detect whether an earlier ARC set was altered or removed. Tampering with the chain is visible.

At the final receiver, the ARC validator checks the chain in order. If the chain is intact and the earliest hop recorded a DMARC pass, the receiver has evidence it can weigh when making its own DMARC decision.

That last sentence matters. ARC is an input to the receiver's judgment, not an override of it. The receiving system still applies its own policy, its own reputation data and its own filtering. A valid chain does not force delivery.

A worked example: a mailing list in the middle

The following scenario is illustrative, not a real case.

Step 1. A sender at example.com sends a campaign to a subscriber at a university address. The university server checks the message: SPF passes, DKIM passes, DMARC passes. It records those results.

Step 2. The subscriber has a forwarding rule that sends university mail to a personal mailbox at another provider.

Step 3. The forwarder relays the message from its own IP address. At the final receiver, SPF fails because that IP is not authorized in example.com's SPF record. If the forwarder also appended a footer, DKIM fails too.

Step 4. If the forwarder supports ARC, it adds its own AAR, AMS and ASeal recording what it saw at that hop — SPF fail, DKIM fail, DMARC fail. But the earlier ARC set from the university server already recorded the DMARC pass at hop 1.

Step 5. The final receiver validates the chain, sees an intact chain with an authenticated DMARC pass at the earliest hop, and can use that as a signal when deciding what to do with the message.

Without ARC, the same flow gives the final receiver nothing but failures. Depending on the sender's DMARC policy, the message may be quarantined or rejected — and the subscriber never learns that forwarding was the reason.

Why ARC matters for senders and receivers

For senders, the stakes are tied to DMARC policy. If you publish p=quarantine or p=reject — which is the direction most sending domains are heading — forwarded copies of your mail can be blocked. The subscribers affected are often your most engaged ones, and they have no way to know their forwarding rule is the cause. ARC gives receivers a path to keep that mail flowing without weakening DMARC for everyone else.

For receivers, ARC reduces false positives on legitimate forwarded mail while still allowing them to reject messages with broken or absent chains.

The limits are worth stating plainly:

• ARC only helps if the forwarder participates and the final receiver evaluates it.
• A broken chain — for example, a forwarder that modifies headers after sealing — provides no benefit.
• ARC does not fix a sender whose own SPF, DKIM and DMARC are misconfigured. If your domain is not authenticated at origin, there is no clean verdict for anyone to preserve.

ARC is one layer in a broader transport security picture. The foundation underneath it is still your own domain's authentication.

How to check whether ARC is working

You can verify ARC behaviour yourself in a few minutes.

1. Send a test message through a forwarder you control to a mailbox whose raw headers you can inspect.
2. Open the raw headers. In Gmail that is "Show original"; in Outlook it is the message properties or internet headers view.
3. Look for the three ARC headers — ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results.
4. Count the instances. You should see i=1, then i=2 and so on, in order. A missing or out-of-order instance means the chain is broken.
5. Read the AAR at the earliest hop to see what the original receiver recorded for SPF, DKIM and DMARC.
6. Check your own DMARC aggregate reports (the rua address). Forwarded mail failing authentication often shows up there before you hear about it from a subscriber.

Support varies between mailbox providers, and some publish their ARC handling in documentation. Test rather than assume.

Where Mailerflow fits

Mailerflow handles own-domain sending with guided DKIM, SPF and DMARC setup and automatic verification, so the authentication foundation that ARC depends on is configured and checked for you. It also suppresses bounces and complaints automatically, monitors reputation and applies warm-up limits — useful when you are ramping a new sending domain.

To be clear about scope: ARC headers are generated by forwarders and evaluated by receivers. Mailerflow does not generate or validate ARC headers. Your job as a sender is to get SPF, DKIM and DMARC right, and that is the part Mailerflow automates. More detail is on the deliverability page.

Related terms

SPF (Sender Policy Framework). A DNS record that lists which IP addresses are authorized to send mail for a domain. It is checked against the envelope sender and the connecting IP, which is why forwarding breaks it.

DKIM (DomainKeys Identified Mail). A cryptographic signature added to a message, covering selected headers and the body. It survives forwarding only if those parts are not modified.

DMARC. A policy and reporting framework built on top of SPF and DKIM. It adds domain alignment and tells receivers what to do when authentication fails.

Alignment. Whether the domain that passed SPF or DKIM matches the domain in the visible From header. Without alignment, a pass does not satisfy DMARC.

Sealing. The ARC-Seal mechanism that chains each hop's ARC headers to the previous set, making later tampering detectable.

Forwarding. The relay scenario that breaks SPF and, frequently, DKIM — the exact problem ARC was designed to address.

BIMI. A separate branding mechanism that displays a logo next to authenticated mail. It depends on a strong DMARC policy, so it sits downstream of getting authentication right.

FAQ

Does ARC replace DMARC? No. ARC feeds the receiver's DMARC decision by preserving earlier authentication results. DMARC remains the policy layer.

Do I need to configure ARC as a sender? No. ARC is implemented by forwarders and evaluated by receivers. As a sender, your work is SPF, DKIM and DMARC on your own domain.

Will ARC fix my deliverability? No. It addresses forwarded mail specifically. Other deliverability problems — list hygiene, engagement, infrastructure reputation — are separate.

Does every mailbox provider support ARC? No. Support varies, so test with the providers that matter to your list rather than assuming.

Can ARC be spoofed? The seal chain makes tampering with earlier ARC sets detectable, but ARC is a signal a receiver weighs, not an absolute guarantee.

Set up your sending domain in Mailerflow with guided DKIM, SPF and DMARC and automatic verification.