Handover that survives

The person who built the programme will move on and the estate will not. What survives that is a small amount of documentation of a specific kind — and it is not the assessment report.

The one document

Per domain:
   what it is for, and whether it should send mail
   its current DMARC policy, and the date it reached it
   every sender, and who inside the organisation owns it
   every DKIM selector, and which vendor it belongs to
   where its DNS is hosted, and where the registrar
     account is
   who to contact when it breaks

Per estate:
   the monitoring in place and where its alerts go
   the exclusions, and why
   the "not doing this, and why" list, with triggers

Everything there is a fact about ownership and intent, which is precisely what cannot be recovered from DNS. A successor can rebuild the technical picture in an afternoon with the assessment method; they cannot rediscover that a selector belongs to a vendor the marketing team pays for on a card.

What does not need documenting

Keeping it true

• Update it as part of the change, not afterwards. A new vendor is not onboarded until it has a row.
• Keep it where the work happens — in the repository or the ticket system rather than in a document nobody opens.
• Check it during the quarterly sweep. A selector in DNS with no row, or a row with no selector, is a finding in its own right.
• Keep it short enough to be read. A successor will read two pages and will not read forty.