A useful domain priority list tells you what to investigate or protect next and why. Begin with business purpose and the consequence of failure. A low-volume payroll domain can deserve attention before a busy newsletter domain, while a silent acquired domain may need ownership research before any restrictive change.
Build a service based register
Create one row for each domain and service relationship. Record purpose, accountable owner, sending and receiving use, critical business event, observed authentication identities, current policy, last test and evidence gaps. A domain can support several services, and a single service can use several domains. Preserve those relationships instead of compressing every finding into one domain badge.
Treat sending, receiving and visible From identity as separate questions. Null MX declares that a domain accepts no mail; it is not a sender-authentication policy. RFC 7505, sections 3 and 4. An organisation can need a restrictive DMARC policy for a domain that sends no approved mail, but classification requires checking the actual service inventory first.
Separate exposure from observed volume
DMARC aggregate reports describe observations made by reporting receivers. They do not provide a complete census of all messages, prove mailbox receipt or identify the business owner behind a source IP. Use their authentication and policy information alongside application logs, approved sender configurations and business interviews. RFC 9990. Missing reports are an evidence gap, not a zero-risk finding.
Give each service a documented impact rating and explain what would fail: payroll distribution, password recovery, a regulated notice or a routine campaign. Then consider unresolved sending authority, known failures and change readiness. Keep high impact and poor evidence visible as separate dimensions. A ranking model is an operational recommendation, not a probability estimate supplied by the DMARC standard.
Work through a bounded impact ordering
A hypothetical register contains four invented services. Payroll has impact 5 and twelve observed messages; the newsletter has impact 2 and ten thousand. Legacy has impact 3, no known owner and zero observed messages. A confirmed defensive registration has impact 1. Sorting by impact, then missing ownership for ties, produces payroll, legacy, newsletter and defensive registration.
This hand-worked ordering follows the stated rule, not a validated risk model or executed scoring program. The invented ratings show why volume alone can put a high-impact service too low. Legacy remains an ownership investigation, not a confirmed non-sending domain. A restrictive change should wait for sufficient classification and the required approval, even though investigation is urgent.
For a real register, use dated evidence, agree the rule with accountable owners and preserve the reason for each rating. Give each item a specific next action and acceptance condition: a payroll failure needs diagnosis, while missing legacy ownership needs attribution. Do not fabricate a precision score for uncertainty that has not been investigated.
Turn priorities into decisions
For the highest-priority service, name the next action, owner, due date and acceptance evidence. A payroll failure might need immediate diagnosis, while an unowned legacy domain needs inventory reconciliation. Do not respond to both findings with the same DNS change. DMARC alignment assesses authenticated domain relationships, not business approval or message safety. RFC 9989.
Review the queue after acquisitions, sender migrations and reporting interruptions. Preserve the prior ranking and reasons for changes. A useful completion statement says which services were tested, which uncertainty remains and who owns it. A high portfolio percentage without that context can hide the most consequential unfinished work.
Keep urgency and change readiness separate
An urgent unknown domain may require immediate attribution without being ready for enforcement. A known critical failure may need an approved repair now. Record those distinct next actions so a high ranking is not mistaken for a blanket DNS-change instruction.