DMARC setup, start to finish

Publishing a DMARC record takes two minutes. Getting to p=reject without deleting your own invoices takes about six weeks, and almost all of it is finding out who sends mail as you.

Should you start at p=none? Yes. Publish this at _dmarc.example.com, change nothing else, and come back in two weeks:

Monitoring changes nothing about delivery. It cannot cause a message to be rejected. The only thing it does is ask receivers to start sending you daily XML reports about mail claiming to be from your domain.

Step 0: write down who sends as you

Before DNS, spend twenty minutes on a list. Ask finance what sends invoices, ask marketing which platform they moved to last year, ask whoever owns the monitoring stack. You will be wrong, and the reports will correct you, but starting with eight known senders and finding three surprises is a much better position than starting with zero and finding eleven.

The usual list: your mailbox provider, one marketing platform, one transactional provider, a helpdesk, a CRM, an HR or payroll system, a monitoring or alerting tool, and something nobody remembers procuring. The provider pages cover the setup for the common ones.

Step 1: publish the record

One TXT record at _dmarc. If your DNS panel already appends the domain, the name is just _dmarc, and if it does not, it is _dmarc.example.com. Getting that wrong produces _dmarc.example.com.example.com, which is invisible to receivers and which I have watched people stare past for an hour.

Exactly one string, starting v=DMARC1. Two records at that name means receivers ignore both. Our DMARC checker reads every tag back to you and flags the ones that leave a gap.

The rua= address has to be able to receive a few hundred XML attachments a week and you have to be willing to read them. If neither is true, point it at our weekly digest. It parses the reports and mails you one summary, free for one domain.

Step 2: read the reports for two weeks

Two weeks, not two days. Monthly senders exist, and the payroll run that fails is always the one on the 28th. What you are building is a table with one row per sending source and three columns: what it is, whether SPF aligns, whether DKIM aligns.

Reading a report by hand walks through the XML. The one thing to internalise now: a source can pass SPF and still fail DMARC, because DMARC needs the passing check to match your From domain. Alignment is where most of the work goes.

Step 3: fix the senders

For each source that fails, one of four things is true.

1. It is a service you use and it supports domain authentication. Turn it on. This is most of them, and it is usually two CNAME records.
2. It is a service you use and it does not. Rare, and a reason to change supplier. In the meantime you can sometimes get SPF alignment by having it use a return-path on your domain, or route its mail through your own server.
3. It is forwarding. Recipients forwarding your mail elsewhere show up as SPF failures with DKIM passing. If DKIM passes, DMARC passes, and there is nothing to fix. This is the strongest practical argument for getting DKIM right everywhere.
4. It is not yours. Someone spoofing your domain. There is nothing to fix and it is the reason you are doing this.

Work down the list by volume. The top three sources are usually 95% of your mail, and the long tail of single-message sources is mostly spoofing and forwarding noise.

Step 4: move to quarantine

All four of these have to be true before I move a domain to quarantine:

• Aligned pass rate above 98% of message volume for two consecutive weeks.
• Every source above 1% of volume identified by name and aligned.
• No new unidentified source in the last seven days.
• The monthly senders have run at least once inside the observation window.

RFC 9989 removed pct, the tag that applied a policy to a share of failing mail, and receivers always applied it unevenly. To test the step first, publish p=quarantine with t=y. Receivers that follow RFC 9989 then treat it as p=none, while receivers still on RFC 7489 ignore t=y and quarantine in full. If you are not ready for every receiver to quarantine your failing mail, you are not ready to leave p=none.

Two weeks at quarantine. Watch the reports and watch your helpdesk. What you are listening for is somebody saying a partner stopped receiving something, because quarantined mail goes to spam where a human can still find it. That grace disappears at the next step.

Step 5: reject

Same criteria, tighter numbers: 99%+ aligned for two weeks at quarantine, and no unexplained failures at all in the last week. Then change one word.

Keep rua=. Reject is the state where receivers refuse a new sender's mail and no bounce reaches you, so the reports are your only instrumentation. This is also the point at which a weekly summary earns its place, because nobody keeps reading raw XML week after week.

Subdomains, which is where this goes wrong

Your policy applies to subdomains unless you say otherwise with sp=. Once the parent reaches p=reject, receivers refuse mail from a marketing platform on news.example.com that somebody configured before you started this, and the person who set it up three years ago does not work here any more.

Two clean approaches. Publish a separate DMARC record on the subdomain with its own policy, which is precise and visible. Or set sp=none temporarily on the parent while you sort it out, which is blunt, wide open, and needs a date attached. What you should not do is leave the parent policy weakened to accommodate one subdomain.

Wildcard-style protection for subdomains you never send from is worth publishing early: a DMARC record on the parent with sp=reject stops accounts.example.com being invented by someone else, at no cost to you if nothing legitimate sends from a subdomain.

The policies, side by side

Policy	Receiver does	Failing mail	Move on when
p=none	Delivers, reports	Arrives normally	98% aligned, 2 weeks, all big senders known
p=quarantine	Delivers to spam	Recoverable by the recipient	99% aligned, 2 weeks, nothing unexplained
p=reject	Refuses at SMTP	Gone, sender gets a bounce	You are done

What goes wrong on the way to p=reject

• SPF breaks at eleven lookups. The record reads fine and returns permerror, so DMARC has only DKIM to work with and half your sources start failing for no visible reason. The lookup guide has the fix.
• Strict alignment set by accident. adkim=s and aspf=s look like the responsible choice and break every subdomain sender you have. Leave them off unless you have a specific reason.
• The unread rua mailbox. Reports going to a distribution list that three people have filtered into a folder is the same as no reports.
• Stopping at quarantine. It is a waypoint. A domain that sits at quarantine for a year has taken the deliverability risk without collecting the protection.

Compliance and the bulk sender rules are what got you here. The reason to finish is bigger: until you are at reject, anyone can put your domain on an invoice email and your customers have no way to tell. Six weeks of careful work buys that, and it holds for as long as you keep the record current when your senders change. The only hard part is the inventory.