Understanding Email Authentication: SPF, DKIM, and DMARC

Published on February 10, 2026

· Updated on March 16, 2026

email-securitytechnical

Email authentication might sound complex, but understanding the basics is essential for anyone who sends emails professionally. Whether you're running email marketing campaigns, managing a business domain, or simply want to understand why some emails land in spam, knowing how SPF, DKIM, and DMARC work will make you a more effective communicator.

In this guide, we'll break down the three main protocols that protect your emails — and explain how they work together to keep your domain safe from spoofing and phishing.

Why Email Authentication Matters

Before we dive into the protocols, it's important to understand the problem they solve.

Email was invented in the early days of the internet, when trust between systems was assumed. The original email protocol (SMTP) has no built-in way to verify that the sender is who they claim to be. This means anyone can send an email that appears to come from your domain — a technique known as email spoofing.

Spoofing enables:

Phishing attacks: Attackers send emails that look like they come from your company, tricking recipients into revealing passwords, credit card numbers, or other sensitive information
Business Email Compromise (BEC): Criminals impersonate executives to authorize fraudulent wire transfers or data sharing
Brand damage: Spam sent from spoofed versions of your domain hurts your reputation, even though you didn't send it
Deliverability problems: If your domain is being spoofed, email providers may start treating your legitimate emails as suspicious

Email authentication protocols — SPF, DKIM, and DMARC — were created to solve these problems. They give receiving email servers a way to verify that an incoming email actually came from an authorized sender.

What is SPF?

Sender Policy Framework (SPF) is a DNS record that specifies which mail servers are authorized to send emails on behalf of your domain. Think of it as a guest list for your email domain — if a server isn't on the list, it shouldn't be sending emails claiming to be from you.

How SPF Works

You publish an SPF record in your domain's DNS settings. This record lists all the IP addresses and servers authorized to send email for your domain.
When a receiving server gets an email from your domain, it looks up your SPF record.
The receiving server checks whether the sending server's IP address matches one of the authorized entries.
If it matches, the email passes SPF. If it doesn't, the email fails SPF.

Example SPF Record

A typical SPF record looks like this:

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

This record says:

v=spf1 — This is an SPF version 1 record
include:_spf.google.com — Google's mail servers are authorized (for Google Workspace users)
include:servers.mcsv.net — Mailchimp's servers are authorized (if you use Mailchimp for newsletters)
-all — Reject emails from any server not listed above (the - means hard fail; ~ would mean soft fail)

SPF Limitations

SPF is a solid first layer of defense, but it has some limitations:

It only checks the "envelope from" address, not the "From" header that the recipient sees. An attacker can still forge the visible "From" address.
SPF breaks when emails are forwarded, because the forwarding server's IP address won't be in the original domain's SPF record.
There's a 10 DNS lookup limit. Complex SPF records with many include statements can hit this limit, causing failures.

That's where DKIM comes in.

What is DKIM?

DomainKeys Identified Mail (DKIM) adds a digital signature to your outgoing emails. This signature is created using a private key (held by your email server) and can be verified using a public key published in your DNS records.

How DKIM Works

When your email server sends a message, it creates a cryptographic hash of certain email headers and the message body.
This hash is encrypted with your domain's private key, creating a digital signature.
The signature is added to the email as a special DKIM-Signature header.
When the receiving server gets the email, it looks up your public key in DNS.
The receiving server decrypts the signature and compares it to its own hash of the email.
If they match, the email passes DKIM — confirming that it came from your domain and wasn't altered in transit.

What DKIM Proves

DKIM ensures two important things:

Authenticity: The email was actually sent by (or authorized by) the claimed domain
Integrity: The email content hasn't been tampered with during transit — no one has modified the subject, body, or headers since it was signed

DKIM vs. SPF

While SPF checks whether the sending server is authorized, DKIM checks whether the email itself is legitimate and unmodified. They complement each other:

	SPF	DKIM
What it checks	Sending server IP	Email content signature
Survives forwarding	No	Yes
Detects tampering	No	Yes
DNS record type	TXT	TXT (public key)

For the strongest protection, you need both SPF and DKIM — plus DMARC to tie them together.

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM. It serves two critical functions:

Policy: It tells receiving servers what to do when an email fails both SPF and DKIM checks
Reporting: It sends you reports about authentication results, so you can monitor who is sending email using your domain

How DMARC Works

You publish a DMARC record in your DNS settings
When a receiving server gets an email from your domain, it checks SPF and DKIM results
DMARC adds an important additional check called alignment: the domain in the "From" header must match the domain used in SPF and/or DKIM
If the email fails alignment, the receiving server follows your DMARC policy

DMARC Policies

DMARC offers three policy levels, allowing you to gradually increase protection:

p=none (Monitor): Don't take any action on failed emails. This is the starting point — you'll receive reports about authentication failures without affecting email delivery. Use this phase to identify all legitimate email sources for your domain.
p=quarantine (Quarantine): Send failed emails to the spam folder. This is a middle ground that protects recipients while still delivering the email (in spam) in case of false positives.
p=reject (Reject): Block failed emails entirely. This is the strongest protection, telling receiving servers to reject any email that doesn't pass authentication. Only move to this level once you're confident that all your legitimate email sources are properly configured.

Example DMARC Record

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

This record says:

v=DMARC1 — This is a DMARC version 1 record
p=quarantine — Quarantine (send to spam) emails that fail authentication
rua=mailto:dmarc@example.com — Send aggregate reports to this email address
pct=100 — Apply the policy to 100% of emails (you can start with a lower percentage during rollout)

DMARC Reporting

One of DMARC's most valuable features is its reporting capability. Receiving servers send you XML reports containing:

How many emails they received from your domain
How many passed or failed SPF, DKIM, and DMARC
Which IP addresses sent the emails
What actions were taken (none, quarantine, reject)

These reports help you:

Discover unauthorized senders using your domain
Identify configuration issues with your legitimate email services
Track phishing attempts targeting your domain
Build confidence before moving to a stricter DMARC policy

How SPF, DKIM, and DMARC Work Together

Think of these three protocols as layers of a security system:

SPF is the bouncer at the door — it checks if the mail server is on the approved list
DKIM is the ID verification — it confirms the email is genuine and hasn't been tampered with
DMARC is the security manager — it decides what happens when something doesn't check out and generates incident reports

For maximum protection, you need all three working together:

Email sent from your domain
  ↓
Receiving server checks SPF → Is the server authorized?
  ↓
Receiving server checks DKIM → Is the signature valid?
  ↓
DMARC checks alignment → Does the "From" domain match?
  ↓
DMARC policy applied → none / quarantine / reject
  ↓
DMARC report generated → Sent to your reporting address

Implementing Email Authentication: A Practical Roadmap

If you're setting up email authentication for the first time, here's a step-by-step approach:

Phase 1: Audit (Week 1-2)

Inventory all services that send email on behalf of your domain (marketing platforms, CRM, transactional email services, etc.)
Check your existing SPF and DKIM records using our free DNS Checker tool

Phase 2: Configure (Week 2-4)

Set up SPF records that include all legitimate sending services
Enable DKIM signing for all email services (most providers like Google Workspace, Mailchimp, and SendGrid offer one-click DKIM setup)
Publish a DMARC record with p=none to start collecting reports without affecting delivery

Phase 3: Monitor (Week 4-12)

Review DMARC reports to identify any legitimate senders you missed
Fix SPF and DKIM configurations for any services that are failing
Use our DMARC Analyzer to parse and understand your DMARC XML reports

Phase 4: Enforce (Week 12+)

Move your DMARC policy from p=none to p=quarantine
Monitor for any delivery issues
Eventually move to p=reject for maximum protection

Why Does This Matter for Everyday Email Users?

Even if you're not a system administrator, understanding email authentication helps you:

Improve your email deliverability: Properly authenticated emails are more likely to land in the inbox, not spam
Protect your domain from spoofing: Prevent attackers from sending phishing emails that appear to come from your domain
Build trust with email providers: Gmail, Outlook, and other providers favor authenticated emails in their ranking algorithms
Reduce the chance of your emails landing in spam: Authentication signals are a key factor in spam filtering decisions
Comply with sender requirements: Google and Yahoo now require SPF, DKIM, and DMARC for bulk senders (5,000+ emails per day)

Analyze Your DMARC Reports

Understanding your DMARC reports can be challenging. The raw XML format is dense and difficult to read manually — especially when you're receiving reports from dozens of email providers.

That's why we built a free DMARC Analyzer tool that helps you parse and understand your DMARC XML reports in seconds. Simply upload your report file, and the tool breaks down:

Total email volume from your domain
Pass/fail rates for SPF, DKIM, and DMARC
Source IP addresses and their authentication results
Actionable recommendations for improving your email authentication

You can also use our DNS Checker to verify that your SPF, DKIM, and DMARC records are correctly published and properly formatted.