ARC (Authenticated Received Chain)

Why ARC matters

Here's the problem it solves: you send an email that passes all the authentication checks (SPF, DKIM, DMARC). Perfect. But then someone forwards it through their company's email server, or it goes through a mailing list that adds a footer. Those modifications can break the original authentication signatures.

What happens next? The receiving server sees a message that claims to be from you but doesn't pass authentication anymore. Spam folder. Or worse, rejected entirely.

ARC fixes this by creating a chain of trust. Each server that handles the message adds its own ARC signature, documenting that yes, this email was legitimate when it arrived here, even though we modified it slightly before passing it along. Think of it like a relay race where each runner signs off that they received the baton legitimately.

According to Google's email sender guidelines, forwarded emails are significantly more likely to fail authentication checks without ARC. That's a lot of legitimate mail getting blocked.

How does ARC work?

The protocol adds three key headers to your email as it moves through servers:

ARC-Authentication-Results records what authentication checks were performed and whether they passed. It's like a report card documenting that your email had valid DKIM and SPF when it first arrived at this server.

ARC-Message-Signature creates a cryptographic signature of the message content at that point in the journey. This proves the message hasn't been tampered with maliciously between hops (small modifications for forwarding are fine and expected).

ARC-Seal ties everything together with another signature that validates the entire chain. Each server adds its own seal, creating a linked sequence. If any link in the chain is broken or suspicious, receiving servers can spot it.

Cleverly, the chain is numbered. ARC-Seal: i=1, then i=2, then i=3. Receiving servers can verify that nothing's missing and each legitimate intermediate server has properly authenticated the previous step.

And unlike older protocols that break when content changes, ARC expects modifications. That's the whole point. It just documents that those changes happened at trusted servers, not by some attacker intercepting your mail.

Setting up ARC

ARC requires configuration on both the intermediate servers (the ones that forward or modify messages) and the receiving servers (the ones that validate the ARC chain). Most users don't need to do anything unless they run their own mail infrastructure.

In Gmail:

Gmail validates ARC signatures when receiving forwarded messages. If you're forwarding mail to Gmail, the intermediate server should add ARC headers. If you're using Google Workspace and forwarding mail through your servers to other destinations, configure your mail servers to add ARC headers. Google provides detailed guidance in their email sender guidelines for administrators managing forwarding services.

In Outlook:

Exchange Online supports ARC validation, but admins need to configure trusted ARC sealers. Go to the Microsoft Defender portal, navigate to Email & Collaboration > Policies & Rules > Threat policies > Email Authentication Settings > ARC. Add the domains of any intermediate services that handle your mail (these must match the 'd' tag in the ARC-Seal header). Good news: Microsoft 365 organizations automatically trust ARC signatures from other Microsoft 365 organizations, so that part's already handled.

In Spark:

Spark relies on the email authentication settings configured by your email provider (Gmail, Outlook, custom IMAP server or EWS accounts like Microsoft 365). As an email client, Spark doesn't handle ARC signing or validation directly. That happens at the server level before messages even reach your inbox.

For custom mail servers:

If you're running your own infrastructure, you'll need to add ARC support to your SMTP server. OpenARC is the most common implementation for Postfix and Sendmail. You'll install it, configure it to sign outgoing mail and validate incoming chains, and add the necessary configuration (similar to DKIM setup, but no DNS records needed for ARC).

The tricky part? ARC only helps if both the intermediate servers and the final receiving server support it. If the destination doesn't validate ARC, the chain doesn't matter. But adoption is growing fast. Gmail, Yahoo, Microsoft, and most major providers now validate ARC chains.

ARC best practices

Set up the core protocols first. ARC supplements SPF, DKIM, and DMARC, it doesn't replace them. Configure those authentication methods before worrying about ARC. Without proper base authentication, ARC has nothing useful to preserve.

Monitor your authentication results. Most email service providers offer reports showing how often your messages pass authentication checks. If you're seeing high failure rates on forwarded emails even with ARC, something's misconfigured. Check your headers.

Keep your DKIM keys secure. ARC builds on DKIM signatures, so if your DKIM keys are compromised, the ARC chain isn't trustworthy either. Rotate keys periodically (every six to 12 months is standard).

Test forwarding scenarios. Send test emails through mailing lists, forwarding services, and different email clients to verify ARC is working correctly. Tools like MXToolbox can help validate your setup and check headers.

Document your trusted sealers. If you're configuring ARC validation, maintain a list of which intermediate services you trust. Review this list quarterly. Services change ownership, get compromised, or shut down. Don't trust ARC signatures from services you no longer use.

Accept that not everyone supports it yet. Some smaller email providers haven't implemented ARC validation. Your forwarded emails might still get flagged with them. But the big players all support it, which covers the vast majority of your recipients.

Related terms

• DKIM
• SPF (Sender Policy Framework)
• DMARC Record
• Email Authentication