If you are asking “What is SPF?” or “What is DKIM?” or “What is DMARC”, well, you are far from alone. There is a lot of confusion around email authentication, such as SPF, DKIM, and DMARC. Here is a plain English, simple explanation of what email authentication is, and what it does.
SPF stands for Sender Policy Framework, DKIM stands for DomainKeys Identified Mail, and DMARC stands for Domain-based Message Authentication, Reporting and Conformance. But, in the immortal words of the movie Airplane, that’s not important right now. What is important is that you understand how these things work.
The bottom line is that SPF, DKIM, and DMARC all live in a tiny text file where your domain is hosted. They do not live in your email program, or at the inbox providers. (DKIM actually does have a second piece that does live in your email, but don’t worry about that for now.)
Let’s say that your domain is example.com. Your SPF, DKIM, and DMARC live in a tiny text file at example.com. Not on the example.com website, but actually within example.com’s DNS record (for this simple explanation you also don’t need to understand what DNS is, but it’s important that you understand that this is where the text file containing your SPF, DKIM, and DMARC resides).
This file is known as a TXT file. (DMARC can also live as a CNAME in your DNS record, but that too is not important right now.) What is important is that you really understand that each of these email authentication mechanisms live as a text-based DNS record where your DNS is hosted. They don’t primarily live with your email program, and they don’t live with your email service provider. Many people are confused about this because it’s called email authentication, and it helps you get your email delivered to the people to whom you are sending it, so it seems logical that it would be part of your email program. But it’s not.
You can think of your DNS (which stands for Domain Name Service) as sort of like a directory that other computers on the Internet can check to find out where on the Internet your website lives (at what IP address), and a bunch of other things related to your domain, including what other places are authorized to send email on behalf of your domain. When an inbox provider gets email that claims to be from example.com, the inbox provider can see where the email actually originated, and the inbox provider will check in the TXT file in example.com’s DNS records to confirm that the originating system that the email is coming from is authorized to assert that it’s coming from example.com.
So keeping with the example of your domain being example.com, let’s say that you use Google’s Gsuite to send your email, and you send your email out as being from: firstname.lastname@example.org.
In your SPF records, in that TXT file, you are going to have information that tells the inbox providers “it’s ok for email coming from Gsuite to use the domain example.com”
Now let’s say that someone is pretending to be you, and pretending to send email as you (this is known as spoofing). Let’s say that they are sending their email from spoofcentral.com, and claiming that it is coming from example.com.
When the inbox providers get that email, they are going to look up your SPF information in that TXT file in your DNS record, and see if you have “spoofcentral.com” listed as a place that is authorized to send email as “example.com”. And, of course, it won’t be there.
This act of looking up in the TXT records to see if a different site is authorized to send email as the domain is called “authentication”.
That is how SPF works.
DKIM is an additional layer of authentication, which relies on a string of characters that look like gibberish, known as a public “key”. That public key lives in… wait for it… you got it! The TXT record in your DNS records.
This public key is used by the inbox providers to decrypt an encrypted signature that is embedded in the email that you send out (so you do need to involve your email program for this one).
DMARC is yet another layer of authentication, which tells the inbox providers that you publish SPF and DKIM, and what the inbox provider should do if they receive email that claims to come with you but that doesn’t pass either the SPF or the DKIM authentication checks (for example they should reject it, or put it in the spam folder, etc.).
This is a very basic, simplified overview of SPF, DKIM and DMARC. The key take-away is that it’s very important to have these email authentication mechanisms set up for any and all email that you send. If you would like assistance checking to make sure that your email authentication is set up correctly, or assistance in getting it set up, authentication analysis and set-up assistance is included with our monthly services!