InboxRatio
Check your domain

Free tool

DMARC generator: build your DMARC record

Generate a DMARC record from the policy, report addresses, and alignment options you pick. The record updates as you change settings, with warnings for combinations that bite — all client-side, nothing leaves your browser.

Receivers apply one policy level down while you rehearse.

RFC 9989 removed pct, so receivers on the new standard ignore it. Turn this on only to steer receivers still on RFC 7489 during the transition.

Your DMARC record

v=DMARC1; p=none

Publish as a TXT record at host _dmarc (full name: _dmarc.yourdomain.com).

  • No aggregate-report address (rua). You will have no visibility into who passes or fails — add one before tightening the policy.

Staged rollout

  1. 1. Monitor p=none; rua=mailto:…

    Publish p=none with an aggregate-report address. Collect reports across your full sending calendar (several weeks at minimum) and identify every legitimate sending source.

  2. 2. Rehearse quarantine p=quarantine; t=y

    Once every legitimate source passes SPF or DKIM with alignment, declare quarantine in testing mode. Receivers on RFC 9989 apply one level down (none), so failing mail is still delivered while reports mark it with the policy_test_mode reason. Receivers still on RFC 7489 ignore t and quarantine for real.

  3. 3. Quarantine p=quarantine

    Remove t=y. Failing mail now goes to spam at every receiver — recoverable if something legitimate was missed. Hold here until reports stay clean for weeks.

  4. 4. Rehearse reject p=reject; t=y

    Declare reject in testing mode: receivers on RFC 9989 keep quarantining while you confirm the failing population is only traffic you want refused. Receivers still on RFC 7489 ignore t and reject outright.

  5. 5. Reject p=reject; np=reject

    The end state: failing mail is refused. Remove t=y, keep rua= forever, and sign every source with aligned DKIM — RFC 9989 §7.4 warns that p=reject must not rely on SPF alone.

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; np=reject; t=y; rua=mailto:dmarc-reports@example.com

Reading left to right: version, the policy for mail that fails authentication, the policy for subdomains that do not exist in DNS, the testing flag that has receivers apply one level down while you rehearse, and where receivers should send daily aggregate reports. The generator follows RFC 9989, the DMARC standard since May 2026, exposes each tag as a field, and warns when a combination undermines itself — testing mode on a policy of none, a legacy pct below 100 without t=y, 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; collect them across your full sending calendar, several weeks at minimum. Stage two rehearses quarantine with p=quarantine; t=y: receivers on RFC 9989 apply one level down, so failing mail is still delivered while the reports mark the test. Stage three removes t=y and quarantines for real. Stage four rehearses reject the same way — p=reject; t=y quarantines rather than refuses — and stage five is p=reject, the end state where spoofed mail is refused outright rather than parked in spam folders. Receivers still on RFC 7489 do not know t and apply the published policy in full, which is what the generator's legacy pct option is for. Enforcement without a testing flag 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 (existing subdomains): leave it unset and subdomains inherit p, which is usually right. Setting sp=none while enforcing on the main domain is an open invitation to spoof billing.yourdomain.com instead.
  • np (non-existent subdomains): added by RFC 9989 for names that do not exist in DNS. Unset, they fall back to sp, then p. Those names send no legitimate mail, so once you enforce, np=reject closes them off.
  • Legacy pct: RFC 9989 removed it, so the generator leaves it out unless you switch on compatibility with older receivers. Paired with t=y, a pct ramp steers receivers still on RFC 7489 while updated ones honor testing mode; a pct below 100 without t=y is the combination the generator warns about, because updated receivers ignore pct and enforce in full.
  • Reject and mailing lists: RFC 9989 §7.4 says a reject domain must not rely on SPF alone — sign everything with aligned DKIM — and advises domains whose users post to mailing lists against reject unless a month at none and a month at quarantine show the impact is acceptable.
  • Alignment modes: adkim and aspf stay 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 happened to pct, and what does t=y do?

RFC 9989, which replaced RFC 7489 as the DMARC standard in May 2026, removed pct (it is historic in the IANA registry) because receivers applied values other than 0 and 100 unevenly. Its replacement is t=y, testing mode: receivers apply one policy level below the published one, so p=quarantine; t=y is handled as none and p=reject; t=y as quarantine. It has no effect at p=none. Receivers still on RFC 7489 ignore t, which is why the generator offers pct only behind a legacy compatibility option.

What does np= do?

np= (added by RFC 9989) sets the policy for subdomains that do not exist in DNS at all. Leave it out and those names fall back to sp=, then p=. A name with no DNS records sends no legitimate mail, so once your policy enforces, np=reject closes off made-up subdomains at no cost.

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.