Email Authentication: SPF, DKIM, and DMARC Explained

Why email needs authentication

Email was designed in the 1970s without any built-in way to verify the sender's identity. The SMTP protocol lets anyone claim any "From" address — there's nothing in the protocol to prevent it. This is like postal mail: you can write any return address on an envelope.

This fundamental design flaw enables email spoofing: attackers sending messages that appear to come from your domain. The consequences range from phishing attacks against your customers to full-blown business email compromise (BEC) fraud.

Three protocols were developed to solve this: SPF, DKIM, and DMARC. Each addresses a different aspect of the problem, and together they form a comprehensive authentication system.

SPF: Who can send?

Sender Policy Framework (SPF) lets you publish a DNS record listing which IP addresses are authorized to send email for your domain.

How it works:

1. You publish a TXT record at your domain: v=spf1 include:_spf.google.com ip4:203.0.113.5 -all
2. When a server receives an email claiming to be from your domain, it looks up your SPF record
3. It checks whether the sending server's IP is in the authorized list
4. If yes, SPF passes. If no, it fails (or softfails, depending on your record)

What SPF can do:

• Verify that the sending server is authorized
• Prevent direct IP spoofing

What SPF can't do:

• Protect the visible "From" header (it checks the envelope sender)
• Survive email forwarding (the forwarding server's IP isn't in your SPF)
• Guarantee message integrity (the content could be modified)

For the full details, read our complete SPF guide.

DKIM: Is the email authentic?

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to each email. The signing domain publishes a public key in DNS, and the receiving server uses it to verify the signature.

How it works:

1. Your mail server generates a key pair (private key stays on your server, public key goes in DNS)
2. When sending, the server creates a hash of certain email headers and the body, then signs it with the private key
3. The signature is added as a DKIM-Signature header
4. The receiving server retrieves the public key from DNS and verifies the signature

What DKIM can do:

• Prove the email wasn't modified in transit
• Cryptographically link the email to a specific domain
• Survive email forwarding (the signature travels with the message)

What DKIM can't do:

• Specify what to do with unsigned or failing emails (that's DMARC's job)
• Prevent someone from adding a valid DKIM signature for a different domain

DMARC: What to do when checks fail?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together with two critical additions: alignment and policy.

Alignment means the domain that passed SPF or DKIM must match the domain in the visible "From" header. Without this, an attacker could use their own domain for SPF/DKIM while spoofing your domain in the "From" header.

Policy tells receiving servers what to do with messages that fail DMARC: nothing (p=none), quarantine (p=quarantine), or reject (p=reject).

DMARC also adds reporting: receiving servers send you aggregate reports showing who's sending email as your domain and whether they pass authentication. For a deep dive, read our DMARC guide.

How they work together

Think of email authentication as a three-layer security system:

For DMARC to pass, at least one of these must be true:

• SPF passes AND aligns — The envelope sender domain matches the "From" header domain
• DKIM passes AND aligns — The DKIM signing domain (d=) matches the "From" header domain

Only one needs to pass with alignment. This is important because SPF breaks during forwarding (the IP changes), but DKIM usually survives (the signature stays with the message).

Why you need all three

SPF alone isn't enough

SPF checks the envelope sender, not the "From" header that users see. An attacker can set the envelope sender to their own domain (passing SPF) while displaying your domain in the "From" header. Without DMARC's alignment check, the user sees a spoofed email.

SPF also breaks during email forwarding. When a message is forwarded, the sending IP changes to the forwarding server's IP, which isn't in your SPF record.

DKIM alone isn't enough

DKIM proves a domain signed the email, but without DMARC, there's no policy for unsigned messages. An attacker can simply send unsigned emails claiming to be from your domain. There's also nothing preventing an attacker from DKIM-signing the email with their own domain while spoofing your domain in the "From" header.

DMARC alone isn't enough

DMARC is a policy layer. It depends on SPF and DKIM for the actual authentication. Without at least one of them, DMARC has nothing to enforce.

Together, they're comprehensive

With all three configured:

• SPF authorizes your sending servers
• DKIM proves message integrity and survives forwarding
• DMARC enforces alignment and provides a policy for failures

The authentication flow

Here's what happens when someone sends an email from user@yourdomain.com:

Sending side

1. Your mail server connects to the recipient's mail server via SMTP
2. It announces the envelope sender (MAIL FROM: user@yourdomain.com)
3. It adds a DKIM signature header to the message
4. It transmits the message

Receiving side

1. SPF check: Look up yourdomain.com's SPF record. Is the sender's IP authorized? → Pass or Fail
2. DKIM check: Find the DKIM signature header. Look up the public key at selector._domainkey.yourdomain.com. Verify the signature. → Pass or Fail
3. DMARC check: Look up _dmarc.yourdomain.com. Check alignment:
   • Did SPF pass? Does the envelope sender domain match the "From" header domain?
   • Did DKIM pass? Does the signing domain match the "From" header domain?
4. Policy enforcement: If DMARC fails, apply the domain's policy (none/quarantine/reject)
5. Reporting: Record the results for the domain's aggregate DMARC report

Common misconceptions

"SPF checks the From header"

No. SPF checks the envelope sender (MAIL FROM), which is invisible to most users. The visible "From" header is a separate field. This is exactly why DMARC's alignment is necessary.

"DKIM encrypts the email"

No. DKIM signs the email — it proves the message wasn't modified. It does not encrypt the content. Email encryption is handled by TLS (in transit) and S/MIME or PGP (end-to-end).

"DMARC is only for large companies"

Small businesses and personal domains are spoofed too — often more easily because they're less likely to have protections. DMARC is free to implement and relevant for any domain that sends email.

"Setting up SPF is enough"

SPF without DMARC leaves the visible "From" header unprotected. You need DMARC to enforce alignment between the envelope sender and the header "From" domain.

"Email authentication prevents all spam"

Email authentication prevents domain spoofing — it stops people from sending email as your domain. It doesn't prevent all spam. An attacker can still send spam from their own properly-authenticated domain.

"Once set up, authentication doesn't need maintenance"

SPF records drift as you add and remove email services. DKIM keys can expire or become weak. New subdomains need their own records. Email authentication requires ongoing monitoring — which is exactly what Sendvery is built for.

Getting started

Here's your action plan:

1. Run the Email Auth Checker to see your current state across all three protocols
2. Fix SPF first — Make sure your SPF record lists all legitimate sending sources. Read our complete SPF guide
3. Set up DKIM — Configure DKIM signing on all your email-sending services. Use our DKIM Checker to verify
4. Add DMARC — Start with p=none and monitoring. Read our DMARC guide for the full setup process
5. Monitor and tighten — Review DMARC reports, fix issues, and gradually move to p=reject

The whole process can be done in an afternoon for simple setups. For organizations with many sending services, allow 2-4 weeks for the monitoring phase before tightening your DMARC policy.