ARC or Authenticated Received Chain helps overcome the shortfalls of DMARC, further strengthening the overall email security standards. ARC is an extension of the existing email authentication standards– SPF, DKIM, and DMARC– that has opened gates for validating the sending sources of emails when they pass through multiple intermediate servers.
Let’s delve deeper into understanding how ARC helps troubleshoot email authentication-related problems by providing valuable insights into the path traveled by an email and any intermediary servers it underwent on its way to the intended recipient.
What is an Authenticated Received Chain?
ARC is an email protocol that lets the recipient’s mail server check the authentication results of forwarded or relayed emails, ensuring nobody tampered with or modified the email content in transit. This relatively new protocol was made public in 2019 and has instilled trust in the email’s origin and unmodified content.
Besides this, ARC also resolves the issue of false positives, where emails sent by authorized senders get marked as spam or bounce back because of forwarding or mailing list services. It addresses this issue by preserving the authentication results throughout the travel path of the email. This way, legitimate emails pass the authentication checks despite passing through multiple intermediate servers.
Image sourced from captainverify.com
What is the problem with the SPF, DKIM, and DMARC authentication process?
When you dispatch an email from a domain that is strengthened with SPF, DKIM, and DMARC, the forwarding server adds a new ‘Received’ header. SPF and DKIM often leave the new ‘Received’ header uncovered, triggering the recipient’s mail server to mark the email as illegitimate.
A similar problem also occurs when you send an email via a mailing list as the email undergoes some modifications like– having the mailing list name added to the subject line or adding an ‘unsubscribe’ button or disclaimer at the end. All these changes make even a legitimate email look spoofed, hence failing DKIM checks.
What’s worse is that the forwarding or mailing list mail servers send the same email from a new IP address, causing trouble in SPF authentication as these intermediary servers are not part of the original sending domain’s SPF record. Due to this, SPF authentication also fails.
As you know, if an email fails SPF and/or DKIM, it also fails the DMARC check. This is where ARC comes in handy.
Let’s use an example to understand this. Imagine an email sent from your domain to Gmail. You have a custom Return-Path set up with DKIM and a DMARC policy in DNS. This ensures emails from your domain are authenticated and “fully aligned” at ISPs like Gmail or Outlook.
Here’s an example of what the headers might look like:
Authentication-Results: mx.google.com;
dkim=pass header.i=@domain.com header.s=20130519032151.pm header.b=SaTOwM7u;
dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
spf=pass (google.com: domain of pm_bounces@bounces.domain.com designates 50.31.156.124 as permitted sender)Now, if your customer forwards this email to a Yahoo account, the message will fail SPF alignment because the Return-Path headers have changed. Additionally, DKIM will likely fail because the message content has changed. This happens because the new sender is Gmail, not your domain, which you verified in SPF.
How does ARC fix the problem?
In simpler words, ARC generates a trusted chain of authentication by adding three extra email headers that ensure no additional headers or modifications by intermediate servers cause the email to fail SPF, DKIM, and DMARC authentication checks. The recipient’s server then verifies this chain of authentication results upon reception.
The three email headers contain-
- ARC authentication results: This includes a copy of the email’s SPF, DKIM, and DMARC results.
- ARC message signature: This is a DKIM-like signature that contains the entire message and headers, except the ARC-Seal header.
- ARC-Seal: This is again a DKIM-like signature that contains the ARC headers generated by each intermediate server.
How do intermediate servers sign the message?
When an ARC-enabled message arrives at the intermediary mail server, such as a forwarder or mailing list, the server performs the following steps:
- Copies the original Authentication-Results into a new ARC-Authentication-Results header with a sequence number starting at 1.
- Generates an ARC-Message-Signature to cover the message contents.
- Creates an ARC-Seal to validate the chain by covering the previous ARC headers.
- Inserts the new ARC headers at the top of the message.
- Forward the email with the added ARC headers.
Each subsequent intermediary repeats this process, incrementing the sequence number each time.
Getting started with ARC
All major email service providers support ARC adoption. However, establishing the right foundation is your responsibility.
Here’s how you can get started with ARC to overcome the shortcomings of SPF, DKIM, and DMARC-
- Implement foundational standards: Set up SPF, DKIM, and DMARC for your domain.
- Verify ARC support: Ensure your email service provider (ESP) supports ARC. Check the documentation or contact support.
- Configure ARC signing: Set up your email system to add and sign ARC headers. Steps will vary by system.
- Test and validate: Send test emails to check that ARC headers are added correctly.
- Monitoring: Evaluate DMARC reports to understand how your email-sending domain is being used and whether there are any instances of false positives. With ARC, there will be fewer failures resulting from email forwarding and mailing lists.
Configuring your mail server to validate inbound ARC
Here’s what you need to do to validate inbound ARC-signed mail-
- Check MTA Support: Ensure your MTA supports ARC. Most modern MTAs do. OpenARC lists compatible software.
- Enable ARC Module: Turn on ARC validation and header parsing in your MTA configuration.
- List Trusted ARC Signers: Specify trusted domains for ARC headers. Only accept ARC results from these domains.
- Set ARC Policy: Decide how your MTA handles ARC authentication. For example, accept emails on ARC pass and reject on ARC fail.
- Test with Known ARC Headers: Send test emails with valid ARC headers to ensure they are authenticated correctly.
- Honor ARC Results: Once ARC validation works, accept valid forwarded emails that would otherwise fail DMARC.
Final words
Please note that ARC only fixes the problem of false positives for legitimate emails that are forwarded or sent through mailing lists as they pass through intermediate servers. It doesn’t provide end-to-end encryption for emails.
