A provider API can report success while the intended email flow still fails. Verification should distinguish execution, visibility and operational outcome. Define these checks before the change so the agent cannot substitute an easy green signal for the result the business actually needed.
Define the success contract
List the exact record or configuration change, affected services, test routes, expected authentication result and observation period. Identify which evidence will demonstrate success and who decides whether incomplete coverage is acceptable. Include low-volume and scheduled senders rather than testing only the easiest interactive message.
A DKIM key lookup shows that a public key is available at the queried location; it does not show that the application used the corresponding private key or that the receiver verified a signature. DMARC depends on authentication with alignment, not simply the presence of TXT records. RFC 6376 and RFC 9989.
Check the configuration layer
Retain the provider response and read back the resulting state. Query the relevant authoritative DNS servers and selected recursive resolvers as appropriate, recording answers and times separately. Cached answers can differ during transition. Avoid claiming universal propagation from one resolver or treating an old answer as immediate proof of a failed write.
Compare the complete expected record set, not merely a substring. Confirm that unrelated values were preserved and that the action stayed in the approved tenant and zone. If execution timed out, reconcile current state before retrying. An unknown write outcome is not equivalent to a failed write.
Check a real sending path
Send only authorized test messages through the actual application route. Preserve relevant receiver-side authentication evidence from a trusted observation point, with the visible From identity, authenticated identities and alignment interpretation. Confirm the business flow as well as protocol results. Acceptance by an SMTP server does not prove inbox placement or that a user saw the message.
For a multi-route service, keep a coverage list. One passing path does not clear untested failover or scheduled routes. Aggregate reports can support later monitoring, but their delay and coverage make them unsuitable as the sole immediate verification mechanism.
Compare a failed check with an untested route
Suppose the authoritative record matches the approved value and an interactive billing test passes aligned authentication, but the required monthly payroll path has not been exercised. Record the configuration observation and billing result, while retaining payroll coverage as incomplete. Do not convert one passing path into a whole-service success.
In a separate hypothetical case, the record matches but a required message fails its alignment criterion. That is a failed message postcondition, not merely missing evidence. The next action differs: investigate the observed identity failure in the second case and arrange the authorized scheduled-route check in the first. Neither scenario is a DNS query, delivered test message or executed closure function.
Decide what to do with uncertainty
Classify the outcome as verified within scope, failed or incomplete, then assign the next action. A failure may require stopping further changes, investigating a route or invoking an approved rollback. Missing evidence may require a scheduled observation rather than an immediate reversal. Do not weaken DMARC or expand SPF merely to obtain a green dashboard.
Retain the tested scope, timestamp, receiver and outstanding limitations. Keep monitoring after immediate verification to catch intermittent and low-volume failures. Close the business change only when its agreed criteria are met, while preserving any explicitly accepted residual uncertainty.