The record you are building
A DMARC record is one TXT entry at _dmarc.yourdomain.com made of semicolon-separated tags. A complete, sensible mid-rollout record looks like:
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com; sp=quarantineReading left to right: version, the policy for mail that fails authentication, the share of failing mail the policy applies to, where receivers should send daily aggregate reports, and the policy for subdomains. The generator exposes each of these as a field and warns when a combination undermines itself — a reject policy at partial pct, strict alignment on an enforcing record, a policy with no report address.
Why the rollout is staged
DMARC is the only DNS record on this site that can break your own legitimate mail if published too aggressively. The policy applies to every message that fails both SPF and DKIM alignment, and on day one you do not actually know what all of your mail looks like. Companies accumulate senders: the CRM, the invoicing tool, the support desk, a marketing platform someone trialed in 2021 and never turned off. Any of them not covered by SPF or DKIM starts failing the moment enforcement begins.
So the sequence matters, and the generator carries it below the record. Stage one is p=none with a rua address: pure observation. Receivers send you XML summaries of every source claiming your domain, with pass/fail per mechanism. Two to four weeks of these reports is normally enough to inventory your senders. Stage two is p=quarantine with a pct ramp — 10, then 50, then 100 — while the reports confirm nothing legitimate is caught. Stage three is p=reject, the end state where spoofed mail is refused outright rather than parked in spam folders. Reject is also the gate for BIMI logo display, if that is on your roadmap.
Choices worth a second thought
- The rua mailbox: reports arrive daily from every receiver, as XML attachments. Point them at a dedicated address, not a human inbox. Reading them raw is workable at small volume; at scale most teams feed them to a report processor.
- sp (subdomain policy): leave it unset and subdomains inherit
p, which is usually right. Settingsp=nonewhile enforcing on the main domain is an open invitation to spoofbilling.yourdomain.cominstead. - pct with reject: the generator warns on this one. Rejecting a random slice of failing mail produces intermittent bounces that are painful to debug — ramp pct at quarantine instead, and switch to reject only at 100.
- Alignment modes:
adkimandaspfstay relaxed unless you have a reason. Strict alignment plus an ESP that signs with a subdomain is a classic self-inflicted outage.
After publishing
Give DNS a few minutes, then verify from outside with the DMARC checker — it parses the live record and grades the policy, which catches copy-paste truncation and stray quotes. Remember DMARC only works on top of the other two mechanisms: it needs SPF or DKIM to pass with alignment, so run the SPF checker and DKIM checker on the same domain, or all of them via the email authentication checker.
A correct DMARC record protects your domain from spoofing and satisfies the mailbox providers' sender requirements. It does not, by itself, put marketing mail in inboxes — sending platform and list practice dominate there. For the platform half of that equation, our deliverability rankings publish measured inbox rates per service, tested as described in the methodology.
Frequently asked questions
Where do I publish the generated DMARC record?
As a TXT record at host _dmarc on your domain — the full name is _dmarc.yourdomain.com. In most DNS panels: host _dmarc, type TXT, value starting with v=DMARC1. One record only; a second DMARC record makes receivers ignore both.
What should my first DMARC record be?
v=DMARC1; p=none; rua=mailto:you@yourdomain.com — monitoring plus a report address, nothing enforced. The reports show every source sending as your domain and whether each passes. Fix the legitimate failures, then tighten. Skipping straight to reject without reports is how companies find out about forgotten billing systems.
What does pct actually do?
It applies the policy to a random percentage of failing mail and leaves the rest at the next-weaker policy. pct=25 with quarantine quarantines a quarter of failures. It exists so you can ramp enforcement gradually — 10, 50, 100 — while watching reports. It has no effect at p=none.
Do I need ruf (failure reports)?
Usually not. Aggregate reports (rua) are the workhorse: daily XML summaries from each receiver. Failure reports were designed as per-message forensic copies, but most large receivers no longer send them for privacy reasons. Leave ruf empty unless you have tooling that consumes it.
When should I use strict alignment?
Rarely, and only deliberately. Relaxed alignment (the default) lets subdomains match — mail from news.example.com aligns with example.com. Strict requires an exact match, which breaks common ESP configurations. Enable it only after your aggregate reports show every source would still align.