In our DMARC article we set a rule: take your domain's DMARC to reject so no one can send fake mail in your name. A correct rule — but it has a side effect, and that side effect can cause some of your legitimate emails to be rejected. The culprit is an innocent operation we all use daily: email forwarding. When an email passes through a mailing list or is auto-forwarded from one account to another, SPF and often DKIM break — and DMARC can mistake a genuinely legitimate email for a "fake" one and reject it.
In this fourth article of our Mail Technologies Series we cover the standard designed to solve exactly this: ARC (Authenticated Received Chain). ARC "seals" the authentication result that breaks during forwarding and carries it reliably to the next server. The goal is the same as always: even a non-technical manager should get a clear answer to "why do my legitimate emails sometimes get rejected, and how does ARC solve it."
1. First, the Problem: Why Does Forwarding Break SPF and DKIM?
The three mechanisms from our first article fare differently against forwarding:
- SPF almost always breaks: SPF checks "is the IP of the server sending this email authorized for the sending domain?" When mail is forwarded A→B→C, the mail reaching C was sent by B's server; but SPF still looks at the original domain's allowed IPs. Since B's IP isn't on that list, SPF returns fail.
- DKIM usually survives — but not always: DKIM signs the content and ignores the IP, so it generally survives simple forwarding. But if a mailing list adds a subject tag ("[List] ..."), pastes a footer, or alters the content, the signature breaks and DKIM fails too.
- DMARC looks at both: For DMARC to pass, SPF or DKIM must pass and be aligned. In forwarding, if SPF is already broken and DKIM has been broken by a list — DMARC fails, the email is rejected. Yet the email is entirely legitimate.
In short: DMARC reject is the right rule; but forwarding can trigger it against legitimate emails too. ARC closes this gap.
2. What Does ARC Do? The "I Verified It, Trust Me" Chain
ARC's idea is this: when an intermediate server (mailing list, forwarding service, security gateway) receives the mail, it sees the authentication result (SPF/DKIM/DMARC) at that moment — not yet broken. ARC attaches this "clean" result to the mail with a seal (ARC-Seal) and says: "When I received this mail, authentication was passing; I guarantee this with my signature."
When the mail goes to the next stop, even if SPF/DKIM are broken there, the receiving server looks at the ARC seal: "I recognize the trusted intermediary that forwarded this mail, and it verified the mail was legitimate at its source. So despite SPF/DKIM broken by forwarding, I can accept this mail." ARC preserves and carries the original link of the broken identity chain.
ARC has three components (conceptually)
- ARC-Authentication-Results: Records the SPF/DKIM/DMARC result at the moment the intermediary received the mail.
- ARC-Message-Signature: Signs the mail's content at that moment (DKIM-like).
- ARC-Seal: Seals all previous ARC headers, guaranteeing the chain's integrity; every new stop adds its own seal to the chain.
3. A Critical Nuance: ARC Provides a "Trail," Not "Trust"
The most common way to misunderstand ARC is to think it's a magic "always accept" button. It isn't. ARC only helps when it's the seal of a trusted intermediary — the receiving server decides on the trustworthiness of the party that placed the ARC seal. An ARC seal from an unknown or untrusted intermediary doesn't rescue the mail on its own. So ARC makes it possible to ask "do you trust the intermediary that forwarded this mail?"; it doesn't make the answer automatically "yes."
That's why ARC produces the most value among large, trusted intermediaries (Microsoft 365, Google Workspace, major mailing-list services, enterprise email security platforms) — because receiving servers are inclined to trust these actors' seals.
4. When Do You Encounter It in Practice?
- Mailing/distribution lists: Mail passing through lists like "info@" or "announce@" can break DKIM with subject/footer changes; ARC rescues these.
- Auto-forwarding: "Forward every incoming email to this address" rules set by employees (note: in our ATO article we saw these abused too).
- Flow between security layers: When mail passes through a security service and reaches Microsoft 365, the intermediate layer's ARC seal ensures DMARC evaluation works correctly.
- When taking DMARC to reject: Before moving to
reject, making sure your legitimate forwarding scenarios are protected by ARC prevents accidental loss of legitimate mail.
5. What Should You Do as an Organization?
Good news: most of the time you don't set up ARC manually. Large platforms like Microsoft 365 and Google Workspace support ARC natively and automatically evaluate ARC seals on incoming mail. Your job is more about correct configuration and correct sequencing:
- Do the DMARC journey in the right order: First watch reports with
p=none(as in our DMARC article), see your legitimate forwarding sources in the reports, verify ARC protects them, then progress toquarantineandreject. A blind jump torejectloses legitimate mail in organizations that have forwarding. - Know your trusted intermediaries: Know which lists and services are part of your mail flow; DMARC reports make this visible.
- Choose compatible layers: Make sure the email security platform you use handles ARC correctly — otherwise the security layer itself can break legitimate mail.
Check Point Harmony Email & Collaboration, with its API-based architecture, works in harmony with the ARC evaluation of Microsoft 365 / Google Workspace; it analyzes incoming mail without breaking the authentication chain and helps you manage your DMARC journey (none→reject) with reports.
Frequently Asked Questions
Do I need to set up ARC separately?
For most organizations, no. Microsoft 365 and Google Workspace support ARC natively and evaluate it automatically on incoming mail. Your job is to progress DMARC in the right order (none→reject) and verify that your legitimate forwarding sources are protected in the reports.
Does ARC replace DMARC?
No — ARC complements DMARC. DMARC asks "is the sender genuine"; ARC prevents that question from mistakenly getting a "no" due to forwarding. Together they both block fake mail and protect legitimately forwarded mail.
Is every email with ARC automatically accepted?
No. An ARC seal carries value only if it comes from a trusted intermediary. The receiving server decides whether to trust the party that placed the seal; an ARC seal from an unknown intermediary doesn't rescue the mail on its own. ARC provides not trust, but a trail on which trust can be evaluated.
My legitimate emails started getting rejected after I set DMARC to reject — what should I do?
The classic forwarding problem. Look at your DMARC reports to find which source (which list/forwarding service) is failing; assess whether that source is protected by ARC and whether it's a trusted intermediary. Usually the fix is mapping these sources with reports before moving to reject — which is exactly what our field audit does.
What Should You Do Now?
If you plan to take DMARC to reject or are experiencing legitimate mail loss after doing so, ARC and your forwarding map are critical. Start with two questions: (1) Which legitimate forwarding/list sources are in your mail flow? (2) Are they protected when you tighten DMARC?
- Free Field Audit: We read your DMARC reports, map your legitimate forwarding sources, and lay out a safe path to reject.
- Managed DMARC journey: We manage the none→quarantine→reject transition without legitimate mail loss, in harmony with ARC.
About this article: The fourth article of our Mail Technologies Series; it adds the forwarding scenario on top of the SPF/DKIM/DMARC foundation from the first article. The next will cover a guide to reading email headers. Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level, holding Email, Endpoint & Browser, Mobile, and SASE Solution Specialization accreditations. The author, Kemal Özleyen, is a cybersecurity engineer certified as a Check Point Workspace Security Expert.
