Domain {{ dmarcRoutePolicyLabel }} {{ dmarcRouteReportLabel }}
Enter example.com or sub.example.com; _dmarc. prefixes are removed.
Choose a preset to seed tags; Custom preserves your manual choices.
Start with none while reading reports, then tighten after legitimate senders align.
Use inherit for normal rollouts; set sp= only for different subdomain handling.
%
Enter an integer 0-100; use 100 for full enforcement after validation.
Separate mailboxes or mailto: URIs with new lines or commas.
Optional; separate mailboxes or mailto: URIs with new lines or commas.
Use r for relaxed alignment; choose s only after all DKIM signers match exactly.
Use r for most rollouts; choose s only when return-path domains are aligned.
Use 0, 1, d, or s; select multiple only when forensic reports are configured.
Enter whole hours or days; 24 hours is the normal daily request.
Turn on when review tickets need pct=100, adkim=r, and aspf=r shown explicitly.
{{ advanced.include_defaults ? 'On' : 'Off' }}
Item Value Copy
{{ row.label }}
{{ row.value }}
{{ row.value }}
{{ row.value }}
Rollout step Decision Operator note Copy
{{ row.label }} {{ row.headline }} {{ row.note }}
DNS item Value Copy
{{ row.label }}
{{ row.value }}
{{ row.value }}
{{ row.value }}
{{ row.note }}
Receiver zone Relative label Owner FQDN Use / TXT value Copy
{{ row.zoneHost }} {{ row.relativeLabel }} {{ row.owner }}
{{ row.useFor }}
{{ row.txtValue }}
Tag Effective value Publish state Why it matters Copy
{{ row.tag }} {{ row.value }} {{ row.publishState }} {{ row.note }}
Check Status Detail Copy
{{ row.label }} {{ row.badgeText }} {{ row.detail }}
Guidance item Detail Copy
{{ row.label }} {{ row.detail }}

      
Customize
Advanced
:

DMARC ties the domain in a message's visible From header to the authentication results that receivers can verify through SPF and DKIM. SPF proves that a permitted sending host used a domain in the SMTP envelope, while DKIM proves that a message carried a valid signature from a signing domain. DMARC asks a stricter question: does at least one of those authenticated domains line up with the Author Domain that the recipient can see?

The alignment check is what separates DMARC from simply publishing SPF or DKIM records. A message can pass DMARC with aligned SPF, aligned DKIM, or both. It fails DMARC when no authenticated identifier aligns with the Author Domain, even if some unrelated SPF or DKIM check passed somewhere in the delivery path. Forwarding, mailing lists, marketing platforms, billing systems, helpdesk tools, and legacy relay paths are common places where that distinction becomes visible.

Author Domain
The domain in the RFC5322.From field, which is the address domain people usually recognize.
Authenticated Identifier
The SPF or DKIM domain that a receiver validates for the message.
Identifier Alignment
The comparison between the Author Domain and the SPF or DKIM authenticated domain.
Enforcement
A receiver's use of a domain owner's published policy preference when DMARC validation fails.
DMARC pass flow from visible From domain through aligned SPF or aligned DKIM

A DMARC policy is published as a DNS TXT record below the _dmarc label. The policy can request monitoring with p=none, suspicious-mail handling with p=quarantine, or rejection with p=reject. Those policies are requests to mail receivers, not commands that bypass local filtering rules, reputation systems, or mailbox-provider judgment.

The 2026 DMARC standards split the protocol into a core specification plus separate aggregate and failure-reporting documents, but the operational shape is still familiar: publish a v=DMARC1 record, collect reports, fix legitimate senders that fail alignment, and raise enforcement only after the reports support the change. The older pct rollout tag still appears in many records and tools, while current standards use different testing language and receiver behavior can vary.

DMARC is strongest when it is treated as a deployment process rather than a single DNS paste. The record needs correct syntax, the right owner label, working report destinations, aligned SPF or DKIM on legitimate mail, and a cautious path from monitoring to enforcement.

How to Use This Tool:

The generator builds a draft DMARC publish pack from the domain, policy, reporting, alignment, and rollout choices you enter.

  1. Enter the Domain. The tool removes a pasted protocol, path, trailing dot, or leading _dmarc. label and shows the resulting Owner name.
  2. Choose a Preset such as Monitoring starter, Pilot quarantine (25%), Full quarantine, or Strict reject. Choose Custom when you want manual control.
  3. Set Policy (p=), Subdomain policy (sp=), and Enforcement percentage.
    pct is kept for compatibility with older rollout plans and deployed receiver behavior; it is not part of the current core DMARC policy-record tag set.
  4. Add one or more Aggregate report URI(s). Plain email addresses are converted to mailto: URIs, and entries can be separated by new lines, commas, or semicolons.
  5. Open Advanced only when you need Failure report URI(s), strict DKIM or SPF alignment, specific Failure report options (fo=), a custom aggregate report interval, or explicit default tags.
  6. Check the summary badge. Fix inputs means the generated value should not be copied yet; Review notes means the value exists but warnings need attention; Ready to publish means the draft has no blocking validation problems.
  7. Use DMARC Publish Records for the owner and TXT value, DNS Zone Labels for provider-specific host-label clues, Receiver Authorization Records for third-party report destinations, and DMARC Deployment Checks for warnings.
  8. Publish the owner and TXT value as one TXT record. If the value is split into multiple quoted strings, keep those strings inside the same TXT record entry rather than creating separate TXT records.

Interpreting Results:

Start with the summary status and then verify the publish rows. A clean-looking TXT string is not enough if the owner label belongs in a different hosted zone or an external report receiver has not authorized the report destination.

DMARC generator status meanings
Status Meaning Next check
Fix inputs The domain or report URI fields contain a blocking validation problem. Correct the named field before copying the TXT value.
Review notes The record can be built, but rollout, reporting, external authorization, or DNS packaging needs review. Read DMARC Deployment Checks and DMARC Publish Notes.
Ready to publish The generated owner, tags, and packaging checks have no blocking issue in the draft. Publish to DNS and confirm the live _dmarc TXT answer separately.

DMARC Publish Records is the copy source for the planned DNS value. DNS Zone Labels helps when your DNS provider asks for a relative host label instead of a full owner name.

Receiver Authorization Records appears when report mailboxes are outside the policy domain's organizational-domain family. Some receivers will not send aggregate or failure reports to an unrelated domain until that receiver domain publishes its own authorization TXT record.

DMARC Tag Map explains which tags are explicit, omitted as defaults, inherited, or ignored for the current scope. A p=reject value should not be treated as safe just because the syntax passes; it can still reject legitimate mail if real senders lack aligned DKIM or aligned SPF.

A generated record does not prove that receivers will honor every requested report or policy detail. Use aggregate reports and live DNS checks before moving from monitoring to quarantine or reject.

Technical Details:

Current DMARC terminology comes from RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. This generator focuses on the operational record fields most administrators still publish: v, p, sp, rua, ruf, adkim, aspf, fo, ri, and the older pct rollout field. It does not perform live DNS discovery or add newer policy tags such as np, psd, or t.

Formula Core:

The DMARC pass decision is a logical OR between aligned SPF and aligned DKIM. One aligned authenticated path is enough for a pass.

DMARCPass = ( SPFPass SPFAligned ) ( DKIMPass DKIMAligned )

When the report interval field is used, the visible value is converted to seconds for ri. Receivers can still send aggregate reports on their own schedule.

ReportIntervalSeconds = IntervalValue × UnitSeconds

Rule Core:

DMARC record rule summary
Area Rule Result effect
Owner Publish the policy record at _dmarc below the policy domain. Controls where receivers find the policy.
Version v=DMARC1 is first. Identifies the TXT record as a DMARC policy record.
Policy p is required and is none, quarantine, or reject. Requests handling for mail that fails DMARC validation.
Subdomain policy sp can set a different policy for subdomains when the record is on the organizational domain. Changes inherited subdomain handling.
Alignment adkim and aspf use relaxed r or strict s. Controls whether organizational-domain matches or exact matches qualify.
Reporting rua requests aggregate reports; ruf requests failure reports when supported. Determines requested feedback destinations.
Failure options fo accepts 0, 1, d, and s. Changes which failures can trigger failure reports.
Legacy rollout pct is generated from Enforcement percentage when needed. Useful for older rollout plans, but no longer part of the current core DMARC tag set.

Transformation Core:

Domain input is normalized before the owner label is built. A pasted URL is reduced to its host, a leading _dmarc. label is removed, trailing dots are trimmed, and internationalized labels are converted to DNS A-label form when the browser can parse them.

DMARC input transformation behavior
Input area Accepted or transformed Blocking condition
Domain Hostnames such as example.com or news.example.com. Empty values, invalid DNS labels, one-label names, overlong names, or repeated dots.
Aggregate reports Email addresses or mailto: URIs separated by new lines, commas, or semicolons. Unsupported URI schemes, invalid mailbox shape, or invalid destination domain.
Failure reports The same mailbox and mailto: handling as aggregate reports. The same URI and mailbox validation failures as aggregate reports.
Report size suffix Legacy !10m-style suffixes are preserved when valid. Suffixes that do not use a number plus optional k, m, g, or t.
Duplicate destinations Duplicate normalized report URIs are removed. Not blocking; the warning explains what was removed.

The TXT payload is counted in UTF-8 bytes. When several tags push the value beyond one 255-byte DNS string, the zone-file snippet groups quoted strings inside one TXT record where possible. That split is DNS packaging, not multiple DMARC policies; very long individual report tags still deserve DNS-provider review.

External-report authorization is detected when a report destination is outside the policy domain's organizational-domain family. The generated authorization owner follows the DMARC pattern of placing the policy domain before ._report._dmarc. and then appending the destination host.

Limitations and Privacy Notes:

The draft is a record generator, not a DNS validator or mail-flow audit. It can build and explain a publish pack, but it cannot prove that every legitimate sender aligns or that every receiver will follow each requested policy or report setting.

  • No live DNS lookup is performed; confirm the public _dmarc TXT answer after publishing.
  • Report addresses become public in DNS once you publish the record.
  • Failure reports can contain message-level information and are not consistently sent by receivers.
  • Current DMARC standards removed pct, ri, and report-size suffixes from the core policy-record tag set, while many existing deployments still expose or understand some older fields.
  • Organizational-domain edge cases can differ between older Public Suffix List behavior and the newer DNS Tree Walk model, so explicit records for important Author Domains are safer than relying on discovery alone.

Worked Examples:

Monitoring a parent domain. Enter example.com, keep Policy (p=) as none, and set Aggregate report URI(s) to dmarc@example.com. Owner name becomes _dmarc.example.com, TXT value includes v=DMARC1; p=none; rua=mailto:dmarc@example.com, and Aggregate visibility passes because one aggregate destination is configured.

External reporting service. A policy for example.com sends aggregate reports to reports@vendor.example.net. Receiver Authorization Records shows an owner like example.com._report._dmarc.vendor.example.net with v=DMARC1, and External report authorization appears as a review item until the receiver zone publishes that authorization.

Subdomain record in a parent zone. Enter news.example.com when only that Author Domain should receive its own DMARC record. Policy owner FQDN becomes _dmarc.news.example.com., while Host label inside example.com zone shows the relative label a parent-zone DNS provider may expect. Record scope warns that the record targets that exact subdomain rather than deeper names through sp.

Invalid report destination. Enter a web endpoint value in Aggregate report URI(s). The summary changes to Fix inputs because only mailbox-style mailto: destinations are supported for generated report URIs; replacing it with reports@example.net or mailto:reports@example.net clears the blocking issue.

Reject with incomplete sender evidence. Choose Strict reject for a domain that has not reviewed aggregate reports yet. The generated TXT value may be syntactically valid, but DMARC Publish Notes and Indirect mail compatibility should still be treated as warnings because forwarded mail and third-party systems often need aligned DKIM before reject is safe.

FAQ:

Does DMARC require both SPF and DKIM to pass?

No. A message can pass DMARC with aligned SPF or aligned DKIM. Having both is stronger operationally because forwarding commonly breaks SPF, while DKIM can survive many relay paths if the signature remains valid.

Should a new domain start with reject?

Most domains should start with p=none and aggregate reports, then move toward quarantine or reject after legitimate senders show aligned SPF or DKIM in real report data.

Why did the tool create a receiver authorization record?

It appears when a report destination is outside the policy domain's organizational-domain family. The destination domain may need to publish the shown v=DMARC1 TXT record before receivers send reports there.

Why is pct shown if current DMARC changed it?

pct is still useful for compatibility with older rollout plans and deployed records, but current DMARC standards removed it from the core tag set. Treat it as receiver-dependent rather than guaranteed partial enforcement.

Can I use an HTTP endpoint for DMARC reports?

This generator accepts mailbox-style destinations and mailto: URIs for report fields. If you paste an http or https URI, the summary changes to Fix inputs.

Does Ready to publish mean my email is protected?

No. It means the draft has no blocking input problem in this page. Protection still depends on publishing the record correctly, validating live DNS, and fixing legitimate mail sources that fail aligned SPF or DKIM.

Glossary:

Aggregate report
A periodic receiver report that summarizes message sources, authentication results, dispositions, and counts.
Author Domain
The domain in the visible From header that DMARC evaluates.
Failure report
A message-specific report about selected authentication failures, when a receiver supports and sends it.
Identifier Alignment
The match between the Author Domain and an SPF or DKIM authenticated domain.
Organizational Domain
The registrable administrative domain used for relaxed alignment and policy discovery decisions.
Policy domain
The domain whose _dmarc TXT record is being drafted.
Receiver authorization
A TXT record that lets a report receiver domain consent to DMARC reports for another policy domain.