An exception register should explain why a control differs from the desired state and what will end that difference. A list of domains marked exempt is not enough. Link each exception to a business service, accountable owner, bounded scope, review date and evidence-based closure test.
Record the actual exception
Describe the intended control, current deviation and business reason. Record the relevant From, envelope and signing identities, affected provider or tenant, criticality, approval and expiry. Distinguish a broad policy relaxation from a narrow unresolved sender route. DMARC alignment can succeed through an aligned successful SPF or DKIM result, so the practical exception may be different from the team's initial diagnosis. Separately, RFC 9989 sections 7.4 and 8 require p=reject domains to apply valid DKIM signatures and not rely solely on SPF. A message-level pass does not waive that deployment obligation. RFC 9989.
Include compensating safeguards and their limits. For example, a business verification process may reduce payment risk but does not make an unauthenticated message authenticated. Do not describe a monitoring subscription or dashboard as proof that the exception is safe. Preserve the evidence supporting the approval and keep unnecessary message data out of the register.
Define expiry as a decision point
Set a review date and an expiry with a named escalation owner. Expiry should trigger an explicit decision: close, renew with new evidence, or escalate. It should not silently delete DNS permissions or interrupt critical mail. A renewal must revisit the reason and scope instead of copying the previous approval indefinitely.
Use a concrete closure test. A legacy relay exception might close after the replacement route has been tested for authentication and business receipt, the old service has been confirmed unused across the relevant cycle and the approved removal has been verified. Aggregate reporting can support this assessment but silence in an incomplete reporting population cannot establish non-use. RFC 9990.
Compare three exceptions at a declared review date
At a hypothetical review on 8 November 2026, EX-01 is a payroll transition with a named owner and a replacement test still requiring verification. EX-02 is an inherited route with no current owner and an expiry of 1 November 2026. EX-03 is a quarterly campaign whose next scheduled use has not yet been observed. EX-02 is overdue by seven calendar days under those stated dates; that arithmetic does not approve renewal or removal.
The next actions differ: obtain the payroll replacement evidence, assign the inherited route’s decision owner, and plan an authorized campaign-cycle check. Zero observations for EX-02 do not fill its ownership or coverage gaps. These are invented register entries and hand-worked date reasoning, not an executed program, risk acceptance or live mail test. Record the exact affected permission and identities before any real decision.
Review the register as an operating queue
Sort by business consequence, overdue status and missing ownership, not merely age. Assign a next action and due date to each unresolved item. Preserve the original reason and later changes so reviewers can distinguish a still-valid constraint from a forgotten workaround.
Measure overdue exceptions, unowned exceptions and closure progress using a defined population. Do not claim a compliance conclusion from those counts alone. A useful monthly review identifies which decisions were made, which evidence changed and where an owner still needs to act. Retain the closed record and its verification evidence rather than erasing history.
Turn the review into a decision queue
For each overdue or approaching-expiry entry, record the specific evidence needed, decision owner and next action. Keep overdue approval, unresolved ownership and a technical test failure as distinct findings so the next reviewer knows what to resolve.