How to organize client subdomains for DMARC monitoring
Updated on 20 Sep 2026: We updated this guide for RFC 9989 policy discovery and safer subdomain operations for MSPs.
Organize each client as its own tenant, keep the organizational domain as the primary monitoring object, and add a subdomain as a separate managed object only when it sends mail, has a distinct owner, or needs an independent DMARC policy. This keeps client data isolated while preserving a clear link between every sending subdomain and the client that owns it.
A useful default is one client organization, one apex domain inventory, and a child register for active mail streams such as marketing, billing, support, and account notices. The register should record business owner, sending service, SPF and DKIM status, DMARC policy, report destination, change authority, and last review date. Do not create separate monitoring entries for every hostname simply because it exists in DNS.
For an MSP, the hierarchy has to work operationally. A technician should be able to identify the client and owner from an alert, find the approved sender behind the traffic, and know whether the MSP can change DNS without reopening discovery. Our DMARC for MSPs workflow uses this separation so cross-client reporting and client-specific remediation remain manageable.
Start with client boundaries, not DNS depth
DNS can contain several levels, but those levels do not automatically describe ownership. mail.eu.client.example might belong to the corporate messaging team, while offers.client.example belongs to marketing and invoices.client.example belongs to a finance platform. Group by accountable service owner first, then retain the full domain name as the technical identifier.
MSP client tenant hierarchy connecting an apex domain and sending subdomains to service owners.
- Client tenant: Use one isolated organization for each contracted client, including its users, alerts, reports, and access roles.
- Apex domain: Treat the organizational domain as the root inventory item and record its DMARC policy and subdomain policy.
- Sending subdomain: Track each active RFC5322.From domain that has separate traffic, ownership, or enforcement needs.
- Non-sending subdomain: Record whether the name exists, then protect it through the applicable parent policy or an exact reject record when needed.
This model also prevents duplicate investigation. If a client has ten web subdomains but only two appear in the visible From address of legitimate email, the service scope usually needs two active mail-stream records, not ten monitoring projects. Keep the other names in the inventory so unexpected traffic has context and can be checked for shadow IT or unauthorized use.
Know which DMARC policy controls each subdomain
DMARC first checks for a policy at the exact RFC5322.From domain, called the Author Domain in RFC 9989. If that domain has no valid DMARC record, current policy discovery uses a bounded DNS Tree Walk to determine the organizational domain or Public Suffix Domain and select the applicable record. An exact Author Domain record still takes priority, but an intermediate record can affect discovery when its psd tag defines an organizational boundary.
|
|
|
|
|---|---|---|---|
Corporate mail | Apex | IT | Parent policy |
Marketing | Separate | Marketing | Exact record |
Transactions | Separate | App team | Exact record |
Unused names | Inventory | IT | Inherited or np policy |
Recommended monitoring treatment by subdomain role
The sp tag on the organizational-domain record supplies the requested policy for existing subdomains that do not publish their own DMARC policy. Under RFC 9989, np can set a separate policy for non-existent subdomains. If np is absent, those names use sp when present, then p. These tags do not create separate reporting ownership or replace source discovery. Aggregate reports still need to be parsed by the evaluated header From domain so the MSP can route work to the correct client service owner.
Watch the inherited policy
Publishing a stricter sp or np value can affect many names without exact records. Before changing either value, compare observed subdomain traffic with the approved sender inventory and confirm that SPF or DKIM passes DMARC for each legitimate stream.
Policy inheritance does not determine whether a message passes DMARC. A message passes when SPF or DKIM passes and the authenticated identifier aligns with the Author Domain. Store the SPF MailFrom domain and DKIM signing domain for each sender so an inherited policy does not hide an alignment gap.
Plan for RFC 9989 adoption
RFC 9989 was published as the standards-track DMARC specification in May 2026 and obsoleted RFC 7489 and RFC 9091. It replaces Public Suffix List-based organizational-domain discovery with a bounded DNS Tree Walk. It also adds np for non-existent subdomains and psd for organizational or public-suffix boundaries, while t replaces the removed pct tag as the testing signal. A t=y value requests test mode for an enforcement policy, but it does not change report generation or affect a none policy.
- Map the boundary: Confirm the organizational domain for each client and document private suffix arrangements that need psd=n.
- Separate name states: Use sp for existing subdomains and consider np for names that do not exist and should not send.
- Retire pct: Remove pct from managed templates and stage enforcement with exact policies, observed evidence, client approvals, and rollback records.
- Track discovery: Retain whether reports identify legacy PSL or RFC 9989 tree-walk discovery when that field is available.
Receiver adoption will not switch at the same time everywhere. During migration, validate exact records at every active Author Domain that needs independent treatment and compare results across major receiver reports before closing a policy exception.
Design reporting addresses around the client hierarchy
Route aggregate reports into one MSP-managed reporting system, but preserve a unique association for each client domain. A provider-issued reporting address or token is safer than a shared mailbox because it reduces manual sorting and prevents one client's XML files from being attached to another client's record. The visible operating model should still map every report to tenant, domain, subdomain, and owner.
Organizational-domain DMARC recordDNS
_dmarc.client.example. 300 IN TXT ( "v=DMARC1; p=none; sp=none;" "rua=mailto:client@reports.msp.example" )
A separately governed sender can publish its own record and use the same reporting destination. Its reports remain distinguishable because each aggregate record identifies the policy domain and Author Domain. Under RFC 9990, external-report authorization is required when the organizational domain where the policy was discovered differs from the organizational domain of the rua destination, unless the reporting platform has already completed that DNS authorization during onboarding.
Independent subdomain DMARC recordDNS
_dmarc.billing.client.example. 300 IN TXT ( "v=DMARC1; p=quarantine;" "rua=mailto:client@reports.msp.example" )
Validate each published record after DNS propagation. The DMARC checker is useful for syntax and policy discovery checks, while the monitoring platform confirms whether reports arrive and whether legitimate sources pass DMARC. DNS validity alone does not prove that the service is operational.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Record the validation result in the client change ticket, including the queried name, returned policy, report destination, discovery method, and timestamp. This gives the service desk a defensible baseline when a later DNS change stops reports or changes enforcement.
Choose inheritance or explicit subdomain records
Inheritance works well when the client has one security owner, a consistent risk decision, and few active mail streams. Explicit records work better when a subdomain has a different rollout schedule, reporting owner, policy, or change path. Both approaches can exist within one client tenant without turning each subdomain into a separate client.
Use parent inheritance
Choose inheritance when the same team owns the apex domain and its subdomains, and all legitimate senders can move through one enforcement plan.
- Lower DNS overhead: Fewer records need change control.
- Broad protection: The sp policy covers existing subdomains, while np can cover non-existent names.
Use explicit records
Choose exact records when business units need separate policy staging or when a subdomain has a distinct sender inventory and change owner.
- Independent rollout: Policy can advance on its own schedule.
- Clear accountability: Alerts route to the responsible team.
Avoid copying identical records across dozens of subdomains without a reason. Each copy creates another change point and can drift away from the approved client policy. If a subdomain needs the same treatment as the parent, document the inheritance decision in the inventory instead of publishing redundant DNS.
Onboard subdomains with a repeatable MSP workflow
Start with the signed service scope and an inventory exported by the client. Then compare that inventory with DMARC aggregate data during observation. Unexpected subdomains should become investigation items, not automatically approved senders. A client owner has to confirm whether each stream is legitimate and who can authorize remediation.
- Create the tenant: Set client users, MSP roles, escalation contacts, and report recipients before adding domains.
- Add the apex: Capture the current DMARC record, organizational domain, policy, and DNS authority.
- Inventory mail streams: List active subdomains, DKIM signing domains, SPF paths, sending services, and owners.
- Publish reporting: Start in monitoring mode with p=none unless reliable evidence already supports enforcement.
- Review exceptions: Resolve unknown sources and record client acceptance for every approved exception.
- Stage enforcement: Advance policy per domain only after legitimate traffic consistently passes DMARC.
The domain inventory is the control record for the service. Our detailed client onboarding workflow covers the wider handoff, while subdomain organization determines how technicians filter reports and assign issues after launch.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Suped keeps client organizations separate and lets MSP operators switch among them without mixing domain ownership. Within a client organization, domain status, message volume, policy state, and issue status give the service desk a common starting point. This supports agencies and MSPs that manage several customer environments through one operational view.
Set ownership and alert rules
Use the real DNS name as the domain identifier and store friendly labels separately. A label such as 'Billing notifications' can change, while billing.client.example remains the object used in DMARC evaluation. Prefix internal ticket subjects with the client code and exact domain so alerts cannot be mistaken for another tenant.
|
|
|
|---|---|---|
Client code | ACME | Ticket routing |
Stream | Billing | Owner lookup |
Policy | Quarantine | Risk state |
DNS owner | Client IT | Change path |
Review | Monthly | Service cadence |
Compact fields for an MSP subdomain register
Alert on changes that need action: a new sending source, a sharp rise in failures, missing reports, a weakened policy, or altered DNS. Route the alert by client and service owner. A global queue without client metadata invites slow triage and accidental disclosure in forwarded tickets.
Domains page showing monitored domains, email volume, DMARC policy, DMARC reporting, SPF flattening, and MTA-STS
Suped's multi-tenant dashboard combines organization switching with domain status and automated issue detection for this operating model. Suped also covers DMARC monitoring, SPF and DKIM monitoring, blocklist (blacklist) monitoring, and deliverability insights. That reduces separate handoffs in a managed service without removing the need for documented client ownership.
Stage enforcement per client mail stream
Do not move every client subdomain to enforcement on the same date. A low-volume billing stream can hide a monthly sender that never appears during a short observation window. Review at least one complete business cycle when the sender cadence requires it, and require clear ownership before changing policy.
Operational gates for policy changes
Use evidence and ownership gates rather than a universal pass-rate target.
Observe
p=none
Inventory incomplete or unknown sources remain
Contain
quarantine
Approved senders pass DMARC and exceptions have owners
Enforce
reject
Legitimate traffic is validated after staged changes
If the parent uses sp=reject while a legitimate subdomain still needs observation, publish an exact p=none record at that subdomain during remediation. Treat it as a temporary exception with an owner and target review date. For controlled policy staging without repeated client DNS edits, hosted DMARC can give the MSP a managed change path after the client completes the initial DNS delegation.
Do not enforce an unknown inventory
A high aggregate pass rate can hide one small but essential sender. Approve policy changes by identified mail stream, not by a client-wide percentage alone. Keep rollback steps and the previous DNS value in the change record.
Keep the hierarchy useful after onboarding
A clean client hierarchy needs routine maintenance. Review newly observed header From domains, dormant subdomains, policy drift, report gaps, and ownership changes at the service cadence. Close entries only after confirming the stream has stopped and the remaining parent or exact policy still protects the name.
- Monthly review: Compare new sources and subdomains with approved client changes.
- Quarterly ownership: Confirm business owners, DNS contacts, and escalation paths.
- Policy audit: Check exact records, inherited policy, reporting addresses, and unexpected downgrades.
- Client report: Summarize protected domains, unresolved sources, policy changes, and agreed actions.
The strongest structure uses one tenant per client and one root inventory per organizational domain. Create separate managed subdomains only where operations differ. Suped's MSP dashboard, real-time alerts, policy views, issue detection, and tailored fix steps support that workflow, while hosted DMARC can reduce follow-up DNS coordination. The client register remains the source for service scope and change authority.
