Understanding SPF and DKIM Authentication

With cyber threats ever-evolving in today’s digital world, protecting our email communications is an ongoing process. Recently, Google and Yahoo, two of the biggest email service providers in the industry, have taken steps to increase email security for their users.

One of the new email policies for 2024 relates to two email authentication tools: SPF and DKIM. In this guide, we’ll explore the ins and outs of SPF and DKIM, and how you can ensure you’re complying with the latest email security protocols.

Table of contents

• What is SPF?
• SPF records
• What is DKIM?
• DKIM txt record and signature
• Another layer of protection: DMARC
• Why use SPF and DKIM?
• Google and Yahoo email policies in 2024
• SendWP makes SPF and DKIM easy

Terms to know

• Sender Policy Framework (SPF)
• DomainKeys Identified Mail (DKIM)
• Domain Name System (DNS)
• Email Service Provider (ESP)

What is SPF?

SPF is an email authentication method designed to detect and prevent email security risks, like spoofing. It allows domain owners to specify which mail servers, or IP addresses, are authorized to send emails on behalf of their domain.

Domain owners who send emails can add an SPF record to the DNS — the database that holds domain information for ESP verification. This SPF record contains a list of authorized mail servers (using their IP addresses) that are allowed to send emails on behalf of the domain.

When an email arrives, the recipient’s mail server checks the SPF record of the sender’s domain to verify the authenticity of the sender. If the sending IP address appears in the SPF records, the email goes through to the inbox. If the IP address is not listed, this is considered an SPF check failure. The email will either be blocked or sent to spam.

SPF records

Setting up SPF records allows you, the sender, to define the authorized mail servers for your domain. The record itself is a text (txt) file stored in the DNS. Here’s an example of a typical SPF txt record:

v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 include:_spf.example-esp.com ~all

Now, let’s break down the record. It starts with the version protocol (v=spf1) followed by a few other sections called “mechanisms.”

v=spf1

Every SPF txt record should begin with this version indicator. It tells the email server that the text is an SPF record.

ip4:192.0.2.1 ip4:192.0.2.2

Next, you’ll list the IP addresses authorized to send mail from your domain. In the example above, ip4:192.0.2.1 and ip4:192.0.2.2 are authorized senders.

This section of your record can vary in length (depending on the number of approved email servers), but the total SPF record string shouldn’t exceed 255 characters. You may need to add additional txt records if you’re authorizing many IP addresses.

include:_spf.example-esp.com

The “include” mechanism of the SPF txt record tells email servers which third parties can send messages for your domain. This may include your HR or payroll platforms, email marketing service, transactional email service, and more.

The receiving ESP will check the listed domains (e.g., “example-esp.com”) for their own SPF records and authorized IP addresses.

~all

The “all” mechanism, typically listed at the end of your SPF txt record, tells receiving servers what to do with messages that fail the SPF check.

More on the all mechanism

There are three options for the all mechanism in your SPF records:

• -all (Fail): Instructs the receiving server to reject messages when the IP address is not in the DNS record (it’s not authorized to send on the domain’s behalf)
• ~all (SoftFail): Says to accept the messages from unauthorized IP addresses, but mark them as spam
• +all (Pass): Gives permission for any server to send on your domain’s behalf (not recommended)

The ~all/SoftFail option is often preferred, especially for new domains or those using SPF authentication for the first time. If you use -all/Fail but your DNS records aren’t set up properly, ESPs may mark legitimate messages as spam. ~all/SoftFail allows you to troubleshoot your SPF settings without harming your sender reputation and spam rate.

TIP: Reviewing your DMARC reports helps ensure you’ve configured your SPF records correctly.

Other SPF txt record mechanisms

You can include additional information in SPF txt records to allow for a more complex setup.

Other mechanisms include:

• ip6: Like ip4, this mechanism allows you to list the IP addresses authorized to send emails on your domain’s behalf. The difference is the IP version — v4 and v6 addresses are listed separately. Learn more about the IP versions here.
• a: A mechanism that tells the receiving ESP to check the sending domain’s approved ip4 addresses for a match. This provides an extra layer of security if there’s an issue with the IP addresses you list after the ip4 mechanism, like mail server changes.
• mx: A mechanism that prompts the receiving ESP to verify the sender by their mail exchange (mx) records, which specifies which servers can handle incoming mail for the domain.

Here’s an example SPF txt record with all the discussed mechanisms:

v=spf1 ip4:192.0.2.1 ip6:2001:0db8:85a3:0000:0000:8a2e:0370:7334 include:_spf.example-esp.com a mx ~all

What is DKIM?

Like SPF, DKIM protects email recipients from potential scams — and safeguards the sender’s reputation.

Both SPF and DKIM are email authentication methods, but they serve different purposes and use different strategies to block bad actors. SPF checks the sender’s IP address, while DKIM focuses on verifying the integrity of the email content. Think of DKIM as a secret password linked to every email your domain sends.

DKIM authentication works like this: The sender’s email server generates two keys — one public and one private. It adds the private key to the outgoing email header (similar to a digital signature). The public key is published in the sender’s DNS records.

When the receiving email server receives the message, it checks the sender’s DNS records and uses the public key to verify the private key. (This is all performed using asymmetric encryption.)

If the private key can be verified, the email passed DKIM authentication. This check goes a long way in preventing spoofing and other cyber attacks.

DKIM txt record and signature

Similar to SPF records, sending domains must publish DKIM txt records so the recipient ESP can verify the message’s authenticity. DKIM also requires another txt record — the signature attached to outgoing messages.

DKIM record

The DKIM record lives in the DNS, where email servers can verify it against the private email key. Here’s an example DKIM record:

v=DKIM1; k=rsa-sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXTiUYbCFEYKEfCUDv7h4s1SZWg7yD4W1+0J
T7itq3c3RlW23xGQqAPwQwxbiUdPZGFOzgXJ2AQlXaRnL4pPE2mLyTFAWADmFyCgHrRSnW66zF2o7p
vLyYzVkAGq5I0HxxH3Bs22YOzOfSW5m7rVwIDAQAB;

Now, let’s break down each component:

v=DKIM1

This version protocol tells email servers this is a DKIM record and indicates the version of DKIM being used, which is always 1.

k=rsa-sha256

This portion of the code specifies the cryptographic algorithms used to encrypt and decrypt the email contents and private key (RSA and SHA256).

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXTiUYbCFEYKEfCUDv7h4s1SZWg7yD4W1+0J
T7itq3c3RlW23xGQqAPwQwxbiUdPZGFOzgXJ2AQlXaRnL4pPE2mLyTFAWADmFyCgHrRSnW66zF2o7p
vLyYzVkAGq5I0HxxH3Bs22YOzOfSW5m7rVwIDAQAB;

The seemingly random jumble of letters and numbers after p= is the public DKIM key, which ESPs can use to verify the private key attached to incoming emails.

DKIM signature

While the DKIM txt record lives in the DNS, a DKIM signature is attached to the email header in every outgoing message from your domain. Here’s an example of a DKIM signature:

DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; s=selector1;
h=from:to:subject:date;
bh=XrDLNnZ7btI3m+nIhRj56NR8k6b1zXXkDxGcv1zbv1o=;
b=dXKkxHqTlOWVKFsv6ZsRFlJH5CQ61IKjIbGh5hR5gCjdyxZdgyXYduqVYgZpFq

Let’s review the parts and pieces:

v=1

This indicates the DKIM signature version, which is always version 1.

a=rsa-sha256

a= specifies the algorithm used for encrypting the email (add the secret signature), which is RSA with SHA-256 hashing.

d=example.com

This section represents the domain that is signing the email. It’s the domain whose DNS records contain the public key used for verification (AKA, the sender’s domain).

s=selector1

s= Specifies the selector used to locate the DKIM public key in the domain’s DNS records. Domain owners may use different DKIM keys for different subdomains, or they may rotate between keys to increase security. Each selector corresponds to a unique DKIM key pair.

h=from:to:subject:date: 

h= Lists the header fields included in the DKIM signature of each email.

bh=XrDLNnZ7btI3m+nIhRj56NR8k6b1zXXkDxGcv1zbv1o=

bh= Represents the hash value of the email body — the text string that encrypts the contents of the email. It’s calculated using the specified hashing algorithm (in this case, SHA-256). This hash value ensures the integrity of the email body.

b=dXKkxHqTlOWVKFsv6ZsRFlJH5CQ61IKjIbGh5hR5gCjdyxZdgyXYduqVYgZpFq

After b= comes the encrypted private key corresponding to the DKIM public key. Receiving mail servers use this key to verify the authenticity of the email.

Another layer of protection: DMARC

SPF and DKIM are complementary — use them together to enhance email security. By implementing both SPF and DKIM, organizations can establish a multi-layered approach to authenticate and secure their email communications effectively.

But there’s another layer to consider. DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds upon SPF and DKIM by telling email servers how to treat messages that fail authentication.

Why use SPF and DKIM?

SPF and DKIM work together to enhance email security, preventing attacks like spoofing and phishing. When domain owners use these authentication protocols, it legitimizes their emails, helps build a strong domain reputation, and protects the people on their email lists from dangerous messages.

These reasons alone are enough to convince any business to use SPF and DKIM. But, there’s yet another factor: Google and Yahoo’s email policies.

Google and Yahoo email policies in 2024

As the most prolific email service provider in the industry, Gmail is always looking for new and better ways to protect email recipients from spam, phishing, spoofing, and other malicious messages. As of February 2024, they require all bulk email senders (those who send 5,000 or more messages to Gmail users per day) to follow three practices:

• Authenticate your emails with SPF, DKIM, and DMARC
• Enable one-click unsubscribe
• Stay below a 0.3% threshold for spam complaints

When Google announced this change in October 2023, Yahoo quickly followed suit. Your email list undoubtedly includes many @gmail.com and @yahoo.com addresses. If you want to keep sending these recipients messages in bulk, setting up SPF, DKIM, and DMARC is non-negotiable.

More about bulk senders

As mentioned, Gmail defines a “bulk sender” as anyone who sends 5,000 or more messages per day. But that doesn’t mean everyone else should ignore the new updates. Gmail’s policies are best practices for any sender, no matter how many emails you send.

If you use an email sending service like SendWP (or MailChimp, etc.), the 5,000 message threshold applies to the sending service itself — how many messages the company sends per day — so you’ll need SPF and DKIM authentication in place.

How do these policies affect transactional email?

Gmail’s policies apply to both marketing and transactional email types. Bulk email sending typically falls under the marketing category. For instance, sending a Black Friday sale message to your entire email list simultaneously.

Transactional email is different. Since a specific transaction on your website triggers these messages — like a customer recovering their password or making a one-time purchase — they go out one at a time. Unless you’re a major brand like Amazon, you’re likely not sending transactional emails in bulk quantities every day.

Still, Gmail’s policies are important. As mentioned, they apply on the service level, so it’s safer to assume your email service meets the bulk sender requirements. Additionally, email authentication is a recommended method that safeguards recipients from spam and cyber attacks. Since transactional emails deal with high-risk details like account credentials and credit card information, it’s best to follow Gmail’s guidance.

SendWP makes SPF and DKIM easy

If you use SendWP for your transactional emails, we’re here for your email authentication needs. Follow the simple steps outlined in our SPF documentation and DKIM documentation pages to comply with Google’s 2024 policies — and protect your email recipients.

As always, please contact us with any questions.