DMARC Policy and Subdomains: Move From Monitoring to Enforcement Carefully
Review DMARC policy, subdomain handling and current specification changes before moving from monitoring to enforcement.
TL;DR
- Inventory legitimate senders and their authentication results before changing a domain's DMARC policy.
- Treat the main domain and its subdomains deliberately; a parent policy can affect mail you did not remember was being sent.
- The current DMARC standard is RFC 9989, published in May 2026; older guides using percentage rollout need to be rechecked.
- Move to enforcement through a reviewed change with monitoring, a responsible owner and a recovery plan.
Begin with the mail you actually send
DMARC settings affect a domain used in the visible From address. Before changing them, list the systems that send on behalf of the organization: application notifications, support tools, billing systems, newsletters, recruitment software and occasional administrative messages.
For each system, record the From domain, the person responsible for it and where its authentication configuration is managed. Send an authorized test message through the normal workflow and inspect the receiving system's authentication results. A screenshot of a provider's “verified domain” page does not prove that every message path is configured correctly.
Include infrequent workflows. A quarterly billing run or an annual event tool can be easy to miss if the review looks at only a few days of traffic. Ask the teams that own those systems rather than assuming the most visible application is the only sender.
Use the current specification
RFC 9989, published in May 2026, replaces the earlier RFC 7489 DMARC specification. Its policy tags distinguish the domain policy, existing subdomains through sp, and nonexistent subdomains through np. Exact policy discovery matters; do not infer the result solely from one record viewed in a dashboard.
The newer standard removes the old pct tag and introduces a testing signal, t. Do not copy a “start with pct=10” rollout from an older tutorial and assume current, uniform behavior. Check your receivers, tooling and implementation support before relying on a particular policy mechanism.
DMARC evaluates alignment with the visible From domain as well as authentication. A message can have a passing authentication result for an unrelated domain and still fail DMARC. Investigate the actual identifiers in the received message rather than counting any “pass” as sufficient.
Review the domain hierarchy
Draw the domains used by legitimate senders. A business might use its main domain for staff mail, a notifications subdomain for application messages and a separate marketing subdomain. Identify which records apply to each before changing the parent policy.
| Review item | Evidence to collect |
|---|---|
| Main domain | Current DNS record, sender inventory and recent authentication evidence |
| Sending subdomain | Actual From address and the policy discovered for that domain |
| External sending service | Configuration owner and a message produced by the real workflow |
| Unused domain or subdomain | Confirmation that no legitimate workflow depends on it |
| Proposed change | Expected effect, responsible owner and a way to restore the prior configuration |
Avoid treating a subdomain as an isolated project without checking its relationship to the organizational domain. A configuration change made by one team can affect a system operated by another.
Use reports to find work, not just to create a score
Aggregate reports can reveal sending sources and authentication patterns. They do not prove that every expected message arrived in the inbox or that a recipient read it. Our DMARC report guide explains how to turn report entries into a sender investigation.
Separate known legitimate systems from unexplained traffic. For a known sender that fails alignment, work with its owner to correct the configuration. For an unfamiliar source, investigate before adding it to an authorized-sender list. Authorizing every observed source would defeat the purpose of the review.
Retain a small change log with dates and the systems affected. When a pattern changes after a DNS update, that history helps distinguish a configuration regression from a new sender or a normal change in traffic.
Move to enforcement through an owned change
Choose a change window when someone can monitor outcomes and respond. Save the prior DNS configuration, document the proposed policy and confirm who can restore it. Consider DNS propagation and receiver caching when interpreting the first results.
After the change, repeat the important user journeys: account confirmation, password recovery, receipts and support replies. Review application events and delivery outcomes as well as aggregate reporting. A daily report is not a substitute for checking a critical message path promptly.
If legitimate mail fails, identify the affected sender and alignment issue. A temporary rollback may be appropriate while the owner corrects a critical path, but record why it happened and what must be fixed before enforcement is resumed.
Keep the inventory current
Add authentication review to the process for introducing a new sending service. Require a named owner, a documented purpose and a test through the actual production-like workflow. Remove obsolete service access when a tool is retired.
Periodically revisit domains that have no expected outbound mail and senders that operate only occasionally. The inventory is useful because it reflects the organization as it operates now, not because it was complete once.
A DMARC policy is an operational decision with consequences for legitimate delivery. The strongest rollout is based on known senders, verified alignment and a team prepared to investigate exceptions.