What is ARC (Authenticated Received Chain)?

Definition

The Authenticated Received Chain is an email authentication standard defined in RFC 8617, published in July 2019. Its purpose is to solve a long-standing weakness in the way SPF and DKIM behave when a message is relayed through an intermediary server rather than delivered directly from the sender to the recipient.

When you send an email straight to a recipient, SPF and DKIM checks usually succeed and DMARC passes. The problem appears when a message travels through a third party in the middle. A mailing list, an account that auto-forwards mail, or a security gateway will often change the message. It may rewrite the subject line, add a footer, or relay the message from a different IP address. Those changes break the original DKIM signature and invalidate the SPF result, which can cause DMARC to fail even though the message is perfectly legitimate.

ARC was designed by an industry group that included engineers from Google and other large mail operators specifically to give receivers a way to recognise this situation. Instead of judging only the broken authentication it sees at the final hop, a receiver can read the ARC chain and learn that the message authenticated correctly before the intermediary touched it.

How It Works

ARC works by having each participating intermediary add a cryptographically signed record, called an ARC set, to the message before it forwards it onward. Each ARC set is made up of three header fields, and each set carries an instance number so the chain can be read in order.

The first field is ARC-Authentication-Results. This captures a snapshot of the SPF, DKIM, and DMARC results that the intermediary observed at the moment it received the message. It is effectively a frozen copy of the authentication verdict at that hop.

The second field is ARC-Message-Signature. This works much like a DKIM signature. It is a cryptographic signature over the message headers and body as they exist at that point in the chain, which binds the recorded authentication result to the actual content that was present.

The third field is ARC-Seal. This is a signature that covers the entire chain of prior ARC headers, not just the current set. The seal carries a chain validation tag, written as cv, that reports the state of the chain so far. A value of none means this is the first hop, pass means every earlier ARC set validated correctly, and fail means something in the chain could not be verified.

As a message moves through several ARC-aware servers, the instance numbers increase with each hop. A receiving server that validates the message reads the ARC sets in order, confirms that no entries are missing, checks that each seal reports the prior entries as valid, and verifies the most recent message signature. If the chain holds together, the receiver can trust the authentication result that was recorded at the very first hop.

Why It Matters for Email Deliverability

ARC matters because forwarding and mailing lists are everywhere, and without ARC they quietly cause legitimate mail to be rejected. A company employee who forwards work mail to a personal account, a discussion list that adds a footer to every message, and a third-party security appliance that scans inbound mail all break DKIM or SPF in ways that have nothing to do with whether the message is genuine.

When a domain owner publishes a strict DMARC policy such as p=reject, those broken authentication results would normally cause the forwarded copy to be discarded. The recipient never sees a message they were expecting, and from the outside it looks like a delivery failure with no clear cause. ARC gives the final receiver enough context to make a better decision. If the ARC chain shows the message authenticated correctly before a trusted intermediary modified it, the receiver can choose to deliver it rather than enforce the strict policy against an honest forward.

It is important to be precise about what ARC does and does not do. ARC does not override DMARC, and it is not a guarantee of delivery. It is a signal. A receiver still decides how much to trust a given ARC chain, and that trust depends on the reputation of the intermediaries that signed it. ARC simply removes a common, frustrating source of false rejections so that good mail has a better chance of reaching the inbox.

How VeriMails Handles It

VeriMails is an email verification service, so it focuses on a different and complementary part of the deliverability picture. ARC protects messages that are already in transit through intermediaries, while VeriMails works before you ever press send, confirming that the addresses on your list are real and able to receive mail.

For every address you check, VeriMails runs syntax validation, an MX record lookup, a DNS check, a live SMTP handshake with the receiving mail server, catch-all detection, disposable address detection, and role-based address detection. That combination tells you whether an address is deliverable before it ever enters a campaign, with clear deliverability categories for campaign decisions.

The two approaches reinforce each other. ARC and the broader authentication stack of SPF, DKIM, and DMARC protect your sending reputation by proving that your mail is genuine. VeriMails protects that same reputation from the other direction by keeping invalid and risky addresses off your list, so you generate fewer bounces and fewer spam complaints. You can verify addresses one at a time through the VeriMails REST API or in batches by uploading a CSV file, and every new account starts with 100 free credits that never expire, with no credit card required.

Frequently Asked Questions