Email Authentication: The Complete Guide to SPF, DKIM, and DMARC

If you send email from your business domain — and you almost certainly do — there are three protocols working behind the scenes to decide whether your messages reach the inbox or the spam folder. They are SPF, DKIM, and DMARC, and together they form the email authentication ecosystem.

This guide is your starting point. It explains what each protocol does, how they work together, and what happens when one or more of them is missing. No technical background required.

Why Email Authentication Matters

Email was invented in the 1970s without any built-in way to verify who sent a message. Anyone can send an email claiming to be from any domain. That design flaw is what makes phishing, spoofing, and business email compromise possible.

Email authentication protocols were created to fix this. They let domain owners declare which servers are allowed to send on their behalf, prove that messages have not been tampered with in transit, and tell receiving servers what to do with messages that fail verification.

There are two practical reasons you should care about this.

Deliverability. Gmail, Yahoo, and Microsoft all use authentication results when deciding whether your email goes to the inbox or the spam folder. Since early 2024, Google and Yahoo require authentication for bulk senders. Even small senders benefit — authenticated emails consistently reach more inboxes.

Security. Without authentication, anyone can send emails that look like they came from your domain. That means phishing emails to your customers, fake invoices to your vendors, and impersonation attacks against your employees. Authentication shuts that down.

SPF: Who Is Allowed to Send

Sender Policy Framework (SPF) is the first layer of email authentication. It answers a simple question: is this server authorized to send email on behalf of this domain?

SPF works through a DNS TXT record that lists every IP address and server authorized to send email as your domain. When a receiving mail server gets a message, it checks the sending server's IP against your SPF record. If the IP is listed, SPF passes. If not, it fails.

Here is what a basic SPF record looks like:

v=spf1 include:_spf.google.com include:amazonses.com -all

This record says: Google Workspace and Amazon SES are authorized senders. Everything else should fail (-all).

SPF has a few limitations. It only checks the server that delivered the message, not the content of the message itself. It breaks when emails are forwarded because the forwarding server's IP is not in your SPF record. And there is a limit of 10 DNS lookups per SPF record, which can become a constraint if you use many third-party sending services.

If you need to create or update your SPF record, you can do that at spfcreator.com.

DKIM: Proving the Message Is Authentic

DomainKeys Identified Mail (DKIM) is the second layer. While SPF checks who sent the message, DKIM verifies that the message itself has not been altered in transit.

DKIM works using cryptographic signatures. When your email server sends a message, it creates a digital signature based on the email's headers and body. That signature is added to the email as a header. The receiving server retrieves your public key from a DNS record and uses it to verify the signature.

If the signature checks out, the receiving server knows two things: the email was actually sent by an authorized system, and nobody changed the message between the sender and recipient.

A DKIM DNS record looks something like this:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

The "selector" is a label you choose to identify different signing keys. You might have one selector for Google Workspace and another for your marketing platform.

The key advantage of DKIM over SPF is resilience to forwarding. Because the signature is attached to the message, it survives when emails are forwarded, redistributed through mailing lists, or relayed through intermediate servers. SPF breaks in all of those scenarios.

You can generate DKIM keys at dkimcreator.com.

DMARC: The Policy Layer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the third layer. It ties SPF and DKIM together and adds two things they lack on their own: a policy mechanism and a reporting system.

Without DMARC, SPF and DKIM can tell a receiving server whether a message passed or failed authentication, but they do not say what to do about it. DMARC fills that gap. It lets you publish a policy in your DNS that tells receiving servers: "If a message from my domain fails both SPF and DKIM alignment, here is what I want you to do with it."

The three policy options are:

• p=none — Take no action, but send me reports. This is for monitoring.
• p=quarantine — Send failing messages to the spam folder.
• p=reject — Block failing messages entirely.

A basic DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

DMARC also introduces the concept of alignment. It is not enough for SPF or DKIM to simply pass — the domain used in the SPF or DKIM check must match the domain in the "From" header that the recipient sees. This prevents attackers from passing SPF with their own domain while spoofing yours in the visible "From" address.

Learn more about DMARC in our what is DMARC guide, or generate your record using the tool below.

How the Three Protocols Work Together

Here is what happens when someone receives an email from your domain, step by step.

This is why all three protocols matter. SPF and DKIM are the authentication mechanisms. DMARC is the policy and reporting layer that makes them actionable. For a detailed side-by-side breakdown, see our SPF vs DKIM vs DMARC comparison, or dive deeper into the relationship between signatures and policy with DKIM vs DMARC.

Beyond the Basics: BIMI and ARC

Once you have SPF, DKIM, and DMARC working together, two additional standards build on that foundation.

BIMI: Your Brand Logo in the Inbox

Brand Indicators for Message Identification (BIMI) lets you display your company logo next to your emails in supporting inboxes like Gmail, Apple Mail, and Yahoo Mail. It requires DMARC enforcement at p=quarantine or p=reject — BIMI is essentially the reward for getting your authentication right.

BIMI requires a specially formatted SVG logo and, for Gmail and Apple Mail, a Verified Mark Certificate tied to a registered trademark. Learn more in our DMARC and BIMI guide.

ARC: Fixing the Forwarding Problem

Authenticated Received Chain (ARC) addresses the forwarding problem that breaks SPF. When a message is forwarded through an intermediary server, ARC preserves the original authentication results so the final receiving server can see that the message was legitimate before it was forwarded.

ARC is implemented by intermediary mail servers, not by domain owners. You do not need to configure ARC yourself — but understanding it helps explain why some forwarded messages pass DMARC while others do not. Our DMARC and ARC guide covers this in detail.

Getting Started

If you are starting from scratch, here is the order to follow:

1. Set up SPF first. List all servers that send email on behalf of your domain. Create your record at spfcreator.com.
2. Set up DKIM second. Generate keys and publish them in DNS. Start at dkimcreator.com.
3. Set up DMARC third. Start with p=none and a reporting address so you can see what is happening. Generate your record above or follow our DMARC setup guide.
4. Monitor and enforce. Review your DMARC reports, fix any authentication issues, and gradually move from p=none to p=quarantine to p=reject.

The entire process can take a few weeks if you have a simple setup, or a few months if you use many third-party email services. Developer teams can streamline this by automating DNS record management and integrating authentication checks into deployment pipelines. If you run your own mail server, our DMARC for self-hosted email guide covers the additional considerations. The key is to start with monitoring, fix issues as you find them, and move toward enforcement at a pace that feels safe.

You can check your current authentication status — SPF, DKIM, DMARC, and MX records — at any time using dmarcrecordchecker.com.

Monitor Your Email Authentication

You've set up your email authentication — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.