The customer has paid. The order exists. Your application displays “Confirmation email sent”. Five minutes later, support hears: “I have not received anything.” Both screens may be telling the truth. They are simply describing different parts of the journey.
World Post Day, on 9 October, commemorates the founding of the Universal Postal Union in 1874. It is a good excuse to borrow a postal distinction: handing a letter to the carrier is not the same as watching someone read it. Email has its own handovers, and the green tick usually tells us less than we would like. United Nations: World Post Day.
From sending to reading: distinct states
Start inside your own product. “Created” can mean the business event was recorded. “Queued” can mean a background job exists. Neither proves that the sending service has accepted the message. If your application treats these as one state, troubleshooting starts with an unreliable witness: its own interface.
An SMTP server that accepts the message after DATA with a 250 response takes responsibility for delivering or relaying it. That is a protocol handover, not proof of inbox placement or reading. Check which server returned the response: an intermediate relay and the final receiving system are different points on the route. RFC 5321, section 6.1.
Provider event names also need a definition. Amazon SES, for example, describes SEND as acceptance of the send request and DELIVERY as delivery to the recipient’s mail server. The distinction is useful precisely because the second event still does not say “the person read it”. Other providers may use different labels. Read their event contract before naming a dashboard column. Amazon SES event definitions.
For a proposed order-confirmation interface, use wording such as “Order recorded” immediately, then show the email status separately. Keep the receipt available in the authenticated account. A missing message should not make the customer wonder whether clicking Pay again is a sensible debugging technique.
What to inspect when the message disappears
Follow one message, not a vague complaint that email is broken. Capture the order reference, creation time, queue job result and provider message identifier. Then find the delivery event and its diagnostic code. Limit access to these records and avoid logging passwords, reset links or complete message bodies just to make investigation convenient.
Enhanced mail status codes classify success with 2.x.x, temporary failure with 4.x.x and permanent failure with 5.x.x. The remaining digits add context. A permanent failure means repeating the same attempt unchanged is unlikely to help; it does not mean the person can never receive email again. Interpret the complete response and the provider’s documentation. RFC 3463: enhanced status codes.
Our suggested investigation order is simple: first confirm that a job was created; then that the worker processed it; then that the provider accepted it; then inspect the receiving-server outcome. Only after that should you investigate inbox filtering with the recipient. Asking someone to check spam before noticing that your queue stopped yesterday is an efficient way to waste two people’s time.
Do not turn a resend button into a mail cannon. Give retries a limit, space them according to the failure, and make repeated requests distinguishable from new business events. An email retry must never recreate an order or trigger another payment. That separation is an application-design recommendation, not a promise made by SMTP.
SPF, DKIM and DMARC are different checks
SPF lets a receiving system check whether a sending host is authorised for the relevant envelope domain. It does not, by itself, authenticate the friendly display name a person sees. Include the legitimate services that actually send for you; copying a DNS record from an unrelated tutorial is not an inventory. SPF specification.
DKIM attaches a domain-linked cryptographic signature to selected headers and the message body. It helps the receiver validate the signature and the signed content. It is not end-to-end encryption and it does not certify that the message is useful, welcome or honest. DKIM specification.
DMARC connects successful SPF or DKIM authentication to the domain in the visible From address through alignment, and lets domain owners publish handling preferences. The current core specification is RFC 9989, published in May 2026, replacing RFC 7489 and RFC 9091. An authenticated message is still subject to the receiver’s other checks. Current DMARC specification.
A practical rollout begins with an inventory: the store, support platform, invoicing tool and newsletter may all send mail. Check their authentication before tightening policy. Otherwise, a change intended to stop impersonation can also expose an overlooked legitimate sender. Treat DNS changes as a controlled deployment with an owner and a recovery plan.
A valid signature is not a reservation in the inbox
Gmail’s guidance for personal accounts requires SPF or DKIM for all senders and adds SPF, DKIM and DMARC requirements for bulk senders. It also addresses TLS, DNS, unwanted messages and unsubscribing. Meeting authentication requirements matters, but the guidance does not offer guaranteed inbox placement. Requirements checked on 8 October 2026; other receiving services have their own rules. Gmail sender requirements.
Separate an order receipt from a promotional campaign in your product design. The customer needs one to complete a transaction and may not want the other at all. Keep the subject descriptive, the sender recognisable and the message focused. This is less glamorous than a deliverability hack, but it also requires fewer apologies.
An “open” is not reliable evidence of reading
Apple explains that Mail Privacy Protection can download remote content in the background regardless of whether the recipient interacts with the email. A tracking image being fetched can therefore produce an apparent opening without proving human attention. Conversely, a person can read a message without loading remote images. Apple: Mail Privacy Protection.
For a transactional flow, measure the result you actually need: did the user complete verification, access the receipt or finish recovery? Define that event inside the application, collect only what is necessary and keep delivery diagnostics separate. A dashboard with a large open-rate number is not a substitute for knowing whether the customer is stuck.
A small acceptance test before launch
Use controlled test addresses and a provider sandbox where available. Try a successful delivery, an invalid destination, a temporary failure and a duplicate submission. Verify that the recorded order remains single, the email states stay distinct and support can trace the attempt without seeing secrets. These are proposed checks, not results of a test conducted by Zephyrus.
For a fictional booking service, the acceptance criterion could be: “If the confirmation email fails, the booking remains visible in the customer account, the failure is recorded and a controlled resend is available.” That is concrete enough for a developer to implement and for the owner to verify.
The useful improvement is rarely a brighter “sent” badge. It is an honest account of what the system knows, what it does not know and what happens next. The digital postman can leave a delivery record. He cannot certify that anyone put down their coffee to read the letter.