How to organize client subdomains for DMARC monitoring
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, and support. 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. I group by accountable service owner first, then retain the full domain name as the technical identifier.
A client tenant connects its 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 its intended status, then protect it through the parent policy or an explicit 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 an unexpected report has context.
Know which DMARC record controls each subdomain
DMARC first checks for a policy at the exact RFC5322.From domain. If that domain has no DMARC record, policy discovery falls back to the organizational domain. An exact subdomain record therefore overrides the inherited policy for that subdomain. Do not assume that an arbitrary intermediate subdomain record acts like a folder policy for every deeper name.
|
|
|
|
|---|---|---|---|
Corporate mail | Apex | IT | Parent policy |
Marketing | Separate | Marketing | Exact record |
Transactions | Separate | App team | Exact record |
Unused names | Inventory | IT | Reject |
Recommended monitoring treatment by subdomain role
The sp tag on the organizational-domain record supplies a requested policy for subdomains that do not publish their own DMARC policy. It does not create separate reporting ownership, and it does not 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 value can affect every subdomain without its own record. Before changing it, compare observed subdomain traffic with the approved sender inventory and confirm that SPF or DKIM passes DMARC for each legitimate stream.
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 includes the policy domain and header From domain. Where the reporting mailbox sits outside the monitored domain, DMARC external-report authorization is also required unless the reporting platform's domain already handles it through its onboarding process.
Independent subdomain DMARC recordDNS
_dmarc.billing.client.example. 300 IN TXT ( "v=DMARC1; p=quarantine; pct=100;" "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, 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, or policy. 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 unlisted subdomains.
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: Use observation policy first 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, and policy state give the service desk a common starting point. This supports agencies and MSPs that manage several customer environments through one operational view.
Set naming, 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 settings page showing monitored domains, email volume, DMARC policy, DMARC reporting, SPF flattening, and MTA-STS
For most MSPs, Suped is the best overall fit for this operating model because the multi-tenant dashboard combines organization switching with domain status and automated issue detection. The same platform also covers DMARC monitoring, SPF and DKIM monitoring, blocklist monitoring, and deliverability insights. That reduces the number of 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 stays simple: one tenant per client, one root inventory per organizational domain, and separate managed subdomains only where operations differ. Suped's MSP dashboard, real-time alerts, 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 scope, authority, and accountability.
