SPF, DKIM and DMARC explained for business owners

SPF, DKIM and DMARC are 3 DNS records that tell the rest of the internet which servers may send email for your domain and what to do with mail that fails those checks. SPF lists the allowed senders, DKIM adds a cryptographic signature to each message, and DMARC ties both to the address people actually see in the From line and sets a policy for failures.

Without them, anyone can send a message that says From: billing@yourcompany.com and many mailbox providers have little reason to doubt it. With them set up correctly, a forged message fails authentication and can be rejected or sent to spam before your customer reads it.

The good news: all 3 are public DNS records, so you can check yours in a few minutes with the commands below.

SPF: who may send for your domain

SPF (Sender Policy Framework, RFC 7208) is a TXT record on your domain that lists the servers and services allowed to send mail for it. A typical record looks like this:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

The ending matters most:

• -all (fail): anything not listed is not authorized.
• ~all (softfail): anything not listed is suspicious.
• ?all (neutral): the record expresses no opinion, which gives receivers almost nothing to work with.
• +all: every server on the internet is allowed to send as you. This is never correct.

SPF also has a hard limit: a receiver evaluating your record may perform at most 10 DNS lookups for mechanisms like include, a, mx and redirect (RFC 7208, section 4.6.4). Each new marketing tool adds an include, and once the count goes over 10, SPF returns an error instead of a pass.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail, RFC 6376) has the sending server sign each message with a private key. The matching public key sits in DNS under a selector name, so receivers can confirm the message was not altered and was signed by someone holding your key.

Each service that sends for you (your mailbox provider, your CRM, your invoicing tool) should sign with its own selector. The DNS record looks like:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DKIM fails quietly. Mail still goes out unsigned, and nobody notices until messages start landing in spam or a provider tightens its rules.

DMARC: the policy that connects everything

DMARC is now defined in RFC 9989, published in May 2026, which replaced the older RFC 7489. It checks whether SPF or DKIM passed for a domain that matches (aligns with) the visible From address, and tells receivers what to do when neither does:

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

• p=none: monitor only. Failing mail is delivered as usual, you just receive reports.
• p=quarantine: failing mail should be treated as suspicious, usually sent to spam.
• p=reject: failing mail should be refused.

The rua address receives aggregate reports from large mailbox providers. Those reports show every source sending mail under your name, including ones you forgot about and ones that are not yours.

How to check your own domain

Run these from any terminal (replace example.com with your domain):

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

For DKIM you need the selector name. Open any email your company sent, view the original message source and look for DKIM-Signature: and its s= value. The same headers also show Authentication-Results: with spf=pass, dkim=pass and dmarc=pass, or the failures.

What to look for:

1. Exactly one SPF record (2 v=spf1 records break SPF entirely).
2. An SPF ending of ~all or -all, not ?all or +all.
3. A DKIM signature on mail from every service that sends for you.
4. A DMARC record that exists and has a rua address someone actually reads.
5. A plan to move from p=none to p=quarantine or p=reject.

Common mistakes and how to fix them

2 SPF records. Often left behind after a provider switch. Merge them into one record.

Too many lookups. Remove services you no longer use, and replace includes with the specific ranges where your provider allows it.

Forgotten senders. A newsletter tool or a help desk sending without DKIM will fail DMARC once you enforce it. Read your DMARC reports for a few weeks first, then enable DKIM for every legitimate source.

Staying at p=none forever. Monitoring is the right first step, but p=none asks receivers to deliver forged mail anyway. Once reports show that all real mail passes, move to p=quarantine, then p=reject.

Parked and unused domains. A domain that never sends mail can still be forged. Publish v=spf1 -all and a DMARC record with p=reject on it.

These records also matter for delivery. Gmail, Yahoo and Outlook now require them from high-volume senders, which we cover in Gmail and Yahoo sender requirements. And they are one layer of defense against the fake invoice scams described in how business email compromise works.

A short checklist

• One SPF record, ending in ~all or -all, under 10 lookups.
• DKIM signing enabled for every service that sends as you.
• DMARC published, with reports going to a monitored mailbox.
• Policy moving toward p=reject once reports are clean.
• Parked domains locked down with -all and p=reject.

How Datahorses helps

Email authentication is one of the areas we watch from the outside every day, together with your domains, certificates and website. When an SPF record changes, a DKIM selector disappears or DMARC is weakened, a person reviews it and you get the exact records to fix. You can see the full list in what we guard, and why it needs no access to your systems. For the broader picture, read what external attack surface monitoring is.