Email Marketing Deliverability
SPF, DKIM, and DMARC: Email Authentication Setup Guide
What each record proves, the exact DNS entries to publish, and the lookup limit that silently breaks SPF.
On this page
The short version
- Three records, three different jobs. SPF says which servers may send, DKIM proves the message was not altered, DMARC says what to do when either fails and reports back.
- SPF has a hard limit of ten DNS lookups. Exceed it and the check returns permerror — which many receivers treat as a failure — with no warning anywhere.
- Alignment is the part people miss. A message can pass SPF and DKIM and still fail DMARC if neither passing domain matches the from address.
Authentication is the cheapest deliverability work available: three DNS records, done once, checked occasionally. It is also the most commonly half-finished, usually because SPF was set up years ago, DKIM was enabled in a platform's dashboard without checking which domain it signs with, and DMARC was published at monitoring level and never revisited.
Each record answers a different question, and understanding which is which makes the failures diagnosable.
The three records
| Record | Answers | Fails when |
|---|---|---|
| SPF | May this server send for this domain? | The sending IP is not listed, or too many lookups |
| DKIM | Was this message altered in transit, and signed by whom? | The key is missing, rotated, or the message was modified |
| DMARC | What should happen when SPF or DKIM fails or does not align? | No policy published, or a policy nobody monitors |
SPF, and the ten-lookup limit
SPF is a text record listing who may send for your domain. Each include in it costs a DNS lookup, and every included record's own includes count too. The specification caps this at ten, and exceeding it produces a permanent error.
This is the single most common silent SPF failure. An organisation adds its email platform, then its CRM, then its help desk, then its invoicing tool, and one day the record crosses ten — at which point every receiver evaluating it gets an error rather than a pass, and nothing in any dashboard says so.
Check it with any SPF validator that counts lookups. If you are over, the fixes are to remove services that no longer send, or to flatten the record — though flattening means you now own the job of updating it when a provider changes their infrastructure.
DKIM, and why the signing domain matters
DKIM adds a cryptographic signature to the message headers. The receiver fetches the public key from DNS and verifies that the signed parts arrived unmodified.
Most platforms will sign with their own domain by default, which technically passes but does not help you — the reputation accrues to the platform's domain rather than yours, and the signature does not align with your from address for DMARC purposes.
Setting up domain-aligned DKIM means publishing the platform's public key on a selector under your own domain, and switching the platform to sign with it. Every serious platform supports this. It is the step that turns DKIM from a formality into something that builds your reputation.
Setting all three up
In order. Each step is verifiable before you move to the next.
Inventory who sends as you
Marketing platform, transactional service, CRM, help desk, invoicing, calendar, anything that sends on your behalf. Missing one means authenticating everything except the tool that then starts failing.
Publish one SPF record covering all of them
A single TXT record on the root domain. Count the lookups before publishing, not after — a validator will tell you the number.
Enable domain-aligned DKIM per service
Each service gives you a selector and a public key to publish. Confirm afterwards that the signing domain in a received message is yours, not the platform's — the message headers show it.
Publish DMARC at monitoring only
Start with a policy of none and a reporting address. This changes nothing about delivery and starts the reports flowing, which is what tells you whether anything legitimate is failing.
Read the reports for a few weeks, then tighten
Reports arrive as XML and are unpleasant to read by hand; a parser or a hosted service is worth it. Once nothing legitimate is failing, move to quarantine, then to reject.
This is the step almost everyone skips. A DMARC record left at none forever is a record that reports and protects nothing.
Alignment, the part that catches people
DMARC does not simply ask whether SPF and DKIM passed. It asks whether the domain that passed matches the domain in the visible from address.
A message sent through a platform can pass SPF against the platform's return-path domain and pass DKIM against the platform's signing domain, and still fail DMARC because neither of those is your domain. Everything looks green and the check that matters fails.
Fixing it means domain-aligned DKIM, and usually a custom return-path — a subdomain of yours pointed at the platform — so that at least one of the two aligns.
Authentication check
- Exactly one SPF record, resolving in under ten lookups
- Every service that sends as you is covered by it
- DKIM signs with a selector on your own domain
- A custom return-path subdomain is configured where the platform supports it
- DMARC is published with a reporting address someone actually reads
- The policy has moved past none, or there is a dated plan to move it
- A real received message shows all three passing and aligned
Frequently asked questions
Do I need DMARC if SPF and DKIM already pass?
Yes, for two reasons. Without it there is no instruction for receivers when a check fails, and no reporting — meaning you cannot see anyone spoofing your domain or a legitimate service quietly failing.
Is p=none good enough?
It is a legitimate starting point and a poor destination. At none you get visibility and no protection, and major providers increasingly expect senders to have a policy in place.
What is BIMI and do I need it?
It displays your logo beside the message in supporting clients, and it requires DMARC at quarantine or reject first. Treat it as something to consider after authentication is finished, not as a reason to start.