Johannesburg, 11 Feb 2021
Delivering correctly authenticated e-mail from our platforms is top of mind at SYNAQ, with the rapid uptake and global standardisation of domain-based message authentication, reporting and conformance (DMARC) policy enforcement on top of Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) authentication for outgoing e-mail.
One of the problems we face in securing our customers' e-mail is that we are a security, mailbox and e-mail branding service provider. With all those layers of functionality on offer, there are several steps or 'hops' when mail is changed or redirected before we deliver it to the Internet.
Why does this matter?
When a mail server signs a mail with a DKIM signature before Internet delivery, that e-mail’s content is encapsulated and treated as an immutable object until a receiver’s server can verify the e-mail’s DKIM signature and all the components encoded into it. This is in addition to the receiver ensuring that the sender’s domain SPF checks pass and that the e-mail passes DMARC.
However, there are several problems with the concept of immutability. First, not all e-mail leaves SYNAQ platforms because they were sent by a customer (mailbox forwarding rules) and second, we must sometimes change the content of an e-mail before it leaves our platform (e-mail branding with the application of signatures and banners).
So how do we forward and brand e-mails while still maintaining the authenticity of our customers’ e-mail? This is where ARC comes in.
The Authenticated Received Chain (ARC) system for DMARC provides a way to generate what is in effect a “chain of custody” for e-mail messages. This allows each mail hop, or a mutating service like SYNAQ branding, to see all the hops that previously handled the e-mail in question. It also shows the message’s authentication status across each step throughout the handling chain.
This is really important when we look at the first problem of e-mail redirects or rule-based forwarding. Before ARC, when forwarding a DKIM-protected e-mail, the receiver would receive the mail with new headers and the DKIM signature check would fail. This also meant that these e-mails would fail DMARC. With ARC in play, all original authentication information is sealed in place for the receiver to inspect and evaluate before forwarding takes place.
The same concepts apply when e-mail branding is applied before delivery. If the mailbox server DKIM signs a mail and ARC seals it and the e-mail ID is sent on to the branding server, the next hop would traditionally evaluate the mail and find e-mail body hash (DKIM encoding) mismatches.
Now with ARC, the original mail is DKIM signed, so when branding service evaluates the mail and confirms its validity, it too applies an ARC seal that confirms the original signature was valid, and so on. The result is that any downstream receiver that supports ARC authentication can follow the “chain of custody” and can validate that the mail is authentic and that it passes the DKIM component of DMARC. Assuming the sending domain’s SPF records are correctly applied for SYNAQ, the e-mail will pass both SPF and DKIM checks for their DMARC policy and will be as authentic as it can be.
SYNAQ is hard at work to ensure that all our mail hops perform ARC sealing after prior validation of the previous mail system’s actions and mutations. As mentioned above, these complex and thorough testing protocols are being built to ensure we get this enhanced security right. But we are on the right track and look forward to rolling out DMARC (with DKIM, SPF and ARC support) as a formal toolset on SYNAQ Securemail, Cloud Mail and Branding services in the first half of 2021.
Please review this article linked below for more detailed information on how ARC works: https://en.wikipedia.org/wiki/Authenticated_Received_Chain
Glossary of terms:
DMARC – Domain-based Message Authentication, Reporting and Conformance
https://en.wikipedia.org/wiki/DMARC
https://tools.ietf.org/html/rfc7489
DKIM – DomainKeys Identified Mail
https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
https://tools.ietf.org/html/rfc6376M
SPF – Sender Policy Framework
https://en.wikipedia.org/wiki/Sender_Policy_Framework
https://tools.ietf.org/html/rfc7208
Share