SPF, DKIM and DMARC, explained without the jargon

Why should a service business care about these records?

Because without them, your invoices, quotes and seasonal reminders are more likely to land in spam, and anyone can send email that claims to be from your domain. Mailbox providers like Gmail and Yahoo use SPF, DKIM and DMARC to decide whether a message really came from you. Since February 2024 both have required at least SPF or DKIM from every sender, and all three from bulk senders (Google's sender guidelines, Yahoo's sender best practices). Our guide to the Google and Yahoo sender requirements covers those rules.

All three are TXT records in your domain's DNS, the settings at your registrar or DNS host where your website and email records live. You don't need to understand cryptography to get them right, but you do need to know what each one does, because the mistakes are easy to make and invisible until mail stops arriving.

What does SPF do?

SPF (Sender Policy Framework, defined in RFC 7208) is a list of the servers allowed to send mail for your domain. When a message arrives, the receiving server looks up the SPF record for the domain in the message's envelope sender (the technical return address, not always the one you see) and checks whether the sending server is on the list.

A company that sends only through Google Workspace would publish:

Reading it left to right: this is an SPF record; Google's servers are allowed; everything else should be treated as suspicious. That is the record Google recommends for domains that send only through Workspace (Google's SPF setup guide). If you also send invoices through your CRM, marketing through an email platform and receipts through a payment processor, each of them may need its own include.

The ending matters. "~all" (soft fail) asks receivers to treat unlisted senders as suspicious. "-all" (hard fail) says they are not authorized at all. Google recommends ~all in its setup guide. Many administrators use -all once they are sure every legitimate sender is listed.

What are the most common SPF mistakes?

Two SPF records. This one is common. Someone sets up a new email tool, its instructions say "add this SPF record", and they add a second one instead of editing the first. RFC 7208 says a domain must not have multiple SPF records, and if a receiver finds more than one, SPF returns a permanent error. Your SPF then fails for every message. The fix is one record with all the includes merged.

Too many lookups. RFC 7208 limits SPF evaluation to 10 DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier each count, and includes inside includes count too. The ip4, ip6 and all mechanisms don't. Add enough services and you go over 10 without noticing, and SPF fails with a permanent error. Remove services you no longer use, and replace includes with ip4 or ip6 ranges only if the provider publishes stable addresses.

Too many empty lookups, and dead includes. The same RFC says implementations should limit "void" lookups (ones that return no answer) to two, and going over that limit is also a permanent error. An include that points at a domain with no SPF record is worse: under RFC 7208 that include returns a permanent error by itself. Delete the includes for services you have cancelled.

Forgetting a sender. The website contact form, the CRM, the accounting software and the phone system may all send email as your domain. List them all before you tighten anything.

What does DKIM do?

DKIM (DomainKeys Identified Mail, defined in RFC 6376) adds a digital signature to each message. The sending service signs certain headers and the body with a private key it keeps secret. You publish the matching public key in DNS. The receiver fetches the key, checks the signature, and learns two things: the message was signed by someone who controls that domain's DNS, and the signed parts weren't altered in transit.

DKIM keys live under a selector, a label the sending service picks, so several services can each have their own key:

Unlike SPF, you can have many DKIM records, one per selector. Each service you send through should sign with your domain, not its own. Many services sign with their own domain by default until you finish their "authenticate your domain" setup, and that default won't help your DMARC.

What does DMARC do?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM to the address people actually see in the From line, and tells receivers what you want done with messages that fail. The original specification was RFC 7489, published for information only. In May 2026 the IETF replaced it with RFC 9989, which puts DMARC on the standards track. The basic record works the same way; one visible change is that the pct tag, which applied a policy to only a percentage of mail, was removed.

The record lives at a special name, _dmarc, under your domain:

The rua address receives aggregate reports: summaries from mailbox providers, daily or more often, of which servers sent mail claiming to be you, and whether it passed. The format is now defined in RFC 9990. These reports are how you find the forgotten sender before you tighten your policy. They arrive as XML files, so most businesses send them to a reporting service that turns them into something readable.

What does alignment mean?

Alignment is the part most explanations skip, and it is why a domain can pass SPF and DKIM and still fail DMARC.

DMARC passes only if SPF or DKIM passes for a domain that matches the domain in the visible From address. Suppose your CRM sends an invoice from billing@example.com. If the CRM's mail service uses its own domain as the envelope sender and signs with its own DKIM key, SPF and DKIM may both pass, but for the service's domain, not yours. DMARC fails because neither check is aligned with example.com.

By default, alignment is relaxed: mail.example.com aligns with example.com because they share the same organizational domain. Strict alignment requires an exact match. Relaxed is right for almost every small business.

The practical fix is the "authenticate your domain" or "custom sending domain" step in each email tool you use. It sets up DKIM signing with your domain, and often a custom return path so SPF aligns too.

How do you check what your domain has now?

You can read your own records in a minute. On a Mac or Linux terminal, dig TXT example.com shows SPF (look for the line starting v=spf1), and dig TXT _dmarc.example.com shows DMARC. On Windows, nslookup -type=TXT example.com does the same. DKIM needs the selector, which you can find in the headers of an email you sent: open the original message and look for "s=" inside the DKIM-Signature header.

If you'd rather not use a terminal, our free email domain check reads MX, SPF, DMARC and a set of common DKIM selectors in one pass, and counts your SPF lookups against the limit of 10.

The easiest real-world test is to send an email to a Gmail address you control, open it, and choose "Show original". In the full headers, find the Authentication-Results line: it reports spf, dkim and dmarc as pass or fail, along with the domain each check used. Google's DKIM setup guide describes this test for checking DKIM. Do this for every tool that sends as you: your mailbox, your CRM's invoice email, your website form, your marketing platform. If any shows FAIL, or passes for the vendor's domain instead of yours, that tool needs its domain setup finished.

How should you roll out DMARC safely?

1. List every sender. Mailbox, website forms, CRM, marketing tool, payment processor, accounting software, phone system.
2. Fix SPF. One record, all real senders included, under 10 lookups.
3. Turn on DKIM for each sender, signing with your domain.
4. Publish DMARC at p=none with a rua address, and read the reports for a few weeks.
5. Fix anything failing that is really you. Ignore the spoofers; that is what the policy is for.
6. Move to p=quarantine, watch for problems, then to p=reject when you are confident.

Skipping straight to p=reject is the classic mistake. It works fine until the day your invoice tool, which nobody remembered, starts having its mail refused.

Our business email service sets these records up and checks them, and our email marketing service makes sure campaigns are signed with your domain. If you are just starting out with campaigns, read our email marketing guide for contractors.

Frequently asked questions