DMARC t Tag is a policy tag in a DMARC record that can make a policy apply only to a specific organisational domain, not to its subdomains. It is used in the DNS TXT record for DMARC, alongside tags such as p and rua, to scope enforcement and reporting.
What the t tag does in DMARC
The t tag is a dmarc policy tag used to scope policy behavior to the organisational domain itself, rather than automatically extending that policy to every subdomain. That makes it a precision control, not just a policy statement.
In practical terms, the tag matters because DMARC is evaluated against domain hierarchy. A record that applies only at the organisational level can leave subdomains governed differently, which affects enforcement, reporting, and how mail receivers interpret your intent.
How t changes DMARC policy scope
The main value of the t tag is control over inheritance. Without that kind of scoping, a DMARC record can be treated as part of a broader domain policy pattern, which may be too aggressive or too loose for organisations that manage multiple branded or delegated subdomains.
This is especially relevant where subdomains are used by different business units, third parties, or customer communications. The tag helps separate policy decisions so that one domain’s authentication posture does not unintentionally override another’s operational needs.
That separation is one reason DMARCbis guidance matters here, since the modern record model is more explicit about policy scope, tree walking, and related record behavior. The DMARCbis Changes Guide is useful for understanding how the t tag fits into the newer DMARC record structure.
Why the tag matters for email authentication operations
DMARC is rarely deployed on a single record alone. It works alongside SPF, DKIM, alignment, and reporting, so a scope-setting tag can change which parts of your email estate are actually covered by a policy decision.
That has operational consequences for message handling, receiver expectations, and reporting analysis. If policy is intended only for the organisational domain, security teams need to confirm that the same assumption is not being made for subdomains, especially where mail streams are split across marketing, support, and transactional systems.
For organisations building a broader sender-authentication programme, the DMARC, SPF and DKIM Guide explains how alignment, policy and reporting work together, while the Email Identity and BEC Guide shows why scoping mistakes can create room for spoofing and business email compromise.
What to check before relying on a t-scoped record
Before using the tag as a control boundary, organisations should confirm which hostnames actually send mail, which ones are parked, and which ones are delegated to vendors. A scoped DMARC policy is only effective if the domain inventory is accurate and the intended mail flow is understood.
It is also important to verify how reporting is consumed. A policy that applies only at the organisational domain may not surface the same signals you expect from subdomains, so investigation workflows should be aligned to the exact scope being enforced.
Where the goal is to protect domains that do not send mail, the Domain Without Email guide is a practical companion because it shows how non-sending domains, null MX records, and DMARC policy choices interact.
Common mistakes when using DMARC scope controls
The most common mistake is assuming a policy on the organisational domain automatically provides the same protection for all child domains. That assumption can leave important subdomains with weaker or inconsistent protection, or create the opposite problem, where an intended exception is accidentally overextended.
Another frequent error is reviewing the DMARC record as if it were only a syntax question. The tag is a governance choice as much as a DNS choice, because it defines who owns the policy boundary, how exceptions are handled, and how reporting should be interpreted across the domain portfolio.
For teams formalising email security controls, the CIS Control 9 Email and Web Browser Protections Guide helps place DMARC within a broader defensive baseline, including browser and mail protections that support authentication outcomes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | DMARC is an email authentication safeguard under Control 9. |
| Recommendation — Implement DMARC as part of email and browser protections to reduce spoofing exposure. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | DMARC policy scope helps preserve the integrity of domain-based email identity signals. |
| Recommendation — Verify domain email identity controls so authenticated mail policies are enforced consistently. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | DMARC supports authenticity of email-origin signals used in trusted communications. |
| Recommendation — Use authenticity controls to reduce spoofed mail that abuses trusted communications. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | DMARC addresses broken sender authentication patterns in email delivery trust. |
| Recommendation — Strengthen sender authentication to block spoofed messages and impersonation. | ||