Blog · Dmarc
What Is ARC in Email Security? Cisco Ironport Just Added Support - Here Is What Changes
What Is ARC in Email Security?
ARC stands for Authenticated Received Chain. It is an email authentication protocol defined in RFC 8617 that tracks what happens to a message as it passes through intermediate servers.
Here is the problem it solves. When you set DMARC to p=reject, forwarded messages and mailing list traffic often stop working. The forwarding server changes the message. The From header no longer matches the SPF or DKIM result. DMARC sees a mismatch and rejects the mail.
This is a real issue for any organization that runs mailing lists, forwards mail across domains, or uses internal mail relays.
ARC creates a cryptographic record of the original authentication results at each step of the delivery chain. When the message arrives at its final destination, the receiving server can check the ARC chain and see what authentication results existed before the forwarding or list processing happened.
How ARC Works: The Three Header Fields
ARC adds three header fields to every message that passes through an ARC-enabled server.
ARC-Authentication-Results (AAR)
This records the authentication results that were present when the message passed through this server. It captures SPF, DKIM, and DMARC results and tags them with the instance number.
ARC-Message-Signature (AMS)
This signs the message headers and body at this step in the chain. It uses the same DKIM approach but applies to the current state of the message after any modifications made by this server.
ARC-Seal (AS)
This is the critical piece. The AS header field seals the entire ARC set, including all previous AAR and AMS headers. It proves the chain has not been tampered with between servers. Think of it like a notarized chain of custody for your message authentication results.
Each server that handles the message adds one more instance to the chain, incrementing the sequence number (i=1, i=2, i=3, and so on).
Sealer vs. Validator: Who Does What
An ARC Sealer is any mail server that modifies or forwards a message and wants to preserve its authentication history. This includes mailing list software like Mailman, forwarding services, and internal mail relays that rewrite headers.
An ARC Validator is the receiving mail server at the final destination. When a message arrives with ARC headers, the validator checks each seal, verifies the signatures, and evaluates the chain before deciding what to do with the message.
If the chain is intact and valid, the receiving server can use the ARC results to inform its DMARC policy decision. A message that would have failed DMARC alignment because of forwarding might still be delivered if the ARC chain shows it originated from a legitimate source.
The DMARC Interaction: Why ARC Matters When You Use p=reject
Here is a concrete example. You run a mailing list at lists.example.com. A subscriber sends a message to the list. The mailing list server receives it, modifies it (adds headers, changes the Subject line, sometimes rewrites content), and re-sends it to all subscribers.
Without ARC: the original SPF and DKIM results came from the subscriber is original mail server. The mailing list server is now the sender. The From header still shows the subscriber, but the envelope mail from is the list server. DMARC alignment fails. If your domain uses p=reject, that message gets blocked.
With ARC: the mailing list server seals the original authentication results. When the message reaches a subscriber is mail server, the ARC chain shows the original SPF and DKIM results were valid. The receiving server can make an informed decision instead of flatly rejecting based on alignment failure.
This is why ARC matters for anyone running mailing lists or dealing with forwarded mail while also using strict DMARC policies.
What Cisco Ironport's ARC Support Means in Practice
Cisco Ironport is one of the most widely deployed enterprise email gateway products. Its addition of ARC support covers four areas.
ARC Sealing
Ironport can now apply ARC seals to outgoing messages that pass through the gateway. If your organization sends mail through Ironport and that mail gets forwarded or processed by a third party, the original authentication results are preserved in the chain.
ARC Verification
Incoming messages with ARC headers can be verified by Ironport. The gateway checks the chain integrity and passes or fails the ARC validation accordingly.
Policy Override
Messages with valid ARC chains can be granted exceptions to local DMARC policy. If a message would normally be quarantined or rejected due to DMARC alignment failure, but the ARC chain is intact and the original authentication was valid, Ironport can deliver it.
Header Visibility
ARC validation status is integrated into Ironport is message tracking and reporting. You can see whether incoming messages have valid ARC chains and what the validation result was.
This is a meaningful addition for Ironport customers because it bridges the gap between strict DMARC enforcement and the reality of mailing lists and forwarded mail.
Who Should Enable ARC on Cisco Ironport?
You should care about this update if any of the following apply.
You run mailing lists or distribution groups that forward messages to external recipients while your domain uses DMARC p=reject. ARC prevents those forwarded messages from being rejected by the recipient is mail server.
You are planning to move from DMARC p=none to p=reject and want a safety net for legitimate forwarded mail during the transition.
You manage a mixed environment where internal mail relays or third-party services process messages before they reach external recipients.
You want better visibility into the authentication chain for messages that pass through intermediate servers.
What You Need to Configure ARC on Cisco Ironport
Configuration requires AsyncOS 15.0 or later. You need to enable ARC processing in the email gateway settings.
DNS configuration depends on your setup. If you want other servers to validate your outgoing ARC seals, you need to publish an ARC seal key in DNS. Ironport generates this key automatically.
Testing matters. Send a test message through your intended forwarding path and check the headers at the receiving end. You should see ARC-Seal, ARC-Authentication-Results, and ARC-Message-Signature headers with increasing instance numbers.
After enabling, monitor your DMARC aggregate reports closely. This is where DMARCFlow helps: it can track alignment failure rates across your domains, flag when forwarded or ARC-sealed messages are passing or failing DMARC, and show you which forwarding paths are most active. Before moving to p=reject, you want to know exactly how many legitimate forwarded messages would be affected. Monitoring your aggregate reports with a tool that surfaces forwarding chain data makes that visible.
ARC Limitations and Considerations
ARC is defined in RFC 8617 as an Experimental protocol. The specification may still change, and interoperability between different implementations is not fully guaranteed.
Not all receiving mail servers validate ARC today. Some major providers including Google and Microsoft check ARC headers on incoming messages, but many smaller mail hosts do not yet support it. Enabling ARC sealing does not guarantee your forwarded mail will be accepted everywhere.
ARC does not replace DMARC. It is a companion protocol that makes DMARC p=reject more compatible with real-world mail flows that involve forwarding and mailing lists. You still need SPF, DKIM, and DMARC to be correctly configured.
ARC cannot fix authentication failures that existed before forwarding. If the original message failed SPF, DKIM, and DMARC, the ARC chain will show that. ARC preserves results; it does not create valid authentication where none existed.
Frequently Asked Questions
Is ARC a replacement for DMARC?
No. ARC works alongside DMARC. It preserves authentication results but does not authenticate messages on its own. You still need correctly configured SPF, DKIM, and DMARC records for ARC to be useful.
Does ARC work with all mail servers?
No. ARC validation support varies by provider. Major providers like Google and Microsoft validate ARC, but many smaller mail hosts do not. Using ARC does not guarantee delivery to all recipients.
What happens if ARC validation fails?
If the ARC chain is broken or the seal is invalid, the receiving server treats the message as if no ARC chain exists. The DMARC policy is applied normally. ARC failures do not cause rejection on their own; they just remove the safety net.
Can ARC help with mailing list delivery to strict DMARC domains?
Yes. If your mailing list server seals outgoing messages with ARC, and the recipient is mail server validates ARC, the original authentication results are preserved. This can allow legitimate list traffic to be delivered even when DMARC alignment would otherwise fail.
Does DMARCFlow support ARC monitoring?
DMARCFlow can track ARC-related DMARC aggregate report data, giving you visibility into how many ARC-sealed messages are passing DMARC alignment and where forwarding chains are active. This helps you understand your mail flow before moving to stricter DMARC policies.
---