When business email stops, the first useful question is not “Is email down?” It is “Which part of email is failing, for whom, and since when?” A clear answer reduces unnecessary changes and gives the team a reliable starting point. This checklist is designed for an administrator coordinating an incident, rather than for employees troubleshooting individual messages.
Define the affected service
Separate incoming delivery, outgoing submission, mailbox access and internal mail. A user who cannot open a mailbox may still be receiving messages. An application that cannot send may have a different problem from the organization’s incoming mail route. Record the earliest known failure, affected domains and one representative example for each symptom.
Assign one person to maintain the incident timeline. Record observations separately from assumptions: “The receiving server did not answer our test” is more useful than “DNS is broken” before DNS has been checked.
Preserve the current configuration
Save the active MX records, receiving destination and relevant service settings before changing anything. Record the previous values and the intended rollback. Changing DNS, a firewall rule and a destination at once makes it difficult to determine which action helped or introduced a new problem.
Check responsibility for waiting mail
Determine whether messages are still with senders, accepted into a gateway queue or already delivered to a mailbox system. These are different states. A backup queue can only protect messages it has accepted within its configured scope. Do not report every expected message as safely queued unless the records support that statement.
Review available queue age and delivery-attempt information. If the outage could approach the service retention limit, escalate early and agree on a receiving destination before making routing changes.
Communicate one confirmed status
Give staff a short update covering what is affected, what they should do and when the next update will arrive. Avoid asking everyone to resend every message immediately. Duplicate submissions can complicate recovery and create uncertainty about which version a customer received.
Verify recovery with a small test set
- Confirm that the intended receiving system is available.
- Send a controlled incoming message and record its delivery outcome.
- Test one normal outgoing message separately.
- Trace a previously queued message to its next confirmed state.
- Check whether mailbox access is working for an affected user.
Close the incident only after distinguishing restored service from a remaining delivery backlog. Keep the timeline, configuration changes and unresolved messages for a short follow-up review. Use that review to improve ownership and monitoring, rather than simply adding another alert.
For the routing background, read our Backup MX and secondary MX guide. Use MX Lookup to inspect DNS; it does not replace the delivery checks above.