SPF, DKIM and DMARC explained, and the order to set them up

If your invoices are landing in customers' spam folders, or someone has been sending phishing emails that appear to come from your domain, the cause is usually the same: three DNS records called SPF, DKIM and DMARC are missing or wrong.

Since 2024, Google and Yahoo have required senders to have these in place, and Microsoft has followed for Outlook.com. Bulk senders face the strictest rules, but a small business sending ordinary email from Microsoft 365 or Google Workspace is still judged on them. Getting them right is one of the cheapest deliverability and security wins there is.

What each record does

The easiest way to understand them is as three different questions a receiving mail server asks about a message claiming to be from your domain.

SPF (Sender Policy Framework): "Is this server allowed to send for this domain?" SPF is a single TXT record listing the services permitted to send email as you, such as your email provider, your CRM, your invoicing software and your website's contact form. A message from anywhere else fails the check.

DKIM (DomainKeys Identified Mail): "Was this message really signed by the domain, and is it unaltered?" Your email service signs each outgoing message with a private key. You publish the matching public key in DNS, and receivers use it to verify the signature. Unlike SPF, DKIM survives forwarding, which makes it the more reliable of the two.

DMARC (Domain-based Message Authentication, Reporting and Conformance): "What should I do if the checks fail, and who should I tell?" DMARC ties SPF and DKIM to the address people actually see in the From line, and sets a policy for failures: do nothing (p=none), send to spam (p=quarantine) or block outright (p=reject). It can also ask receivers to send you reports showing who is sending email using your domain.

The order to set them up

Doing these in the wrong order is how legitimate email ends up blocked. Work through them like this:

List everything that sends email as you. Your mailbox provider, plus every tool that sends on your behalf: newsletters, invoices, helpdesk, booking system, website forms. This list is the hard part, and the part people skip.
Publish SPF. One record only (two SPF records on the same domain is itself a failure). Include each sending service, and end it with ~all while you are testing.
Turn on DKIM for each service. Each provider gives you a record (usually a CNAME or TXT at a selector such as selector1._domainkey). Add it, then enable signing in that provider's settings. Do this for your mailbox provider and for every third-party sender that supports it.
Publish DMARC at p=none with reporting. For example v=DMARC1; p=none; rua=mailto:[email protected]. This changes nothing about delivery yet, but the reports will show you any legitimate sender you missed in step 1.
Fix what the reports reveal, then move to p=quarantine, and eventually p=reject. Only at that point is your domain properly protected from spoofing.

The mistakes we see most often

Too many SPF lookups. SPF allows at most 10 DNS lookups, and each include: can use several. Add enough services and you go over the limit without noticing. Receivers then treat SPF as a permanent error, and mail can be rejected. Our SPF checker counts the lookups for you.
DMARC left at p=none forever. A p=none policy is a monitoring setting, not protection. It tells receivers to deliver spoofed mail anyway. It is meant to be a stepping stone.
DKIM published but not switched on. Adding the DNS record is only half the job. If signing is not enabled in the email service, nothing gets signed.
A new tool added later without updating SPF. Someone signs up for a new newsletter platform, its emails start failing authentication, and nobody connects the two.
Records silently changed. A DNS migration, a new web host or an over-eager agency overwrites a TXT record, and email starts failing weeks later.

How to check yours

You can check all three in under a minute with our free tools, no signup needed:

SPF checker: finds your record, checks the syntax and counts DNS lookups against the limit of 10.
DKIM checker: looks up the public key for a given selector.
DMARC checker: reads your policy and reporting settings and explains what they mean.

If anything comes back missing or failing, start with step 1 above: the cause is almost always a sender nobody listed.

Keep them working

Email authentication is not set-and-forget. Records get edited, providers change, and the first sign of trouble is often a customer asking why they never received an invoice.

VigilVault can watch these for you. Its SPF monitor alerts you if the record disappears or goes over the 10-lookup limit, its DMARC monitor flags a missing record or a policy still sitting at p=none, and its DNS change monitor takes a snapshot of your A, MX, NS and TXT records and alerts you the moment any of them changes unexpectedly, which also catches a hijacked domain or a botched migration. They sit alongside your uptime and SSL checks, so your website and your email are watched from one dashboard.

Check your SPF record now, or set up email monitoring free.