Hosting a mail server means taking responsibility for delivery attempts, authentication, abuse handling and recovery, as well as mailbox access. Choose it only with named operational owners and a testable recovery plan. A sent-message log, a receiver’s acceptance and a recipient seeing the message are different observations that should be recorded separately.
Begin by listing the mail streams your business depends on: staff correspondence, application notifications and subscribed messages, where relevant. Identify who operates each sender and who investigates failures. This article uses Exim’s SMTP transport reference and Google’s requirements for personal Gmail recipients as concrete evidence, while keeping those product and receiver scopes explicit.
What does a delivery attempt actually involve?
Exim SMTP transport sends messages over TCP/IP using SMTP or LMTP. Exim applies timeout and retry processing independently to each IP address. These transport behaviours explain why a mail investigation needs the destination and connection evidence, rather than only the time an application requested a send.
Exim connect_timeout governs establishing the TCP/IP connection to a remote host. Exim command_timeout governs waiting for responses to SMTP commands and the initial banner. The configuration reference distinguishes these stages. Ask an operator to identify where the observed failure occurred before considering a configuration change. Increasing a timer indiscriminately does not establish the cause.
Keep submission, remote delivery and recipient observation as separate entries in an incident record. An application may say it passed a message to the local mail service; the operator still needs to inspect what happened next. Use the actual response and message identifier when available, while protecting message contents and personal data in shared troubleshooting notes.
Which receiver requirements should you verify?
Gmail requires SPF or DKIM authentication from all senders covered by its personal-account guidelines. Gmail requires valid forward and reverse DNS for sending domains or IPs. Gmail requires TLS when transmitting email to its personal accounts. These are Google’s receiver requirements, not a guarantee of delivery or a universal specification for every receiving service.
Gmail bulk-sender requirements call for SPF, DKIM and DMARC. For covered bulk senders, Gmail requires one-click unsubscribe on marketing and subscribed messages. Review those additional requirements against the actual sending pattern and message type. Do not assume that a configuration sufficient for an ordinary staff message answers the requirements for a subscribed marketing stream.
Activity from other senders on a shared IP can affect that IP’s reputation. Google’s shared-IP guidance makes the infrastructure arrangement relevant to a hosting decision. Ask who monitors that shared environment, what evidence is available during a delivery incident and where responsibility for remediation sits. Avoid accepting “dedicated mailbox” as an answer to a different question about sending infrastructure.
Original mail-stream responsibility and evidence ledger
Consider a hypothetical business with staff mail, booking notifications and a subscribed newsletter. This original ledger is a proposed operating exercise using test recipients who have agreed to participate. It is not a record of messages sent or a claim about a deployed mail service.
| Mail stream | Owner to name | Evidence for a controlled test | Failure question to answer |
|---|---|---|---|
| Staff correspondence | Mail administrator and business contact | Submission record, delivery response and recipient observation | At which stage did the message stop? |
| Booking notification | Application owner and mail operator | Test booking, message identity and corresponding delivery trace | Was a message created and handed over? |
| Subscribed newsletter | List owner and mail operator | Approved subscription and unsubscribe test | Does the next audience selection respect the change? |
| Unexpected outbound activity | Incident owner | Approved alert or isolated abuse-control test | Who can contain the source and inspect evidence? |
| Recovery copy | Recovery operator | Restored test mailbox and configuration checks | Can a user read the intended restored messages? |
For each row, record the sending identity, relevant domain and infrastructure owner privately. Keep credentials and signing secrets out of the worksheet. Include the source of the observed result so the reviewer can distinguish an application’s own log from a response supplied by a receiving service.
Run the booking-notification exercise from the application side as well as the mail side. A missing notification might start before the message reaches the mail server. Trace the approved test booking through the defined handover. Record uncertainty explicitly rather than assigning every missing message to the host or treating a generic service-status page as an investigation.
For the newsletter row, agree what the unsubscribe action should change in the business workflow, then test the next intended audience selection with fictional or approved test records. The platform requirement and the organisation’s implementation are separate checks. A link appearing in a message does not itself demonstrate the later list-selection behaviour.
How should abuse controls be reviewed?
Ask for a specific access-control and incident plan. It should state who is allowed to submit messages, how suspicious sending is detected and who can contain the affected account or application. Review the proposed control in a separate environment or by an agreed non-disruptive method. Do not use live customers as test recipients or create uncontrolled external traffic to discover whether abuse is possible.
Keep legitimate mail streams identifiable during an incident. If an application starts behaving unexpectedly, the operator needs a route to isolate that source without guessing which business process owns it. The source ledger supports that investigation by connecting a sending identity to an accountable person and an intended use.
Review receiver feedback alongside authentication and configuration. Where a receiving service reports a rejection or deferral, retain the response and investigate its stated context. Avoid presenting a configuration change as a guaranteed inbox-placement fix. The useful outcome is a clear explanation of the observed failure and the next check, supported by evidence.
Complete the incident row with a worked interpretation as well. In the fictional booking workflow, “the application recorded a notification request” and “the recipient reported no message” leave a gap for the mail operator to investigate. Ask which submission and remote-response evidence would close that gap, then assign each missing observation. Avoid repeatedly generating new messages merely because the original trace is incomplete. The ledger should preserve the relationship between the original business action and its message so the team can investigate that specific event and decide whether any later resend is appropriate.
What should a recovery test demonstrate?
Define the recovery scope before choosing a backup product: messages, mailbox configuration, relevant domain settings and the service configuration the operator needs. Specify which items are restored in the isolated test and which external dependencies remain separate. A readable archive is only an input to that test.
Restore an approved test mailbox to a separate recovery environment, then have the designated tester inspect known messages and the intended access method. Check the relevant sending configuration without switching live mail routing. Record what was recovered, what remains unresolved and who can approve a later production recovery. Avoid casually restoring over active mailboxes or changing shared services during the exercise.
Use business email, hosting and domains to frame the wider requirements. To discuss the operational scope, get started with the mail-stream ledger and the recovery result you need demonstrated. The decision should account for ongoing ownership and incident handling, not only whether a server can send a first test message.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.