Email Authentication: SPF, DKIM & DMARC Explained

Updated February 6, 2026

Every day, billions of emails are sent pretending to be from domains they don't belong to. Email authentication is the set of protocols that stops this — it lets receiving mail servers verify that an email genuinely came from your domain.

There are three key protocols, and they work together:

SPF — Who Can Send

Sender Policy Framework (SPF) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email for your domain.

When a mail server receives an email claiming to be from yourcompany.com, it looks up the SPF record and checks if the sending server's IP is on the approved list.

A typical SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net -all

This says: "Google Workspace and SendGrid can send for us. Reject everything else."

Learn more: What is SPF? Complete Guide

DKIM — Message Integrity

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and publishes the matching public key in DNS.

The receiving server uses the public key to verify two things:

1. The email actually came from a server with the private key
2. The message wasn't modified in transit

A DKIM DNS record is published at selector._domainkey.yourdomain.com and contains the public key.

Learn more: What is DKIM? Complete Guide

DMARC — The Policy Layer

Domain-based Message Authentication, Reporting & Conformance (DMARC) ties SPF and DKIM together. It tells receiving servers:

1. Which authentication methods to check (SPF, DKIM, or both)
2. What to do when authentication fails (none, quarantine, or reject)
3. Where to send reports about authentication results

A DMARC record is a DNS TXT record at _dmarc.yourdomain.com:

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

Learn more: What is DMARC? Complete Guide

How They Work Together

Think of email authentication as three layers of verification:

For DMARC to pass, at least one of SPF or DKIM must pass with alignment — meaning the domain in the From: header matches the domain that passed SPF or DKIM.

Why It Matters

Without email authentication:

• Attackers can send phishing emails that appear to come from your domain
• Your legitimate emails may land in spam folders
• Email providers have no way to distinguish your real emails from forgeries

With proper authentication:

• Spoofing attempts get blocked at the receiver's end
• Your email deliverability improves
• You receive reports about who's sending email as your domain

Setting Up Email Authentication

Step 1: Configure SPF

Add a TXT record to your domain's DNS with your authorized senders. Most email providers (Google Workspace, Microsoft 365, etc.) provide the exact include: values to use.

Step 2: Enable DKIM

Generate a DKIM key pair through your email provider. Publish the public key as a DNS TXT record at the selector they specify.

Step 3: Add DMARC

Start with a monitoring policy:

v=DMARC1; p=none; rua=mailto:[email protected]

Review reports for 2-4 weeks, fix any issues, then tighten the policy to p=quarantine and eventually p=reject.

MX Records — The Foundation

Before any email authentication can happen, your domain needs MX records that tell the world which servers handle your incoming mail. Without MX records, email simply can't reach you.

Checking Your Setup

The fastest way to verify your email authentication is to use an automated checker that inspects all three records at once and flags misconfigurations.