Ensuring the sender of any email is actually who they say they are is a real problem. Email is not the only old protocol from the early days of the internet that relies a bit too heavily on the “honesty system” in its architecture, but it is certainly the one most used today. This weakness has been wholeheartedly taken advantage of by malicious actors in the form of phishing emails or sender impersonation attacks.
Techniques for sender validation or sender authentication within emails have evolved over time, so finally there are now ways to guarantee that the sender of an email is who they say they are.
- Domain-based Message Authentication, Reporting, and Conformance (DMARC): A DNS record including a policy statement about mail being sent from a domain.
- Sender Policy Framework (SPF): A DNS record to state what servers are authorised to send mail for a domain.
- DomainKeys Identified Mail (DKIM): A method of confirming email validation through the use of certificates.
SSS offers a DMARC consultancy service to guide clients through the complexities and knowledge hurdles involved with DMARC authentication.
The ultimate gain of the service is to move a client’s posture to one of reject so that all company emails are sender authenticated meaning one less company that can be exploited by phishing scammers. This overall helps make email transactions safer and more trustworthy.
Contact us on 04 917 6670 or email sales@sss.co.nz if you want to know more.
In this article we are describing the benefit of these techniques in protecting a company’s brand/image on the internet today.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Most email authentication articles start with the more basic of the validation protocols, Sender Policy Framework (SPF). Today SSS believes companies should seriously look to the newer of these protocols, DMARC, as soon as possible, even in some cases before implementing the others. DMARC provides the central reporting required to improve and fully understand if the other protocols are working. This is essential in understanding how a company’s emails are being validated in the outside world. For now, please just regard SPF and DomainKeys Identified Mail (DKIM) as different protocols that also evaluate a PASS (legitimate) or a FAIL (illegitimate) for each email.
DMARC is something a legitimate sending company/domain does to inform recipients of its emails that the company is a legitimate sender. By implementing DMARC, SPF, and DKIM, a company is helping protect its own brand/domain from being used in phishing emails. It does not directly prevent inbound phishing emails, however. Implementing any of the protocols also helps prevent spoofing of your own domain if your own mail gateway is verifying the sender using these protocols.
A company’s DMARC policy is conveyed in a simple domain name record (TXT record) as below example:
A DMARC policy is public knowledge, similar to an SPF policy.
The TXT record can indicate a lot of information, but a simplified form can be as follows:
This record indicates the following information:
- “p=none” – This indicates the domain (example.co.nz) has a sending policy of “none” (no policy)
- “rua=….” – This indicates the recipient of aggregate DMARC reports – In this case dmarcreports@example.co.nz. This is the reporting part of the equation that makes DMARC ideal for one of the first of these protocols to implement. Mail servers supporting DMARC verification should be sending reports showing basic information on what emails were accepted and rejected, and why.
When a receiving mail server verifies DMARC it evaluates the from domain indicated in the header of an email (the “header from”). This is the domain of the sender that is presented to any user reading the email e.g.
In the example from header above the sending domain is example.co.nz.
Assessing the from domain in the header is more relevant to preventing phishing emails, which makes DMARC more effective in this compared to SPF.
DMARC assesses whether the from domain aligns with the domain used by the other authentication protocols e.g.
- SPF evaluation was against the domain example.co.nz – The from domain in the header is example.co.nz, therefore the domains are aligned.
- DKIM evaluation was against the domain differentcompany.com in the DKIM signature – But the from domain in the header is example.co.nz, therefore the domains are not aligned.
- If any of the aligned domains is a successful PASS in their respective protocols, then DMARC is also a PASS.
A DMARC policy is flexible in that it requires either SPF or DKIM to align, but an aligned domain must PASS. If there is no alignment, or there is alignment but the aligned domain is evaluated as FAIL, then that results in a DMARC FAIL. This covers most of the ways email can traverse the internet.
Additional key points on DMARC usage:
A sending domain can implement the DMARC DNS record without any other technology requirements. Changing a DNS record and having an email address to receive reports is all that is required.
However, in order to use DMARC information to reject / quarantine email you must have a mail gateway capable of DMARC verification. That mail gateway should also provide a means for sending DMARC reports to other participating companies so that information can be shared.
It is also important that the action on DMARC FAIL follows the sender’s policy, and does not arbitrarily enforce a different policy.
Note that the DMARC policy does not specify anything should be done if either SPF or DKIM or both FAIL. An evaluation of FAIL for either of the other protocols means the action is dictated by their respective protocols.
The diagram below best illustrates this evaluation:
Figure 1 Read more on DMARC at https://www.dmarcanalyzer.com/dmarc/
What the receiving mail server does with a DMARC FAIL is then determined by the policy that the sending domain has in their DMARC record. In the example above, the policy is “none” and therefore nothing is done. This is a great policy for first using DMARC purely as a reporting tool to gain insights into how a company’s mail is evaluated on the internet.
To further explain the reporting function, DMARC verifiers (receiving mail servers) are also encouraged to send aggregate reports to the nominated email indicated in the sender’s DMARC record. These reports are usually sent once a day but can be weekly. These reports indicate a simple XML report of what email was DMARC assessed, what the result was, key information given by SPF/DKIM, and what IP addresses or hostnames sent those emails.
This information can then be compiled by the sending company to much better understand how emails from their domains are being verified on the internet. This can help inform changes that might be required to ensure that DMARC PASSES for all legitimate mail.
The goal in interpreting DMARC reports is for a company to gain confidence in changing the DMARC policy of “none” to “quarantine”, and then ultimately to “reject”. Using a “reject” policy means DMARC FAILS will be treated as illegitimate mail and rejected. This achieves the goal of ensuring the company domains are protected and cannot easily be used in impersonation attacks (phishing email).
Sender Policy Framework (SPF)
SPF is the simplest of the sender validation protocols and was introduced around 2005. A sending domain’s SPF policy is conveyed in the same way as DMARC – by a simple DNS TXT record which is attached to the root of the domain. This means a domain’s SPF policy is public knowledge. For the domain example.co.nz the SPF lookup could be as follows:
The SPF record simply indicates all IP addresses that are permitted to send emails from a domain. However, in interpreting what domain to look up, SPF evaluates the envelope from domain (not the header from), or in the absence of this (which can happen in case of non-delivery reports (NDR) etc.), it uses the domain given by the sending mail server’s hostname in the HELO/EHLO command.
The above example record indicates that the following information:
- “a” – means the A record for that given domain e.g. the IP address that is resolved to by the A record for example.co.nz can send emails for example.co.nz.
- “mx” – means the MX record of for the given domain can send emails for a domain.
- “include=..” – means to include the SPF record of another domain as valid for this domain. In this case example.co.nz uses protection.outlook.com (Office365) so any IP address that Office365 use are also valid IP addresses for example.co.nz.
The last part of the example record is very important. Pay attention to the character/symbol before the declaration “all”. This indicates the policy that receiving servers should take if mail does not come from the indicated addresses. Common options are as follows:
- “-all” – Indicates a hard fail – If coming from any other IP then reject email.
- “~all” – Indicates a soft fail – If coming from any other IP then quarantine or tag email. Do not reject.
- “?all” – Indicates neutral – If coming from any other IP then do nothing.
Additional key points on SPF usage:
SPF is very easy to set up with just a DNS record, and can initially be run in a neutral mode to provide information for DMARC.
In order to use SPF information on your mail gateway you should have SPF evaluation configured. Most modern email gateways support SPF validation. If possible, your mail gateway should be set to reject emails that evaluate as a hard FAIL. The rejection message should include helpful information indicating the rejection is because of SPF FAIL.
The key weakness of SPF is does not account for the fact that email has two from addresses –
- Envelope from address – used by the receiving server to return to sender (bounce a message). This from address can often be discarded at the SMTP transaction but it often indicated as the “Return-Path” header field.
- Header from address – the sender displayed to the user. Is used when replying to an email (although ReplyTo header can override).
This means that a malicious actor can easily bypass SPF by not providing a sending domain in the envelope from, or providing a completely different envelope from domain that may even PASS SPF, while still impersonating a domain in the header from. SPF does rely heavily on the honesty system to provide any level of authenticity.
However, despite these weaknesses SPF still provides an easy method to legitimise company email. Often if there is no SPF record in place for a company and that company needs to move to using a different sending IP address, this can cause problems with delivering email as the new IP address may not have an established reputation. SPF provides a way to indicate publicly that a new IP address is in use, so these problems with reputation should not occur.
Most legitimate email should PASS SPF, but emails are sometimes not sent directly and can be forwarded via different services. For this, another protocol is required to add legitimacy to the body of the email itself.
DomainKeys Identified Mail (DKIM)
DKIM is a protocol that verifies the contents of an email (including header from address, other headers, and the body of the email) via a cryptographic signature. That signature can be verified using a public key that is in the DKIM signature DNS records.
The cryptographic signature is provided in the email itself and would look something like this:
This signature is similar to cryptographically signing emails with other encrypting email standards like SMIME or PGP, but distributes the public verification key as a DNS record making it universally referenceable.
Picking out key pieces of information from the above example to reference as below:
- “d=example.co.nz” – This is the domain that is used to provide the DKIM signature.
- “s=selector1” – This is the selector, which is an arbitrary name for the host of the verification key used to verify this signature.
- “h=…..” – This provides a list of email headers that have been signed by the DKIM signature.
- “bh=….” – This provides the hash of the above indicated headers that can be verified using the public key.
- “b=….” This provides the hash of the body of the email that similarly can be verified using the public key.
A key weakness of DKIM is that the header from domain in the email itself is not the domain that is evaluated against. The DKIM signature itself provides the two pieces of information to a receiving server that indicate what DNS record contains the public key to use for evaluation. This means a malicious actor can PASS DKIM using a domain with a key that they control that is unrelated to the header from domain.
The domain and the selector are used to indicate the DNS record to get the public key. Our example signature would indicate that the following TXT record should be looked up:
The nature of using a selector that is not known to the public (unless guessed) means that whether a company supports DKIM or not is not necessarily public knowledge. Only having a given email from a company would indicate that DKIM is supported. This is not meant to create a layer of obfuscation, as the selector method provides a way that other legitimate third-party email senders can use DKIM and you can use their DKIM keys to authenticate your own domain.
A DKIM signature is still valid if an email is forwarded via another email service provider as long as that service doesn’t change the body or key headers of the email. Some headers can change naturally (received headers), but not key headers like “from” and “subject”.
DKIM by itself does not currently have an enforced method of conveying a sender policy for DKIM signing like SPF does. With DKIM itself you cannot determine if some, all, or none of a sending domain’s email should be DKIM signed. There is a specification called Author Domain Signing Practices (ADSP), but this specification has been declared historic. Ultimately DMARC fills this role by creating a sending policy for both SPF and DKIM in a flexible centralised manner, so that one or other protocol can apply as required.
Additional key points on DKIM usage:
In order to use DKIM there are a few more steps to go through to implement. DKIM requires that the sending mail server supports adding a DKIM signature to all outgoing emails. It is important with any signing operation that this is the last operation on any outbound email so that all changes are signed and valid.
Many third-party email services may support DKIM signing themselves. There is an extra step required to ensure that third parties sign using your own domain record in the DKIM signature. This requires setup o fa CNAME record to share the third-party public keys as your own DKIM record and enabling this with the third party.
DKIM verification on inbound can be handled differently depending on circumstances. DKIM does not specify a sending policy for a sending domain, so rejecting DKIM FAIL emails may not be the correct thing to do . Ultimately DMARC and DKIM are closely aligned so following a sender’s DMARC policy is the best policy.
