“Sent” can mean that an application handed a message to a queue, that a relay accepted it, or that a destination server accepted it. These are different events. Start by finding the last confirmed step in the message's path, then investigate the next step with logs and recipient evidence.
Map the message path
Record the sending application, outbound relay, envelope sender, recipient domain and message identifier. Check whether the message entered the outbound queue and whether the relay attempted delivery. If a website form never submitted a message to a mail service, DNS authentication changes will not repair the form.
For a controlled test, use a mailbox you own and an ordinary message with a unique subject. Do not repeatedly send to a failing recipient or a large list while investigating. Keep logs redacted: recipient addresses, message bodies and tokens can contain personal or confidential data.
Read the actual SMTP response
A temporary 4xx response generally asks the sending system to try again later. A permanent 5xx response generally rejects that attempt; the accompanying text and enhanced status code explain the reason more precisely. Do not infer the cause solely from the first digit. A provider may describe rate limits, policy, authentication or an invalid recipient in the response text.
| Observation | Investigate |
|---|---|
| Connection times out before SMTP | Network route, outbound port policy, destination availability. |
| Relay login rejected | Credentials, supported authentication, account restrictions. |
| Temporary deferral | Response text, queue retry behavior, provider limits. |
| Recipient rejected | Address accuracy and destination policy. |
| Accepted but absent from inbox | Mailbox rules, junk folder, filtering and recipient trace. |
Check routing and authentication separately
MX records normally tell senders where inbound mail for a domain should go. They do not authorize every outbound sending service. SPF authorizes the evaluated envelope identity, DKIM verifies a signature, and DMARC evaluates alignment with the visible From domain. Check each according to its role.
If your organization operates its own outbound mail server, confirm its hostname, address and reverse DNS with the hosting provider's supported process. Reverse DNS is generally controlled by the IP address owner, not by adding an arbitrary PTR record to your forward zone. Check the receiving provider's current requirements for the kind of mail you send.
Inspect a received example
When a controlled test reaches a mailbox, examine the trusted recipient Authentication-Results and the Received chain. Verify the actual signing domain and selector. Compare a failing stream with a working stream, looking for a different relay, envelope domain or signature. Do not assume every application uses the same outbound route.
Authentication passing is useful evidence, but recipients can still classify mail as junk. Permission, complaint rates, sending reputation, volume patterns and content all matter. Avoid claims that a particular DNS record guarantees inbox delivery.
Protect queues and avoid duplicate sends
Before retrying manually, check whether the original message remains queued. A second submission can create duplicates when the original later succeeds. Use your relay's documented retry and expiry controls. If a campaign system tracks per-recipient state, inspect that state instead of restarting the whole campaign.
For temporary provider limits, reduce unnecessary retries and follow the provider's published guidance. For permanent recipient failures, correct the address or suppress it as appropriate. Do not bypass rejection by cycling domains or sources; fix the identified cause and maintain consent-based sending.
Send the provider a minimal evidence package
- Timestamp and timezone, relay and message identifier.
- Exact redacted SMTP response and enhanced status code.
- Whether the message is queued, rejected or accepted.
- Relevant redacted authentication results and recent changes.
- A controlled reproduction using a mailbox you own.
No reply from a recipient is not itself proof of non-delivery. Use delivery logs and available mailbox traces. For record-specific failures, continue with SPF troubleshooting or DKIM verification; for routing failures, use the DNS incident workflow.