What does the 0 to 100 score measure?

The score measures the DMARCbis compatibility of your current DMARC v1 record. 100 = no change required. 90 or above = one or two minor adjustments. 75 to 89 = partial migration. 50 to 74 = major migration. Below 50 or invalid record = rewrite before migrating.

Which tags are removed in DMARCbis?

Three tags are dropped: pct (the policy applies to 100% by default), rf (only one report format remains), ri (default report interval is enforced). The fo tag is retained. If pct was below 100, the tool converts it to t=y to signal testing mode.

What is the new np tag for?

The np tag (non-existent subdomain policy) defines the policy applied to nonexistent subdomains. In DMARCbis, these subdomains no longer implicitly inherit from sp or p: np must be explicit. The tool derives np from sp if available, otherwise from p.

What is the difference between t=y and pct=0?

The t=y tag is the official replacement for pct=0 in DMARCbis. In t=y mode, receivers apply a policy one level down: reject becomes quarantine, quarantine becomes none. The semantics are clearer than a percentage.

Will the migration break deliverability?

No. The version stays v=DMARC1 and receivers that do not yet support DMARCbis ignore np, t and psd without rejecting the record. Backward compatibility is complete, your emails are still processed by DMARC v1 during the transition.

Which dimensions does the score evaluate?

Six weighted dimensions: no deprecated tags (40 points), np tag present (15 points), policy strength (20 points), DKIM and SPF alignment (10 points), rua reporting configured (10 points) and syntactic hygiene (5 points).

What if my record is invalid?

The tool returns a critical verdict and keeps the original record without applying the migration. Fix the syntax errors first (invalid policy, malformed rua URI, out-of-range pct) with the DMARC Validator, then run the migration again.

Should I migrate before the official RFC is published?

It is not mandatory. The DMARCbis draft is in the final IETF stage. Preparing your record by removing deprecated tags and adding np allows you to be ready as soon as the RFC is published. The new tags are ignored by current receivers, so there is no risk in migrating early.

DMARC to DMARCbis Migration Tool - Free

Why migrate to DMARCbis?

DMARCbis succeeds RFC 7489, published in 2015. The draft introduces four structural changes:

Removal of pct, rf, ri: the policy now applies to 100% of traffic, only one report format remains defined, and the report interval is enforced by default. The fo tag is retained.
Addition of np: the nonexistent subdomain policy becomes explicit, closing a gap exploited by attackers who fabricate fictitious subdomains.
Conversion pct<100 to t=y: testing mode replaces the percentage. Simpler, more predictable, more aligned with actual receiver behavior.
DNS tree walk to identify the organizational domain, replacing the Public Suffix List.

Your current DMARC record keeps working during the transition. Migrating now means being ready when the RFC is officially published and immediately benefiting from nonexistent subdomain protection via np.

How the analyzer works

The tool parses your DMARC v1 record, applies the DMARCbis transformations and computes a DMARCbis compatibility score on 100. The computation is local, with no DNS resolution or external call.

The five possible verdicts

Verdict	Score	Meaning
Already compliant	90 to 100	No change required or minor adjustment. Watch for the official RFC publication.
Partial migration	75 to 89	One to three minor changes (typically redundant `pct=100` or missing `np`).
Major migration	50 to 74	Four or more changes. Multiple deprecated tags and weak policy.
Invalid record	0 to 49 or invalid state	Syntax errors to fix before migrating.
No record	N/A	Empty field. Paste a DMARC record before running the analysis.

The six scoring dimensions

Dimension	Weight	What it measures
No deprecated tags	40 points	Presence of `pct`, `rf`, `ri`. The more present, the stronger the deduction.
`np` tag present	15 points	Explicit nonexistent subdomain policy. Inherits from `sp` or `p` if absent.
Policy strength	20 points	`reject` earns the maximum, `quarantine` a fraction, `none` a minimal credit.
DKIM and SPF alignment	10 points	`adkim=s` and `aspf=s` earn the maximum, `r` keeps part of it.
`rua` reporting configured	10 points	Valid mailto URI for aggregate reporting.
Syntactic hygiene	5 points	Well-formed, parsable record.

Three priority factors are surfaced at the top of the result to explain the score immediately, before the dimension-by-dimension breakdown.

Key DMARC to DMARCbis changes

Removed tags

Tag	Action	Why
`pct`	Remove	The policy applies to 100% by default. If `pct<100`, the tool converts to `t=y`.
`rf`	Remove	Only one report format remains defined in DMARCbis.
`ri`	Remove	Receivers enforce a default report interval.

Added tag

Tag	Value	Why
`np`	inherits from `sp` or `p`	Policy for nonexistent subdomains. Must be explicit in DMARCbis.

Tags kept unchanged

v=DMARC1, p, sp, adkim, aspf, rua, ruf. Their semantics are unchanged.

Recommended migration plan

Step 1: audit the current record. Run the analysis with your published DMARC record. Note the score, verdict and recommendations.

Step 2: apply the proposed changes. Copy the migrated record and publish it in your DNS zone at _dmarc.captaindns.com. Keep the previous record for 48 hours with a short TTL (300 seconds) to allow a quick rollback if needed.

Step 3: monitor the rua reports. For two to four weeks, check your aggregate DMARC reports to confirm no impact on legitimate flows. The switch to np may reveal undocumented active subdomains.

Step 4: stabilize the TTL. Once reports are validated, raise the TTL back to 3600 or 86400 seconds. The migration is complete.

If you are also moving from a lenient policy to p=reject, use t=y for a few weeks. DMARCbis receivers then apply a policy one level down, which serves as a safety net during the validation phase.

Common mistakes to avoid

Keeping pct=100. This value is redundant in DMARCbis. The whole tag can be removed without changing the behavior.

Confusing np and sp. sp targets existing subdomains, np targets exclusively nonexistent subdomains. The two tags are complementary, not interchangeable.

Combining pct and t. In DMARCbis, t always takes precedence. There is no point in keeping pct when t=y is present.

Removing rua during cleanup. Aggregate reporting is the only source of truth on your policy effectiveness. Keep rua=mailto:reports@captaindns.com (or your dedicated address) in the migrated record.

Migrating without reviewing existing reports. Before tightening the policy, check which legitimate senders are not yet SPF or DKIM aligned. Migrating to p=reject without this step can block internal flows.

Declaring psd=y without being a registry. The psd=y tag is reserved for public suffix operators such as .bank or .gov.uk. For a standard organizational domain, omit the tag or use psd=n to make it explicit.

Tool	Purpose
DMARCbis Checker	Audit a published domain against DMARCbis with DNS tree walk
DMARC Checker	Verify publication and resolve the DMARC record from DNS
DMARC Validator	Validate the syntax of a DMARC v1 record before publishing
DMARC Generator	Create a DMARC or DMARCbis record from scratch
DMARC Report Reader	Decode aggregate XML reports
DMARC Monitoring	Receive and analyze your aggregate DMARC reports automatically