SPF – DKIM – DMARC – What they all Mean for Email Deliverability

Learn how SPF, DKIM, and DMARC all impact email deliverability.

Tasia Potasinski | May 14, 2020

If email deliverability is core to your product or platform, you’ll quickly find that there are a handful of factors that can impact deliverability.

Managing the sending and receipt of email effectively and safely requires authentication processes. The three main authentications are SPF, DKIM, and DMARC. It’s useful to have a working knowledge of each email authentication method, especially if you need to deploy all three at the same time. 

Applying SPF

SPF (Sender Policy Framework) records are a form of email authentication that specifies how receiving mail servers can verify incoming messages. Fundamentally, SPF is a list of IP addresses. These are the addresses that a given domain will allow for the sending of emails. It’s a simple authentication that adds some control to email processes and improves deliverability rates, but it does not protect the actual email content. 

How does SPF help deliverability? When a domain produces a SPF record, that’s a way to turn spammers away because spam filters will likely catch the spoofed messages. They’ll move on to non SPF-protected domains. An increase in messages marked “spam” drives up the chances for domain blacklisting, which then of course negatively impacts deliverability. 

Layering on DKIM

DomainKeys Identified Mail, or DKIM, is a technical standard designed to protect both senders and email recipients from phishing schemes, spam, and other malicious email usages. Imagine sending a paper letter to a family member where you sign your name at the bottom. If someone was trying to impersonate you, they might intercept the letter and submit their own version. However, your family member’s keen eye would recognize the signatures do not match. That’s DKIM broken down. 

DKIM is a public encryption key that determines if email messages were altered or forged. Generated through the MTA, the DKIM signature is a unique hash value that’s stored in the domain. The receiver checks the signature against the public DNS key, and then decrypts the message’s hash value. If they’re a match, then that provides the MTA with assurance that the email was not altered. 

The DKIM signature is part of the RFC2822 header field, here’s an example of a DKIM signature:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;

     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;

     h=from:to:subject:date:keywords:keywords;

     bh=MTIzNDU2Nzg5MDEyMzQ1NjcjM0NTY3ODkwMTI=;

     b=dzdVyOfAKCdLXdJOc9GlEbav+yuUruD00lszZ;

 

 

The signature contains multiple elements, including the domain of the sender message, the signing algorithm, a selector to determine which public key to use, algorithm instructions for the header and body, query method, timestamp, expiration times, list of headers, and hashed message body, 

Setting DMARC

Domain-based Message Authentication, Reporting and Conformance, or DMARC, extends upon DKIM and SPF by providing an additional layer of protection from misuse as well as improved deliverability. DMARC combined with SPF and DKIM provides businesses with full deliverability control. It’s a type of email “alignment” where a sender can ensure messages are genuine, and then the recipient can validate the message.

With a DMARC policy in place, a sender can denote their messages are under SPF or DKIM (or both), and gives instructions to the recipient side about what to do if a message doesn’t pass either of the authentication methods. This action automates processes for noting emails as junk or rejecting the message outright. The actual DMARC records are part of a company’s DNS database, and appears as a version of a standard DNS TXT record, and includes info about the DMARC version, preferred treatment, mailbox for aggregate reports, mailbox for forensic reports, and a percentage tag noting the amount of mail for which the DMARC policy is applied.

Here’s an example DMARC TXT RR for the domain “sender.dmarcdomain.com” that reads:

“v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]

DMARC is especially useful for preventing spoofing attacks. For example, during the COVID-19 pandemic, hackers used the WHO’s own address for spoofed emails, a problem preventable through usage of DMARC. Google noted it is blocking 18 million COVID-19 scam emails a day, and is pushing the WHO and other organizations to utilize DMARC to stem this flow of spam., Domain owners that implement DMARC create a kind of feedback loop that provides info on failing or passing emails coming from a certain domain. The lack of such feedback means senders often do not understand the scale of the problems with their email communications. They do not have benchmarks for checking progress or debugging. DMARC provides this feedback in a usable form, which reduces spoofing rates and improves deliverability. 

Stronger Together 

SPF, DKIM, and DMARC together provide senders and recipients with strong authentication and rules that substantially impact deliverability rates. These processes add up to a simple equation where the more proof a sender can present about their identity equals less chances of spam designations, and higher chances of reaching the inbox. 

At Nylas, we power applications with email, calendar, and contacts connectivity, saving developers over 30,000 engineering hours and $2M in development costs by providing a single point of integration connecting your app to 100% of email service providers.  

Emails sent over the Nylas API get near perfect email deliverability (more on this here). If you’re interested in seeing how Nylas works, you can sign up for a free developer account here.

About the Author

Tasia is the Director of Product Marketing at Nylas. She's passionate about communications and helping connect the world through APIs. In her free time, she writes and produces music.

Ready to Start Building?