DMARC: How to Prevent Email Spoofing
Modern email authentication uses a combination of three methods: SPF, DKIM, and DMARC. These methods help ensure that a message came from a sender shown in the From header.
By deploying DMARC, email senders can prevent spoofed spam and phishing emails from reaching their email subscribers and customers, protect their brand and the subscribers’ personal data.
This post explains the basics of SPF, DKIM, and DMARC, and tells how to deploy DMARC properly and read DMARC reports.
1. Sender Policy Framework (SPF)
SPF was the first method of email authentication widely adopted by email senders. Most email receivers still want you to have it deployed on your domain to deliver your messages. For example, Gmail and G Suite will throttle emails sent from a domain that doesn’t have a valid SPF record.
SPF works by checking for a specially formatted TXT record in DNS of the domain of the Mail FROM header (also called Return-Path, Envelope From or Return email address) in the SMTP transaction. The SPF record tells which servers are authorized to send mail from that domain by using mechanisms to specify authorized IP addresses and hostnames, or even including the SPF records of other domains.
A domain or subdomain can have only one SPF record, but each subdomain can have its own SPF record.
An SPF record starts with v=spf1. After that, mechanisms are used to specify which mail servers are allowed (or not allowed) to send emails on behalf of that domain or subdomain.
10 DNS Lookup Limit
Some mechanisms use additional DNS lookups to work. SPF has a maximum DNS lookup limit of 10, including any included records. An SPF record that requires more than 10 DNS lookups to resolve is invalid!
You can test your SPF record in GlockApps. Copy-paste the domain with the SPF record in the SPF Flattener and click “Check SPF”.
To comply with this limit, send emails from different subdomains. Each subdomain can have its own SPF record and its own set of limits for that record. For example, you could send email newsletters from newsletter.example.com, and transaction emails from account.example.com.
SPF’s Mechanisms, Qualifiers and Modifiers
Below is the list of SPF mechanisms and their descriptions:
ip4: describes an ipv4 address or CIDR block of addresses.
ip6: describes an ipv6 address or block of addresses.
mx: describes the servers listed in the mx record of the domain, counts against the 10 DNS lookup limit.
mx – the servers listed in the mx records of its own domain
mx:example.com – the servers listed in the mx records of example.com
a: describes the servers listed in the A and/or AAAA records of the domain, counts against the 10 DNS lookup limit.
a – the IP addresses listed in the domains’ own A/AAAA records
a:example.com – the IP addresses listed in the A/AAA records of example.com
include: includes the SPF record from the domain after the colon (it does not include the all modifier, if any). Counts against the 10 DNS lookup limit.
redirect: stops processing the SPF record, and continues at the specified domain’s SPF record (including the all modifier!). Counts against the 10 DNS lookup limit.
exists: used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to specify what is permitted. Counts against the 10 DNS lookup limit.
Mechanisms in the SPF record are preceded by qualifiers. Possible qualifiers are:
+ (pass): a “pass” result means the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.
? (neutral): a “neutral” result indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client. A “neutral” result must be treated exactly like the “none” result. The difference exists only for informational purposes. With a “none” result, the SPF verifier has no information at all about the authorization or lack thereof of the client to use the checked identity or identities. The check_host() function completed without errors but was not able to reach any conclusion.
~ (softfail): a “softfail” result has to be treated as somewhere between “fail” and “neutral”/”none”. The domain manager believes the host is not authorized but is not willing to make a strong policy statement. The email receiver should not reject the message based solely on this result but may subject the message to closer scrutiny than normal.
– (fail): a “fail” result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of messages with the SPF fail is a matter of local policy.
SPF records (except those that are designed to be included in other SPF records) end with an all modifier. The all modifier consists of the word all preceded by a qualifier. The all modifier states how emails that do not match any of the listed mechanisms should be treated.
SPF’s Weak Side
It’s a common misconception that SPF prevents email spoofing. It doesn’t stop it, but it makes email spoofing a little bit difficult for an attacker.
As we told above, SPF checks for an SPF record at the domain in the Mail FROM header in the SMTP transaction (also known as the Return-Path or Envelope From), not in the message From header that the recipient sees in their email client.
This means that an attacker can use SMTP headers to tell the target’s mail server to check a domain that the attacker controls, which contains an authorizing mechanism for the mail server the attacker is using while spoofing a completely different domain for the recipient to see in the message From header field.
A domain mismatch occurs legitimately when a mailbox rule forwards a message from another domain. The email “From” domain will stay the same, but the SMTP Mail FROM header will contain the domain of the forwarding mail server. Hence, SPF evaluation fails.
Once you know exactly which email sources legitimately send on behalf of your domain (DMARC reports will tell you), update the SPF record for your domain, and change the ?all modifier to -all.
Examples of SPF Record
SPF record for new domains:
v=spf1 mx ?all
This record authorized any servers listed in the domain’s MX record while treating all other servers as neutral. This is a good temporary SPF record for new domains that do not have an SPF record yet.
v=spf1 include:spf.protection.outlook.com ?all –
v=spf1 include:_spf.google.com ?all
SPF record for domains that do not send emails (e.g. parked domains):
This record explicitly states that no mail servers are authorized to send emails on behalf of this domain. This must be added to all domains that do not send emails, inducing parked domains.
2. DomainKeys Identified Mail (DKIM)
DKIM is an email authentication method developed to detect forged email header fields and content. DKIM allows the receiver to check whether or not email headers and content have been altered in transit.
A DKIM-enabled email server signs an email message on its way out, using a private key which is a part of a generated keypair.
When the message arrives, the receiving server checks if a DKIM-Signature field exists in the header, and if it does, the server uses the DKIM public key in the DNS to validate the signature.
Depending on the result of the DKIM signature check on the receiving server, the email passes or doesn’t pass DKIM authentication. The DKIM authentication result is then used for DMARC authentication.
DKIM-Signature in the Header
A DKIM-signature header field looks like this:
v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=tiadfhs7i3i3dkzhbjmofp6nm32djwj2;
d=glocksoft.com; t=1568985733; h=Content-Type:MIME-Version:Date:Subject:From:Reply-To:
The tags that are required to be in a DKIM-signature are:
v: signature version
a: signing algorithm (rsa-sha256 should be used)
d: the domain where the public key can be found
s: the selector pointing to the public key at the domain (an arbitrary string)
h: a colon-separated list of header fields that have been signed
bh: the base64-encoded signature hash of the message body
b: the base64-encoded signature hash of the headers listed in the h tag
Optional tags are:
c: canonicalization algorithm(s) for header and body which define(s) if/how the receiving mail server should normalize the message to account for slight variations in whitespace and line breaks that could otherwise invalidate the signature. Relaxed mode is strongly recommended for the header and body canonicalization (i.e. c=relaxed/relaxed).
q: default query method
t: signature timestamp in UNIX timestamp format
x: signature expiration timestamp in UNIX timestamp format
l: number of characters from the beginning of the body to use when calculating the body signature (not recommended because someone could append malicious content)
i: identity/user-agent of the signer
DKIM Record in DNS
DKIM public key records in a domain’s DNS are formatted as:
v=DKIM1; k=rsa; p=<public key>;
Lines in DNS TXT records are limited to 256 characters. If the record is longer, it must be split into separate lines in the same record in order to be valid.
Here are the tags that can appear in a DKIM DNS record:
p: base64 encoded public key (keys must be at least 1024 bytes long. 2048 bit length is strongly recommended)
v: version (must be “DKIM1”)
k: a list of mechanisms that can be used to decode a DKIM signature (rsa by default)
h: a colon-separated list of hash algorithms that might be used to produce a digest of message data
n: readable notes for administrators reviewing DNS records
s: a list of service types to which this selector may apply
q: a list of query methods
l: body length limits
t: a list of flags to modify the interpretation of the selector
DKIM Key Rotation
The private key of a DKIM keypair may be stolen if an attacker compromises the system where it is stored. Therefore, it is recommended to change DKIM keys once per month. This practice is known as key rotation.
If you are using an email service provider or delivery service, you don’t have to do anything as DKIM key rotation is done automatically for you.
Manual DKIM key rotation is necessary only if you run your own email delivery service in-house.
You should create two key pairs and store the public keys under two different selectors, for example:
s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key 1>;"
s2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key 2>;"
Start by signing your outgoing emails using the s1 selector. When it is time to rotate the keys, sign outgoing emails using the s2 selector. After a week of not using the key at the s1 selector, replace the key at the s1 selector.
When it is time to rotate keys again, start using the s1 selector exclusively, wait a week, then replace the key at the s2 selector with a new key, so it will be ready for the next rotation.
It is important to wait a week before replacing the key (unless it is known to be compromised), as some receiving mail servers will cache the public key at a given selector for up to a week.
Using this rotation scheme, you’ll ensure that your emails are always signed with a valid, secure key.
DKIM’s Weak Side
Without DMARC, the domain in the d= tag in a DKIM signature in the header is not required to match the same domain that the user sees in the message From header field.
An attacker can place a valid DKIM signature header in an email with a d= value containing a domain the attacker controls, allowing DKIM to pass while still forging the From email address to the user.
3. Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
DMARC ensures that SPF and DKIM authentication mechanisms authenticate against the same domain that the end-user sees in the From header field.
A DMARC record must be published in DNS by a domain owner, and email receivers must honor this record, including its policy, and send back DMARC reports if requested by the domain owner.
A message passes a DMARC check by passing DKIM or SPF, as long as the related indicators are in alignment with the message From email address.
DKIM pass: the signature in the DKIM header is validated using a public key published as a DNS record of the domain name specified in the signature.
DKIM in alignment: the signing domain aligns with the base domain in the message From header field.
SPF pass: the mail server’s IP address is listed in the SPF record of the domain in the SMTP envelope’s Mail FROM header field.
SPF in alignment: the domain in the SMTP envelope’s Mail FROM header field aligns with the base domain in the message’s From header.
DKIM alignment is more important than SPF alignment because only DKIM remains aligned when a message is forwarded.
DMARC requires email domain owners to add a policy (p=) tag in their DMARC record. This policy tells email receivers how they should treat an email that appears to come from the domain in the From header, but does not pass DMARC alignment.
There are three DMARC policies:
none: no action will be taken regarding the delivery of messages. This policy is used for monitoring and collecting data about email authentication of the messages sent from a domain.
quarantine: an email that fails the DMARC check will be treated by email receivers as suspicious. Depending on the email receiver, This can mean “send to spam folder”, “subject to thorough filtering”, and/or “flag as suspicious”.
reject: an email that fails the DMARC check will be rejected during the SMTP transaction.
It is recommended to start with the “none” policy to collect data about email sources sending from the domain.
You can use the percent (pct) option to specify the percentage of suspicious emails (ones that fail the DMARC check) to have the DMARC policy applied. The default value is 100% (all suspicious messages). For example, p=quarantine pct=10 means that 10% of suspicious messages must be quarantined.
Increase the percentage over time as you refine your DMARC policy. Below is an example of how to use the p and pct options to gradually strengthen your DMARC policy:
Day 1: p=none pct=100
Day 20: p=quarantine pct=1
Day 23: p=quarantine pct=5
Day 26: p=quarantine pct=10
Day 30: p=quarantine pct=25
Day 35: p=quarantine pct=50
Day 50: p=quarantine pct=100
Day 60: p=reject pct=1
Day 65: p=reject pct=5
Day 70: p=reject pct=10
Day 75: p=reject pct=25
Day 80: p=reject pct=50
Day 100: p=reject pct=100
Domain owners are required to set the rua and ruf tags in their DMARC record where they indicate the email addresses to send DMARC reports to. Email receivers that honor DMARC will send the reports to those email addresses.
DMARC reports give very useful information for monitoring and troubleshooting message alignment and identifying malicious sources sending on behalf of a domain.
There are two types of reports.
Aggregate reports are compressed XML files which contain the number of messages sent from an IP address, and the SPF and DKIM status. These reports are sent regardless of success or failure so that domain owners have a picture of email authentication of all the messages that appear to be sent from the domain.
Aggregate reports in GlockApps DMARC Monitor
Forensic reports are emails with the messages that failed the DMARC check attached. These reports can be very useful for identifying messages that failed DMARC. However, most email receivers do not send forensic reports, or may only provide the message headers for privacy reasons.
Forensic reports in GlockApps DMARC Monitor
You can activate the 14-day trial of the DMARC Monitor in your GlockApps account and start getting DMARC data for your email messages. You will get visibility about your sending sources, SPF, DKIM, and DMARC evaluations and will be able to identify and block any suspicious mail streams coming from your domain.