Customers said the confirmation email never arrived

A customer books a car, pays, and hears nothing. They email you to ask whether the booking went through. Then a second customer does the same. Then you get a bounce message in your own inbox saying a message from your business could not be delivered, in language that looks like it was written for somebody else, and you forward it to us with the question every owner asks: what did you change?

The answer, for this self-drive car rental operator in Goa (the system behind GOI Car & Taxi), was that nobody had changed the software. From noon on 5 September, every confirmation sent to a Gmail address was refused. The first estimate of the damage, worked out from the domain’s settings, was every customer email since 22 August, 692 of them. Checked against the actual delivery records, that was wrong: delivery was clean until 12:00 on 5 September and broke from that minute, which puts the real figure at roughly 37 bounced confirmations. The wrong number was corrected before it reached the owner, but it is worth recording, because the tempting figure was twenty times the true one.

What was actually going on

Email has a set of public records, held with the domain name, that tell receiving mail systems which senders are allowed to use that name. On the afternoon of 5 September, the records for this operator’s domain were set to the strictest setting: reject anything that is not signed by, and sent from, the domain itself. That is a reasonable setting for a business that spoofs easily. But the service that actually sends the portal’s email was signing messages under its own name, not the operator’s, and the record listing approved senders named only Google. So nothing lined up, and Gmail did what the record told it to: refused every message.

The sending service, on inspection, had never been set up to sign as the operator’s domain at all. It held the sending address as a bare address with signing switched off, and no domain identity existed. Half of a separate bounce-handling arrangement had been published in the domain’s records but never told to the sending service, and would not have helped anyway under a strict setting.

So the bounce was not a code fault. It was a domain configuration that had been made stricter than the sending arrangement could satisfy.

What we changed

The operator’s domain was registered with the sending service as a proper identity, signing was switched on, and the three records that publishes were added to the domain. Then, rather than assume, we sent a test message through the exact production sender to a Gmail inbox and read the result out of the received message’s own headers: signed by the operator’s domain, passed the domain’s policy, no adverse disposition.

While there, a file of live credentials was found sitting in the repository directory one command away from being committed. It was excluded from version control and reorganised into a properly named configuration file.

What it did not fix

The roughly 37 confirmations that were refused during the window were refused. A domain record cannot resend an email, and the log for this work records no resend.

Three things were flagged for the owner and left. The sending service’s access key and secret are hard-coded as fallbacks in two source files and therefore live in the repository’s history, which no later edit removes. A second sending identity, for the portal’s own hostname, is in a failed state. And the administrator credentials supplied for this work should be deleted and rotated now that it is done.

The mechanism, briefly

_dmarc on the domain published p=reject with adkim=s and aspf=s; the SPF record listed only Google’s sender, and SES was signing with amazonses.com, so neither DKIM nor SPF aligned to the domain and Gmail rejected with 550-5.7.26. Fixed by creating the domain identity in SES with Easy DKIM, publishing the three CNAMEs DNS-only at the DNS host, and verifying dkim=pass header.i=@ the domain, dmarc=pass and dis=NONE in the raw headers of a message sent through the production Source.

Where this ends up

A confirmation that is refused at the door is indistinguishable, to the customer, from one that was never sent, which is why Sazinga Rentals treats the domain’s mail authentication as part of the booking flow and checks delivery from the received headers, not from the send succeeding.