DMARCbis Draft Retires pct Tag, Introduces Simpler t Flag

A newly updated version of the DMARCbis specification—a draft standard currently under review by the Internet Engineering Task Force (IETF)—proposes a significant change to how domain owners manage and signal the enforcement of their DMARC policies.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol that helps prevent domain spoofing by verifying that messages are correctly authenticated with SPF or DKIM and that these identifiers align with the domain in the “From” header. To implement DMARC, domain owners publish DNS records that tell receiving mail servers how to handle unauthenticated email—either monitor it (p=none), quarantine it (p=quarantine), or reject it (p=reject).

Because jumping straight to full enforcement can be risky—especially for large domains with complex mailflows—many organisations prefer to roll out enforcement gradually. Historically, this was done using the pct (percentage) tag, which instructed receivers to apply the policy to only a portion of the email traffic (e.g., pct=25 would apply the policy to 25% of mail).

However, the latest draft-ietf-dmarc-dmarcbis-41 published on 22 July 2025 proposes removing the pct tag entirely, citing widespread confusion and inconsistent implementation. Most receivers only respected pct=0 (testing) or pct=100 (full enforcement), ignoring intermediate values or applying them unpredictably.

In its place, the draft introduces a simpler, binary t (testing) flag:

• t=y — equivalent to pct=0, indicating the policy is in test mode and enforcement should not occur
• t=n — equivalent to pct=100, indicating full enforcement is expected

This change simplifies the rollout path while providing a clearer, more predictable signal to mailbox providers.

The draft also introduces structural revisions to improve clarity around organisational domain discovery—the process of determining which domain to evaluate for alignment when multiple subdomains or delegated services are involved. Additionally, several existing tags are marked for deprecation or replacement.

Summary of Key Changes

• Removed: pct, rf, ri (deprecated)
• Added: t (testing flag), np (nonexistent policy), psd (public suffix domain)
• Clarified: Steps for organisational domain discovery and DNS tree traversal

Why This Matters

✅ Simplifies Policy Deployment

The removal of pct reduces configuration complexity and eliminates variable behaviour across different receivers. The new t flag offers a clear and consistent way to signal testing vs full enforcement, improving reliability during rollout phases.

📌 Improves Alignment Discovery

The draft strengthens guidance on how receivers should identify the “organisational domain”—a critical step for accurately assessing DMARC alignment, especially in cases involving subdomains or third-party services.

⏳ No Immediate Changes Required

DMARCbis remains a draft and is not yet a final standard. Existing DMARC records remain valid, and domain owners do not need to change anything immediately. However, understanding the proposed changes now will help technical teams plan for eventual adoption.

Recommended Actions for Email Teams

• Review Your Current DMARC Configuration
  Ensure your policy tags (p, sp, adkim, aspf) are correctly set. Work out your approach for staged rollout that does not rely on pct.
• Prepare for the t Flag
  Familiarise technical staff with the new binary testing flag. Update internal documentation to reflect its meaning and usage.
• Track DMARCbis Progress
  Follow IETF developments and be prepared to adjust records once the specification reaches final RFC status.
• Reinforce Alignment Across SPF and DKIM
  DMARCbis does not change alignment rules, so maintaining consistent identifier alignment remains essential.
• Engage with the IETF Process
  Participate in the public review phase if you have feedback or implementation insights to contribute.