The 3 Pillars of Email Authentication: SPF, DKIM, DMARC


If you’re an email marketer or maybe troubleshooting with email issue, you’ve probably heard acronyms like “SPF,” “DKIM,” and “DMARC” being tossed around with little explanation.

The good news is that SPF, DKIM, and DMARC can work together for you like a triple rainbow of email authentication, and that’s why I want you to have a thorough understanding of them. The explanations are technical, but these are three fundamental concepts to understand about email authentication.

I’ll provide you with a brief and insightful look at each of these protocols, then you’ll be able to start tossing these acronyms around like the pros. First things first…

What is email authentication, and why is it so important?

Email authentication helps to improve the delivery and credibility of your marketing emails by implementing protocols that verify your domain as the sender of your messages.  

Using authentication won’t guarantee that your mail reaches the inbox (that’s where you need to focus on improving your email deliverability), but it preserves your brand reputation while making sure you have the best possible chance of having your messages reach their intended destination. 

Read on to find out how to ensure you’re achieving the gold standard of email authentication.

SPF, DKIM, and DMARC: 3 Technical, but Essential, Explanations

SPF: Sender Policy Framework

SPF, Sender Policy Framework, is a way for recipients to confirm the identity of the sender of an incoming email.

By creating an SPF record, you can designate which mail servers are authorized to send mail on your behalf. This is especially useful if you have a hosted email solution (Office365, Google Apps, etc.) or if you use an ESP like Higher Logic.

Here’s a brief synopsis of the process:

  1. The sender adds a record to the DNS settings.
    1. The record is for the domain used in their FROM: address (e.g. if I send from [email protected], add the record to This record includes all IP addresses (mail servers) that are authorized to send mail on behalf of this domain. A typical SPF record will look something like this:
      v=spf1 ip4: ip4: ip4: ~all
  2.  The receiving server checks the DNS records.
    1. When the mail is sent, the receiving server checks the DNS records for the domain in the FROM: field. If the IP address is listed in that record (as seen above), the message passes SPF.
  3. If SPF exists, but the IP address isn’t in the record, it’s a hard fail.
    1. If the SPF record exists, but the IP address of the sending mail server isn’t in the record, it’s considered a “hard-fail.” This can often cause mail to be rejected or routed to the spam folder.
  4. If no SPF record exists, it’s a soft fail.
    1. If no SPF record exists at all, this is considered a “soft-fail.” These are most likely to cause messages to be routed to spam but can lead to a message being rejected as well.

How does SPF work?


  • upon receipt the HELO message and the sender address are fetched by the receiving mail server
  • the receiving mail server runs an TXT DNS query against the claimed domain SPF entry
  • the SPF entry data is then used to verify the sender server
  • in case the check fails a rejection message is given to the sender server

DKIM: DomainKeys Identified Mail

DKIM, short for DomainKeys Identified Mail, also allows for the identification of “spoofed” emails but using a slightly different process. Instead of a single DNS record that keys off the FROM: address, DKIM employs two encryption keys: one public and one private.

The private key is housed in a secure location that can only be accessed by the owner of the domain. This private key is used to create an encrypted signature that is added to every message sent from that domain. Using the signature, the receiver of the message can check against the public DKIM key, which is stored in a public-facing DNS record. If the records “match,” the mail could only have been sent by the person with access to the private key, aka the domain owner.  

How does DKIM work?


  • 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
  • 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

DMARC: Domain-based Message Authentication, Reporting, & Conformance

While SPF and DKIM can be used as stand-alone methods, DMARC must rely on either SPF or DKIM to provide the authentication.

DMARC (Domain-based Message Authentication, Reporting, & Conformance) builds on those technologies by providing directions to the receiver on what to do if a message from your domain is not properly authenticated.

Like SPF and DKIM, DMARC also requires a specific DNS record to be entered for the domain you wish to use in your FROM: address. This record can include several values, but only two are required:

  • (v) tells the receiving server to check DMARC
  • (p) gives instructions on what to do if authentication fails.

The values for p can include:

  • p=none, which tells the receiving server to take no specific action if authentication fails.
  • p=quarantine, which tells the receiving server to treat unauthenticated mail suspiciously. This could mean routing the mail to spam/junk, or adding a flag indicating the mail is not trusted.
  • p=reject, which tells the receiving server to reject any mail that does not pass SPF and/or DKIM authentication.

In addition to the required tags advising how to handle unauthenticated mail, DMARC also provides a reporting component that can be very useful for most organizations. By enabling the reporting features of DMARC, your organization can receive reports indicating all mail that is being sent with your domain in the FROM: address. This can help identify spoofed or falsified mail patterns as well as tracking down other business divisions or partners that may be legitimately sending mail on your behalf without authentication.

How does DMARC work?


  • upon reception the receiving mail server checks if there is any existing DMARC policy published in the domain used by the SPF and/or DKIM checks
  • 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

Where Should You Start with Email Authentication?

The first step is to talk to your email support team about how to ensure you’re authenticating your emails. In addition, there are lots of great tools available on the web, including a number of SPF wizards and DKIM key generators to guide you through the process of creating a record you can copy and paste into your domain management console.

However you go about it, I strongly recommend you authenticate your messages with SPF, DKIM, and DMARC. You’ll be able to acronym like the best of them, while keeping your brand’s reputation safe and secure.

The bad news: limits and best practices

Unfortunately even by having a perfectly functional mail system with all the above tools enforced you won’t be 100% safe from the bad guys out there. Not all servers are using all three tools shown above. It’s enough to take a look at the table shown in Wikipedia [2] to see how that’s possible.

Furthermore there are some limits that you should always consider when dealing with SPF, DKIM and DMARC:

  • as already said above DKIM alone doesn’t grant in any way that the sender server is allowed to send outgoing mail for the specific domain
  • SPF is powerless with messages forged in shared hosting scenario as all the mail will appear as the same coming IP
  • DMARC is still in its early age and unfortunately not used as much as hoped to make a huge difference
  • DMARC can (and will) break your mail flow if you don’t set up both SPF and DKIM beforechanging DMARC policy to anything above “none”.

Please work through the proper process carefully, otherwise your precious messages won’t be delivered to your users as potentially seen as fraudulent by a wrong SPF, DKIM or DMARC setup.

What’s the message behind all this? Should I use these tools or not?

The short answer is: Yes. The longer answer is that everybody should and eventually will in future, but I’m just not there yet. So even if all these tools already have a lot of power, they’re not still shining as bright as they should because of poor adoption.

Hopefully things will change soon and that starts by every one of us adopting these tools as soon as possible.

[1] The lack of such a monitoring tool is considered one of the reasons why other tools (such as ADSP) in past have failed during the adoption phase. [2] Comparison of mail servers on Wikipedia


Please enter your comment!
Please enter your name here