Deliverability
What is Authenticated Received Chain and why should you care?
Email authentication is crucial for combating phishing and ensuring the integrity of messages. One significant development in this arena is Authenticated Received Chain (ARC). But what exactly is ARC, and why does it matter?
PUBLISHED ON
Authentication has been a top-of-mind topic in the email world for some time, but it feels like the buzz has grown after the announcements made by Google and Yahoo in October 2023 around sender requirements. A big requirement is the implementation of SPF, DKIM, and DMARC for bulk senders, which means we also need to talk about ARC which picks up the slack if these authentications break.
Table of contents
Incorrect SPF records
DKIM Alignment
DMARC Alignment
How do intermediary servers sign the message?
How does the receiving server validate ARC?
ARC email example
What is Authenticated Received Chain?
Authenticated Received Chain (ARC) is a standard designed to address authentication challenges in email delivery, particularly when messages pass through intermediary servers like mailing lists or forwarding services. It was developed in 2016 to support other authentications which can sometimes break when messages are passed through these intermediaries.
Curious about the buzz around email authentications? Learn more in our post on the Gmail and Yahoo sender requirements which spurred an increase of adoption for authentications like DMARC.
Before delving deeper into the depths of ARC, let's recap our existing email authentications. There are three key authentications that all work together, DMARC, SPF, and DKIM. DMARC verifies with both SPF and DKIM to validate sender identity and message authenticity to protect against bad actors.
However, intermediary servers in the email delivery process, such as forwarding services and mailing lists, can inadvertently break DMARC authentication, leading to legitimate emails being marked as spam or rejected. This is where ARC comes in. ARC helps overcome the limitations of existing email authentications by preserving authentication data throughout the email delivery process, including through intermediaries.
The adoption of ARC offers several benefits:
Improves email deliverability by reducing the likelihood of spoofing and building trust in the message's origin and content so it is not flagged as spam.
Bolsters email security by verifying the chain of custody.
Helps with email troubleshooting by providing valuable insights into the path an email took and any intermediary servers it encountered along the way.
How can intermediary servers break authentications?
ARC operates by creating a verifiable chain of custody for email messages. This is important because the intermediary servers we mentioned may alter the integrity of the original message in some way causing authentication to fail. Here are a few basic examples of how authentications may fail without ARC:
Incorrect SPF records
SPF is a standard email authentication that aims to detect cases of email spoofing by validating with the sender’s domain. Here’s how it might fail using an email forwarding service:
Original sender: OGbob@example.com
Forwarding service: Forwardingexample.com
Recipient: Bob@example.com
If forwardingexample.com doesn’t have an SPF record that includes example.com, the recipient’s server might reject the message.
DKIM Alignment
DKIM is another standard email authentication that uses encrypted keys and a signature in the header to validate authentication. Here’s how it could fail:
Original sender: OGbob@example.com
Forwarding service: Forwardingexample.com
Recipient: Bob@example.com
If the DKIM signature was created for example.com but the forwarding service changes the header to forwardingexample.com the message will fail.
DMARC Alignment
DMARC requires alignment with both SPF and DKIM in terms of the “From” domain. Here’s how it could fail:
Original sender: OGbob@example.com
Forwarding service: Forwardingexample.com
Recipient: Bob@example.com
If the forwarding service changes the “From domain to forwardingexample.com, alignment will fail since example.com was expected domain.
How does ARC work?
Now that we know why we need ARC, let’s talk about how it works, and why it doesn’t break when other more robust authentications do. ARC is a protocol that is simply designed to create a trusted chain of authentication so that any additional headers or changes made by intermediaries don’t cause the message to fail.
How do intermediary servers sign the message?
When an email passes through an intermediary server, that server adds its cryptographic signature to the message header, indicating that it has handled the message. This signature is added without altering the original message content to ensure the integrity of the email.
How does the receiving server validate ARC?
The recipient's server examines the ARC headers to validate the authenticity of the intermediary servers' signatures when the message is received. By verifying the chain of custody, the receiving server can prove the message hasn't been tampered with and that it originates from a legitimate source.
ARC email example
To better understand ARC in action, let's look at a scenario:
Imagine Company A sends an email to Company B, but the message passes through several intermediary servers, including a mailing list service and an email forwarding service. With ARC enabled, each intermediary server adds its signature to the message header, allowing Company B to verify the chain of custody and ensure the email's authenticity.
The header passes through each hop on the message journey and is used by each mail server to validate authentication.
Learn more about the email journey in our post: How does email work?
How do you implement ARC?
If you manage your own email infrastructure, implementing ARC involves configuring your email server to generate and validate ARC headers as messages are processed. This typically requires integrating ARC-specific software or modules into your email server infrastructure and defining policies for handling messages with invalid or missing ARC headers. This ensures compatibility with existing email authentication mechanisms like SPF, DKIM, and DMARC, and regularly updating your configuration to align with evolving ARC specifications and best practices.
If all of that sounds like a lot, don’t worry, we’ve got you covered.
ARC is automatically implemented for Sinch Mailgun users
If you are a Sinch Mailgun user, you don’t have to do a thing.
Mailgun has enhanced MTA to use the Authenticated Received Chain (ARC) protocol with all inbound and forwarded messages that go through Mailgun. This means we have released support for ARC and now evaluate DKIM and SPF, and add signed ARC headers if messages are forwarded using our Routes (inbound emails), as well as messages that are sent to or are replied to on a mailing list.
In the authentication example below, you can see that by using ARC, the results are passed through each hop from each mail server throughout the chain. And that the results are defined for each passing authentication (DKIM, SPF, and DMARC).
Final thoughts
Standards like ARC play a crucial role in safeguarding against phishing attacks and ensuring the integrity of email communications. By addressing the limitations of existing authentications, ARC offers a solution to validate the message chain no matter the intermediary servers a message might pass through. As organizations continue to prioritize email security, the adoption of ARC will become more widespread.
At Sinch Mailgun, we like to try and stay ahead of the game, and part of that is keeping you updated on emerging technologies and industry news. Want to stay in the loop? Be sure to subscribe to our newsletter so you don’t miss a beat.
