{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Standard{{ profileLabel }} Policy{{ resultsReady ? normalized.policy : '—' }} Review{{ resultsReady ? reviewCountLabel : '—' }}
TXT value: {{ resultsReady ? computation.values.txt_value : '—' }}

{{ primaryCopyAnnouncement || textExportStatus }}

Current mode uses active tags; compatibility mode labels historic rollout tags explicitly.
A pasted URL or leading _dmarc. label is normalized locally.
Start with monitoring and aggregate reports before moving to stronger handling.
Receiver behavior remains subject to local policy and operational judgment.
Testing has no effect when p=none.
Compatibility-only integer from 0 to 100.
%
Report addresses become public when the record is published in DNS.
The neutral default omits sp so the domain policy is inherited.
The neutral default omits np and inherits sp or p.
Relaxed alignment is the default and keeps adkim omitted.
Relaxed alignment is the default and keeps aspf omitted.
Leave blank unless the privacy and processing implications are understood.
The default fo=0 is omitted unless explicit defaults are requested.
Ordinary domain owners normally leave this unspecified.
Omit is neutral; receivers historically treated non-daily intervals as best effort.
Off is neutral: default-valued tags stay omitted.
{{ include_defaults ? 'Enabled' : 'Disabled' }}

{{ chartExportStatus }}

The chart renderer is unavailable. Exact scope policies remain available in the deployment ledger.

AreaStatusDetailValue or actionCopy
{{ row.area }}{{ row.status }}{{ row.detail }}{{ row.value }}

{{ tableExportStatus }}

MTA-STS Validator Check an email domain's MTA-STS TXT and HTTPS policy, then review MX patterns and the policy-host certificate before enforcement.
TLS-RPT Record Validator Validate a TLS-RPT policy from live DNS or pasted text, check report destinations and RFC rules, then build a reviewable TXT record.
SMIMEA / OPENPGPKEY Lookup Look up SMIMEA or OPENPGPKEY records for a mailbox and derive its RFC owner name with DNSSEC and resolver evidence plus cache and payload details.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.

A receiving mail system needs more than a valid signature or an SPF result to know whether a message is authorized to use the domain visible in its From address. Domain-based Message Authentication, Reporting, and Conformance (DMARC) adds that relationship. It checks whether a passing DKIM signing domain or SPF-authenticated domain aligns with the author domain, then consults the domain owner's published policy when neither mechanism produces an aligned pass.

Alignment can be relaxed or strict. Relaxed alignment accepts domains that share the same organizational domain, while strict alignment requires identical domains. Relaxed mode is the default for both DKIM and SPF because legitimate mail often uses service subdomains. Strict mode can narrow that trust boundary, but it can also expose senders whose signing or envelope domains were never configured to match exactly.

Policy Request for mail that fails DMARC Typical rollout role
p=none Do not apply quarantine or rejection because of DMARC Collect evidence and repair sender alignment
p=quarantine Treat the message as suspicious Intermediate enforcement after monitoring
p=reject Reject the message during handling Strong policy after legitimate mail paths are known

These values express the domain owner's requested assessment policy. Receivers retain local judgment, and forwarding or mailing-list transformations can change authentication outcomes. A syntactically correct record should not move directly to enforcement without checking every service that sends as the domain, including marketing platforms, ticketing systems, transactional providers, and delegated subdomains.

Reporting turns DMARC from a blind policy into an operational feedback loop. Aggregate reports summarize authentication and alignment by sending source. Failure reports can contain message-level information and are not offered consistently, so they require a separate privacy and handling decision. Report mailbox addresses also become public once they appear in DNS.

The current 2026 specification uses the t tag for policy testing and adds active np and psd semantics. The older RFC 7489 profile used pct for sampling and ri for a requested aggregate-report interval. Mixing the two models can produce a record that looks familiar but does not communicate the intended rollout to current receivers.

DMARC depends on working SPF and DKIM; it does not replace them. A record generator can assemble a valid policy expression, but only live DNS checks, authentication results, and real report data can show whether the domain's mail ecosystem is ready for enforcement.

How to Use This Tool:

Choose the standards model and rollout intent before adding optional tags. Monitoring with an aggregate-report destination is the safest starting point for an unmeasured domain.

  1. Select RFC 9989 (current) unless you are deliberately preparing an RFC 7489 compatibility record. Enter the policy domain; a pasted URL or leading _dmarc. label is normalized.
  2. Choose a Rollout preset or set Domain policy and Policy application directly. Under the current profile, test mode requests one policy level below the declared value and has no effect on p=none.
  3. Add one or more Aggregate report destinations as mailbox addresses. Review every generated external authorization record when a report mailbox belongs to another organizational domain.
  4. Open Advanced for explicit subdomain policies, strict DKIM or SPF alignment, failure reports, public-suffix designation, or compatibility-only report timing. Leave default-valued tags omitted unless the deployment requires them to be explicit.
  5. Copy the TXT value only after the deployment review is clear. Publish the policy and any required authorization records, then query the exact DNS owner and inspect real DMARC reports before increasing enforcement.

Interpreting Results:

The generated owner and TXT value show what to publish, while the review rows show decisions that still need operator judgment. A syntax pass means the tag sequence and values are internally valid. It does not confirm DNS publication, sender alignment, report delivery, or receiver behavior.

The enforcement profile is a planning view of the declared domain, subdomain, and non-existent-subdomain policies. Under current test mode, quarantine is shown at the none level and reject at the quarantine level. Treat that view as the requested policy effect, not a prediction of how every mailbox provider will classify a message.

After publication, query _dmarc.<domain> as TXT and join adjacent quoted strings from the same DNS answer without adding spaces. Then compare aggregate reports with an approved sender inventory before changing from monitoring to enforcement.

Technical Details:

A DMARC policy record is a semicolon-separated tag list stored at the _dmarc owner below the policy domain. v=DMARC1 must come first, followed here by the domain policy and only the optional tags justified by the selected profile and settings.

Rule Core:

Rule area RFC 9989 profile RFC 7489 compatibility profile
Required start v=DMARC1; p=none|quarantine|reject
Testing or sampling t=y for test mode; t=n only when defaults are explicit pct=0 through pct=100 when non-default or explicit
Subdomains sp overrides p for existing subdomains; omission inherits p
Non-existent subdomains np overrides sp or p; omission inherits Not emitted
Public suffix psd=y, psd=n, or omitted when unspecified Not emitted
Report interval ri is not emitted Optional ri=3600|21600|43200|86400

Relaxed alignment is represented by the omitted default or explicit adkim=r and aspf=r. Strict mode emits adkim=s or aspf=s. Aggregate mailboxes become a comma-separated rua value. Failure mailboxes become ruf; fo is emitted with them when it differs from the default or explicit defaults are requested.

For a current monitoring record on example.com with aggregate reports sent to dmarc-reports@example.com, the core result is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A report destination outside the policy domain's organizational domain requires DNS authorization by the destination domain. The generated companion owner follows <policy-domain>._report._dmarc.<destination-domain> and carries v=DMARC1;. External-domain detection uses a limited organizational-domain approximation rather than a live public-suffix database, so multi-label public suffixes and unusual delegations require manual review.

The TXT value is measured in UTF-8 bytes. When it exceeds 255 bytes, it is split into multiple quoted character-strings within one TXT resource record, preferably at a semicolon boundary. DNS readers concatenate those adjacent strings; they must not be published as several competing DMARC records.

Input normalization lowercases the domain, removes a leading _dmarc., trims trailing dots, and accepts mailbox-style report destinations with or without an explicit mailto: prefix. Historic report-size suffixes are accepted for compatibility, but the current profile flags them as obsolete.

Limitations and Privacy Notes:

  • The generator does not query DNS, discover all sending services, parse DMARC reports, or test real messages. A ready record is still a draft.
  • Aggregate report addresses are public in DNS. Third-party processing and retention should be approved before publication.
  • Failure reports can contain message-level information, may expose private content, and are not sent consistently. Add ruf only with a defined security and privacy process.
  • Policy requests do not override receiver discretion. Forwarding, mailing lists, authentication changes, and organizational-domain discovery can affect live outcomes.

References: