Deliverability
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.
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.
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:
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:
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:
If forwardingexample.com doesn’t have an SPF record that includes example.com, the recipient’s server might reject the message.
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:
If the DKIM signature was created for example.com but the forwarding service changes the header to forwardingexample.com the message will fail.
DMARC requires alignment with both SPF and DKIM in terms of the “From” domain. Here’s how it could fail:
If the forwarding service changes the “From domain to forwardingexample.com, alignment will fail since example.com was expected domain.
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.
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.
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.
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.
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.
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).
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.
Send me the Mailjet Newsletter. I expressly agree to receive the newsletter and know that I can easily unsubscribe at any time.
