New article about email authentication, here I'll talk about ARC : Authenticated Received Chain !
Less than a month ago, I announced during our weekly Monday call that I was going to write an article about ARC... Suddenly, Marion (whose last name I will not mention ) is up in arms, "What's that thing you're doing... SPF, DKIM, DMARC, BIMI... and ARC, is that something you invented???"... After a moment of solitude, I said to myself that this article wasn't such a bad idea after all, so Let's Gooooooo! Attention, this article will introduce you to ARC, I am already planning another one on its setup, be patient
Definition of CRA
ARC or Authenticated Received Chain is an email authentication protocol defined by the RFC 8617. The objective of ARC is to allow to keep the authentication results of an e-mail (we are talking about SPF, DKIM, DMARC) when the latter goes through an indirect messaging flow (a mailing list, an e-mail forwarding service or a filtering service). If you want to know more about ARC's history, please visit the official website.
Why implement ARC?
You are in the process of effectively protecting your domain against spam and phishing by setting DMARC with a security policy of "reject". Well, ARC is for you! Let me explain:
During an email transfer, the SPF & DKIM authentication systems will unfortunately fail because a different IP will be used during the transfer (and therefore this IP will not appear in SPF) and the DKIM signature will not be valid since the email will not be sent from the advertiser's server but from the recipient.
Thus, when DMARC will try to validate SPF & DKIM, the result will be irrevocable and will lead to the rejection of the e-mail since it will not be able to validate SPF & DKIM (and therefore will apply the security policy defined by the administrator).
And that's where ARC comes in (as if by magic) ! By implementing ARC, it will bring an additional layer to DMARC compliance by maintaining authentication of the original e-mail at each transfer. And don't forget that e-mail transfer is a positive signal for your reputation, because your subscribers/customers/prospects, by transferring your e-mail, are telling their contacts about you... And that's priceless!
In the end, the implementation of ARC will allow you to (if DMARC is set to "reject") :
- Improve the legitimacy and compliance of your emails.
- Improve your reputation.
Advantages and disadvantages of ARC!
Fortunately or unfortunately, ARC offers many advantages but also disadvantages that can impact (positively or negatively) each recipient... Thus ARC will allow :
- (+) To make the results of the SPF, DKIM, DMARC authentication systems visible from the first transfer (and for all the following). These signatures are transmitted intact and the intermediaries' signatures can be reliably linked to their domain name.
- (+) To give intermediaries the right to modify the original message.
- (+) Provide data on intermediaries to a reputation system tracking their behavior.
But like any system, ARC has its limits and will not allow :
- (-) To provide information about the reliability of the sender of the original message or the various intermediaries.
- (-) To give information about the contents of the transferred messages: an intermediary can very well inject bad content or modify/delete some elements of ARC.
How does ARC work in practice?
We will try to explain how ARC works with the diagram below:
- A: The sender sends an e-mail to a recipient.
- B: The recipient's incoming mail server receives the email and validates SPF, DKIM and DMARC authentication systems (see ARC if the email already comes from a transfer).
- C: The recipient forwards the e-mail and his outgoing mail server inserts the ARC headers.
- D: The final recipient receives the email and the ARC, SPF, DKIM, DMARC authentication systems.
Between the validation of the e-mail transfer by the recipient and the sending via the outgoing e-mail server, the intermediate server will have to perform the following steps:
- Copy the "Authentication-Results" field into a new AAR field "ARC-Authentication-Results (starting with
i=1) and add it to the message. - Calculate the AMS "ARC-Message-Signature" of the message (with AAR) and add it to the message.
- Calculate the "ARC-Seal" AS for the previous ARC-Seal headers and add it to the message.
On its side, the incoming mail server of the recipient receiving the transfer will have to perform the following steps to validate ARC:
Need help?
Reading content isn't everything. The best way is to talk to us.
- Validate the string of ARC-Seal headers.
- Validate the last ARC message signature based on the instance number.
How to check if ARC is present in an e-mail?
To find out whether ARC is implemented, you'll need to dig into the header of one of your Gmail emails and find the following 3 tags:
ARC-Authentication-Results (AAR)
This field records the authentication rating of the original email. We can therefore find all the information related to SPF, DKIM & DMARC. In the two examples below, we can identify (in green) authentication results for each advertiser.
ARC-Authentication-Results: i=1; mx.google.com; spf=pass(google.com: domain of neobounces@rueducommerce.com designates 178.251.200.41 as permitted sender)smtp.mailfrom=neobounces@rueducommerce.comARC-Authentication-Results" field of a Rueducommerce email
ARC-Authentication-Results: i=1; mx.google.com;dkim=pass header.i=@accounts.google.com header.s=20161025 header.b=vjGrpQ1x;spf=pass (google.com: domain of 3zx-twwgtctqde-h4fbo022ekdji.6ee6b4.2eci58.18ij0d6c08b.2ec@gaia.bounces.google.com designates 209.85.220.69 as permitted sender) smtp.mailfrom=3Zx-TWwgTCtQDE-H4FBO022EKDJI.6EE6B4.2ECI58.18IJ0D6C08B.2EC@gaia.bounces.google.com;dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=accounts.google.comARC-Authentication-Results" field of a Gmail email
ARC-Message-Signature (AMS)
This field is a combination of an instance number (i) and a DKIM signature of the whole message (from the FROM address to the last tag of the HTML code)with the exception of the "ARC-Seal" field. It contains, as in a DKIM signature, the domain (d=) and its selector (s=).
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;h=message-id:mime-version:reply-to:to:subject:date:from;bh=/MJZCOxVmR9iFbpVGw20Q0FiNtS4pfBaSeClVnhcrY4=;b=LUqzB4TJ9R3/WhqOaj0Ar5mKh0H5XJXdrbYCaU6t1QTAomlWsrgrfnuvXTmPo+2/WvgzNznOptInpUm9c2RzbxApLg5KYVqJX6Hr44qf69wBAoHtEdvCZcYTKsHhJsi4rTN5NFiAheKd+kNg0VMA1X7NMh6bVbCum5oT1HNTyv9Z5tvLitG/sviiEaKarVtvrRy68IV6pkWeKlFtCHLChgrRGS936RLwsYdrSA+dbIbbcrKo27DViwHWYQz/0w9vtQcYZfllh93lKAFar8m6EAjtOxh0SnGzieHDTnutWavrXwwuS4Ouvl9KFUu3FWfKViYfIQp094BjUS5fsk5YKA==Field "ARC-Message-Signature" of an e-mail from Rueducommerce
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;h=to:from:subject:message-id:feedback-id:date:mime-version:dkim-signature;bh=6O3KORUzqD0WkIe5vS5NB3NlP0d6tsso3cA/RNIlEAM=;b=mqTA4V4YQrXFyc19butpFPxewHaXYQOYnK6ViP2zbUN98oBFsf+tdVi5toKHsdN6RDhN3niui5C48BPDTYhCUrDWUE19ZglG2vRRSdjOdd/FpQ8dgOaqN6SBaVWK9f+gjMDTbB9Azs+rBync1Wj7ymie0QCDeQzrVJLz020PZ2L+BBie4Uft1H45bS/Re9J0yuGSshigocih3MHBh7PGHgwdm5ESva36qQNw6HkS7V38CaLtcT85+6PO9hAl0tDMYrsJCDfPsAfJvPQnA4lKbSx5sdWQ9sFiMCo2wnOukEQ3Qkws00mDOxXbK4dtfFoD6C4HC8TAaccM3WyAp3Eqig==ARC-Message-Signature" field of a Gmail email
ARC-Seal (AS)
This field is a combination of an instance number (i)a DKIM signature of the previous "ARC-Seal" field and the validity of previous ARC entries. As before, we find in both examples the domain (d=) and its selector (s=).
ARC-Seal: i=1; a=rsa-sha256; t=1585815476; cv=none;d=google.com; s=arc-20160816;b=U55HkMyXyyuerzECYjLPqNgXpPgnejdOxX7xz60+EKKKVRdK5K3/T3owmUMLdUIsWTXw7/2B19BQPA7LnNpLQYs4p8S8ETe2RJ12rRUu+EOHXCQI7pimhwmVvhzrUbbkH+561kxvk0l69Ck7zWNvtRi+7rEJAIFaJwS9bQQtLYovLi1JICNgcyZCGd49yn/Ues2oNHpjstApQQ3yJ1z0vGKfmBAtO2ijLSMMZQIlOwCcYa7deU0TQCmehDhJ9GkjGqxP4HXssdGo8vFhGj3ya8VbAeHFMw7xSiqC2Uly5w7+dFt0vL4kRN9QFNxpzth+xjKNTiHxXyh18jipbwnkCg==Field "ARC-Message-Signature" of an e-mail from Rueducommerce
ARC-Seal: i=1; a=rsa-sha256; t=1536368489; cv=none;d=google.com; s=arc-20160816;b=AU3leI36p81PkbNQHPV4wpVB4oKjzR+xBRpPt7eh3B1DYCfJFK5gbb6nJiO0KjxSKoVc/ubFz4hYFyYNqIpMbCvNLE7DMLYf0Df3JksYRJVeklAvOnNZhuORaNs2K+CoBBGrxbEa+oZI0Yv88VCPsNDGEB0EP4X8jYdQLyaU1Lpv/wLmgRxuMh2mXsWuSNatxsXZ2m4o9Wkl5CE7q8vnfUGOVUPrmdgc5avuGVLrGQvICUdAImGkT5haxYwxBGQD8F0jMRr1aK7e/J9tCbY3eCiZOtdlkeVkdWwcUFAxRehOSNhE2pOB3r+s9B2l5uep47fHZpuVwhtoqII2Me0EkQ==ARC-Message-Signature" field of a Gmail email
We conclude!?!
When you know how important it is for a company to protect its domains against spam and identity theft with DMARC complianceThe implementation and parameterization of ARC can quickly become a priority task for IT teams... For the writing of this article, 3 sources were used:
- The official ARC website.
- Overview of the ARC Protocol for Email (by Steve Jones).
- Wikipedia (EN).
One Response
I thought everything was moving towards simplification, but the opposite is happening!