DMARC setup: why your mail does not arrive
The three records, in plain language
Think of your message as an envelope that gets checked at a reception desk.
| Record | What it states | Its role at the desk |
|---|---|---|
| SPF | Which servers may post mail for the domain | “This courier is on our list” |
| DKIM | A digital signature on the message | “The seal is intact, nobody touched it in transit” |
| DMARC | What to do when the first two fail | “If it does not check out: let it through, set it aside, or send it back?” |
DMARC on its own protects nothing: it builds on the SPF and DKIM results. That is why all three are needed.
What they look like in practice
SPF — a TXT record on the domain itself:
`` example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``
DKIM — a TXT record under a selector; the key comes from your mail provider:
`` selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." ``
DMARC — a TXT record on the _dmarc subdomain:
`` _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100" ``
The DMARC fields worth knowing:
p=— the policy:none(monitor and report only),quarantine(send to spam),reject(refuse outright).rua=— where aggregate reports are sent. Without it you are working blind.adkim=/aspf=— how strictly the domain must match:r(relaxed, subdomains count) ors(strict, exact match).pct=— what percentage of mail the policy applies to. Useful for a gradual rollout.
The four most common mistakes
1. Two SPF records on one domain
The most common one, and it invalidates the lot immediately. The standard permits exactly one SPF record per domain. If your mail provider added one and your newsletter tool added another, they must be merged, not placed side by side:
`` "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``
2. Too many DNS lookups
Evaluating SPF may use at most ten DNS lookups. Every include: uses at least one, and some use several because they reference further. Past the tenth, evaluation fails and your message is treated as if you had no SPF at all. With many providers, the include list has to be trimmed.
3. A forgotten sender
The classic case: mail is with Google, but the invoicing tool, the shop and the newsletter system send from elsewhere. SPF lists only Google, so your invoices get stuck — exactly the mail that matters most. That is why the work always starts with an inventory: which systems send mail in your name?
4. Going straight to p=reject
It is tempting to set the strictest policy immediately. When you do, mail from your legitimate but not-yet-authenticated senders disappears too — not into spam, but for good. Rolling out DMARC is deliberately a slow process.
The rollout
Step 1 — inventory
Write down everything that sends mail in your name: mail provider, shop, invoicing, CRM, newsletter, helpdesk, monitoring alerts. That list is the basis for SPF.
Step 2 — fix SPF
One valid record containing every legitimate sender. End it with -all (hard fail) or at least ~all (soft fail); +all lets everyone through and is therefore pointless.
Step 3 — DKIM on every sender
It has to be enabled separately in each system, each with its own key and selector. With most providers this is one switch and one DNS record.
Step 4 — DMARC in monitoring mode
`` "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``
At this point nothing changes in delivery, but you start receiving daily aggregate reports on who is sending mail in your name and which senders fail authentication. This is the important phase: it is where you find out what you left off the list. Give it two to four weeks.
Step 5 — tighten
Once every legitimate sender passes in the reports, move to quarantine, then after a week or two to reject. If you want to be careful, step through with pct=: first a quarter of traffic, then half, then all of it.
What to look for in the reports
A DMARC report is XML and was not designed for humans. Look for two things:
- A legitimate sender that fails — that needs fixing (a missing
include, DKIM not enabled). - A foreign server sending in your name — either a forgotten system of yours, or abuse. For most clients this report brings the first surprise.
If you would rather not read XML, several services translate the reports into plain language; you point the report address at them.
Why did this suddenly become important?
Because the large providers tightened up. Since 1 February 2024, Gmail requires every sender to have at least SPF or DKIM, a valid PTR record and a TLS connection. Anyone sending more than 5,000 messages a day to Gmail addresses needs SPF, DKIM and DMARC (the DMARC policy may be p=none), plus one-click unsubscribe in marketing mail. Spam rates reported in Postmaster Tools must stay below 0.3% — Google's own recommendation is to stay under 0.1%.
The practical consequence: without authentication your mail first goes to spam, and then stops arriving at all.
Verification: how do you know it works?
- Send a test message to a Gmail and an Outlook account from each of your systems separately.
- Read the headers (“Show original” in Gmail): the
Authentication-Resultsline should sayspf=pass,dkim=passanddmarc=pass. - Check that the From domain aligns with either the SPF or the DKIM domain. This is called alignment, and it is where DMARC most often fails even when SPF and DKIM pass individually.
- Look at the DMARC report a week later — it shows what your test messages cannot.
Frequently asked questions
I do not send newsletters. Do I still need this?
Yes, for two reasons. First, invoices and automatic confirmations are mail too, and they have to arrive. Second, missing authentication is not about your sending — it is about someone else being able to send as you.
I have a domain I never send mail from. Does it matter?
Very much. Those “parked” domains are exactly the ones used for spoofing. They deserve the strictest records, because there is nothing to break:
`` "v=spf1 -all" "v=DMARC1; p=reject;" ``
My hosting provider already set something up. Is that not enough?
Typically they add a basic SPF record for their own server. That is enough if all your mail leaves from there — but the shop, the invoicing tool and the newsletter system usually send from elsewhere. Those are precisely the senders that get left out.
How long does the whole thing take?
Setting up the records is a day or two plus a few hours of DNS propagation. The monitoring phase is two to four weeks — it cannot be skipped, because it is what protects your own mail. After that, tightening is a matter of days.
What happens if I get it wrong?
The most common consequence is that your own mail stops arriving. That is what the monitoring phase and the header checks are for: both show you the problem before your customers meet it.
If you would rather not edit DNS records, we will put your e-mail authentication in order — from the inventory to reject, measuring all the way that your own mail keeps arriving.