Skip to content

SPF, DKIM, DMARC: The three pillars of email authentication

Your domain can send emails. But can it prove it was actually the sender? And what happens when someone manipulates that proof?

Three mechanisms, one goal

SPF, DKIM, and DMARC are three independent mechanisms that together answer one question: Does this email really come from the domain it claims?

Without them, any mail server in the world can claim to send mail from your domain. With them, the receiving server can verify whether that's true.

All three live as DNS records. And that's exactly what makes them attackable.

SPF: Who may send?

SPF (Sender Policy Framework) is a list of IP addresses and servers authorized to send mail for your domain. The receiving server checks: Is the sending server in the SPF list?

A typical SPF record:

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

This says: Google Workspace and Amazon SES may send. Nobody else (-all).

What happens on manipulation: An attacker adds an additional server to the SPF list. From now on, their server may also send mail in your name – and it passes SPF checks. Phishing emails from your domain land in inboxes, not spam.

DKIM: Is the mail unaltered?

DKIM (DomainKeys Identified Mail) cryptographically signs every outgoing mail. The public key lives as a DNS record. The receiving server checks: Does the signature match the public key?

A DKIM record looks like this:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

What happens on manipulation: An attacker swaps the public key in DNS. Now they can sign mails with their own private key – and DKIM verification passes. Or they remove the DKIM record entirely. Then verification fails, but without a DMARC policy, nothing happens anyway.

DMARC: What to do on failure?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It tells the receiving server: What should you do when SPF or DKIM fail?

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The three policies:

• none – do nothing, just report (monitoring mode)
• quarantine – move to spam
• reject – reject the mail entirely

What happens on manipulation: An attacker changes the DMARC policy from "reject" to "none". From now on, mails that fail SPF and DKIM are delivered anyway. The protection is gone – without you noticing, because your own mails keep working fine.

The chain of trust

SPF, DKIM, and DMARC together form a chain:

1. SPF checks: May this server send?
2. DKIM checks: Is the mail authentic and unaltered?
3. DMARC decides: What happens when 1 or 2 fail?

Break one link, break the chain. And all three links are DNS records – TXT entries that can be changed in seconds with compromised DNS access.

Gradual degradation

The insidious part: Email authentication can degrade gradually without anyone noticing.

• An employee adds a new mail service but forgets to update the SPF record. Mails from that service land in spam.
• A DKIM key gets rotated, but the old DNS record stays. Two keys are active – one of them possibly compromised.
• The DMARC policy is set to "none" for testing and never switched back to "reject".

None of these cases trigger an alarm. Everything "works" – only the protection is gone.

What Driftguard detects

Driftguard monitors all three as part of your DNS baseline:

SPF: New includes, removed servers, switch from -all to ~all (from strict to soft-fail).

DKIM: Changed public keys, removed records, new selectors.

DMARC: Policy changes (reject → none), changed report addresses, removed records.

Every change is detected and documented. So you can see whether your email authentication is still as strong as the day you set it up.