What ARC on Cisco/Ironport Means for Email Admins

What changed

Cisco/Ironport has added support for ARC, the Authenticated Received Chain protocol (RFC 8617). Ironport is one of the most widely deployed enterprise email gateways, and its adoption of ARC matters for anyone managing email authentication. If you run Ironport or deal with forwarded mail in your organization, this changes what you can monitor and what you can finally stop guessing about.

What ARC actually is

ARC solves a specific problem that has plagued email administrators for years: DMARC fails when email is forwarded.

Here is why. DMARC checks whether the domain in the From header aligns with the domain that passed SPF or DKIM. When a message passes through a forwarding service, a mailing list, or a security gateway that modifies headers, the From domain may stay the same while the authentication results no longer apply to the new handler. The forwarding service did not send the original message, so SPF and DKIM fail alignment checks even though the message was never spoofed.

ARC fixes this by creating a documented chain of custody. As a message passes through each ARC-enabled handler, that handler records what authentication results it observed and what it did with the message. This chain is signed and sealed so later handlers can verify it was not tampered with.

In short: ARC tells receivers "here is what authentication looked like when this message left the original sender, and here is every hop it went through since." DMARC alone cannot tell you that.

The three ARC header fields

ARC adds three header fields to every message it handles:

ARC-Authentication-Results (AAR) -- Records the authentication assessment at this hop. This is the same information that goes into Authentication-Results headers, but preserved and timestamped at each step.

ARC-Message-Signature (AMS) -- Protects the message headers and body at this hop, similar to how DKIM works. The AMS signature covers the message content as it existed when this handler processed it.

ARC-Seal (AS) -- A cryptographic seal applied by each ARC handler. The chain of seals lets any downstream handler verify that the ARC chain has not been modified. If any handler in the chain broke authentication or modified headers in a way that was not disclosed, the chain invalidates.

Think of it like a signed ledger. Each handler adds its entry. If someone tears out a page or changes an entry, the seals downstream will not verify.

Why this milestone matters for enterprise email

Enterprise email environments are full of multi-hop flows. A message might originate from a SaaS tool, pass through a marketing email gateway, then through a security scanning service, then land in a user mailbox. Without ARC, each hop breaks the authentication chain. Without ARC, each hop can silently discard or alter authentication results that the original sender worked hard to establish.

When a major gateway like Ironport emits ARC seals, the entire multi-hop chain becomes traceable. Security teams can finally see which handler modified a message, where authentication results changed, and whether the final receiver has enough context to make a correct trust decision.

For DMARC specifically, this has a direct practical implication: organizations that could not move to p=reject because forwarding broke legitimate mail may find that ARC-enabled forwarding preserves enough context to make p=reject viable. The fear of breaking forwarding is still real, but ARC is the protocol designed to make forwarding and DMARC enforcement compatible.

This is not theoretical. Google and Yahoo started requiring DMARC alignment for bulk sender compliance in 2024. As more major receivers enforce DMARC strictly, senders who forward mail need a way to preserve authentication context. ARC is that way.

What DMARC reports do not tell you (and ARC does)

DMARC aggregate reports show you pass and fail counts, but they do not show you the chain of handlers that touched a message. If a message failed DMARC at your receiver, you know it failed. You do not necessarily know why, or which handler in the chain modified it.

ARC closes that gap. When a message fails DMARC at a receiver that also checks ARC, the receiver can look back at the ARC chain and see whether the failure was inherited from an earlier hop or introduced at a later one. This matters for troubleshooting: a DMARC failure caused by a forwarding service is a different problem than a spoofing attempt, and ARC helps you distinguish between them.

Here is a concrete example. A user forwards work email to a personal Gmail address through their company Ironport gateway. Without ARC, the forwarded message fails DMARC at Gmail because the forwarding MTA is not in the SPF/DKIM alignment. The company DMARC report shows a failure from an external IP they do not recognize, and there is no way to tell whether this is a spoofing attempt or a known forwarding pattern. With ARC, the failure traces back to the forwarding step: the original authentication was clean, the forwarding service is the break point, and the security team has something concrete to act on.

This is also where DMARCFlow comes in. Standard DMARC monitoring tools process aggregate reports and show pass/fail counts. DMARCFlow reads the ARC chain alongside DMARC data, so you can see the full hop history for forwarded messages rather than just the end result. For Ironport environments, this makes the difference between knowing something failed and knowing why it failed.

What email admins should do now

If you run Ironport, check whether ARC sealing is enabled in your current configuration. Ironport documentation covers how to enable ARC for both inbound and outbound processing. If it is not already on, evaluate turning it on for inbound processing first, since that is where forwarding chains will benefit most.

If you are already monitoring DMARC reports, start looking for messages that include ARC headers alongside DMARC authentication failures. The combination of DMARC and ARC data gives you a fuller picture of what is happening in your email flows. Tools that correlate both data sources will show you which forwarding patterns are causing DMARC failures in your aggregate reports, and whether those forwarding services are now ARC-aware.

If you are considering moving to p=reject, review your current forwarding patterns. Any legitimate forwarding chain that does not yet support ARC is a potential break point. ARC does not eliminate all forwarding risks, but it makes them visible and diagnosable in a way they were not before.

How DMARCFlow helps you read ARC headers

DMARCFlow reads and parses ARC headers from forwarded and multi-hop mail. Most DMARC monitoring tools focus on aggregate pass/fail counts. DMARCFlow goes further and surfaces the ARC chain information that standard DMARC reports do not include.

This means you can see not just that a message failed DMARC, but whether the failure traces back to a forwarding service, a mailing list, or an inline security gateway. That diagnostic context is what makes ARC data actionable rather than just more noise in your reports.

For Ironport environments specifically, DMARCFlow can correlate ARC chain data with your inbound mail flows, giving you a clearer picture of which legitimate forwarding patterns are affecting your DMARC compliance rates.