Email Authentication ARC: How It Works, Setup, and Troubleshooting

Email authentication ARC is the mechanism to understand when legitimate mail is forwarded, processed by a mailing list, or changed by a security gateway and then starts failing SPF, DKIM, or DMARC. It does not replace those protocols; it supplies signed evidence about what a trusted intermediary observed before the message changed.

What email authentication ARC means

ARC stands for Authenticated Received Chain. Defined by RFC 8617, it lets mail handlers add an ordered, cryptographically signed record of the authentication assessment they made when they processed a message. A downstream receiver can validate that record and use it as additional input when deciding whether to accept, junk, quarantine, or reject a message. (rfc-editor.org)

The key word is additional. ARC does not make a failing message pass DMARC by itself, does not override a recipient’s spam filters, and does not prove that every message passing through an intermediary is safe. It gives the recipient evidence that a specific system saw specific SPF, DKIM, and DMARC results at an earlier point in the delivery path.

That makes ARC especially useful for indirect mail flows:

• A user forwards mail from one mailbox to another.
• A mailing list adds a subject tag, footer, or unsubscribe content.
• A secure email gateway removes an attachment or rewrites links.
• An inbound service routes messages through an archive, help desk, CRM, or ticketing system.
• A group or alias service redistributes a message to many recipients.

ARC is published as an IETF Experimental RFC. That label describes the protocol’s standards-track status, not whether it is used operationally. Microsoft 365 documents ARC as a way to preserve original authentication information when legitimate intermediaries modify incoming mail. (learn.microsoft.com)

The forwarding problem ARC is designed to solve

Email authentication is evaluated at a particular moment and from a particular network location. Forwarding and modification can make a legitimate message look suspicious at the final destination.

Why SPF commonly fails after forwarding

SPF checks whether the IP address delivering a message is authorized by the envelope sender domain’s SPF policy. In a basic forward, the forwarder—not the original sender’s authorized server—connects to the final recipient. The final recipient can therefore see an unauthorized IP for the original envelope sender and return an SPF failure.

This is not necessarily a configuration error by the original sender. It is a consequence of forwarding without a mechanism such as Sender Rewriting Scheme (SRS) to change the envelope sender. ARC does not repair SPF at the final hop; it preserves evidence that SPF may have passed when the intermediary first received the message.

Why DKIM can fail after modification

DKIM signs selected headers and a hash of the message body. If a mailing list adds a footer, a gateway rewrites a URL, an archive changes content encoding, or an attachment-removal tool edits the message, the original DKIM signature can fail.

Some forwarding leaves the message untouched, in which case the original DKIM signature can still verify. But you should never design a mailing-list or gateway flow around the assumption that it always will. A small change to a signed header or body is enough to invalidate a DKIM signature.

Why DMARC follows those failures

DMARC passes when either SPF or DKIM passes and the passing identifier aligns with the visible From: domain. If forwarding causes SPF to fail and modification breaks the aligned DKIM signature, DMARC can fail too—even if the original sender authenticated correctly before the intermediary handled the mail.

Microsoft describes this exact sequence for altered inbound messages: a new source IP can cause SPF failure, content changes can cause DKIM failure, and the combination can cause DMARC failure. (learn.microsoft.com)

ARC creates a signed chain of custody around the earlier results so the final receiver has more context than the final-hop SPF/DKIM/DMARC verdict alone.

ARC versus SPF, DKIM, and DMARC

A useful way to avoid implementation mistakes is to assign each protocol one job.

ARC is therefore not an outbound-domain baseline in the same way as SPF, DKIM, and DMARC. Gmail’s sender guidance requires senders to implement SPF or DKIM, and requires bulk senders sending more than 5,000 messages per day to Gmail accounts to implement SPF, DKIM, and DMARC. ARC is not a substitute for those requirements. (support.google.com)

For a normal application sender, the priority remains straightforward:

1. Configure SPF for every authorized sending service.
2. Enable DKIM signing with the domain visible in From: where possible.
3. Publish and monitor DMARC before moving to an enforcement policy.
4. Make sure each transactional and marketing platform is authorized and aligned.
5. Investigate ARC only if your mail is redistributed or you operate an intermediary that changes mail.

In other words, do not add ARC headers to an app’s outbound receipt emails merely because you read that ARC helps deliverability. If your app sends directly through an email provider to a mailbox provider, ARC is usually not your job. The party operating the forwarding, list, or modifying gateway is normally the party that seals ARC sets.

The three ARC headers, decoded

Each ARC-aware intermediary adds an ARC set. A valid set consists of three headers with the same instance number, written as i=. The first ARC-enabled intermediary creates i=1; each later ARC sealer adds the next sequential instance. ARC’s model is an ordered set of handling assertions, not one mutable header. (rfc-editor.org)

1. ARC-Authentication-Results (AAR)

ARC-Authentication-Results records the authentication results the intermediary saw when it accepted the message. It resembles the familiar Authentication-Results: header used by mail systems.

Illustrative example:

ARC-Authentication-Results: i=1; mx.forwarder.example;
 dkim=pass header.d=sender.example header.s=s2025;
 spf=pass smtp.mailfrom=sender.example;
 dmarc=pass header.from=sender.example

This says the first ARC sealer, mx.forwarder.example, observed passing DKIM, SPF, and DMARC results at its point in the path. It is an assertion, not proof on its own—which is why ARC signs it.

2. ARC-Message-Signature (AMS)

ARC-Message-Signature is a DKIM-derived signature over the message as the intermediary received or produced it. It helps later systems determine whether the portion of the message covered by that ARC signer has changed since that ARC set was made.

An abbreviated example looks like this:

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=forwarder.example; s=arc2025; t=1735689600;
 h=from:to:subject:date:message-id:mime-version;
 bh=BASE64_BODY_HASH; b=BASE64_SIGNATURE

The important operational fields are i= for the ARC set number, d= for the signing domain, s= for the DNS selector, and a= for the signing algorithm. The b= field holds the signature; it is intentionally long and commonly folded across lines.

3. ARC-Seal (AS)

ARC-Seal seals the ARC chain. It signs the relevant ARC headers from this and preceding sets so a later party cannot silently alter, remove, reorder, or splice the prior ARC history.

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example;
 s=arc2025; t=1735689600; cv=none; b=BASE64_SIGNATURE

The cv= tag communicates the signer’s validation result for the chain that existed before it added its own set:

• cv=none means no prior ARC chain existed. This is normal for i=1.
• cv=pass means the signer validated the chain it received before appending its own set.
• cv=fail means the signer found the prior chain invalid.

A later set should normally be sequential and have a coherent chain-validation history. For example, an i=2 ARC set with cv=pass is plausible after a valid i=1 set; an i=3 set with no i=2 is a structural warning sign.

How ARC validation works at the receiving side

A receiving system does not simply read dmarc=pass from an AAR header and trust it. It validates the cryptographic and structural chain first, then decides how much weight to give the signer.

At a high level, a receiver performs these checks:

1. Collect the ARC headers and group them by their i= values.
2. Check structure: each ARC instance needs one AAR, one AMS, and one AS; instances must run continuously from 1 through the newest value.
3. Retrieve public keys in DNS using the s= selector and d= signing domain.
4. Validate the AMS and AS signatures using the DKIM-derived ARC rules.
5. Evaluate the chain-validation values and determine whether the latest complete chain passes.
6. Apply local policy: decide whether the sealers are trusted enough and whether the prior results should influence delivery.

The crucial final step is local policy. A syntactically correct, cryptographically valid ARC chain is not an unconditional allow-list entry. A receiver can still consider phishing signals, malware verdicts, sender reputation, content, user complaints, and local anti-abuse policy.

That boundary protects recipients. If every valid ARC signature forced delivery, any domain able to sign ARC could turn itself into a universal bypass. RFC 8617 instead frames ARC as evidence that mail handlers may use to inform disposition decisions and to identify systems that break other authentication mechanisms. (rfc-editor.org)

Who needs to configure ARC—and who does not

The most practical question is not “How do I enable ARC for my domain?” It is “Which system changes or redistributes mail, and which receiving system needs to evaluate the evidence?”

You are the original sender

If you send product emails, invoices, password resets, or newsletters directly through an ESP or transactional email API, set up SPF, DKIM, and DMARC. You generally do not need to operate an ARC signer merely because recipients may forward your messages.

Your responsibility is to ensure the message is correctly authenticated before it enters the mail ecosystem. Signing ARC as the originator does not solve changes made later by a list or forwarder. Good DKIM coverage and alignment remain your best defense against ordinary forwarding problems.

You operate a mailing list, alias service, or forwarder

You are a strong ARC candidate if you accept a message, assess its authentication, then resend it while changing it or changing the delivery path. Mailman’s documentation, for example, recommends ARC signing for indirect flows such as mailing lists and describes ARC configuration as a combination of authentication assessment and cryptographic key management. (docs.mailman3.org)

You run a security or email-processing gateway

You may need ARC if the gateway removes attachments, sanitizes HTML, rewrites URLs, adds banners, journals messages, or otherwise modifies mail before a downstream mailbox service evaluates it. The gateway must be able to authenticate mail accurately before modification and protect its signing key.

You receive mail in Microsoft 365

Microsoft 365 administrators can configure specific trusted ARC sealers when a legitimate intermediary regularly modifies messages before delivery to their tenant. Microsoft advises adding only legitimate, required services; it then uses the original authentication information from that trusted ARC sealer during authentication assessment. (learn.microsoft.com)

This is a receiver-side trust decision. It is separate from publishing the ARC signer’s DNS key and separate from the sender’s DMARC record.

How to implement ARC on an intermediary

ARC is usually enabled in a mailing-list manager, mail security gateway, MTA milter, or hosted forwarding product—not in an application’s ordinary SMTP library. Exact screens, packages, and field names depend on your mail stack, but the implementation sequence is consistent.

Step 1: Map the actual mail flow

Document the path with real hostnames and actions. For each hop, record:

• Where SPF, DKIM, and DMARC are checked.
• Whether the system modifies headers, body content, attachments, or envelope recipients.
• Whether the system forwards unchanged messages or generates a new outbound copy.
• Which domain will appear in the ARC signer’s d= tag.
• Which teams control DNS, private keys, and outbound mail configuration.

Do this before generating a key. ARC applied at the wrong place can attest to incomplete or untrusted authentication results.

Step 2: Authenticate before modifying

The ARC sealer needs reliable authentication results for the message as received. Configure it to evaluate SPF, DKIM, and DMARC itself, or to consume Authentication-Results: only from specifically trusted upstream authentication servers.

Never treat arbitrary Authentication-Results: headers arriving from the public internet as authoritative. An attacker can inject headers that look persuasive unless your system knows which authentication service produced them.

Step 3: Generate and store an ARC signing key

ARC uses DKIM-style signing and public-key discovery. Choose a selector, such as arc2025, and a signer domain you control, such as forwarder.example. Generate the key pair in the ARC-capable product or a compatible key-management workflow.

The public key is published at:

arc2025._domainkey.forwarder.example

A typical DNS record has DKIM key-record syntax:

arc2025._domainkey.forwarder.example. IN TXT
"v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

ARC implementations commonly use this selector-and-domain lookup model. Sympa’s ARC/DKIM key documentation, for example, specifies publishing the public key at <selector>._domainkey.<signer domain> and shows a v=DKIM1 TXT record format. (sympa.community)

Keep the private key only on the signing system or a dedicated secrets service. Do not paste it into a shared ticket, source repository, or chat thread. Use a selector that can be rotated later; a dated selector makes a key rollover easier to reason about.

Step 4: Configure signing after assessment and before outbound delivery

Enable ARC only after authentication assessment has completed and before the message leaves your intermediary. The system should add all three headers—AAR, AMS, and AS—in the same processing stage.

If your intermediary also rewrites a subject, appends a footer, or strips content, do those transformations before it creates the ARC message signature. Otherwise your own changes may immediately invalidate the AMS you just generated.

Step 5: Preserve existing ARC sets

If the message already has ARC headers, your system must validate the incoming chain, add the next instance, and set cv= accordingly. Do not overwrite i=1, renumber the chain, or delete prior ARC sets merely because your system is adding its own.

If the incoming chain is invalid, your signer should reflect that result rather than disguising it. ARC is valuable precisely because each hop can communicate whether it considered the prior chain valid.

Worked example: mailing list forwarding to Microsoft 365

Assume sender.example sends a legitimate announcement to team@lists.example. The list system at lists.example adds [Team] to the subject and a footer, then redistributes the message to a member whose mailbox is hosted in Microsoft 365.

Before ARC

1. sender.example sends with From: updates@sender.example.
2. SPF passes at the list server because the connection came from an authorized sender IP.
3. DKIM passes at the list server using d=sender.example.
4. DMARC passes because the aligned DKIM or SPF identifier matches sender.example.
5. The list changes the subject and appends a footer.
6. The list sends onward to Microsoft 365.
7. Microsoft 365 sees the list server’s IP, not the sender’s authorized infrastructure, so original SPF may fail.
8. The list’s changes invalidate the original DKIM body or header signature.
9. DMARC can fail because neither aligned SPF nor aligned DKIM survives at the final hop.

With ARC enabled on the list

At step 4, before making modifications, the list records what it observed and then signs the message it will forward:

ARC-Authentication-Results: i=1; lists.example;
 dkim=pass header.d=sender.example header.s=s2025;
 spf=pass smtp.mailfrom=sender.example;
 dmarc=pass header.from=sender.example

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=lists.example; s=arc2025;
 h=from:to:subject:date:message-id:mime-version;
 bh=BASE64_BODY_HASH; b=BASE64_SIGNATURE

ARC-Seal: i=1; a=rsa-sha256; d=lists.example; s=arc2025;
 cv=none; b=BASE64_SIGNATURE

Microsoft 365 still performs normal authentication on the message it receives. Direct SPF and original DKIM can still fail because forwarding and modification occurred. But if the ARC chain verifies and lists.example is a legitimate, explicitly trusted ARC sealer for this inbound flow, Microsoft 365 can use the earlier signed results in its authentication decision. Microsoft documents this configuration specifically for intermediaries that modify inbound messages and thereby trigger SPF, DKIM, and DMARC failures. (learn.microsoft.com)

The success condition is not “every header says pass.” It is: the final receiver sees a valid ARC chain from the expected sealer, recognizes the original authentication evidence, and handles the known-good indirect flow as intended without broadly weakening spoofing protection.

How to test that ARC works

Testing ARC needs more than sending yourself a message and seeing it arrive. You need to inspect raw headers and validate the intended failure-and-recovery scenario.

Build a controlled test path

Use a sender domain with correctly configured SPF, DKIM, and DMARC. Send a uniquely identifiable test message through the intermediary, ensuring that the intermediary performs the same action it performs in production—such as adding a footer, rewriting a subject, or forwarding to an external mailbox.

Test at least two destinations if possible: one mailbox provider where you can inspect full message source and the actual destination that has the delivery problem. A message that looks good in your own system may be assessed differently by the downstream provider.

Inspect the raw source

Search the delivered message source for all three ARC header names. Then check:

1. Every ARC instance has an AAR, AMS, and AS.
2. The i= numbers are contiguous: 1, 2, 3, and so on.
3. The AAR at the first sealing hop reports the authentication results you expect.
4. d= names the signer domain you intended to use.
5. s= resolves to the published public-key record at selector._domainkey.domain.
6. i=1 uses cv=none; a later valid signer normally uses cv=pass after validating the prior chain.
7. The destination’s authentication results show a passing ARC evaluation where that receiver exposes one.

Do not confuse the message’s normal Authentication-Results: header with ARC-Authentication-Results:. The former reports the receiver’s current evaluation; the latter carries a signed record of an earlier intermediary’s evaluation.

Verify DNS separately

Use a DNS lookup tool to retrieve the exact TXT record for the selector shown in ARC-Seal and ARC-Message-Signature. For the worked example, query:

arc2025._domainkey.lists.example TXT

A missing record, incorrect selector, malformed p= value, or DNS publishing delay will prevent downstream verification. When rotating keys, publish the new selector before enabling it in the signer, then leave the old selector published long enough for messages signed with it to finish delivery and be investigated.

ARC troubleshooting: common failures and fixes

Failure: ARC headers are absent

Likely cause: ARC is not enabled in the mail-processing product, the flow bypasses the signing node, or a later system strips the headers.

Fix: Trace one message hop by hop. Confirm the signing module runs after authentication and before outbound delivery. If headers exist immediately after the list or gateway but disappear later, find the downstream system that removes them.

Failure: arc=fail or a signature cannot be verified

Likely cause: The signer’s DNS key cannot be found, the selector is wrong, the private key does not match the public key, a signed field changed after signing, or ARC sets are malformed.

Fix: Compare the live d= and s= tags to the exact DNS name. Check that the system has the matching active private key. Verify that the signer adds ARC only after all planned message transformations. Also look for duplicate, missing, or out-of-sequence i= values.

Failure: ARC passes but the message still goes to junk

Likely cause: ARC is not a delivery guarantee. The receiver may not trust that sealer, may see phishing or malware signals, or may score the message poorly for unrelated reputation or content reasons.

Fix: Confirm that the original authentication results were genuinely good, that the ARC signer is expected for this flow, and that no other security controls are triggering. Do not respond by broadly allow-listing the sender or trusting every ARC signer you see.

Failure: Microsoft 365 still treats the flow as unauthenticated

Likely cause: The trusted sealer is not configured, the configured domain does not match the ARC d= value, the chain is invalid, or the service modifying mail is not the one you thought it was.

Fix: In the Microsoft Defender portal’s email authentication settings, add only the required trusted ARC signer domain for the affected service. Microsoft’s guidance is explicit that this option is for legitimate modifying intermediaries and that the trusted signer must be a service you actually use. (learn.microsoft.com)

Failure: A list signs ARC but records bad source data

Likely cause: The list trusted an attacker-supplied authentication-results header, did not authenticate incoming mail itself, or sealed the message after modifications rather than recording the original assessment.

Fix: Define trusted upstream authentication servers, run local SPF/DKIM/DMARC checks where appropriate, and make the pre-modification authentication state the basis of the AAR.

Operational and security rules for ARC

ARC expands the set of systems that can influence a receiver’s trust decision. Treat your ARC signer like security infrastructure, not like a cosmetic deliverability toggle.

Keep the signer population small

Only systems that truly mediate indirect mail should seal ARC. A company-wide outbound relay that never forwards or modifies third-party mail may not need it. Every additional sealer adds key-management work, an attack surface, and a reputation dependency.

Protect and rotate keys

Use separate selectors for planned rotations, protect private keys with least privilege, and document which service uses each selector. Remove or revoke obsolete keys deliberately rather than losing track of them. A DNS key record proves control of a signing key, so an exposed ARC private key is a security incident.

Monitor exceptions, not just passes

Track ARC validation failures, unexpected signer domains, repeated cv=fail results, missing sets, and mail flows where direct DMARC fails but ARC is relied upon. Those signals can reveal broken forwarding, a misconfigured gateway, or an intermediary whose behavior changed.

Keep normal email authentication strong

ARC works best when it preserves credible original evidence. Continue to maintain SPF authorization, DKIM signing, DMARC alignment, and legitimate sending-domain reputation. ARC cannot compensate for an origin sender that never authenticated its mail correctly.

The practical takeaway

Email authentication ARC is a targeted solution for a targeted problem: legitimate intermediaries can break direct authentication signals while forwarding or altering mail. It preserves signed context from the point before that breakage happened.

If you are an original sender, prioritize SPF, DKIM, and DMARC. If you operate a mailing list, forwarder, or modifying gateway, evaluate ARC signing and make sure your system authenticates mail before it changes it. If you receive affected mail in Microsoft 365, trust only the exact ARC sealers required for known legitimate flows.

The best ARC implementation is narrow, testable, and observable: a known intermediary, a controlled signing key, an accurate pre-modification authentication record, a valid chain, and a receiver policy that treats ARC as useful evidence rather than a blanket bypass.

FAQ

Is ARC required for email authentication?

No. ARC is not a replacement for SPF, DKIM, or DMARC, and it is not a universal sender requirement. It is most useful when a legitimate intermediary forwards or modifies mail in a way that breaks direct authentication at the destination.

Do I need an ARC DNS record for my sending domain?

Usually not if you only send normal application or marketing email. An ARC signer publishes a DKIM-style public key under its own selector and signing domain. The intermediary that seals mail—not necessarily the original From: domain—needs that DNS record.

Can ARC make a DMARC-failing message deliver?

It can give a receiving provider trustworthy context about an earlier passing authentication assessment, but it does not force delivery or override recipient policy. The receiver decides whether it trusts the ARC sealer and whether other security signals permit delivery.

What does cv=none mean in ARC?

It normally appears on the first ARC set, i=1, because there was no earlier ARC chain to validate. Later sealers use cv=pass or cv=fail to communicate whether they validated the chain received from prior intermediaries.

Why does my message have ARC headers but still fail DKIM?

ARC does not restore the original DKIM signature after a body or signed-header modification. It records and signs the fact that an intermediary observed an earlier result, while the destination can still correctly report that the original DKIM signature no longer verifies on the modified message.