A useful observation period ends when the team has enough evidence to make a particular policy decision. The calendar helps organise that work, but it cannot tell you whether the payroll system, disaster-recovery service or annual renewal process has been tested.
Start with the proposed change and the mail it could affect. Then identify what the current evidence covers, what it misses and who will resolve each gap. A policy decision is easier to defend when it names those boundaries.
Build the calendar from the business
List sending events rather than choosing a standard number of days. Interview finance, customer support, HR, marketing and application owners. Include unusual routes: a backup region, a manual invoice run, a delegated mailbox or a supplier's emergency notification process.
For each event, record its expected frequency, service account, visible From domain, route and owner. Use the sender inventory to keep these details attached to a service instead of an unexplained source IP.
An application can be operationally important while sending very little mail. Volume should influence investigation priority, but it should not decide which services deserve verification.
Mark observed, tested and unknown separately
An observed report row and a controlled message test answer different questions. Under RFC 9990 §3.1 and RFC 9989 §5.3.8, reports show what participating receivers recorded during their reporting periods. A test can examine a specific service and its identities, even when its usual business event has not occurred.
Keep three evidence states:
- State: Observed and tested; Meaning: A named route has report evidence and a representative received-message check; Next step: Retain the evidence and monitor changes
- State: Tested, not yet observed in routine use; Meaning: A controlled run worked, but a periodic business event remains outstanding; Next step: Confirm the test represents that production path
- State: Unknown or unresolved; Meaning: Ownership, route or authentication is not established; Next step: Investigate before treating the service as ready
This is a suggested working matrix, not a protocol reporting format. It prevents a test result from silently becoming proof of every future delivery path.
Use a coverage example, not a countdown
Consider this fictional company planning a change for its billing domain:
- Flow: Invoice receipts; Normal cadence: Daily; Evidence after ten days: Routine reports and a verified received example
- Flow: Payment-failure notices; Normal cadence: Event driven; Evidence after ten days: Controlled test through the production sending route
- Flow: Monthly statements; Normal cadence: Monthly; Evidence after ten days: No representative run yet
- Flow: Recovery-region messages; Normal cadence: Only during failover; Evidence after ten days: Configuration known; failover route untested
Ten healthy days cover the first flow well. They do not answer the last two rows. Extending the calendar without an investigation plan may still leave the recovery region untested.
The team could arrange a safe statement test and a documented recovery exercise, then determine whether those tests adequately represent the missing production events. If a test would disrupt customers, record the limitation and choose a later decision point. The outcome should be an explicit coverage judgment.
Apply the standards guidance to the right domain
RFC 9989 RFC 9989 §5.1.7 explains that sending cadence can require many months of report consumption before its owner is confident about authentication. It also advises against reject for domains whose users may post to Internet mailing lists.
For those domains nevertheless considering reject, The guidance in RFC 9989 §7.4 recommends at least a month at none, followed by an equally long period at quarantine, with comparison of message dispositions. That is specific interoperability guidance, not a universal two-month approval rule. Completing those periods does not establish that every legitimate route is safe.
A controlled transactional domain and an employee correspondence domain need different assessments. Choose the policy for the domain's actual use, including indirect delivery, rather than making reject the automatic destination of every monitoring project.
Inspect the denominator behind a pass rate
A high pass rate can be dominated by one healthy service. Ask which receivers contributed reports, which periods are represented and whether important senders appear.
Aggregate reporting is not a complete log of all mail sent. Receiver participation, report delivery and processing affect the evidence available. Use the aggregate-report guide to separate raw authentication, alignment, policy handling and missing coverage.
Likewise, an unknown source is not automatically malicious. Preserve uncertainty until ownership and supporting evidence justify a conclusion. Do not improve a readiness percentage by simply relabelling unexplained failures.
Set a decision gate and a review date
Before changing policy, require named owners for critical services, representative identity evidence, resolved consequential failures and an assessment of indirect routes. Confirm the reporting collection path and a practical recovery procedure.
Under RFC 9989 §5.3.5, a message evaluated under an applicable policy can pass DMARC through one passing aligned authentication path. That does not replace the broader full-participation requirements in RFC 9989 §8, which include aligned SPF and DKIM, reporting and policy publication. Under RFC 9989 §7.4, domains using reject must not depend solely on SPF and must apply valid DKIM signatures.
If the evidence is incomplete, name the missing test and set a date for completing it. If a known limitation is accepted, identify the accountable decision maker and the affected workflow. “Wait another week” is useful only when that week is expected to produce specific evidence.
Keep the observation record alive
After a policy change, watch the services and receivers relevant to the decision, investigate new failures and retain the configuration timeline. A new supplier, key change or gateway can invalidate an earlier assumption.
The useful observation period is therefore tied to a documented question: have we seen and verified the legitimate flows that this change could affect, and do we understand the remaining uncertainty? When the answer changes, reopen the decision rather than relying on an old date.
Record a decision that can be reviewed
For the ten-day fixture, label the monthly-statement and recovery-region rows unresolved. A further week only helps if it yields a specified event or test; a planned exercise is not evidence it succeeded. The case supports coverage planning rather than a universal waiting period. No monitoring period, failover exercise or message test was performed.