There are few messages less comforting than We sent you an email when you are looking directly at an inbox containing no such email.
The person saying it may be completely right. So may the person waiting. Email has several handoffs, and software sometimes describes the first successful one as though the whole journey is finished.
Google’s new sender requirements beginning in February 2024 make this a timely moment to review the setup.1 For a business relying on order confirmations, shipping instructions or approvals, I’d also review what happens after the application says Sent.
Think of parcel tracking. Left the warehouse and In your hands would be rather ambitious synonyms. Email deserves similarly careful wording.
Work out what each status actually proves
A message may be queued by the application, accepted by a sending provider and processed for delivery afterward. Those stages answer different questions.
Provider terminology varies. Read the definitions before turning them into staff-facing labels, particularly when a label could persuade someone to resend an important message.
Accepted means another system has taken responsibility
A sending service may accept the message before attempting delivery. Temporary problems can delay the next stage. A permanent rejection may need a corrected address or another response.
Preserve the provider’s message reference so later events can be linked to the business action that triggered the email. An order record and a bounce event are much more useful when staff can establish that they belong together.
Without that connection, the team can spend an afternoon confidently discussing two different messages. Everyone has evidence. Nobody has an answer.
Delivered is not a reading receipt
A delivery event commonly indicates acceptance by the receiving mail server. It doesn’t establish placement in the primary inbox or prove that the customer read the content.
Open tracking also has limits because mail clients can block or automatically retrieve images. An important approval workflow should establish completion through the required action, such as signing in and approving the request, rather than treating an image request as consent.
Decide what the business needs to know. A marketing report and a customer authorization are different jobs. One can tolerate uncertainty that the other really should not inherit.
Connecting systems that were never introduced? See our integrations and AI work.
Make the route dependable enough to investigate
There are two connected responsibilities here: configuring the sender appropriately and receiving useful evidence about what happened.
Solving one doesn’t remove the other. A correctly authenticated message can still bounce, and an excellent bounce log doesn’t repair an incorrectly configured sender.
Check the sender requirements that apply
Google’s October 2023 announcement set out stronger authentication, easy unsubscription for commercial email and a reported-spam threshold for bulk senders. The announced bulk scope concerns more than 5,000 messages to Gmail addresses in one day.
That doesn’t mean every small business must apply every bulk-marketing rule to every receipt. Identify the actual senders and the requirements relevant to them.
A company may send through its office account, website, commerce platform and marketing service. The domain configuration needs to account for those authorized sources. Check the provider’s instructions for authentication mechanisms such as SPF and DKIM and any applicable DMARC requirements.
Authentication helps receiving systems assess the message’s claimed identity. It does not guarantee an inbox destination. There are still other systems and reputation signals involved, all with their own opinions about your very important confirmation.
Listen for outcomes and define the recovery
Many providers expose delivery information through webhooks. Svix’s documentation guidance supplies useful questions: which events exist, what triggers them, how signatures are verified and how failed deliveries are retried.2
The receiving application should record those events against the original message. It also needs to handle duplicates safely.
The idempotency principles in Stripe’s API guidance are relevant to repeated attempts at the same intended action.3 Check what your particular email provider supports rather than assuming it makes an identical promise.
Keep the recovery understandable to staff. A bounce should create a visible exception, with enough context to check the address or choose an appropriate next step. A retry should not quietly trigger a new order or send several warnings about the same problem.
For a hypothetical customer-offer workflow, the email might be one route to an offer also available through a secure account. That gives the person another way to complete the task. Any alternative contact method still needs appropriate permission and context.
Zulu Shack recommends testing a deliberate delivery failure before considering an important email workflow finished. Check what staff see, who owns the exception and how the customer can continue.
Sending a test message to the developer’s inbox is a useful first step. We just shouldn’t make it the entire dress rehearsal.
Follow one important email from its business trigger to the action it is meant to support. Keep the statuses honest and give somebody a way to resolve the gaps.
Then We sent it can be the beginning of an investigation, instead of the end of the conversation.