DMARC to DMARCbis Migration Tool

Guide to migrating from DMARC to DMARCbis

Why migrate?

The DMARC to DMARCbis migration does not impose any deadline. Your current DMARC records continue to work. However, using a DMARC upgrade tool to migrate allows you to:

• Protect nonexistent subdomains with the np tag, closing a gap exploited by attackers
• Simplify management by removing tags ignored by modern receivers
• Declare your organizational scope with psd=n, clarifying the DNS hierarchy for receivers

Migration steps

1. Remove obsolete tags

2. Add the np tag

Choose a policy for nonexistent subdomains:

• np=reject: recommended if p=reject (maximum protection)
• np=quarantine: intermediate approach
• np=none: monitoring only

If np is absent, the sp policy applies (then the p policy).

3. Evaluate the t tag

• If you currently use pct=0 for testing mode, switch to t=y
• If your policy is fully enforced, no action is required (the default t=n is equivalent)
• Do not combine pct and t: t always takes precedence

4. Declare psd if relevant

• Organizational domain (captaindns.com): psd=n declares that you are not a public suffix
• Registry (.bank, .gov.uk): psd=y enables publishing a policy for all registrants
• Default: psd=u (undetermined), the DNS tree walk determines the organizational domain

Migration example

Before:

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

After:

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Changes:

• pct=100 removed (equivalent to the default t=n)
• ri=86400 removed (ignored by receivers)
• np=reject added (protection for nonexistent subdomains)
• psd=n added (organizational scope declaration)

Real-world migration examples

Here are three representative scenarios you may encounter when migrating your DMARC record to DMARCbis.

Scenario 1: record with partial pct

Before:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

After:

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

The value pct=50 means the policy was only applied to half of all messages. In DMARCbis, this granular approach is replaced by a binary mode. The t=y tag activates testing mode: DMARCbis-aware receivers apply the policy one level down (quarantine becomes none). The np=quarantine tag inherits from the p policy to protect nonexistent subdomains.

Scenario 2: strict record with no obsolete tags

Before:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

After:

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

This record is already clean: no obsolete tags to remove. Simply add np=reject to cover nonexistent subdomains and psd=n to declare that the domain is not a public suffix. The migration consists of adding two tags without changing the existing policy.

Scenario 3: record with all obsolete tags

Before:

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

After:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Here, three obsolete tags are removed at once. pct=100 corresponds to the default behavior (full enforcement), so no t tag is needed. ri=86400 never actually influenced report frequency. rf=afrf was the only possible value, now implicit. The np=reject tag is added for complete protection.

What happens during the transition?

The transition period between DMARC and DMARCbis poses no risk to your email deliverability. Here is why:

• Unknown tags are ignored: receivers that do not yet support DMARCbis simply ignore the np, t, and psd tags. They continue applying p, sp, and rua as before.
• The version stays v=DMARC1: DMARCbis does not change the version identifier. No receiver will reject your record because of the update.
• The t tag in practice: a DMARCbis-aware receiver applies testing mode if t=y is present. A DMARC v1 receiver does not recognize t and applies the p policy at 100% directly. This means that during the transition, your emails benefit from the highest protection level of either standard.
• Gradual adoption: major providers (Google, Microsoft, Yahoo) adopt new specifications incrementally. The coexistence of both behaviors is expected to last several years.
• No urgent action required: your current DMARC records remain functional. The migration can proceed at your own pace, with no maintenance window or service interruption.

Recommended rollout strategy

To migrate safely, follow these four steps in order:

Step 1: Audit your current record. Use our DMARCbis Checker to analyze your published DMARC record. The tool identifies obsolete tags and evaluates DMARCbis compliance.

Step 2: Remove obsolete tags. Delete pct, rf, and ri from your record. These tags have no effect in DMARCbis and their presence adds unnecessary clutter to your DNS configuration.

Step 3: Add the new tags. Add np=reject (or the policy of your choice) to protect nonexistent subdomains. Add psd=n to explicitly declare your organizational scope. Both additions strengthen your email security posture without changing the main policy.

Step 4: Test before enforcing. If you are moving from a lenient policy (none or quarantine) to a strict policy (reject), use t=y for a few weeks. Monitor your DMARC aggregate reports to verify that no legitimate mail flow is impacted. Once reports are validated, remove the t tag (the default t=n enforces the policy fully).

Common mistakes to avoid

Forgetting to disable testing mode. The t=y tag is useful during the validation phase, but it intentionally reduces the protection level. Set a reminder to switch to t=n (or remove the tag) after your testing period.

Confusing np with sp. The sp tag defines the policy for existing subdomains. The np tag targets exclusively nonexistent subdomains, the ones attackers fabricate to bypass protections. Both tags serve distinct and complementary roles.

Accidentally removing the rua tag. When cleaning up your record, make sure to keep the rua tag pointing to your aggregate report address. Without reporting, you lose all visibility into spoofing attempts and alignment issues.

Declaring psd=y without being a registry. The psd=y tag is reserved for public suffix registries (such as .bank or .gov.uk). If you own a standard organizational domain, use psd=n. An incorrect declaration could send the wrong signal to receivers and complicate the DNS tree walk.

Migrating without reviewing existing reports. Before modifying your record, analyze your recent DMARC aggregate reports. They reveal which legitimate senders are not yet SPF or DKIM aligned. Migrating without this check risks blocking legitimate email flows when switching to a stricter policy.

Related tools

Before migrating, check your domain's current DMARCbis compatibility with the DMARCbis Checker. The checker performs a full DNS tree walk analysis and detects all deprecated tags.

For a complete DMARC audit, explore these tools:

• DMARC Syntax Checker to validate your current DMARC record syntax
• DMARC Record Inspector to look up and analyze the DMARC record published on your domain
• DMARC Generator to create a new DMARC record from scratch
• DMARC Report Reader to decode aggregate XML reports

Learn more about the protocol changes in our guide: DMARCbis: every change and how to get ready.