Get to know how SPF, DKIM and DMARC works together.
What is SPF
Sender Policy Framework (SPF) is a protocol that aims to reduce spam. SPF can reduce email spoofing and spam by determining if the sender is authorized to send on behalf of the listed sender.
How SPF works
You have a SPF record like “v=spf1 include:spf.protection.outlook.com -all”, if an unauthorized server sends on behalf of your domain the email can get a spf=fail in the message header, because this IP is not listed in your SPF record.
SPF will pass if the senders IP is added to the SPF record from the domain that is visible after “smtp.mailfrom:” in the Authentication-Results header.
Implementation of SPF
The implementation of SPF can be very quick because it is only a TXT record in your DNS zone. But there are some things to think about before implement this. When adding your domain to Microsoft 365, Microsoft ask to add a SPF record like “v=spf1 include:spf.protection.outlook.com -all”. If you got more authorized senders, you need to add them to the SPF record.
The SPF record will be different for everyone, when implementing it is important to know the following.
A SPF record:
- Can take up to a maximum of 10 DNS lookups like “include:spf.protection.outlook.com”
- Because “spf.protection.outlook.com” also includes a DNS lookup, so your SPF record already have two DNS lookups by default.
- If you got more than 10 Lookups, you would need to flatten your SPF record or create subdomains for each lookup.
- Example: “v=spf1 include:spf.application.com -all” can be “v=spf1 ip4:22.214.171.124 -all”. But if one of the IP address would change, you need to change the record to the new IP and that is difficult to manage. Otherwise create a subdomain(like application.domain.com) for your domain and give it his own SPF record in the DNS zone.
- Can only have 255 characters, but it can be split to multiple strings in a single record.
- Example: “v=spf1 first string” “second string”
- Can get a softfail or fail, you determine this at the end of the record.
- With ~all: If an email is sent from a host or IP that is not in the SPF record, the message will still pass, but it can be flagged as spam (Softfail).
- With -all: If an email is sent from a host or IP that is not in the SPF record, it can be rejected by the receiving server (Fail).
Limitations of SPF
Although SPF works relatively well in theory, there are several flaws in the protocol, which means that SPF on its own is not enough to fight the email spoofing and spam. The SPF protocol only protects the envelope sender (P1 Sender, smtp.mailfrom domain in the Authentication-Results header) and not the content of the e-mail, where the sender (P2 Sender, header.from domain in the Authentication-Results header) of the letter is located. This is the sender that the recipients sees, when they received the email. DKIM has been set to protect the “from” domain (P2 Sender) by setting a signature on the email. Then there is the problem that not every receiving mail server has an active policy on SPF and DKIM. To close that last gap, DMARC was established. With this, the sender indicates what to do with e-mails on behalf of his domain if they do not meet the requirements.
What is DKIM
DomainKeys Identified Mail (DKIM) is a technique based on authentication, by using DKIM, the receiving mail server can check the authenticity of a e-mail with the DKIM-Signature header. This signature is created using the SHA-256 hash function.
How DKIM works
The receiving server use the domain name of the sender (the one that is displayed in the “from” field that the recipient sees, P2 Sender) to make a DNS request. In response to the DNS request, the receiving server receives the public key from a DNS record like selector1._domainkey.yourdomain.com in the DNS zone of the sending domain and calculates this with the private key in the message from the sending server.
DKIM will pass if the private key from the sending server, can be verified by the receiving server, using the public key in the DNS zone of the sending domain. For example, in the DKIM-Signature header you see d=yourdomain.com and s=yourselector (like selector1) if the private key can be verified by the record like selector1._domainkey.yourdomain.com (public key) in your DNS zone, DKIM will pass.
Note that for each sending server there is a DKIM key needed for outgoing mail (private key on server and public key on DNS).
Implementation of DKIM
DKIM can also be implemented with a TXT record in your DNS zone using a DKIM wizard. For now, we use CNAMES (most secured because the private and public keys rotates every time by the provider) records that Exchange Online provide. Open your DNS zone and add two CNAME records;
- Hostname: selector1._domainkey
- Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
- Hostname: selector2._domainkey
- Value: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
When the CNAME records are added, open PowerShell and connect to Exchange Online and run the following command.
New-DkimSigningConfig -DomainName yourdomain.com -Enabled $True
To check if DKIM is running, you can run the following.
get-DkimSigningConfig -Identity yourdomain.com | Format-List
TXT versus CNAME records for DKIM keys
- CNAME: Most secure because the keys rotate automatically and cannot be in hand with a malicious person.
- TXT: This keys do not rotate automatically because they are static. Advice in this situation is to rotate the keys for at least every six months. Doing that reduces the risk of active keys being compromised, either by attackers cracking or stealing them.
What is DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance), forms a extension on SPF and DKIM. DMARC is also a DNS setting Like SPF and DKIM. As told earlier, not every receiving mail server has an active policy on SPF and DKIM, which also allows e-mails without these records to pass, DMARC was established in 2014 to close that gap. With DMARC, the sender indicates what to do with e-mails on behalf of his domain if they do not meet the requirements.
How DMARC works
Once published, any receiving email server can verify the incoming email based on the instructions in the DMARC policy. If the email passes the DMARC authentication, it will be delivered and can be trusted. If the email fails the check, depending on the instructions in the DMARC record, the email can be delivered, quarantined, or rejected.
DMARC will pass if the senders domain in the “From:” field plus domain that is listed in “header.from=” in the Authentication-Results header is equal to the Return-Path header, and if SPF and DKIM are both passed.
Implementation of DMARC
Before you use DMARC, you first want to know how many DMARC fails you gonna get. Therefore, you can monitor the fails with Valimail (free for Microsoft 365 users with an Exchange Online plan), you can monitor DMARC with the policy, p=none. I advise to monitor this with Valimail for at least three months. Open your DNS zone and add the following record as a TXT;
- Hostname: _dmarc
- “v=DMARC1; p=none; rua=mailto:email@example.com;”
- In ValiMail we can obtain an email address to monitor all the failures
- “v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org;”
- After the monitoring phase, we will set the DMARC policy on p=reject
- v=DMARC1; p=reject; rua=mailto:email@example.com; sp=none; pct=100; ri=86400
sp=none means that subdomains are not included, if you want to include your subdomains you can put this on sp=reject. But if you do that, SPF and DKIM needs to be setup for your subdomain and you need to know the senders for sure.
I hope that I was able to explain on how to use SPF, DKIM and DMARC in your environment.