A purchase confirmation can be legitimate and still arrive at the wrong moment, for the tenth time. That is the uncomfortable part of transactional email: the business can have a valid reason for every message while the customer experiences one noisy system.

Separate your newsletter from your transactional sending. Then inspect what the transactional system actually sends. A different subdomain is a useful boundary, not permission to stop paying attention to the inbox.

Separation protects a stream, not every customer

There is a sound reason to give newsletters and essential messages distinct sending identities. A promotional experiment should not casually share its operational fate with tickets, receipts and account access. Amazon SES recommends considering separate subdomains for marketing and transactional communications , describing separate reputations as a way to reduce risk.

Do that work properly: authenticate each sending domain, inspect the actual message headers and test the routes that customers depend on. Changing the address before the at-sign is not a substitute for checking the sending infrastructure. Neither is moving to a new subdomain a guaranteed, instant escape from an existing problem.

The boundary also has limits. Google’s sender guidelines distinguish authentication, reputation and sending practices, and note that other senders can affect a shared IP’s reputation. Splitting domains does not necessarily split that IP. Inspect the arrangement with your provider; do not buy a dedicated IP merely because it sounds like stronger isolation.

But even a neatly separated transactional stream can be exhausting. Infrastructure tells you where the message came from. It does not tell you whether the recipient needed another one.

Count the journey, not just the flow

Start with a customer who buys several times in a short period. Walk through every email they receive over the following week. Include confirmations, payment notices, shipping updates, delivery reminders, feedback requests and messages from systems outside the email team’s dashboard.

For each trigger, write down the customer’s need, the event that fires it and what happens if that event repeats. A sensible flow viewed alone can look very different beside five other sensible flows.

A business sending purchase confirmations reported that two flows alone exceeded a million messages in a month, with repeated purchases creating bursts for individual customers. Its point was that these were genuine confirmations, not promotions dressed up as receipts. That distinction deserves to survive the diagnosis.

The answer is not to switch off essential receipts indiscriminately. Protect the message that confirms a purchase or gives someone access to what they paid for. Then look for duplicate triggers, repeated nonessential reminders, avoidable status messages and opportunities to combine updates without withholding information the customer needs.

Assign someone responsibility for the whole journey. An email team can improve each template and still miss the combined load if checkout, support and fulfilment systems are making separate sending decisions.

Authentication is not an incident diagnosis

In that same reported incident, Gmail displayed a phishing warning despite apparently clean authentication. The business also said it found HTTP tracking links and changed them to HTTPS. The available account does not establish why Gmail showed the warning, whether the link change resolved it or how long recovery took. Those are separate questions, not a single proven story about excessive sending.

That distinction matters during an incident. Inspect authentication and alignment, message content, link destinations and redirects, provider responses, and customer complaints as separate evidence. A successful authentication check should close one diagnostic branch, not the investigation.

Nor should the word transactional close it. Google’s sender FAQ excludes certain transactional messages from its marketing one-click-unsubscribe requirement, while warning that high spam rates can hurt delivery of any message type. An exemption from one requirement is not a general reputation exemption.

Waiting may be necessary after a correction. Waiting without identifying a correction, monitoring delivery and keeping essential messages reachable is not a plan. Do not promise a recovery date that your provider has not established.

Make essential email someone’s operating responsibility

Before increasing send volume, keep a short register of critical messages: what triggers each one, who owns it, which sending route it uses and how delivery problems reach that owner. Review per-customer bursts as well as aggregate volume. Follow provider guidance when changing sending patterns rather than making a large, unexplained jump.

The practical decision is not architecture or restraint. You need both: separation to contain risk, and trigger-level judgment to keep a valid transaction from becoming an unwanted sequence. A receipt earns its place by helping the customer complete the purchase, not merely by passing an authentication check.