What are SPF, DKIM + DMARC?

SPF, DKIM, DMARC. Three acronyms that, to any newcomer to email marketing, are daunting and feel almost impossible to understand. Luckily for you, I’ve done the research, talked the talk and walked the walk. Here, I want to lay it all out in one place for ya. So, you’re welcome.


No, not the level of your sunscreen. SPF is short for “Sender Policy Framework”, a DNS (Domain Name System… Holy shit, enough with the acronyms, Internet) entry that contains the server names that are a-okay to send mail for a specific domain.
Meaning, you (or your IT person) have to add your server name to your Domain Name System so that ISPs see these emails are coming from a legitimate source. According to End Point, “[Because] SPF is a DNS entry can also [be] considered a way to enforce the fact that the list is authoritative for the domain, since the owners/administrators are the only people allowed to add/change that main domain zone.”
This also means that because only you or your administrators have the power to change your SPF entry, it signals to everyone else that you must be real, “After all, only their top people can change it.”
If only they knew you are probably working out of a garage trying to get your start-up off the ground. But no worries, we all start somewhere.


Just another one of those terms that you’ve definitely heard but probably never even bothered to ask about. What does DKIM mean?
DomainKeys Identified Mail. That grammatical nightmare of a name is a method for content verification. You or your IT person has to add a DKIM Key entry to your DNS so that when every message you send goes out, the DKIM Key is attached to the message. This communicates to ISPs that the content in your email has not changed since it left your server (thanks, SPF) and made it’s way to someone else’s.
The fact that it’s a private Key code adds that level of legitimacy needed to be considered trustworthy.


Let’s just get it over with, because it’s a doozy:
Domain-based Message Authentication, Reporting & Conformance. Say that 10 times fast, do 20 jumping jacks, and finish reading this. Without DMARC, SPF and DKIM don’t necessarily work. DMARC, again according to the fine people at End Point, states “a clear policy which should be used about both the aforementioned tools and allows to set an address which can be used to send reports about the mail messages statistics gathered by receivers against the specific domain.”
In fact, let’s take more from End Point (Why even have this blog? Because, I’m funnier than they are) and look at how each of these work:
How SPF Works: Upon receipt, the HELLO message and the sender address are fetched by the receiving mail server (Your recipient).
The receiving mail server then runs an TXT DNS query against the claimed domain SPF entry.
The SPF entry data is then used to verify the sender server.
And in case the check fails, a rejection message is given to the sender server (You).
How DKIM Works: When sending an outgoing message, the last server within the domain infrastructure checks against its internal settings if the domain used in the “From:” header is included in its “signing table”. If not, the process stops here. And ya dead.
[In layman’s terms, let’s say I send an email from “andrew@crmcomplete.com”. Once I send it, the final server that I plugged into my DNS, using the DKIM key, will verify that, indeed, my message was both SENT FROM and ACTUALLY CONTAINS “crmcomplete.com”. That means it matches what I told my DNS it should. If it can’t find that, then you or anyone else will not see my email.]
If the domain used in the “From” header is included in the “Signing Table,” however, then…
A new header, called “DKIM-Signature”, is added to the mail message by using the private part of the key on the message content.
From here on the message main content cannot be modified otherwise the DKIM header won’t match anymore.
Upon reception, the receiving server will make a TXT DNS query to retrieve the key used in the DKIM-Signature field.
The DKIM header check result can be then used when deciding if a message is fraudulent or trustworthy. If it passes said “Fraud Check”, your message is deemed from legitimate source.
How DMARC Works: Upon reception, the receiving mail server {Your recipient’s} checks if there is any existing DMARC policy published in the domain used by the SPF and/or DKIM checks. There should/better be.
If one or both the SPF and DKIM checks succeed while still being aligned with the policy set by DMARC, then the check is considered successful, otherwise it’s set as failed.
If the check fails, based on the action published by the DMARC policy, different actions are taken. That means there are degrees to which you might get dinged.
For example, if you passed both SPF and DKIM checks, but for some reason there’s still an error pertaining to the DMARC policy, you could be sent to Spam, held back from just a few recipients, grey or blacklisted. You just never know, so best practice is just make doubly sure your DMARC policy is set up and ready to go.
Boom. If anyone asks you, just repeat all of that verbatim.
[Thanks to endpoint.com for that information. While I spruced it up and made it a little more relatable, the bulk of that info came from them.]
Oh, and one more thing:
You don’t technically need to set up SPF, DKIM, or DMARC in any way. These are best practices put in place to ensure deliverability and the safety of your audience. While without them, they could get you in trouble with the FTC, this is not a standard government regulated practice. These are tools we as marketers can use to make life much, much easier.