Orbit web apps
Orbit web apps
Build the exact _dmarc TXT record, understand every tag, and roll out enforcement without bouncing your own mail. Runs entirely in your browser.
The record is published at _dmarc.<domain>. A pasted URL or _dmarc. prefix is stripped for you.
What receivers do with unaligned mail.
Share of failing mail to enforce. Default 100.
Policy for subdomains. Blank inherits p.
Relaxed lets subdomains pass. Default relaxed.
Same, for SPF. Default relaxed.
When to send forensic reports. 0, 1, d, s.
Where the daily reports go. The mailto: is added for you.
Optional. Carries message content — most providers no longer send it.
Defaults are omitted, not restated. pct=100, adkim=r, aspf=r and fo=0 are what receivers assume when a tag is absent, so leaving them out gives the shortest correct record rather than the noisiest.
What each tag means
vpHost / name: _dmarc.<domain>
v=DMARC1; p=none2 tags· colours match the field swatches
Checks
Warning: No aggregate reporting address
`p=none` with no `rua` is a record that does nothing: no delivery change and no reports. The whole point of the monitoring stage is the aggregate reports — add an address to receive them.
Recommended rollout
p=nonePublish with `p=none` and a `rua` address. Nothing about delivery changes. Read the aggregate reports for two to four weeks and get every legitimate sender passing SPF and DKIM alignment.
p=quarantine; pct=25p=quarantinep=rejectIndicative deployment path from RFC 7489 and M3AAWG guidance — sit at each stage until the aggregate reports are clean before advancing. SPF, DKIM & DMARC explained has the full walkthrough.
DMARC is the record that decides whether a mailbox provider trusts mail claiming to be from your domain. Get it right and spoofing of your brand stops; publish p=reject on day one and you can bounce a quarter of your own lifecycle programme before anyone notices. The whole craft is in the order you turn the dials.
DMARC does not authenticate mail itself — SPF and DKIM do that. What DMARC adds is a published instruction, at _dmarc.<domain>, for what a receiver should do when a message claims to be from your domain but is aligned with neither. Alignment is the subtle part: SPF and DKIM can pass on a technicality while the visible From address belongs to someone else entirely, and DMARC is what closes that gap.
That is why the first move is never a policy — it is turning on reporting. p=none with a rua address changes nothing about delivery and starts the daily aggregate reports that tell you, for the first time, every system in the world sending mail as you. Almost every sender discovers a forgotten one: an invoicing tool, an old ESP, a helpdesk. You fix their SPF and DKIM alignment before you enforce, not after the bounces start.
The published deployment path is none → quarantine → reject, and the pct tag exists precisely so you can cross the quarantine stage gradually. p=quarantine; pct=25 applies the quarantine action to a quarter of failing mail and leaves the rest alone, so a legitimate sender you missed shows up in the reports as a trickle into spam rather than a wall of bounced invoices.
You raise the percentage only when a run of aggregate reports shows nothing but mail you would genuinely want blocked. Reaching p=reject is a decision you make deliberately after weeks of clean quarantine data — not a setting you paste on the first afternoon because a checklist told you reject is the strong option.
A DMARC record on yourdomain.com does not, by default, do anything different for subdomains — they inherit the parent policy. The trap is setting sp=none while the parent is at reject, which explicitly tells receivers to take no action on mail from any subdomain. Attackers know this, and marketing.yourdomain.com or mail.yourdomain.com becomes the spoofing surface you left open.
Either match sp to p, or leave the sp tag off entirely so subdomains inherit enforcement. The one thing not to do is enforce the parent and relax the children, which is the exact shape of record that looks locked down in an audit and is wide open in practice.
adkim and aspf control whether alignment is checked strictly (the sending domain must match your domain exactly) or relaxed (a subdomain counts). Relaxed is the default, and it is the right default for almost everyone: your ESP signs with a subdomain, your transactional provider uses another, and strict alignment rejects all of them.
Strict alignment is a deliberate choice for a domain you have locked down to a single, exact-match sender — not a security upgrade to apply by reflex. Turn it on and most lifecycle programmes fail alignment overnight, which is why the builder flags it as a note rather than treating it as best practice.
The aggregate reports (rua) are the entire value of DMARC as an operational tool: a daily XML feed of who sent as you, whether they aligned, and what your policy did about it. Keep a rua address on the record permanently, through every stage, because new senders appear and the reports are how you catch them before they force a delivery incident.
Forensic reports (ruf) are a different thing — per-message samples that include headers and sometimes bodies. Because that is personal data, most large mailbox providers stopped sending ruf years ago, so an address there will often receive nothing. Set it if a specialist tool asks for it; do not rely on it as your view of the programme.
Built into Orbit
Orbit's deliverability tooling reads a domain's live SPF, DKIM and DMARC and flags the gaps before a send — a missing rua, a premature reject, a subdomain left open. Claude can walk a domain from p=none to p=reject and read the aggregate reports back to you at each stage.
Sign up free