Email Security

DMARC, DKIM, and SPF Explained

Email authentication is the foundation of email security. Understand how these three protocols work together to protect your domain from spoofing and improve deliverability.

Check Your Email Authentication

Why Email Authentication Matters

Email was designed in the 1970s and 1980s without any built-in method to verify who actually sent a message. This fundamental design flaw means that anyone can send an email claiming to be from your domain. Attackers exploit this to impersonate businesses, trick employees, and steal sensitive data. SPF, DKIM, and DMARC were developed to solve this problem by giving domain owners the ability to prove their emails are legitimate and tell receiving servers how to handle messages that fail verification.

The Three Layers of Email Authentication

Think of email authentication as a three-layer security system. Each layer addresses a different aspect of email verification, and together they provide comprehensive protection.

SPF

Who is allowed to send?

DKIM

Is the message authentic?

DMARC

What to do when checks fail?

SPF: Sender Policy Framework

SPF is the first line of defense. It allows you to publish a DNS record that lists every server and service authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server is on the authorized list.

How SPF Works

1You publish a TXT record in your DNS that specifies which IP addresses and services can send email for your domain.
2A receiving mail server gets an email from your domain and looks up your SPF record.
3The server compares the sender's IP address against your authorized list.
4If the IP matches, SPF passes. If not, the email fails SPF authentication.

Example SPF Record

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

v=spf1 -- declares this is an SPF record
include:_spf.google.com -- authorizes Google Workspace servers
include:servers.mcsv.net -- authorizes Mailchimp for marketing emails
ip4:203.0.113.50 -- authorizes a specific IP address
-all -- reject (hard fail) any email from unauthorized sources

SPF Limitations

Limited to 10 DNS lookups -- too many include statements will cause failures
Breaks when emails are forwarded (the forwarding server is not in your SPF record)
Only checks the envelope sender (Return-Path), not the visible From address

DKIM: DomainKeys Identified Mail

DKIM adds a digital signature to every outgoing email. This signature is created using a private key that only your mail server possesses. The corresponding public key is published in your DNS. Receiving servers use the public key to verify that the email was genuinely sent from your domain and that its content has not been modified in transit.

How DKIM Works

1Your mail server generates a public/private key pair. The private key stays on your server; the public key is published as a DNS TXT record.
2When an email is sent, your server creates a hash of key headers and the message body, then encrypts the hash with the private key to produce a DKIM signature.
3The signature is added to the email header as a DKIM-Signature field.
4The receiving server looks up your public key via DNS, decrypts the signature, and compares the hash. If they match, the email is verified as authentic and unaltered.

DKIM Strengths

Survives email forwarding (unlike SPF)
Verifies message integrity (detects tampering)
Builds domain reputation over time

DKIM Limitations

Does not specify what to do when verification fails
Mailing lists can break signatures by modifying headers or body
Keys must be rotated regularly to maintain security

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication and provides a reporting mechanism so you can see who is sending email using your domain -- both legitimate services and attackers.

How DMARC Works

1You publish a DMARC policy in your DNS specifying how to handle authentication failures.
2A receiving server checks the email against both SPF and DKIM, then verifies alignment -- the domain in the visible From address must match the domain validated by SPF or DKIM.
3If alignment fails, the receiving server follows your DMARC policy: none (monitor only), quarantine (send to spam), or reject (block entirely).
4The receiving server sends aggregate reports back to you detailing all authentication results for your domain.

DMARC Policy Levels

p=none (Monitor)

Take no action on failures, but send reports. Start here to understand your email ecosystem without impacting delivery.

p=quarantine (Spam)

Send failing emails to spam/junk. Use this after monitoring confirms all legitimate sources are authenticated.

p=reject (Block)

Block failing emails entirely. The strongest protection -- only deploy after thorough monitoring and quarantine phases.

How SPF, DKIM, and DMARC Work Together

SPF Checks the Sender

"Is this email coming from a server that's authorized to send for this domain?"

Then...

DKIM Verifies the Message

"Was this email actually signed by the domain it claims to be from, and has it been tampered with?"

Finally...

DMARC Enforces the Policy

"Both checks ran. Did at least one pass with domain alignment? If not, here's what to do with the email."

Recommended Implementation Order

Set Up SPF

Inventory all services that send email for your domain
Create your SPF TXT record including all authorized senders
Verify the record resolves correctly and stays under 10 lookups

Enable DKIM

Generate DKIM keys in your email provider
Publish the public key as a DNS TXT record
Send test emails and verify DKIM signatures pass

Deploy DMARC

Start with p=none and a reporting address
Analyze reports for 2-4 weeks to catch all legitimate senders
Progress to quarantine, then reject once all sources are authenticated

Common Mistakes to Avoid

Jumping straight to p=reject without monitoring -- this blocks legitimate emails you forgot to authenticate
Forgetting to authenticate third-party senders (CRM, marketing tools, ticketing systems)
Using ~all (soft fail) in SPF instead of -all (hard fail) for production domains

Not monitoring DMARC reports after deployment -- your email ecosystem changes over time
Exceeding the SPF 10-lookup limit, which causes the entire SPF check to fail
Never rotating DKIM keys -- stale keys are a security risk

Is Your Email Authentication Configured Correctly?

Our free tool checks your domain's SPF, DKIM, and DMARC records and identifies misconfigurations that could be hurting your deliverability or leaving you vulnerable to spoofing.

Check Your Records Email Security Services

Get Security Insights Delivered

One email per month with our best articles. No spam.