Policy builder

DMARC Record Generator

Build a syntactically valid DMARC record from plain-language choices, see what each tag does, and compare it with the record your domain publishes today.

dmarc record generatordmarc generatorcreate dmarc recorddmarc record example
Build a DMARC recordGenerated locally from your choices. Enter a domain to compare with the record currently published.
RFC 7489 / RFC 9989 tag syntax

What this analysis does

Choose the policy, reporting addresses, alignment modes and rollout percentage, and Mailybox assembles the exact TXT value to publish at _dmarc. Every tag is explained in operational terms, risky combinations are flagged before you copy anything, and when a domain is supplied the proposal is diffed against the live record so you can see precisely what changes.

A DMARC record is short, but each tag changes what receivers do with mail that fails authentication. The generator turns those decisions into a correctly formed TXT value, explains the operational effect of each choice, and shows exactly what would change if the domain already publishes a policy.

Reviewed against RFC 9989 on 2 September 2026

Start at p=none unless you already have reporting data

The policy tag tells receivers what to do when a message fails DMARC: nothing, quarantine, or reject. Publishing reject on a domain whose senders have never been inventoried is the most common way legitimate mail is lost, because every platform that sends for the domain without an aligned path is suddenly refused.

The safe sequence starts with p=none and an aggregate reporting address. Reports arrive daily from participating receivers and show which sources send as the domain and whether they align. Once every legitimate source has an aligned path, move to quarantine, then reject — optionally with pct to apply the stricter policy to a fraction of failures first.

  • p=none blocks nothing; it collects evidence.
  • Add rua before enforcing, or failures will be invisible.
  • Use pct for a staged move from quarantine to reject.

Alignment modes and subdomains are where surprises come from

Relaxed alignment lets a subdomain identity satisfy the policy for the organizational domain; strict requires an exact match. Most domains should stay relaxed. Strict is appropriate only when every sending path has been configured for the exact From domain and you have confirmed that with real messages.

The sp tag sets a separate policy for subdomains. It is easy to enforce reject at the apex and leave subdomains — which attackers invent freely — under a weaker inherited policy. If you set sp, confirm that every subdomain that sends mail has its own aligned path first.

External reporting addresses need authorization

When rua points at a mailbox on a different domain, receivers check that the destination domain agrees to receive reports for yours. That agreement is a TXT record at yourdomain._report._dmarc.destination-domain. Without it, many receivers discard the reports silently and the policy appears to produce no telemetry.

Reporting services handle this for you by publishing the authorization on their side. If you run your own reporting mailbox on another domain you control, publish the record yourself. The generator flags every external address so this step is not forgotten.

Example: replacing a monitoring policy with enforcement

Evidence supplied
Domain publishes v=DMARC1; p=none; rua=mailto:dmarc@example.com. Proposal: p=reject, adkim=s, pct=50.

How to read the result
The generator produces the new record and lists three changes against the live one: p from none to reject, adkim from unset to strict, pct from unset to 50. It warns that strict DKIM alignment breaks platform-signed mail and that pct=50 leaves half of failing messages at the next weaker policy.

Known limits

  • The generator validates syntax and explains effect; it cannot know which platforms send for the domain.
  • Comparison uses the record at _dmarc only; inherited organizational policies are shown by the tree walk explorer.
  • Receivers apply DMARC alongside their own filtering, so a published policy is a request, not a guarantee.

Common questions

Do I need both rua and ruf?

No. rua (aggregate) is essential. ruf (forensic) is sent by few receivers, can contain message content, and is optional.

What happens if I publish two DMARC records?

Receivers treat multiple records as an error and apply no policy. Replace the existing record rather than adding another.

Should pct be used permanently?

No. It is a rollout aid. Once reports show no legitimate failures, remove pct so the full policy applies.

Primary references