Review the control, not just the current record
A quarterly email-authentication review should answer whether the organization still knows who sends for its domains, why those senders are authorized and how it would recover from an unsafe change. A green dashboard cannot answer those ownership questions. Treat the quarter as a decision point with a defined evidence window, responsible reviewer and list of unresolved risks.
Quarterly is the proposed operating cadence here, not an interval mandated by DMARC. This documentary workflow uses RFC 9989 and RFC 9990, published in May 2026, alongside NIST configuration-control guidance reviewed on 8 November 2026. It does not establish which protocol revision a particular receiver or reporting product implements. No customer review, DNS query, message test or approval has been performed.
Establish the review population and evidence cutoff
Start from the domain and service inventory, not only the domains that happen to appear in the reporting tool. Include active sending domains, delegated subdomains, recently acquired brands and domains classified as non-sending. Mark the classification and owner of each entry. A domain omitted from telemetry is not automatically unused, protected or outside the organization's responsibility.
For each important business flow, identify the application owner, sending provider, visible author domain, expected signing domain and envelope-sender domain. Separate the provider's technical operator from the business person who can confirm that the service remains necessary. Record departures, outsourcing changes and contracts approaching termination as review inputs, without assuming they authorize removal.
Define the reporting interval and cutoff date. Distinguish absent reports, parser failures and genuinely low observed traffic. A quarterly sample should be appropriate to the business calendar: a payroll or renewal flow may be important despite being infrequent. Record known blind spots rather than claiming that one quiet week represents the whole quarter.
Compare effective state with the approved baseline
Collect a read-only baseline through already authorized sources. The proposed packet contains the exact DNS owner names and record types, observed values, query timestamps, observation points and the approved configuration against which they will be compared. Keep provider control-panel displays separate from authoritative and recursive answers. DNS authority and caching are different parts of the resolution process. RFC 1034
Review authentication results by service and identity, not merely an overall percentage. Under DMARC, an authenticated identifier supplied by SPF or DKIM must align with the author domain. A change to a return path or signing domain can therefore matter even if another authentication result still says pass. A DMARC pass is not a certification that the application is approved or its messages are wanted. RFC 9989
Reconcile reported observations with approved services and investigate mismatches. Aggregate reports are receiver observations grouped over an interval; they do not replace the organization's service inventory. Preserve reporting coverage and uncertainty alongside the result. Avoid treating the largest source-IP volume as the most important business risk. RFC 9990
Revisit ownership, access and exceptions
Ask whether each service approval still has an accountable owner and a current purpose. A familiar platform name can outlive the specific customer account that was approved. Escalate an unowned service for investigation instead of silently accepting it or deleting its DNS permissions.
Review who can edit the relevant zones, change sending identities, manage signing material and export evidence. Read access for the review must not become an implicit grant to change DNS or obtain credentials. Record suspected excess access as a finding with an owner. Any access removal, credential operation or external evidence sharing needs a separate human decision and authorized execution.
For each exception, preserve the reason, affected flow, compensating measure, approving person and next decision date. Check whether the original condition still exists. An overdue exception is a decision to escalate, not a reason to automatically impose enforcement on a business-critical flow.
Turn findings into bounded change proposals
Classify findings as a documented no-change conclusion, a request for more evidence, or a proposed correction. NIST SP 800-53 Rev. 5 CM-3 supports documented review and approval of controlled changes. The cited PDF includes the December 2020 updates; the publication page announces Release 5.2.0. This guide uses the identified control, not a claim of organization-wide NIST compliance. NIST control catalogue
A proposed correction should specify the domain, exact existing and intended record set, affected business flows, prerequisites and rollback conditions. Separate the authority to recommend from the authority to approve and execute. If the observed baseline changes before execution, stop and reconcile the proposal instead of applying an old diff to a new state.
Consider this fictional review example: a renewal-mail service remains active, but its named owner has left. The proposed outcome is to identify a replacement owner and verify the service's configured identities before deciding whether any DNS change is needed. It is not evidence that an actual service was reviewed or that removing an SPF dependency would be safe.
Close decisions and retain verification gaps
The review can close with approved follow-up work still pending, provided the record distinguishes the review decision from implementation. Give each unresolved finding a responsible person, next action and escalation condition. Do not label a planned rollback or test as completed evidence.
After a separately authorized change, acceptance should combine observed DNS state with relevant message evidence and the business owner's confirmation. The change owner should retain what happened, not only what was requested. A successful lookup alone does not establish delivery for all recipients, and a single successful message does not erase a coverage gap.
The next review should begin with those outstanding decisions and the last verified baseline. This creates continuity without treating quarterly paperwork as a substitute for monitoring between reviews. A new service, unexpected DNS change or material authentication failure can warrant an earlier review.
Required original evidence: A change record with baseline, intended diff, business sign-off, verification and rollback criteria. That commissioning gate remains open; the fictional example and proposed review packet do not supply an executed change record.