Browse All Articles > Mail Authentication - SPF, DKIM, DMARC
The following article describes what SPF, DKIM, and DMARC are used for, their importance, and how they are implemented.
SPF, DKIM and DMARC are all methods used to prevent email spoofing and verify the authenticity of a mail or mail server. While SPF and DKIM can be implemented independently, DMARC uses a combination of SPF and DKIM to further secure a domain and the transmission of mail using that domain.
An email message contains two sender addresses - one is contained in the From header, which normally displays the name and the email address of the sender that you would see in your mail client; the other is the Envelope From or Return-Path address. You can think of it like this - the Envelope sender would be similar to the Return Address on the envelope of a traditional letter, and the From header would be similar to the signature or letterhead on the actual letter that’s inside the envelope. If the letter was returned to the sender, it would be returned to the Return Address, while if the recipient were to reply to the sender, they would address their letter to whoever signed it - emails work in a similar way.
As with traditional snail mail, both of these sender addresses can be very easily spoofed/faked in an email. To prevent this, we use Mail Authentication (SPF, DKIM, and DMARC). This protects both the owners of a domain as well as the mail recipients.
SPF uses a DNS TXT record to verify the Envelope From sender only. This means that if a spammer spoofs the Envelope From address using a domain that uses a valid SPF policy, it will be caught at the receiving server as a forgery if SPF verification is being performed. However, if the spammer spoofs the From header, SPF will not be able to catch this if the Envelope From sender is valid. An SPF DNS record essentially holds a list of all IP addresses (or hostnames) permitted to send mail on the domain's behalf. Below is an example of an SPF record.
This SPF policy contains a number of mechanisms - the mx mechanism signifies that the IP(s) of the MX host is permitted to send mail on the domain’s behalf; the a mechanism permits the IP(s) of the domain’s A (Address) records to send mail; the ip4 mechanism authorises a specific IPv4 address; and the include mechanism essentially includes or daisy-chains an additional, separately published SPF record or policy. The last mechanism (all) always matches and it should always go at the end of the record. The - (minus) symbol prefixed to this mechanism denotes a strict or Fail policy. Another common qualifier is the ~ (tilde) symbol, which denotes a loose or SoftFail policy.
DKIM seals or signs outbound mail with a digital signature using a private cryptographic key. That signature can be verified by a receiving mail system using a corresponding public cryptographic key that is stored as a DNS TXT record. DKIM can sign multiple headers of a mail or even parts of the message body. We can therefore use DKIM to verify that a mail (or the signed parts of a mail) have not been altered during transit. DKIM uses two parameters - d= and i= - that are used to identify the sender of a mail. However, with DKIM, there is no requirement for the d= or i= values to match any of the headers in an email - so alone, it is not very useful for anti-spoofing. This is where DMARC comes in.
DMARC ties together SPF and DKIM. With DMARC, the d= value in the DKIM signature must match the domain in the From: header. DMARC will first check to see if the domain in the From header and the domain in the Envelope From match - if they do, it will check if the SPF verification passes. If this condition is true, you have SPF alignment, and DMARC verification will pass. However, if the domains do not match, DMARC will check to see if the domain in the From header matches the domain specified in the DKIM signature (d=example.com). If this condition is true, you have DKIM alignment and the DMARC test passes. If neither SPF nor DKIM alignment checks pass, the DMARC verification fails.
All 3 frameworks allow you to specify some form of strict or relaxed policy. As already mentioned above, with SPF, the ~all mechanism at the end denotes a loose policy - SPF fails will get flagged but mails failing SPF verification should not get rejected. The -all mechanism denotes a strict policy and mails failing SPF should get blocked or rejected. DMARC has more options - you can select between (no action/collect data only, quarantine, or reject). DMARC can also be configured to report - making it easy to test a DMARC implementation before deploying a stricter policy. Alignment can be set to strict or relaxed:
Strict Alignment: Envelope address domain or d= and Header address domain must be the same.
Relaxed Alignment: Envelope address domain or d= must be the same as the Header address domain, or a sub-domain of that domain.
Furthermore, DMARC can be configured to trigger on all mail or only on a percentage of mail using the pct parameter.
An example of a DMARC record would be as follows:
This specifies that DMARC failures should be quarantined, aggregate reports and failure / forensic reports should be sent to test@example.com, and the DMARC policy should be applied to 80% of mails.
Below is a diagram of how DMARC works:
An email message contains two sender addresses - one is contained in the From header, which normally displays the name and the email address of the sender that you would see in your mail client; the other is the Envelope From or Return-Path address. You can think of it like this - the Envelope sender would be similar to the Return Address on the envelope of a traditional letter, and the From header would be similar to the signature or letterhead on the actual letter that’s inside the envelope. If the letter was returned to the sender, it would be returned to the Return Address, while if the recipient were to reply to the sender, they would address their letter to whoever signed it - emails work in a similar way.
As with traditional snail mail, both of these sender addresses can be very easily spoofed/faked in an email. To prevent this, we use Mail Authentication (SPF, DKIM, and DMARC). This protects both the owners of a domain as well as the mail recipients.
SPF (Sender Policy Framework)
SPF uses a DNS TXT record to verify the Envelope From sender only. This means that if a spammer spoofs the Envelope From address using a domain that uses a valid SPF policy, it will be caught at the receiving server as a forgery if SPF verification is being performed. However, if the spammer spoofs the From header, SPF will not be able to catch this if the Envelope From sender is valid. An SPF DNS record essentially holds a list of all IP addresses (or hostnames) permitted to send mail on the domain's behalf. Below is an example of an SPF record.
v=spf1 mx a ip4:198.51.100.1 include:_spf.n-dns.net -allThis SPF policy contains a number of mechanisms - the mx mechanism signifies that the IP(s) of the MX host is permitted to send mail on the domain’s behalf; the a mechanism permits the IP(s) of the domain’s A (Address) records to send mail; the ip4 mechanism authorises a specific IPv4 address; and the include mechanism essentially includes or daisy-chains an additional, separately published SPF record or policy. The last mechanism (all) always matches and it should always go at the end of the record. The - (minus) symbol prefixed to this mechanism denotes a strict or Fail policy. Another common qualifier is the ~ (tilde) symbol, which denotes a loose or SoftFail policy.
DKIM (DomainKeys Identified Mail)
DKIM seals or signs outbound mail with a digital signature using a private cryptographic key. That signature can be verified by a receiving mail system using a corresponding public cryptographic key that is stored as a DNS TXT record. DKIM can sign multiple headers of a mail or even parts of the message body. We can therefore use DKIM to verify that a mail (or the signed parts of a mail) have not been altered during transit. DKIM uses two parameters - d= and i= - that are used to identify the sender of a mail. However, with DKIM, there is no requirement for the d= or i= values to match any of the headers in an email - so alone, it is not very useful for anti-spoofing. This is where DMARC comes in.
DMARC (Domain-Based Message Authentication, Reporting & Conformance)
DMARC ties together SPF and DKIM. With DMARC, the d= value in the DKIM signature must match the domain in the From: header. DMARC will first check to see if the domain in the From header and the domain in the Envelope From match - if they do, it will check if the SPF verification passes. If this condition is true, you have SPF alignment, and DMARC verification will pass. However, if the domains do not match, DMARC will check to see if the domain in the From header matches the domain specified in the DKIM signature (d=example.com). If this condition is true, you have DKIM alignment and the DMARC test passes. If neither SPF nor DKIM alignment checks pass, the DMARC verification fails.
All 3 frameworks allow you to specify some form of strict or relaxed policy. As already mentioned above, with SPF, the ~all mechanism at the end denotes a loose policy - SPF fails will get flagged but mails failing SPF verification should not get rejected. The -all mechanism denotes a strict policy and mails failing SPF should get blocked or rejected. DMARC has more options - you can select between (no action/collect data only, quarantine, or reject). DMARC can also be configured to report - making it easy to test a DMARC implementation before deploying a stricter policy. Alignment can be set to strict or relaxed:
Strict Alignment: Envelope address domain or d= and Header address domain must be the same.
Relaxed Alignment: Envelope address domain or d= must be the same as the Header address domain, or a sub-domain of that domain.
Furthermore, DMARC can be configured to trigger on all mail or only on a percentage of mail using the pct parameter.
An example of a DMARC record would be as follows:
v=DMARC1; p=quarantine; rua=mailto:test@example.com; ruf=mailto:test@example.com; pct=80;This specifies that DMARC failures should be quarantined, aggregate reports and failure / forensic reports should be sent to test@example.com, and the DMARC policy should be applied to 80% of mails.
Below is a diagram of how DMARC works:
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)