SPF, DKIM, and DMARC: The Email Authentication Checklist Every Domain Needs

Email is still one of the most abused attack surfaces on the internet. If someone can spoof your domain, they can impersonate your team in phishing, invoice fraud, and account takeover attempts.

The good news: modern email authentication standards make spoofing dramatically harder — if you configure them correctly.

This guide explains SPF, DKIM, and DMARC in practical terms and gives you a checklist you can follow.

The problem: spoofing is easy without authentication

SMTP was designed in an era where trust was assumed. By default, a message can claim to be from you@yourdomain.com even if it didn’t originate from your mail system.

SPF, DKIM, and DMARC fix this by letting domain owners publish verifiable rules:

• SPF: “Which servers are allowed to send mail for this domain?”
• DKIM: “Was this message cryptographically signed by the domain?”
• DMARC: “What should receivers do if SPF/DKIM checks fail, and where should reports go?”

SPF: Sender authorization (IP-based)

SPF is a DNS TXT record at the domain root (or a subdomain) that lists which sending sources are allowed.

Example:

example.com.  300  IN  TXT  "v=spf1 ip4:203.0.113.10 -all"

Key concepts:

• v=spf1 starts the record.
• Mechanisms like ip4:, ip6:, include:, and a define allowed senders.
• The ending -all (hard fail) means “reject anything not matched.”

Common SPF mistakes

1. Multiple SPF records
   • Only one SPF TXT record should exist for a given name.
2. Overly broad includes
   • Includes can allow unexpected sending paths. Keep it intentional.
3. Using ~all forever
   • ~all is a soft fail; it can be okay during rollout, but it’s not the final stop for spoofing resistance.

DKIM: Cryptographic signing (message-based)

DKIM adds a signature header to each outgoing email. The public key is published in DNS at a selector name like:

selector1._domainkey.example.com

The receiver verifies the signature using that public key. If it matches, it’s strong evidence the message came from an authorized sender using a private key your domain controls.

What a DKIM rollout looks like

You typically:

1. Generate a DKIM keypair (your sending system does this).
2. Publish a TXT record for the selector with the public key.
3. Enable signing for outbound mail.

If you use multiple sending systems, you may have multiple selectors — that’s normal.

DMARC: Policy, alignment, and reporting

DMARC is where SPF and DKIM become enforceable in a consistent way.

DMARC lives at:

_dmarc.example.com

Example:

_dmarc.example.com.  300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

DMARC adds two important ideas:

1. Alignment
   • SPF can “pass” for a different domain than what users see in the From header.
   • DKIM can “pass” with a signature domain that doesn’t match the visible From.
   • DMARC checks that the authenticated identity aligns with the From domain (relaxed or strict).
2. Policy
   • p=none → monitor only (no enforcement)
   • p=quarantine → treat failures as suspicious
   • p=reject → reject messages that fail DMARC

A safe DMARC rollout strategy

If you haven’t deployed DMARC before, do this:

1. Start with p=none and enable reports (rua=mailto:...).
2. Fix legitimate senders that are failing SPF/DKIM.
3. Move to p=quarantine (optionally with pct=25 then ramp up).
4. Move to p=reject once you’re confident.

This avoids accidentally blocking legitimate marketing, support, or transactional mail streams.

Validation: how to check your records

1) Check SPF TXT

dig TXT example.com +short

Look for exactly one v=spf1 ... record.

2) Check DMARC TXT

dig TXT _dmarc.example.com +short

Confirm v=DMARC1 exists and policy (p=) is what you intend.

3) Check DKIM selector TXT

Selectors vary. If you know the selector name:

dig TXT selector1._domainkey.example.com +short

If you don’t know the selector, check your sending system configuration — it should tell you.

What “good” looks like (a minimal target state)

• SPF: present, valid, and limited to the systems that actually send mail for your domain.
• DKIM: enabled on primary outbound mail streams.
• DMARC: present with reporting, with a plan to move toward enforcement.

FAQ

Do SPF/DKIM/DMARC improve deliverability?

They can. Authentic mail is less likely to be flagged as spoofing. But deliverability also depends on content, sending reputation, and list practices.

Is SPF enough by itself?

Not really. SPF is useful but can be bypassed in some forwarding scenarios, and it doesn’t prove the message wasn’t modified. DKIM + DMARC together are much stronger.

Can I set DMARC to reject immediately?

You can, but it’s risky if you don’t fully understand all legitimate mail streams using your domain. Start with monitoring unless you’re sure.