Which domain and sending routes are in scope?
Start with the address your clients see, not the name of your subscription. Microsoft's documentation distinguishes its own onmicrosoft.com routing domains from a customer's custom domain. Ask which of your domains and subdomains actually send mail and who controls their public DNS records.
Then list the routes that bypass ordinary Outlook sending. An appointment system may send its own reminders. A website can produce form notifications. A marketing service may use a different infrastructure entirely. These are examples to check against your business, not assumptions that every organization has the same setup.
What should the administrator confirm about DKIM?
Microsoft's current custom-domain guidance requires two DKIM CNAME records and an enabled signing state. It introduced a changed target format for new custom domains in May 2025. Use the exact values shown for your domain in the supported administrator tools; do not construct them from an old tutorial or another company's example.
Ask for a dated note confirming the records, the signing state, and a test message from your custom domain. This is enough to make the work reviewable without asking anyone to export credentials or private signing material. Keep the note with the domain's other change records.
What belongs beside the Microsoft settings?
The sender inventory belongs beside them. Microsoft recommends reviewing non-Microsoft mail sources as part of authentication setup. A supplier's ability to send email is not the same as correct authentication using your visible business domain. Have the administrator identify how each approved service is configured and tested.
We recommend assigning one business owner to each service. That person can confirm whether it is still used and produce a harmless representative message. The technical administrator then interprets the result. This division avoids asking IT to guess which old marketing integration is still commercially important.
How should a change be handed over?
Request a short record with the domain, approved scope, before-and-after values, test results, and unresolved exceptions. Keep account protection separate: multi-factor authentication and administrator access controls address a different question from published sending policy. Neither workstream should disappear because the other received a passing result.
For a provider migration or a new bulk sender, agree the test plan before the cutover. Name the messages the business cannot afford to overlook, the person who will check them, and the response if they fail. This is a practical preparation step, not a promise of uninterrupted delivery.
- Which custom domains and subdomains were checked?
- Are both Microsoft DKIM records present and signing verified?
- Which non-Microsoft senders were included?
- Who approves and records subsequent changes?
What should you send when requesting a review?
Send your business domain, say that you use Microsoft 365, and name the person who manages it. Include a list of sending tools if available. Do not send an administrator password, recovery code, private key, or customer message merely to begin a public-record review.