These three technologies can get confusing, especially if your professional specialty is not email. I am going to try and break down the differences in the simplest way I can.
SPF #
SPF is Sender Policy Framework. This is the simplest of the three to understand. This is a DNS text (TXT) record that states what entities are allowed to send email on behalf of your domain. Here is an example:
v=spf1 mx include:servers.mcsv.net ip4:52.1.4.70 include:amazonses.com include:spf.protection.outlook.com -all
This record says these servers can send email for mailborder.com:
- include all MX servers (email servers) for mailborder.com
- include a list of IP addresses from servers.mcsv.net (MailChimp)
- the IP 52.1.4.70 (our web server)
- include a list of addresses from amazonses.com (Amazon email delivery)
- and include a list of IP addresses from spf.protection.outlook.com (Microsoft Office 365)
So, if an email gets delivered to your server with a From: address that is from the domain mailborder.com and the IP of the sending server is not included in that SPF record, then it will fail the SPF check.
The last part of the record is the -all statement. The other option is to use ~all with a tilde instead of a dash. The -all (dash) instructs everyone to reject any email that comes from a server that is not authorized in your SPF record. The ~all (tilde) is the whishy-washy option that tells everyone to accept the email even if it fails an SPF check.
Don’t be wishy-washy.
DKIM #
DKIM is Domain Keys Identified Mail. I know that was helpful, but I will go ahead and explain. It is a digital signature placed into the email header that other email servers can validate. This is done using a private/public key pair. The private key is used to sign the email (on your email server), and the public key is pulled from DNS so that remote servers can validate the signature.
There is a lot going on under the hood here, but I will just point out the d= parameter. This is the domain. So, if you get an email from mailborder.com, it will be d=mailborder.com and your email server will know that this signature needs to be validated using a public key from mailborder.com.
Ok, great. One problem though. The d= parameter doesn’t need to match any of the other headers in the email. So, you could get an email From:
bo*@ib*.com
with a DKIM signature from mailborder.com as long as the stuff in the DKIM signatures passes, then … well … it passes.
Ok, that’s dumb. Now what? This is where DMARC comes in.
DMARC #
DMARC is Domain-based Message Authentication, Reporting and Conformance. I know, helpful.
-> DMARC provides an alignment check between SPF, and/or DKIM, and the headers in the email.
DMARC is also a DNS text (TXT) record. This is an example of mailborder.com:
v=DMARC1; p=reject; sp=none; rf=afrf; pct=100; ri=86400; adkim=s; aspf=s
The important part of that string is p=reject. That is the policy, and it directs remote servers to reject any email from mailborder.com that fails the DMARC check. You can also be wishy-washy here and set it to “none” or “quarantine”. The “none” value instructs the remote server to just ignore a DMARC failure and just accept the email. (You should only do this in testing.) The “quarantine” option tells the remote server to quarantine the email if it fails the DMARC check.
There are two possible alignment tests:
- If there is an SPF record, DMARC will test that and compare it to the email From: and the Envelope From: headers. If SPF passes and those two headers match, you have SPF alignment.
- If there is a DKIM signature, DMARC will compare the domain in the d= value in the DKIM signature to the domain in the From: value in the header. If those match, you have DKIM alignment.
If either condition is true, the email will pass the DMARC check. If both are false, then the email will fail the DMARC check. Note that just one of those items can exist in an email and it would be considered a pass if the check passes. There does not have to be both an SPF record and a DKIM signature. However, you should do both when sending email.
