How to create a DMARC record, tag by tag

A working DMARC record is one TXT record, published at _dmarc.yourdomain.com, that looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

Publish that today. It changes nothing about how your mail is handled and starts the flow of aggregate reports that tell you who sends as your domain. Everything after this is how to read those reports and tighten the policy safely.

What DMARC does that SPF and DKIM do not

SPF says which servers may use your domain in the envelope. DKIM proves a message was signed by a key published in your DNS. Neither looks at the From address the recipient actually sees. DMARC adds two things on top: a requirement that the authenticated domain *aligns* with the visible From domain, and an instruction to receivers about what to do when it does not.

Alignment is the part people miss. Both checks can pass and DMARC can still fail.

• Relaxed (the default, aspf=r and adkim=r): the authenticated domain only has to share an organisational domain with the From domain. bounces.yourdomain.com aligns with yourdomain.com.
• Strict (aspf=s, adkim=s): exact match only. That same bounces.yourdomain.com now fails.

DMARC passes if *either* SPF or DKIM passes with alignment. That is why DKIM is the more valuable of the two for real-world delivery: a forwarded message loses SPF alignment almost always, but keeps a valid DKIM signature as long as nothing rewrote the body.

Every tag worth knowing

Two notes on currency. pct and rf are being retired by the DMARC revision work that updates the original RFC 7489 specification; the revision also replaces the Public Suffix List with a DNS tree walk for finding the organisational domain, and adds a policy tag for non-existent subdomains. Keep using pct for a staged rollout if your reporting tool still honours it, but do not build a process that depends on it long-term. ruf is worth setting only if you have somewhere to put failure copies that may contain recipient data; the large receivers largely do not send them.

Set fo=1 on day one. It asks for a report whenever *either* check fails, rather than only when the whole evaluation fails, which is what makes early reports actually diagnostic.

Worked examples

Monitoring, which is where everybody starts:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; ri=86400

Enforcing on the apex while a legacy subdomain catches up:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com; fo=1

Full enforcement with strict alignment — only once you have confirmed every sender signs with the exact domain:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com

A parked domain that must never send anything:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com

Pair that last one with an empty SPF record (v=spf1 -all) and a DKIM wildcard denial (*._domainkey with v=DKIM1; p=) on every domain you own but do not send from. Parked domains are what spoofers reach for.

Sending reports to another domain

If rua points at a mailbox on a domain you do not control — a monitoring service, or a shared mailbox on a different domain — that domain has to authorise it. The receiving domain publishes:

yourdomain.com._report._dmarc.reportingservice.com   TXT   "v=DMARC1"

Without that record, compliant receivers discard the report rather than send it. This is the single most common reason "DMARC is published but no reports arrive".

The rollout path

1. Publish `p=none` with `rua` and `fo=1`. Wait a full week — report cadence is roughly daily, and weekday-only senders will not appear on a weekend.
2. Inventory your senders from the reports. You will find things you forgot: the ticketing system, the invoicing tool, a marketing platform someone trialled, a payroll provider.
3. Fix each one so it either signs with an aligned DKIM key or sends with your domain in the envelope. Aligned DKIM is the better goal.
4. Move to `p=quarantine`. Watch for a week. Quarantine is reversible and visible: mail lands in spam, not nowhere.
5. Move to `p=reject`, and only then consider strict alignment.

Expect each step to take a week minimum, longer in an organisation where you do not control every tool.

What not to do

• Do not publish p=reject on a domain whose senders you have not inventoried. You will reject your own invoices and find out from a customer.
• Do not point rua at a mailbox a human reads. Aggregate reports are gzipped XML and arrive constantly; send them to a parser or a dedicated address.
• Do not publish more than one DMARC record at _dmarc. Two records make the policy undefined and receivers may ignore both.
• Do not forget sp=. Without it, subdomains inherit p= — which is usually what you want for reject, and almost never what you want mid-rollout.
• Do not treat DMARC as a deliverability feature. It stops people spoofing your exact domain; it does not make your own mail land in the inbox.

MailPilot verifies SPF, DKIM and DMARC for each connected mailbox's domain and flags a missing or contradictory record before warm-up begins, so you are not warming a mailbox that receivers cannot authenticate in the first place.