How to review a DMARC subdomain policy for client domains

Review a DMARC subdomain policy by checking the exact sending subdomain, identifying the applicable organizational-domain policy, and testing whether legitimate mail passes aligned SPF or DKIM. Keep the DNS observation separate from delivery evidence: a published policy describes requested handling, while message headers and reports show how mail actually authenticates.

How to Review a DMARC Subdomain Policy for Client Domains

Use this procedure for each domain appearing after the @ sign in the visible From address. A website hostname, return-path domain, or DKIM signing domain is not automatically the domain whose DMARC policy you need to evaluate.

For your 2026 review, use the policy-discovery procedure in RFC 7489, section 6.6.3, as the stated technical baseline. Record the evaluator and policy-discovery method when interpreting results. The broader assessment boundary is covered in whether an SPF, DKIM, and DMARC checker is enough to assess email risk.

1. Identify the From domain. Collect representative legitimate messages and list their visible From domains. Include marketing platforms, billing systems, support tools, and other authorized senders supplied by the client.
2. Query the exact domain. For mail from billing.example.com, inspect the TXT response at _dmarc.billing.example.com. Preserve the query name, response, lookup time, and resolver context.
3. Validate the record. Check DMARC syntax, required tags, and whether the response contains conflicting DMARC records. A readable TXT answer is not sufficient evidence of a usable policy.
4. Check organizational-domain fallback. Under the RFC 7489 procedure, when no applicable exact-domain record exists, discover the organizational domain and evaluate its policy. Use sp for subdomains when present; otherwise use p.
5. Validate legitimate mail. Inspect authentication results and alignment for representative messages. Separate the requested disposition from the receiver's actual handling.
6. Assign the next action. Name the DNS owner, sending-platform owner, and person responsible for reviewing reports. Agree on the intended outcome before changing enforcement.

This produces a bounded finding: the policy observed, the domain affected, the evidence reviewed, and the remaining unknowns. It does not establish that the client has experienced impersonation or compromise.

Why This Matters

A parent domain can request rejection for its own mail while requesting monitoring for subdomains. A subdomain can also publish its own policy that differs from the organizational-domain record. Reading only the parent record misses both distinctions.

The review must establish which policy applies before judging whether that policy matches the client's intent. For a 2026 client evidence packet, retain the raw response alongside the explanation so another practitioner can reproduce the interpretation.

A permissive result is a discovery question. Ask whether it supports a documented sending requirement, a migration, or an unfinished enforcement plan. The DNS response alone cannot establish which explanation is correct.

How p and sp Affect Subdomain Policy

The p tag states the domain owner's requested policy. The sp tag specifies the requested policy for subdomains when the organizational-domain record supplies the applicable policy. If sp is absent, the organizational domain's p value applies to those subdomains.

The following records are illustrative configurations, not observations from a client scan. They show policy discovery under RFC 7489 rather than guaranteed mailbox outcomes.

There are 3 policy values in this baseline: none, quarantine, and reject. Their presence is evidence of a request, not proof that every receiver will apply that disposition.

p=none: Monitoring Before Enforcement

A none policy requests no specific delivery action based on DMARC failure. It supports observation while the owner identifies senders and checks alignment. Report receipt also depends on report configuration and participating receivers.

The trade-off is explicit: monitoring does not request quarantine or rejection for failing messages. Document whether that is intended rather than labeling the domain compromised or the work unfinished.

p=quarantine: Requesting Suspicious Handling

A quarantine policy asks receivers to treat failing mail as suspicious. That can support an enforcement transition after legitimate senders have been reviewed. Receivers retain discretion over handling.

The constraint is sender readiness. A legitimate message that fails alignment can be affected, so the recommendation needs message evidence and an accountable sending-platform owner.

p=reject: Requesting Rejection

A reject policy asks receivers to reject messages that fail DMARC. It suits domains whose owners have validated legitimate sending paths and approved that outcome.

It does not establish complete email security. Lookalike domains, compromised legitimate accounts, and messages that pass authentication require separate analysis.

Check Authentication and Alignment Separately

DMARC evaluates 2 authentication mechanisms, SPF and DKIM. A message needs 1 aligned authentication pass through either mechanism to pass DMARC. An SPF or DKIM pass without the required alignment does not satisfy that condition.

SPF evaluates the envelope sender domain, with HELO used in the relevant empty-envelope case. DKIM authenticates a signing domain identified by d=. DMARC compares the relevant authenticated domain with the visible From domain under the configured alignment mode.

Relaxed alignment permits organizational-domain matching. Strict alignment requires an exact domain match. The aspf and adkim tags control those modes; their defaults are relaxed under RFC 7489.

For each legitimate sending service, preserve a representative header and record which mechanism supplied the aligned pass. Keep that message evidence separate from DNS evidence collected during the 2026 review. A valid policy record cannot show that a billing platform actually signs its outgoing mail correctly.

Forwarding adds another boundary. SPF can fail after forwarding, while an intact, aligned DKIM signature can still provide a DMARC pass. Avoid treating one forwarded-message result as a complete assessment of the original sending service.

Why DMARC Subdomain Policy Results Vary

Different results need explanation at the domain and message level. These factors change the applicable policy or its practical interpretation:

• An exact subdomain record can replace the policy that would otherwise be inherited.
• The organizational record's sp value can differ from its p value.
• Missing sp makes the organizational record's p relevant to subdomain fallback.
• Alignment mode changes whether authenticated domains match the visible From domain sufficiently.
• Authorized services can use different envelope sender and DKIM signing domains.
• Receiver handling can differ from the domain owner's requested disposition.

Nested subdomains deserve particular care. Under RFC 7489 policy discovery, an evaluator checks the exact From domain and then the organizational domain where fallback is required. It does not walk every intermediate parent looking for the nearest DMARC record.

For example, a record at _dmarc.sales.example.com should not automatically be treated as the inherited policy for alerts.sales.example.com. State the discovery method instead of describing DMARC inheritance as ordinary DNS-tree inheritance.

Turn the Finding Into Evidence, Insight, and Proof

A useful client explanation connects a reproducible observation to a decision. Use the following sequence for your 2026 evidence packet, preserving the distinction between what DNS shows and what the client confirms.

Observed

State the condition with its check name, affected domain, lookup timestamp, and raw response. Identify whether the policy came from the exact domain or organizational-domain fallback. Use Observed for a readable public DNS result; keep Unreadable separate when the evidence cannot be interpreted.

Possible Consequence

Explain the requested handling and its boundary. For a monitoring policy, say that the policy does not request quarantine or rejection on DMARC failure. Keep compromise, message volume, business impact, and the client's intentions unknown unless separate evidence establishes them.

Ask

Name the owner and offer the next choice. Ask who operates the sending service, who reviews aggregate reports, and whether the policy matches the approved sending plan. Offer an authorized sender review before recommending an enforcement change.

Verify

Pin the original observation as the baseline. After an approved change, repeat the DNS check and review representative mail again. Proof is the documented difference against that baseline, with remaining coverage gaps retained.

Keep the client-facing recommendation independent of a vendor purchase. The agreed outcome might require a DNS change, sending-platform configuration, report review, further investigation, or no change. The MSP owns that judgment.

Keep Public DNS and Microsoft 365 Evidence Separate

A public DMARC lookup establishes what the queried DNS source returned at the recorded time. It cannot establish Conditional Access coverage, tenant application permissions, license assignments, device state, or tenant sharing configuration.

Customer-authorized Microsoft 365 review addresses a different evidence scope. SCOUTz limits that evidence to configuration and metadata, excluding mail, files, chats, documents, and prompts. Neither evidence source substitutes for validating the client's actual sending requirements.

SCOUTz is best for MSPs preparing sales conversations with dated cybersecurity evidence and account context. Its cybersecurity prospect intelligence supports preparation; the relationship and sale stay with the MSP. Public-domain observations belong beside clearly labeled unknowns, not speculative breach claims.

For the next step, choose Join Open Beta through SCOUTz. Confirm the scope against the intended review before proceeding. Deterministic checks establish findings; a person signs off on the client-facing claim.

Does an Explicit Subdomain Record Override sp?

An explicit, valid DMARC record at the exact From domain supplies that domain's policy instead of organizational-domain sp fallback. Preserve both records when explaining an exception so the client can see why the result differs from the parent policy.

Do not generalize that exception to sibling domains. Each sending domain needs its own discovery result.

Does a Missing Subdomain Record Mean DMARC Is Missing?

A missing exact-domain record does not establish that DMARC is missing. Under RFC 7489, organizational-domain fallback can supply the applicable policy through sp or, when sp is absent, p.

A failed or unreadable lookup is a different evidence state. Record the lookup failure and leave the policy unresolved until the evidence supports an interpretation.

Should an MSP Change Every Subdomain to Reject?

An MSP should recommend rejection only after establishing the intended outcome and validating legitimate sending paths. The word reject in DNS is not evidence that the client has reviewed every authorized sender.

Prioritize domains with a known owner and a testable change plan. Keep unreviewed domains explicitly unassessed rather than treating the absence of reported trouble as validation.

FAQ

One Last Thing

An unused subdomain and an unreviewed subdomain are different conditions. Before recommending a restrictive policy, identify who can authorize sending from that domain and how a future service would enter the approval process.

Make sender ownership part of the handoff. A dated DNS result explains the current observation; an accountable owner helps keep later changes deliberate.

Related Guides

• Review Dangling DNS Records Without Claiming a Takeover
• Build a Domain-Scan Evidence Packet for the First Call
• Explain Security Findings to a Nontechnical MSP Buyer