SPF, DKIM, and DMARC Explained — A Practical Guide for Sysadmins

Email was designed in an era when everyone on the internet knew each other. There was no authentication layer — any server could send mail claiming to be from any address. That architecture still underlies the email system today, which is why spoofing and phishing remain so prevalent. SPF, DKIM, and DMARC are the three records that sit in DNS to fill that gap.

Understanding all three — not just knowing they exist, but knowing what each one actually checks — is the difference between a domain that's protected and one that can be freely impersonated by anyone with access to a mail server.

Why email authentication matters

When a phishing email appears to come from support@yourbank.com, that address in the From: header is trivially easy to forge. The receiving mail server has no way to know, by default, whether the message genuinely originated from your bank's infrastructure or from a server in a data centre rented ten minutes ago.

Authentication records published in DNS give receiving servers a way to verify claims. They don't prevent spam, and they don't encrypt mail — but they do provide a verifiable chain of custody between a domain and the mail sent in its name.

SPF: which servers are allowed to send

SPF (Sender Policy Framework) is a TXT record published at the root of your domain that lists the IP addresses and mail servers permitted to send email on its behalf.

When a receiving mail server gets a message claiming to be from example.com, it looks up the SPF record for example.com and checks whether the sending server's IP appears in that list. If it does, SPF passes. If it doesn't, SPF fails.

A minimal SPF record for a domain that only sends through Google Workspace looks like this:

v=spf1 include:_spf.google.com ~all

The include: mechanism delegates to Google's list of sending IPs. The ~all at the end is a soft fail — it marks mail from unlisted sources as suspicious rather than rejecting it outright. Using -all (hard fail) is stricter. Without any all directive, the record is incomplete.

One common mistake: adding too many include: mechanisms until the record requires more than 10 DNS lookups to resolve. SPF limits lookups to 10; beyond that, the record is treated as invalid.

DKIM: cryptographic signatures on outgoing mail

DKIM (DomainKeys Identified Mail) takes a different approach. Instead of listing allowed servers, it lets the sending server cryptographically sign each outgoing message. The signature travels with the email in a header; the receiving server retrieves the public key from DNS and uses it to verify the signature is genuine.

DKIM keys are published as TXT records at a subdomain in this format:

SELECTOR._domainkey.yourdomain.com

The selector is a string chosen by the mail provider. Google Workspace uses google, most ESPs use default, mail, or a custom string. This is why checking DKIM requires knowing the selector — you can't discover it just from the root domain.

A real DKIM record contains a public key and looks like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA...

If the signature verification passes, DKIM confirms two things: the message genuinely came from infrastructure controlled by the domain owner, and the message body was not altered in transit.

DMARC: the policy that ties them together

SPF and DKIM each answer one question. DMARC answers: "What should you do when mail from my domain fails both of them?"

Published as a TXT record at _dmarc.yourdomain.com, a DMARC record specifies a policy (p=) and an address to send aggregate failure reports to (rua=).

The three policy values are:

• p=none — Monitoring mode. Mail is delivered regardless of authentication results, but reports are sent to the address in rua=. Use this first to understand your mail flows before enforcing anything.
• p=quarantine — Mail that fails authentication goes to the spam folder. Stricter, but it still reaches the recipient.
• p=reject — Mail that fails authentication is blocked at the receiving server and never delivered. This is the goal for production domains.

A starter DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The recommended path is: start with p=none and collect reports for two to four weeks. Review the aggregate reports (services like dmarcian or Postmark's DMARC Digests make them readable). Once you're confident all legitimate mail is passing, move to p=quarantine, then to p=reject.

Jumping directly to p=reject without checking your mail flows first is a reliable way to break transactional mail, forwarding chains, or newsletter delivery.

DMARC alignment: why SPF alone isn't enough

DMARC adds one more concept: alignment. It's not enough for SPF to pass — the domain in the Return-Path header must match the domain in the visible From: header. Many ESPs and bulk senders use a shared Return-Path domain, which means SPF passes technically but fails DMARC alignment. DMARC then falls back to checking DKIM alignment — which is why having both SPF and DKIM configured correctly matters.

Check your domain now

If you're responsible for a domain that sends email, the fastest way to see where things stand is to query all three records at once.