Why a parent DMARC record does not replace a sender inventory

A parent DMARC policy can establish how receivers should handle some subdomain mail that fails authentication. It cannot tell you which application sends that mail, who approved it, or whether a critical notification service still works. Those questions require a sender inventory tied to received-message evidence.

The distinction matters during enforcement. A DNS check may show a protective policy at the organisation's main domain while an old campaign platform uses an explicit child policy, a subsidiary controls its own namespace, or a password-reset service authenticates with an unrelated vendor identity. The record and the inventory answer different questions.

Start with the domain the recipient sees

For each business workflow, capture the domain in the message's From address. Do not substitute the website domain, the account's login domain or the mail provider's brand name. Then identify the applicable policy, the SPF-evaluated identity and the DKIM signing domain or domains.

Under current DMARC discovery, an applicable record found specifically for the Author Domain takes precedence over fallback to the organisational domain or public suffix. The current specification uses a DNS tree walk. An immediate parent is not automatically the applicable organisational boundary. See RFC 9989 §4.10.1.

Your inventory should therefore record the discovered policy domain, not merely a checkbox labelled “covered by parent”. Also record the receiver or evaluator used and the test date. Older implementations may use legacy discovery behaviour, so a documentary calculation does not establish universal deployment.

Compare three subdomain cases

The following is a synthetic illustration, not an observed customer configuration. Assume example.com is the organisational domain, discovery selects its record when no child record exists, and its record contains p=reject; sp=quarantine; np=reject. The version tag is omitted from this sentence only for readability; a real policy record must start with v=DMARC1.

• Author Domain case: Existing billing.example.com, with no explicit DMARC record; Applicable policy in this example: Parent sp=quarantine for failing mail; What the inventory must still establish: Which billing workflow sends, its owner, and a received message's aligned authentication result
• Author Domain case: Non-existent unused.example.com, with no explicit policy; Applicable policy in this example: Parent np=reject for failing mail; What the inventory must still establish: Whether it truly does not exist in DNS and whether any legitimate workflow unexpectedly uses it
• Author Domain case: Existing news.example.com, with its own v=DMARC1; p=none record; Applicable policy in this example: The explicit child p=none policy; What the inventory must still establish: Who owns that exception, why it exists and when it will be reassessed

In all three cases, a passing aligned identity can produce DMARC pass. The policy column describes requested handling of failure, not a command to reject every message from the domain. Receiver decisions remain separate under RFC 9989 §5.4. The sp and np selection rules are specified in RFC 9989, section 4.10.1.

A delegated DNS zone is another inventory item, not proof of an explicit DMARC policy. Record who controls it and test discovery from its actual Author Domains. Do not infer organisational boundaries from your company chart.

Connect every sender to a business owner

Build one row per meaningful sending workflow. A single application may need separate rows for campaigns, transactional notifications and employee-triggered messages if they use different identities or routes.

At minimum, keep the workflow, accountable owner, Author Domain, envelope domain, signing domain and selector, sending service, applicable policy, last test and retirement condition. Add the evidence location and any unresolved issue. A named provider without an identified customer account or business owner remains an investigation lead, not approved sending authority.

Use aggregate reports to find observed traffic and compare it with that register. Under RFC 9990 §3.1 and RFC 9989 §5.3.8, reports describe traffic seen by participating receivers; absence from a report is not proof that a monthly or rarely used workflow does not exist. Ask application owners to exercise password resets, receipts, alerts and scheduled jobs deliberately.

Change policy against the inventory

Before changing the parent policy, identify the rows that will inherit the change and the rows with independent child policy. Assign testing to their owners. A safe review asks whether legitimate mail remains authenticated and aligned, whether exceptions are justified, and whether recovery can be restricted to the affected workflow.

Avoid weakening the parent policy simply because one application's configuration is incomplete. First establish whether the service can use a supported aligned signing domain. If an exception is necessary, document its scope, approver, expiry and verification plan. Treat that as an explicit risk decision rather than quietly hiding the sender from the inventory.

After the change, compare new message results and reports with the pre-change rows. Keep the policy diff and the evidence together. Close the change only when the affected business owners confirm their real workflows and unresolved senders have a named next action.

Keep policy coverage and sender coverage separate

A useful dashboard has two measures: domains with a verified applicable policy, and business sending workflows with a current owner and tested aligned route. Improving one does not automatically improve the other. Use the sender inventory guide for the operational register and the subdomain policy guide for discovery details.

Make the next decision explicit

For the three-domain fixture, group billing under the inherited sp policy, unused under the assumed applicable np policy, and news under its explicit p policy. A parent sp change should not be described as changing the explicit news policy. Keep each workflow owner and evidence gap separate. This is a consequence of the stated discovery assumptions, not a live tree walk or approval to change policy.