A customer tells you your invoice was in their junk folder. Someone suggests you “fix your SPF”, your host’s support mentions DKIM, and a DNS checker warns that you have no DMARC policy. Three acronyms, all apparently urgent, and none of them explained in words you can act on.
If your emails are going to spam and these three records keep coming up, this is the plain version. It covers what each record does, how they depend on each other, how to read them on your own domain, and the mistakes that make correct-looking records fail. No provider pricing, just how the checks work.
SPF DKIM DMARC explained: start with the two sender addresses
Much of the confusion clears once you know this. An email has the From address you see in your inbox, and a second, hidden sender address used by the servers while delivering it, often called the envelope sender or Return-Path. Usually both are on your domain. Sometimes, when a newsletter tool or a website plugin sends for you, the hidden one belongs to that service instead.
SPF checks the hidden address. DKIM checks a signature. DMARC then asks whether either of those checks passed for the same domain the reader actually sees in the From line. Keep those three sentences in mind and the rest follows.
SPF: the list of servers allowed to send
SPF, the Sender Policy Framework, is a single TXT record at your domain’s root. It begins with v=spf1 and lists the services allowed to send mail for the domain, then ends with an instruction about everything else. A domain using Google Workspace and one other sending service might have a record shaped like this:
v=spf1 include:_spf.google.com include:[the other service’s value] ~all
The include: parts point to lists the providers maintain. The ending ~all means “treat anything else with suspicion”, while -all means “anything else should fail”.
What trips people up with SPF
- Only one SPF record is allowed. Adding a second TXT record that starts with v=spf1 for a new service makes SPF fail for everything. Merge the includes into one record instead.
- There is a limit of ten DNS lookups. Each include can trigger further lookups. Pile up enough services and the record breaks, even though it looks fine.
- SPF does not survive forwarding well. When a message is forwarded, the forwarding server is not on your list, so SPF can fail at the final destination.
DKIM: a signature that travels with the message
DKIM, DomainKeys Identified Mail, works differently. The sending service signs each outgoing message with a private key. You publish the matching public key in DNS as a TXT record (some services use a CNAME that points to their own) at a name like selector._domainkey.yourdomain.com. The receiving server reads the signature, fetches the public key and checks that the message was not altered and was signed for that domain.
The selector is just a label, which lets several services sign for the same domain without clashing. Google Workspace generates its key in the admin console. Microsoft 365 and Zoho provide their own records. Newsletter and invoicing tools have their own as well.
Because the signature is inside the message, DKIM usually survives forwarding where SPF does not. That is one reason a domain should have both.
DMARC: the policy that ties them to your From address
DMARC is a TXT record at _dmarc.yourdomain.com. It does two jobs.
First, it adds the alignment test. A message passes DMARC only if SPF passed for a domain matching the visible From, or DKIM passed with a signature from a domain matching the visible From. A newsletter tool that passes SPF for its own domain, but not yours, does not count.
Second, it tells receivers what to do when that test fails, through the p= tag:
- p=none: take no action, just report.
- p=quarantine: treat failing mail as suspicious, usually the spam folder.
- p=reject: refuse failing mail outright.
An rua= tag gives an address where receivers send aggregate reports. These arrive as XML files, unreadable by eye, but a DMARC report tool turns them into a list of every service sending as your domain and whether it passes.
Why your emails are going to spam even with records in place
Having the three records is not the same as having them right. These are typical faults when a domain “has SPF, DKIM and DMARC” and mail still goes to junk:
- Two SPF records, one added by the old provider and one by the new.
- DKIM switched on for the mailbox provider but not for the website, the CRM or the invoicing tool, so those messages fail alignment.
- The website sending through the web server’s own mail function rather than through an authorised service. Our page on fixing WordPress mail that never arrives covers that route.
- DMARC jumped straight to p=reject before anyone checked which services were sending.
- Records added at the wrong host name, for example the DKIM record created as a full name inside a DNS panel that automatically appends the domain again.
Authentication also cannot fix everything. If the server you send from is on a blocklist, if recipients keep marking your messages as spam, or if your website has been abused to send junk, records alone will not rescue delivery. That last situation is covered under stopping a website that sends spam.
A worked example with several senders
Imagine a small furniture shop. Staff mail is on Google Workspace. The WordPress website sends order notifications through an SMTP relay. A newsletter platform sends monthly offers. An online accounting tool emails invoices.
To be trusted, each of the four needs attention:
- Workspace: Google’s include in SPF, and DKIM generated and switched on in the admin console.
- The relay: its include added to the same SPF record, and its DKIM record published for the shop’s domain.
- The newsletter platform: domain authentication completed in its settings, which normally means adding its DKIM records.
- The accounting tool: either set up to sign as the shop’s domain, or configured to send from its own address with the shop’s address as Reply-To.
Then one DMARC record at p=none with a reporting address. After a few weeks of clean reports, the shop moves to p=quarantine. This step-by-step is what we mean by professional email setup: every sender listed, signed and checked, not just the mailbox.
Where these records go, and how to enter them
All three are added in the DNS panel for your domain. That is not always your hosting company. DNS is managed wherever your domain’s nameservers point: the registrar, the host, or a service such as Cloudflare. Changing records anywhere else does nothing at all, which is a surprisingly common reason a “fixed” record never takes effect.
Most DNS panels ask for three things: a type, a host or name field, and a value. For the root SPF record the host is often written as @. For DMARC it is _dmarc. For DKIM it is the selector followed by ._domainkey. Many panels add your domain name automatically, so typing the whole name produces a record like _dmarc.yourdomain.com.yourdomain.com that nobody will ever find.
Changes are not seen everywhere at once. Each record has a TTL, the time other servers may cache the old answer, so allow for that before testing. Once the records are in, the next step is proving they work on real messages.
How to check your own messages
You do not need special tools to see whether a message passed. Send an email from your business address to a free Gmail account, open it, and use the three-dot menu’s Show original option. Gmail shows a summary with SPF, DKIM and DMARC each marked PASS or FAIL, and the full headers below.
In Outlook and most other mail programs you can view the message source or headers and look for the line starting Authentication-Results. Look for spf=pass, dkim=pass and dmarc=pass, and check the domain each one names.
Repeat the test for every service that sends as you: a contact form submission, a password reset from your website, a test invoice, a test newsletter.
What to keep on record
- The exact SPF record, and the service each include belongs to.
- Every DKIM selector in use, and which service it is for.
- The current DMARC policy and where reports go.
- The date of each change, so a sudden delivery problem can be matched to it.
If the DNS panel itself is the obstacle, because you are not sure where your domain’s records are managed, our hosting and domain support can find and sort that first. Getting these three records right is unglamorous work, but once done, it rarely needs touching until you add a new service that sends as your domain.
Next in this series: Migrate Email to Google Workspace Without Losing Mail
