The missing email that uncovered a legacy gateway

An employee could not receive the confirmation email needed to activate their password-manager account. I was working on single sign-on and automated provisioning, so the first place to look was the integration itself.

The synchronization process was running. Accounts were being provisioned. But the email required to complete onboarding was not arriving for some employees.

Following that failure led beyond the password manager to an unexpected part of the organization’s email infrastructure: a legacy gateway that was still receiving incoming mail before it reached Google Workspace.

That routing arrangement dated back to 2022. We discovered the problem while working on something else, roughly four years later.

The organization and its identifying infrastructure details are omitted here. The important parts are how we investigated, what we could prove, and how we approached the change without casually putting business email at risk.

There had been earlier warning signs

Before this rollout, some employees had complained about missing order-confirmation emails. We had not given those reports enough attention or followed them through with a consistent delivery investigation.

That is an uncomfortable part of this story, but it belongs in it.

Most email continued to arrive. People could send messages, reply to colleagues, and carry on with their work. Against that background, a missing confirmation could seem like an isolated problem with a merchant or sender.

We should have treated those reports as evidence worth collecting. A timestamp, a sender address, the intended recipient, and a delivery trace could have turned an anecdote into something testable.

I cannot retrospectively prove that every missing order confirmation was caused by the legacy gateway. We did not have the historical traces needed to make that claim. The routing arrangement had existed since 2022; that does not establish that the same failure happened continuously throughout those years.

What I can say is that the earlier complaints deserved investigation, and we missed an opportunity to understand them sooner.

The password-manager rollout gave us a specific failure to trace

The new onboarding problem provided a clearer starting point. We knew which service was sending the message, which workflow required it, and which recipient was waiting for it.

The provider’s delivery report pointed to a transport-security problem: the receiving mail server did not support the TLS connection required for delivery.

That changed the direction of the investigation. Repeating the invitation or changing provisioning settings would not resolve a receiving gateway’s inability to accept the required encrypted connection.

I needed to establish which server the sender was actually contacting.

Using Gmail did not mean mail arrived directly at Google

Employees used Google Workspace, but the domain’s public MX records still directed incoming messages to a legacy hosting provider’s mail gateway. The evidence indicated that messages for Workspace users were then relayed onward to Google.

The visible mailbox and the first server in the incoming delivery path were different systems.

Employees read their mail in Gmail, but the first server it reached was the old gateway.

Stage	Existing arrangement	Intended arrangement
Public incoming-mail destination	Legacy hosting gateway	Google Workspace
Intermediate forwarding dependency	Legacy gateway before Google	Legacy gateway removed from this path
Employee mailbox	Google Workspace	Google Workspace

That distinction explained why ordinary mailbox use had not revealed the dependency. An employee could read email in Gmail without knowing which infrastructure accepted it first.

It also explained why successful delivery from one sender was insufficient evidence that every sender could deliver. Different senders can enforce different transport requirements.

Testing the gateway supported the diagnosis

I independently checked the legacy gateway’s SMTP capabilities. The tested endpoints did not advertise STARTTLS. The hosting provider subsequently confirmed that this gateway did not support it.

STARTTLS allows an SMTP connection to negotiate transport encryption. In this incident, the sender required encrypted delivery, and the receiving gateway could not meet that requirement.

Three pieces of evidence aligned:

The sender’s delivery report identified a TLS-related obstacle.
Independent checks showed the legacy gateway did not advertise STARTTLS.
The gateway provider confirmed the limitation.

Three independent sources pointed at the same gateway.

That was enough to justify addressing the delivery path. It was not a reason to weaken the sender’s security requirement.

The next question was how to change the route carefully while preserving normal business communication.

Before changing DNS, I checked the destination

An MX change affects incoming mail for a domain. I wanted evidence that Google was ready to receive it directly before redirecting traffic.

I verified the domain and Gmail service status in Google Workspace and reviewed the visible routing, default-routing, and inbound-gateway settings for conflicts. I also documented the existing DNS configuration, including the mail-related records and authoritative nameservers.

The preparation covered several separate concerns:

Concern	Preparation
Destination readiness	Verify the domain, Gmail service, and relevant routing settings.
Recovery reference	Preserve the existing DNS configuration and record the intended changes.
Baseline behavior	Test sending and receiving before the change.
Sender authentication	Inspect authentication results and existing records.
Legacy data	Identify mailboxes still associated with the old provider and discuss their preservation.
Change scope	Keep unrelated DNS and account changes outside the cutover.

The legacy mailboxes mattered. Redirecting new incoming mail does not migrate historical messages or establish that every old mailbox is disposable. Their contents and retention needs required separate consideration.

I also avoided combining the migration with an immediate SPF cleanup. Existing test messages authenticated successfully, while other legitimate sending services still needed to be inventoried. A mail-routing change was already enough to validate in one window.

The production change stayed narrow

I coordinated the work during an after-hours window and changed the incoming-mail route. The registrar, authoritative nameservers, website records, and existing Google Workspace accounts stayed in place.

The new Google MX destination was added before the legacy MX entries were removed. That avoided intentionally leaving the domain with no MX record during the edit sequence. It did not eliminate caching, provider synchronization, or other transition risks.

I also removed the legacy wildcard MX route that had been identified in the existing configuration.

After the edits, I queried both authoritative nameservers and checked public resolvers. For a short period, the authoritative responses were not fully consistent as the provider’s infrastructure synchronized. I kept checking until both authoritative servers returned the intended Google-only result.

A DNS control panel accepting an edit was one observation. The authoritative servers publishing the intended records was another. I needed the latter.

Google Admin also required completion of its Gmail activation workflow. I completed that step and then repeated delivery tests.

An edit the control panel accepts isn’t the same as records the nameservers publish.

Verification had to include real messages

The most important test was whether external mail reached the intended mailbox through the new route.

I tested in both directions using independent email providers, including Gmail and Proton Mail. I inspected message headers as well as the inbox result.

One inbound test showed Proton connecting directly to Google’s receiving infrastructure over TLS 1.3. That was useful evidence: the message arrived, and its headers showed it had bypassed the old gateway.

The verification extended beyond those test messages:

Inbound and outbound exchanges worked after the cutover and activation.
Inspected messages passed SPF, DKIM, and DMARC checks.
Email logs showed real business messages reaching employee and support mailboxes.
Follow-up checks continued the next business day.
An employee who previously could not receive the password-manager confirmation reported receiving it after the migration.

That final result connected the infrastructure change back to the original problem. It confirmed that the missing confirmation-email obstacle was resolved for that employee. It did not, by itself, establish that every employee had completed activation or that all onboarding work was finished.

Based on the tests, logs, and employee feedback reviewed, we observed no widespread disruption to normal business email. I would not describe that as proof that no individual message was delayed, rejected, or lost.

The logs also showed why monitoring could not stop there

Post-change monitoring revealed isolated rejected messages. Those needed to be interpreted individually.

A message appearing in a log does not mean it reached the mailbox. A rejection can reflect sender reputation, authorization, recipient configuration, or other conditions. It should not automatically be attributed to the change that happened most recently.

In the examples reviewed, Google reported sender-related rejection reasons that were distinct from the original legacy-gateway TLS problem. I did not respond by broadly allowlisting senders or weakening controls. The next step was to determine whether the messages represented expected business communication and investigate accordingly.

That is another reason to read beyond a summary status. A transport can be encrypted and the message can still be rejected for another reason.

What I would change about our operational habits

The earlier order-confirmation complaints are the part I keep returning to. We did not need to predict this specific gateway problem. We needed a better habit for handling reports of missing mail.

For a future report, I would collect a small set of facts immediately:

The expected sender and exact recipient.
The approximate send time and timezone.
The kind of message expected, without unnecessarily collecting its private contents.
Any bounce or delivery report available from the sender.
The message ID, when available.
The receiving-side status and any upstream trace that can be obtained.

That creates a starting point for investigation while the relevant evidence is still available.

I would also make periodic email-log review part of routine administration, with closer review after routing changes and whenever employees report missing messages. The appropriate cadence depends on mail volume and business needs; the important part is having an owner and a repeatable process.

A useful review looks for patterns: recurring failures involving a sender, repeated recipient errors, delays, or expected transactional mail that never appears. It should include checking the actual delivery disposition rather than counting log entries as successes.

Logs contain sensitive metadata, so reviews should stay limited to authorized administrators and the information needed to resolve delivery problems.

Receiving-side logs have a limit

Checking Google Workspace logs is valuable, but it would be a mistake to assume they can explain every message sent toward a domain.

If an upstream gateway rejects a message before it reaches Google, Google’s logs may have no corresponding delivery event. An empty search result is therefore not proof that the sender never tried.

Google’s troubleshooting guidance explicitly recommends checking the recipient domain’s MX records when a message does not appear in Email Log Search. Depending on the delivery path, the investigation may also require the sender’s trace or the intermediate provider’s logs.

This was the broader lesson of the incident: inspect the route the message actually takes. The application people use every day may expose only the final part of that route.

What stayed with me

We discovered this issue while implementing something new. The new workflow brought an old dependency into view, and a specific delivery failure gave us the evidence to investigate it properly.

The technical fix was only part of the work. The rest involved preparing the destination, preserving the existing configuration, considering old mailbox data, limiting the scope of the change, testing from outside the organization, and watching real delivery afterward.

The earlier complaints should have received that same curiosity. We could not explain them simply because most other messages were arriving.

The next time someone says, “I never got that email,” I want our first response to be a small, documented investigation while there is still evidence to follow.