An implementation is not finished when the DNS change is complete. The receiving team needs to know which domains and senders are covered, which exceptions remain and what to do when evidence stops arriving. Make handover an acceptance decision with named owners rather than an email announcing that setup is done.
Assemble the operating baseline
Record the customer tenant, domain inventory, DNS operator, approved senders, current authentication configuration and last verified message tests. For each important stream, retain the sending service, expected signing and envelope identities, business owner and test date. Keep private keys and credentials outside the handover pack. Link to approved access procedures instead.
RFC 9989 describes DMARC evaluation through authenticated identifiers aligned with the author domain. A DNS screenshot alone cannot establish that the actual billing stream passes alignment. Include representative message evidence and identify what remains untested, such as a seasonal sender that did not run during implementation.
Agree the service boundary
Identify who reviews reports, investigates failures, contacts sender owners, approves DNS changes and performs them. The monitor may investigate without having authority to change production. State coverage hours and escalation contacts in the customer agreement. Distinguish acknowledgement, investigation and resolution: an MSP cannot promise when an unrelated receiving system will recover.
Treat reporting availability separately from mail delivery. RFC 9990 defines aggregate reporting, not a complete census of all messages sent. A quiet dashboard may mean low traffic, delayed reports or a broken collector. Establish expected report sources from observed history without treating that history as a guarantee that every receiver reports.
Run the handover drill
Walk through one failed approved sender, one missing reporting period and one unauthorized change request. Ask the receiving operator to identify the right evidence, contact and next action without the implementation engineer guiding each step. Store the result with the accepted runbook revision. If the escalation number or evidence location is wrong, keep the handover open and repair it.
Suppose the operating baseline is documented and the billing route passes its authorized test, but the receiving monitor cannot access the retained evidence and has not accepted ownership. Keep handover open. Repair the access path within the approved scope and have the receiving operator repeat the drill rather than declaring readiness from the implementation engineer’s success.
In a separate hypothetical case, the monitor accepts its duties but a seasonal critical sender remains untested. Transfer that gap with a service owner, review date and explicit acceptance decision; do not relabel it as passed. These are assumed handover conditions, not an executed lifecycle function, actual test receipt or customer acceptance.
Close implementation without losing exceptions
Transfer every exception with an owner, reason, review date and safe next step. Do not hide failed tests inside a successful project status. The customer owner accepts residual risk; the monitor accepts operational responsibility; the DNS operator accepts only the permissions actually granted. Review access after the transfer and remove implementation-only privileges when approved.
Schedule the first operating review before closing the project. Compare newly observed senders against the baseline and investigate gaps. If monitoring is not staffed or the customer cannot approve urgent changes, escalate the service gap explicitly. Recovery means keeping the previous accountable owner engaged or narrowing the service commitment until the receiving team can perform it.