Free tool

DMARC record generator.

Answer a few questions and get a valid _dmarc TXT record to paste into your DNS — with policy, reporting, and alignment options explained.

Build your recordVerify with DMARC checker

8

record options

RFC 9989

compliant output

0

stored input

Start at p=none, always with rua

The safest first DMARC record collects evidence without touching delivery: p=none with a rua address you actually read. Aggregate reports reveal every service sending as your domain — legitimate and otherwise — before you ask receivers to quarantine or reject anything.

  • p=none changes nothing about delivery; it only turns on visibility.
  • The rua address is where daily XML reports arrive — point it somewhere monitored.
  • Move to quarantine, then reject, only after reports show legitimate mail aligned.

Publish, then verify

Create a TXT record at _dmarc.yourdomain.com with the generated value, wait for DNS to propagate, then confirm publication with the DMARC checker. A record at the wrong hostname (yourdomain.com instead of _dmarc.yourdomain.com) is the most common setup mistake.

Fundamentals

What a DMARC record does

DMARC (RFC 9989) is a TXT record at _dmarc.yourdomain that tells receivers two things: how strictly to treat mail that fails aligned SPF and DKIM, and where to send reports about who is using your domain. It is the only authentication layer that gives you feedback — SPF and DKIM are silent unless you read headers on every message. The record is a semicolon-separated list of tags. The generator keeps the output intentionally small: policy, subdomain policy, testing mode, reporting addresses, and alignment modes. Anything you leave unset uses the receiver's default, which is usually what you want. DMARC does nothing on its own until SPF and DKIM exist and align with your visible From domain. If you have not set those up, do that first — the sender compliance checker audits all three in one pass.

Reading the tags

What each option means

The generator keeps the record minimal by design — unset tags fall back to sane defaults, and a short record is easier to maintain.

  • p: the policy for mail failing aligned authentication. none = monitor only, quarantine = spam folder, reject = bounce. Start at none.
  • sp: the same decision for subdomains. Omit it and subdomains inherit p; set sp=reject early on domains that never send from subdomains.
  • t: testing mode. t=y asks receivers to apply one policy level below quarantine or reject while you validate the change; omit it or use t=n for normal enforcement.
  • rua: where aggregate (XML) reports go. These daily reports show every IP sending as your domain — the single most valuable DMARC feature.
  • ruf + fo: per-failure forensic reports. Most large receivers no longer send them; safe to skip.
  • adkim / aspf: relaxed (r) lets subdomains align; strict (s) requires exact domain matches. Relaxed is right for almost everyone.

Rollout

From generated record to enforcement

A DMARC record is a program, not a one-time paste. The safe sequence is evidence first, enforcement later.

  • Week 1: publish p=none with rua. Reports start arriving within 48 hours.
  • Weeks 2–4: label every legitimate sender in the reports — ESP, CRM, support desk, transactional provider — and fix SPF or DKIM alignment for each.
  • Weeks 5–6: move to p=quarantine once legitimate volume aligns, keeping the rua address in place.
  • Later: p=reject when reports stay clean across multiple cycles. The full schedule with checkpoints is in the DMARC rollout guide.
  • Ongoing: new services appear over time. Watch reports continuously — DMARC monitoring turns the XML into a sender inventory instead of a folder of attachments.

Common mistakes

Mistakes that break DMARC setups

Most broken DMARC records fail on syntax or placement, not policy.

  • Wrong hostname: the record must live at _dmarc.yourdomain.com — publishing it at the bare domain does nothing.
  • Multiple records: exactly one DMARC TXT record is allowed; a second one makes the whole policy undefined.
  • rua to an unread mailbox: reports pile up unread while unknown senders keep using your domain. Point rua somewhere actionable.
  • Jumping to p=reject without a sender inventory: the classic way to break invoices, password resets, and CRM mail in one afternoon.
  • Forgetting subdomains: sp= unset means subdomains inherit p — an attacker-friendly gap on domains that only send from the apex.

Generator

Build your DMARC record

Answer the questions; the TXT record updates live. Publish it at _dmarc.yourdomain.com as a TXT record, then verify publication with the DMARC checker.

Start with none; move up with evidence.

Optional override for subdomains.

Use t=y only while validating a new RFC 9989 policy.

Where daily XML reports go. Strongly recommended.

Per-failure forensic reports; many receivers skip these.

When failure reports are generated. Default 0 is fine.

Your TXT record — publish at _dmarc.<yourdomain>

v=DMARC1; p=none;
Verify with DMARC checker

Related

DMARC rollout guide

From p=none to p=reject without breaking mail.

DMARC checker

Verify your published record after rollout.

SPF, DKIM, DMARC explained

How the authentication layers fit together.

Sender compliance checker

Audit all the Gmail and Yahoo requirements at once.

FAQ

What is the minimum viable DMARC record?

v=DMARC1; p=none; rua=mailto:you@yourdomain — it changes nothing about delivery and turns on aggregate reporting, which is the visibility every later decision depends on. Add enforcement only after the reports show all legitimate senders aligned.

Where exactly do I publish the record?

As a TXT record in your DNS at the hostname _dmarc.yourdomain.com (some DNS UIs want just the _dmarc part). One record only — a second DMARC TXT record makes behavior undefined. After publishing, verify with the DMARC checker.

Should I set ruf and fo?

Usually no. Forensic (per-failure) reports are barely supported by major receivers anymore and can contain message content, which has privacy implications. Aggregate rua reports give you the sender inventory without either problem.

What does testing mode do?

RFC 9989 replaced the unreliable pct tag with t. With t=y, quarantine is tested as none and reject is tested as quarantine. Remove t=y, or use t=n, when the reports show the declared policy is ready.

Do subdomains need their own DMARC records?

Only if you want a different policy for them. The sp tag in the parent record covers all subdomains; a separate record at _dmarc.sub.yourdomain overrides it for that subdomain. For domains that never send from subdomains, sp=reject is a cheap hardening step.