Email ARC explained (the short, useful version) — when it helps forwarded mail

ARC in one paragraph (what it does, what it doesn’t)

ARC is a way for an intermediate mail handler (a forwarder, a mailing list, a gateway) to record the authentication results it saw when it received a message, then cryptographically seal that record so downstream receivers can decide whether to trust it. In practice: it helps a receiver accept mail that fails SPF or DKIM after forwarding, by allowing the receiver to see a verifiable “at the forwarder, this message passed” statement.

ARC is not a replacement for SPF, DKIM, or DMARC. It’s an evidence chain. It doesn’t make a forged message authentic; it just gives you a trustworthy breadcrumb trail when authentication got broken by normal transit behavior (like forwarders changing the envelope sender, or mailing lists changing the body).

Why forwarding breaks SPF/DKIM/DMARC (and why that’s normal)

SPF fails because the forwarder is the one connecting

SPF checks whether the connecting IP is allowed to send mail for the envelope-from domain (MAIL FROM / Return-Path). When Alice’s provider sends to a forwarder, SPF can pass. When the forwarder later sends to your mailbox provider, SPF now evaluates the forwarder’s IP against Alice’s domain. Unless Alice’s SPF explicitly authorizes that forwarder (it won’t), SPF fails.

This isn’t a bug. SPF is doing exactly what it was designed to do: bind connecting IP to an identity. Forwarding changes the connecting IP. Game over.

DKIM fails when intermediaries modify signed content

DKIM signs selected headers and (often) the body. A forwarder that doesn’t touch the message can preserve DKIM. A mailing list that adds a footer, rewraps lines, alters Subject tags, or normalizes MIME boundaries can invalidate the signature. Some systems also re-encode content (quoted-printable vs base64) or reorder headers in ways that break fragile signing choices.

DMARC fails because it depends on SPF/DKIM and alignment

DMARC says: either SPF or DKIM must pass, and whichever passes must align with the visible From: domain (strict or relaxed alignment depending on policy). When forwarding causes SPF failure and mailing lists cause DKIM failure, DMARC fails. If the sender has a “reject” policy, your receiver is invited to drop the mail on the floor.

Joke #1: Email authentication is like a museum badge system—perfectly logical until someone holds the door for you, and suddenly you’re “unauthorized” in the gift shop.

So what does ARC change?

ARC does not resurrect SPF at the final hop. It does not force DKIM to pass after a list rewrite. It gives the receiver a sealed statement from an intermediary: “When I received it, it passed SPF/DKIM/DMARC (or didn’t). I also saw these identifiers.” Receivers can choose to accept based on that chain when it’s reasonable and the intermediary is trustworthy.

ARC parts: AAR, AMS, AS (and what each buys you)

AAR: Authentication-Results (as seen by the intermediary)

ARC carries an ARC-Authentication-Results header (AAR). It looks similar to the normal Authentication-Results header you see at receivers, but it’s inserted by the ARC intermediary. It contains the intermediary’s evaluation of SPF/DKIM/DMARC at the time it handled the message.

Why you care: this is the “what did the forwarder observe?” data. Without a seal, it would be trivial to forge. ARC’s other parts fix that.

AMS: Message Signature (binds the message to this ARC set)

ARC adds an ARC-Message-Signature header (AMS). It signs the message content (headers and optionally body) as seen at that hop. This helps downstream parties know that the AAR corresponds to this specific message state, not some copy-pasted claim.

The AMS is not “the DKIM signature.” It’s the intermediary’s signature over the message as it handled it, with ARC-specific semantics.

AS: Seal (protects the chain)

The ARC-Seal header (AS) seals the set, including references to previous ARC sets, forming a chain. Each hop that participates increments an instance counter i=. A complete chain is a series of ARC sets: i=1, i=2, i=3… each with AAR/AMS/AS.

The receiver verifies the chain and decides whether it trusts it. Verification can succeed while trust still fails. That’s the point: cryptography proves integrity, not goodness.

Trust is policy, not math

ARC can tell you “this chain was not modified.” It cannot tell you “this forwarder is competent” or “this gateway isn’t compromised.” Receivers typically combine ARC validation with reputation and heuristics about intermediaries.

One quote that belongs on the wall near every inbound mail pipeline: “Hope is not a strategy.” — paraphrased idea often attributed to Gordon Sullivan (leadership maxim used widely in operations).

When ARC helps forwarded mail (and when it’s lipstick on a pig)

ARC helps when a trusted intermediary breaks authentication downstream

ARC shines when the message is legitimate at entry to an organization, but gets forwarded or processed in a way that breaks SPF/DKIM by the time it reaches the final receiver. Typical cases:

• Simple forwarding (user forwards to another mailbox provider).
• Secure email gateways that scan and sometimes rewrite messages (URL defense, attachment sandboxing).
• Mailing lists that add footers or change Subject tags, breaking DKIM.
• Ticketing systems that re-inject mail as part of workflow.
• Multi-tenant inbound relays where the “first receiver” is an appliance, not the mailbox provider.

ARC does not help when the original message never authenticated

If the message fails SPF/DKIM/DMARC at the first competent evaluation, ARC just preserves bad news. That’s useful for forensics, but it doesn’t save deliverability.

ARC can hurt when you treat it as a universal bypass

If you start trusting ARC from random sources, you’ve reinvented “please let me spoof anyone.” ARC should be meaningful primarily for intermediaries you operate, contract, or have reason to believe are high-quality. For everyone else, treat ARC as a signal, not a skeleton key.

ARC complements, not replaces, SRS and list hygiene

SRS (Sender Rewriting Scheme) can fix SPF for forwarders by rewriting the envelope-from so SPF aligns with the forwarder’s domain. That’s great, but not universally deployed. Mailing lists can preserve DKIM by avoiding body modifications or by using DMARC-friendly From rewriting (“list rewriting”) or “reply-to munging.” Those are political and product decisions as much as technical ones. ARC is a pragmatic bridge when you can’t make the world stop forwarding.

Interesting facts & history (short, concrete)

1. ARC emerged because DMARC worked—once big senders started publishing “p=reject,” forwarders and lists felt the blast radius.
2. Mailing lists were early casualties of strict DMARC: list footers and subject tags routinely break DKIM, and SPF doesn’t survive forwarding.
3. ARC is standardized as RFC 8617 (2019), which is relatively recent for email infrastructure.
4. The “instance” counter (i=) in ARC headers is not optional; it’s how receivers know the intended order of the chain.
5. ARC reuses DKIM-style cryptography (public keys in DNS, signatures over canonicalized headers), which makes it implementable in existing mail stacks.
6. ARC doesn’t claim the sender is good; it claims an intermediary observed authentication results at a specific time and sealed them.
7. Receivers can accept a message with DMARC fail if ARC chain validates and the intermediary is trusted—this is a policy choice, not a protocol mandate.
8. ARC is one of the few “forwarding reality” standards that acknowledges email’s messy middleboxes rather than pretending they don’t exist.

Fast diagnosis playbook

The fastest way to debug ARC issues is to stop thinking in terms of “ARC good/bad” and instead answer three questions: (1) Did the message authenticate anywhere? (2) Did something break it later? (3) Is the chain verifiable and from an intermediary you trust?

First: identify the final receiver’s decision

• Look for the final hop’s Authentication-Results header.
• Note SPF/DKIM/DMARC results and any ARC evaluation results (some receivers add arc=pass/fail).
• Decision: if the receiver already says DMARC passed, ARC is probably irrelevant for deliverability; it may still matter for auditing.

Second: inspect the ARC chain structure

• Count ARC sets by i=.
• Verify you have AAR + AMS + AS for each instance.
• Decision: missing or out-of-order instances usually mean a broken implementation or a message modified mid-chain.

Third: validate cryptography and DNS keys

• Confirm the ARC seal and message signature validate against DNS keys for the signing domain(s).
• Decision: if validation fails, ARC cannot be relied upon. Fix the signer, DNS, or message handling that altered headers.

Fourth: determine where authentication broke

• Compare DKIM signatures: which one failed, which domain signed it, and whether the body was modified.
• Check SPF: which hop caused the connecting IP mismatch.
• Decision: if the intermediary is the breaker, decide whether to preserve DKIM, use SRS, or rely on ARC plus receiver trust.

Practical tasks: commands, outputs, and decisions (12+)

The commands below assume you have access to a mail gateway or a debugging host that can read stored messages (e.g., from a quarantine, a ticketing system’s raw source, or an MTA spool copy). The examples use common Linux tooling plus OpenDKIM utilities where relevant. Adjust paths and service names to your environment.

Task 1: Pull the raw message and isolate ARC headers

cr0x@server:~$ sed -n '1,/^$/p' message.eml | egrep '^(ARC-|Authentication-Results:|Received:|From:|Return-Path:|DKIM-Signature:|Message-ID:)'
Return-Path: <billing@example.com>
Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
ARC-Authentication-Results: i=1; forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=corp.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=corp.example; s=arc1; cv=none; ...
Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com
From: "Billing" <billing@example.com>
Message-ID: <...>

What it means: You have an ARC set at i=1 created by corp.example, claiming the message passed at the forwarder. The receiver sees failures now.

Decision: Proceed to ARC validation; if the chain validates and you trust corp.example, you may treat the message as legitimate forwarding fallout.

Task 2: Count ARC instances and check for completeness

cr0x@server:~$ grep -E '^ARC-(Authentication-Results|Message-Signature|Seal):' -n message.eml | sed -E 's/.* i=([0-9]+).*/i=\1/' | sort | uniq -c
      3 i=1

What it means: Three ARC headers for i=1 implies a complete ARC set (AAR+AMS+AS) for that instance.

Decision: If you see fewer than 3 per instance, expect receivers to distrust the chain or treat it as malformed.

Task 3: Verify ARC seal and AMS with OpenDKIM (when available)

cr0x@server:~$ opendkim-testmsg -A -d corp.example -s arc1 < message.eml
opendkim-testmsg: ARC-Seal pass (i=1)
opendkim-testmsg: ARC-Message-Signature pass (i=1)

What it means: The message matches what the ARC signer sealed, and DNS keys for arc1 under corp.example validate.

Decision: If this fails, ARC can’t be used to justify accepting the mail. You’ll fix DNS keys, canonicalization, header rewriting, or the ARC signing configuration.

Task 4: Fetch the ARC public key from DNS and sanity-check it

cr0x@server:~$ dig +short TXT arc1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."

What it means: ARC uses DKIM-style DNS publication. If this record is missing, wrong, or truncated, validation fails.

Decision: If TXT is split weirdly or absent, fix DNS. If you rotated keys, confirm caches and propagation behavior.

Task 5: Check DMARC policy of the original sender domain

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=r"

What it means: Strict DKIM alignment (adkim=s) plus reject means small authentication deviations will be punished.

Decision: If you operate a forwarder for your users, you should plan on ARC and/or SRS; otherwise you will continue to lose messages.

Task 6: Inspect SPF policy and understand why forwarding fails

cr0x@server:~$ dig +short TXT example.com | head -n 2
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

What it means: The forwarder’s IP isn’t listed, so SPF fails at the final receiver when the forwarder sends onward.

Decision: Don’t “fix” this by adding your forwarder IP to someone else’s SPF (you can’t). Use SRS or ARC, or preserve DKIM.

Task 7: Check if DKIM broke due to message modification (body hash mismatch)

cr0x@server:~$ opendkim-testmsg -v < message.eml | sed -n '1,20p'
opendkim-testmsg: dkim=fail (body hash did not verify)
opendkim-testmsg: key retrieved from DNS

What it means: The signature key exists, but the body changed after signing.

Decision: Identify the modifier (mailing list footer, gateway URL rewrite, content filter). Either stop modifying, sign again (with your own DKIM/ARC), or rely on ARC where receivers trust you.

Task 8: Confirm whether your gateway is rewriting content (common culprit)

cr0x@server:~$ grep -iE 'X-(IronPort|Proofpoint|Mimecast|Barracuda|Symantec|MS-Exchange|Spam|Virus|Scanned)' -n message.eml | head
142:X-Proofpoint-Virus-Version: vendor=baseguard engine=...
143:X-Proofpoint-ORIG-GUID: ...

What it means: Security middleware is involved, often rewriting URLs or adding banners—both can break DKIM.

Decision: If you must rewrite, implement ARC signing at the last point of modification and ensure you preserve received headers and ARC headers correctly.

Task 9: Validate that your MTA is not stripping ARC headers

cr0x@server:~$ postconf -n | egrep '^(header_checks|smtp_header_checks|cleanup_service_name|receive_override_options)'
header_checks =
smtp_header_checks =
cleanup_service_name = cleanup
receive_override_options =

What it means: No explicit header checks shown. If you have header filters, they may remove ARC-* headers “for safety.”

Decision: If header checks exist, audit them. Stripping ARC breaks the chain and removes evidence your downstream provider may rely on.

Task 10: Grep for header checks that remove ARC

cr0x@server:~$ sudo egrep -Rin 'ARC-|Authentication-Results|REMOVE|IGNORE' /etc/postfix | head -n 20
/etc/postfix/header_checks:12:/^ARC-/ IGNORE

What it means: Someone decided ARC headers are “untrusted” and configured Postfix to drop them.

Decision: Stop doing that unless you have a very specific threat model and you’re replacing ARC with your own signing at a controlled boundary.

Task 11: Check OpenDKIM/OpenARC milter connectivity (classic production failure)

cr0x@server:~$ sudo journalctl -u postfix -u opendkim -u openarc --since "1 hour ago" | egrep -i 'milter|openarc|opendkim|connect|timeout|error' | tail -n 20
postfix/cleanup[22102]: warning: connect to Milter service unix:/run/openarc/milter.sock: No such file or directory
postfix/cleanup[22102]: warning: milter unix:/run/openarc/milter.sock: can't read

What it means: Postfix can’t talk to the ARC signer/verifier. Your mail will transit without ARC handling, or worse, with partial headers.

Decision: Fix the milter service and restart. Then re-test with a known-forwarding scenario and verify ARC sets appear.

Task 12: Confirm the ARC signer is actually enabled and signing outbound/forwarded mail

cr0x@server:~$ sudo grep -RinE 'OpenARC|milter_default_action|milter_protocol' /etc/postfix/main.cf
/etc/postfix/main.cf:27:smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:28:non_smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:29:milter_default_action=accept
/etc/postfix/main.cf:30:milter_protocol=6

What it means: The milters are wired in for both SMTP-received and locally generated mail flows, and failure mode is accept (mail flows even if milter is down).

Decision: For high assurance, consider tempfail during incidents (with care). For most enterprises, accept keeps mail flowing while you page the right people.

Task 13: Check OpenARC configuration for signing domain/selector alignment

cr0x@server:~$ sudo egrep -n '^(Domain|Selector|KeyFile|Socket|AuthservID)' /etc/openarc.conf
AuthservID mailgw1.corp.example
Domain corp.example
Selector arc1
KeyFile /etc/openarc/keys/corp.example/arc1.private
Socket local:/run/openarc/milter.sock

What it means: Your ARC signer claims identity as corp.example using selector arc1.

Decision: Make sure DNS has the matching public key. Also ensure the signing identity represents a boundary you control (gateway domain, not a random subdomain you forget to renew).

Task 14: Confirm that forwarded mail is leaving through the expected host (so ARC is applied)

cr0x@server:~$ grep -n '^Received:' -m 6 message.eml
12:Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
18:Received: from forwarder.corp.example (198.51.100.25) by mx.receiver.example ...

What it means: The forwarder is the re-sender. That is exactly the forwarding pattern that breaks SPF and triggers DMARC pain.

Decision: If the re-sender isn’t your ARC-signing gateway, route forwarded mail through the gateway that signs ARC, or you’ll never have consistent evidence.

Task 15: Check for multiple Authentication-Results headers and interpret them

cr0x@server:~$ grep -n '^Authentication-Results:' message.eml
25:Authentication-Results: forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
61:Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com

What it means: The forwarder saw success; the final receiver saw failure. That’s the canonical ARC use case.

Decision: If your forwarder supports ARC, prefer adding ARC rather than inventing local allowlists. Allowlists rot; ARC gives traceable evidence.

Task 16: Prove whether a mailing list footer is breaking DKIM

cr0x@server:~$ awk 'BEGIN{p=0} /^$/{p=1} {if(p) print}' message.eml | tail -n 20
--
You received this message because you are subscribed to Corp List.
To unsubscribe, visit: ...

What it means: A footer was appended, which often breaks DKIM body hash.

Decision: For lists, either avoid modifying the body, or ARC-sign after modification so downstream receivers can trust that the list handled a previously-authenticated message.

Three corporate mini-stories from the trenches

Mini-story #1: The incident caused by a wrong assumption

A global company rolled out a new “customer email forwarding” feature in their SaaS portal. Customers could forward receipts, alerts, and compliance notices to any address. The product team assumed forwarding was “just SMTP routing.” They validated that messages left their system and arrived somewhere. Job done.

Two weeks later, support tickets hit a weird pattern: some customers received everything, some received almost nothing, and a few received the messages only when they removed forwarding. The internal dashboards were clean; queue depth was normal. The system was “working.”

The mail headers told the real story. The original sender used DMARC with a strict policy. When the customer forwarded from Provider A to Provider B, SPF failed at Provider B (because the forwarder’s IP wasn’t authorized), and DKIM failed because the forwarder normalized MIME boundaries. DMARC went to fail, and Provider B honored the sender’s “reject.”

The wrong assumption wasn’t technical; it was organizational: they believed deliverability was “best effort.” The result was invoices not delivered, compliance notices delayed, and finance teams doing workarounds in spreadsheets. Eventually they implemented ARC signing at the forwarding boundary and adjusted their gateway to preserve DKIM where possible. The tickets didn’t disappear overnight, but the failures became explainable and fixable. That’s a win in production.

Mini-story #2: The optimization that backfired

An enterprise security team deployed a URL defense system that rewrote every link in inbound mail. They were proud. The CPU graphs were good, the click-tracking reports were shiny, and phishing simulations improved.

Then the business unit running partner onboarding started missing time-sensitive contract emails. The messages weren’t in quarantine; they were rejected upstream. This is the worst kind of failure: your system doesn’t even have the evidence because someone else refused to accept it.

The security gateway had been placed in front of the mail provider and was rewriting messages before delivery. That broke DKIM for many senders. On its own, broken DKIM is survivable—SPF might still pass. But forwarding and sub-routing meant SPF wasn’t stable either. DMARC failures stacked up. Partners using “p=reject” were being honored by the recipient side.

They “optimized” by stripping unknown headers to reduce storage and prevent “header injection.” Unfortunately that included ARC headers. So even when upstream forwarders had created a valid ARC chain, the gateway removed the evidence and re-inserted a blank slate. Receivers downstream had no reason to trust what they were seeing.

The fix was boring and humbling: stop stripping ARC, add ARC signing after rewriting, and align the architecture so the last modifier is also the signer. Security kept their rewrite. The business got their contracts. Operations got fewer midnight escalations and more daylight.

Mini-story #3: The boring but correct practice that saved the day

A large B2B firm ran a pair of inbound gateways in active/active. Nothing fancy: Postfix, OpenDKIM, OpenARC, a clear separation between “edge accept” and “internal delivery.” They also had a policy: every inbound sample from quarantine gets stored with full headers for 30 days, and every change to header handling requires a peer review by someone who has been burned before.

During a vendor migration, they flipped a forwarding rule so that certain mailboxes were delivered via an internal ticketing system. Tickets started missing external emails from a particular bank. The bank’s DMARC policy was strict. The ticketing system modified the message body to add a case banner. DKIM broke. SPF failed because the ticketing system re-sent with the original envelope-from. DMARC failed and the final mailbox provider rejected.

Because they stored raw messages, they could compare the “pre-ticketing” and “post-ticketing” versions. The diff was obvious: a banner footer was added. Because they had peer-reviewed header handling, ARC was still intact up to the gateway, and they already had OpenARC ready to sign. They changed only one thing: the ticketing system’s outbound path routed through the gateway that ARC-signed after modifications.

That’s it. No vendor blame, no magical allowlists, no permanent exception rules. Just a stable boundary: if you modify mail, you sign what you deliver, and you keep enough telemetry to prove it. Boring systems keep businesses running. Exciting systems keep incident responders employed.

Joke #2: The only thing more eternal than email is the meeting about why email is eternal.

Common mistakes: symptoms → root cause → fix

1) “ARC is present but receivers ignore it”

Symptoms: ARC headers exist; deliverability still fails; receiver shows DMARC fail and no mention of arc=pass.

Root cause: ARC chain doesn’t validate (bad key, modified headers), or receiver doesn’t trust the ARC signer domain, or ARC set is incomplete/malformed.

Fix: Validate the chain cryptographically; ensure DNS keys exist; ensure your signer is stable and reputable; don’t strip/modify ARC headers mid-flight.

2) “We enabled ARC signing, but the chain validation fails intermittently”

Symptoms: Sometimes ARC-Seal validates, sometimes not; failures correlate with certain message sizes or content types.

Root cause: Downstream processing changes canonicalized headers/body after signing (antivirus banners, rewrapping, line ending normalization).

Fix: Sign at the last point of modification. If you must modify after signing, you must re-sign (new ARC instance) at the new boundary.

3) “Forwarded mail fails SPF and DMARC; we assumed ARC would fix it”

Symptoms: SPF fail, DMARC fail at final receiver; ARC chain either missing or not trusted.

Root cause: No ARC signing at the forwarder, or forwarder isn’t a participant; plus SPF failure is expected without SRS.

Fix: Implement SRS for SPF survivability and/or ARC signing at the forwarder. If you don’t control the forwarder, preserve DKIM and avoid modifications; otherwise accept you can’t force remote receivers to accept.

4) “Mailing list posts vanish from some corporate domains”

Symptoms: Posts from domains with DMARC reject never arrive; others do.

Root cause: List modifies the message, breaking DKIM; SPF fails on list remail; DMARC rejects.

Fix: Either stop modifying (no footers), use From rewriting for DMARC, or implement ARC so receivers can credit the list’s observation of authentication.

5) “We stripped ARC headers because they’re ‘user supplied’”

Symptoms: ARC chains never validate downstream; partners complain about forwarded deliverability.

Root cause: Header sanitation policy deletes ARC-* along with other headers; breaks chain integrity.

Fix: Don’t strip ARC if you rely on it. Instead, sign a new ARC instance at your boundary. If you must strip, do it before you generate your own ARC set and accept that upstream evidence is discarded.

6) “ARC signing domain doesn’t match our organizational boundary”

Symptoms: ARC validates but receivers still distrust; or your own downstream filtering can’t build trust rules.

Root cause: ARC uses a random subdomain, a vendor domain, or an unstable hostname that isn’t consistently reputation-bearing.

Fix: Sign with a domain you control and will keep long-term (e.g., corp.example). Make sure the selector and key rotation are managed like any other critical identity.

Checklists / step-by-step plan

Checklist A: Decide if you actually need ARC

1. Do you operate forwarding (user aliases, routing rules, ticketing re-injection, listserv)? If no, ARC is mostly observational.
2. Do you routinely modify messages in transit (banners, URL rewrite, DLP stamps)? If yes, you’re in ARC territory.
3. Are you seeing DMARC-related rejects from major senders? If yes, ARC may be the least-worst lever.
4. Can you instead preserve DKIM by not modifying content? If yes, do that first. ARC is for when you can’t.
5. Can you implement SRS for forwarders? If yes, do it; it reduces SPF pain and complements ARC.

Checklist B: Implement ARC at a controlled boundary (the sane way)

1. Pick the boundary host(s): the last place where messages are modified before leaving your control.
2. Publish stable DNS keys: create selector arc1 (or similar), publish TXT record, and verify retrieval from multiple resolvers.
3. Enable ARC signing: wire OpenARC (or your chosen implementation) as a milter on the boundary MTA.
4. Do not strip upstream ARC unless you have a clear policy; if you do strip, always create your own ARC instance afterward.
5. Monitor validation failures: treat ARC signing like DKIM—key rotation, DNS failures, and canonicalization changes are operational risks.
6. Test real flows: forwarding between providers, mailing list posts, ticketing re-injection, and “security rewrite on/off” scenarios.

Checklist C: Operational readiness (SRE basics applied to email)

1. Log and retain raw headers for samples (quarantine or journaling) long enough to debug multi-day delivery failures.
2. Add a canary: a daily forwarded message from a DMARC “reject” domain you control in a lab, so you detect breaks early.
3. Alert on milter downtime (OpenARC socket missing, timeouts, or error rates).
4. Document the “last modifier signs” rule. Enforce it in change reviews.
5. Keep a runbook mapping: which systems modify mail, which sign DKIM, which sign ARC, and where routing changes happen.

FAQ

1) Does ARC make DMARC pass?

No. DMARC is evaluated based on SPF/DKIM results and alignment at the receiver. ARC gives the receiver verifiable evidence that authentication passed earlier, and some receivers may accept despite DMARC fail.

2) If I add ARC, can I stop caring about SRS?

Don’t. SRS fixes SPF survivability for forwarding; ARC helps explain and sometimes mitigate failures. They solve different parts of the forwarding mess. In many environments, using both is the most stable outcome.

3) Should every MTA sign ARC?

No. Sign ARC at meaningful boundaries: forwarders, mailing lists, security gateways, ticketing re-injection points. Random internal relays signing ARC just adds chain noise and operational overhead.

4) Can attackers forge ARC headers?

They can forge the headers syntactically, but they can’t forge a valid chain without the signing private key. The real risk is receivers trusting ARC from low-quality or compromised intermediaries. Trust is the hard part.

5) What breaks ARC validation most often?

Header/body modifications after signing, DNS key issues (missing, rotated incorrectly), and “helpful” header sanitation rules that strip or reorder signed headers.

6) We run a mailing list. What’s the best approach?

First try to avoid modifying the body and preserve DKIM. If you must modify, implement ARC signing so receivers can see you handled a previously authenticated message. Also consider DMARC-friendly list behaviors (like From rewriting), but that’s a policy decision with community implications.

7) How do I know whether receivers trust my ARC?

You don’t get a universal guarantee. Some receivers will surface ARC evaluation results in headers; others won’t. The practical method is controlled testing: send/forward messages through your system to common mailbox providers and analyze acceptance patterns.

8) Is ARC relevant if we already have DKIM on outbound mail?

Yes, if you forward or modify inbound mail. Your outbound DKIM doesn’t protect the original sender’s DKIM. ARC is about preserving authentication context across intermediaries.

9) What’s the difference between Authentication-Results and ARC-Authentication-Results?

Authentication-Results is a receiver’s statement about what it evaluated. ARC-Authentication-Results is an intermediary’s statement, sealed by ARC so downstream receivers can verify it wasn’t tampered with.

10) Can ARC help with internal phishing defenses?

Yes, as telemetry. ARC can tell you whether a message likely authenticated at the edge before being transformed internally. But don’t treat ARC as a phishing bypass; treat it as evidence that feeds your risk scoring.

Conclusion: next steps you can actually do this week

ARC is not a silver bullet. It’s a chain of custody for authentication results. That sounds bureaucratic, which is exactly why it works: email is a bureaucracy with SMTP ports.

1. Pick one failing forwarded flow (ticketing, list, user forwarder). Capture a raw message with full headers.
2. Determine what broke: SPF due to forwarding? DKIM due to modifications? DMARC due to alignment?
3. Find the last modifier and make that host the ARC signer. Don’t sign earlier and hope nothing changes.
4. Stop stripping ARC headers unless you replace them with your own ARC instance at a controlled boundary.
5. Set up a canary and alerting for milter health and ARC validation failures before the business finds out first.

Then do the unglamorous part: keep the keys published, rotate them intentionally, and treat mail authentication as production identity infrastructure. Because it is.