Transactional email often flies under the radar
Transactional email deliverability is one of the most commercially damaging problems a growing business can have, precisely because it gives you almost no warning before it starts costing money. Unlike a marketing campaign that underperforms, a transactional email failure does not show up as a drop in open rates or a rise in unsubscribes. It shows up as a user who never activated, a customer who thought their order failed, or a support ticket from someone who never received the password reset they asked for three minutes ago.
Most businesses have no idea how their transactional email is actually performing. This post covers why that is, what tends to go wrong, and where to start if you want to find out.
What transactional email actually means
The cleanest definition of a transactional email is a practical one rather than a legal or platform-based one: would the recipient get in touch with you if it did not arrive?
If someone requests a password reset and the email does not land, they will contact support. If an order confirmation never arrives, they will assume the purchase failed and either try again or call. If an activation email goes missing, the new user does not activate, and there is a reasonable chance they never come back. These are emails the recipient is actively waiting for, triggered by something they specifically did, and their absence causes an immediate, visible problem for the person expecting them.
Most emails do not pass that test. A promotional offer, a newsletter, a re-engagement campaign: none of these would prompt a support ticket if they disappeared. Those are marketing emails regardless of what the sending platform calls them, and the distinction matters because transactional and marketing email behave very differently in the inbox, carry different deliverability risks, and should be treated as entirely separate infrastructure.
A word on notification emails
Notifications sit in an awkward middle ground that is worth thinking through carefully before you decide how to treat them. An email telling a user that someone commented on their document, that a new report is ready, or that their trial is expiring in three days is triggered by activity rather than a direct request, and it sits somewhere between transactional and marketing depending on how you look at it.
The two questions worth asking before treating a notification as transactional are whether the recipient would genuinely miss it if it did not arrive, and whether they had a real opportunity to opt out of receiving it. If the answer to both is no, treat it as marketing email and send it through your marketing infrastructure with appropriate preference controls attached.
There is also a volume problem with notification email that most teams do not notice until it is already damaging their sending reputation. If your platform sends an email every time a user performs an action or triggers an event, it is worth modelling what happens at scale before you go live. A shared document with fifteen collaborators, each making changes throughout the day, can generate dozens of notification emails to every member of the team before lunchtime, and that volume hits your sending reputation hard while almost certainly not being what anyone intended when the trigger was originally set up. Build rate limits and digest logic into any notification sequence from the start rather than waiting for the complaint rate to surface the problem.
Why transactional email deliverability problems are so hard to catch
The reason transactional deliverability problems go undetected for so long is that there is rarely a visible signal in the data you are already looking at. Marketing email has open rates, click rates, and unsubscribe data that, however imperfect, at least point you towards a problem. Transactional email typically don’t have all of those as are mostly informational, nor are they tracked from an email to revenue perspective internally.
A password reset email that lands in spam does not show up as a bounce. An activation email that gets filtered does not generate a complaint. It simply disappears, and the only person who knows is the user who never completed sign-up and never heard from you again.
Without active monitoring of your transactional streams, you will not find out about a problem from your sending data. You will find out because conversion rates are lower than they should be, because support tickets start mentioning missing emails, or because a cohort of new users churns before they ever saw your product properly. By that point the problem has usually been running for weeks, sometimes longer.
The infrastructure mistakes that cause most of the damage
Sending transactional email from your primary domain
- The problem: reputation damage from marketing sends bleeds directly into your transactional stream
- The risk: a promotional campaign that drives complaints can suppress password resets and activation emails sent from the same domain on the same day
- The fix: separate transactional and marketing sends at the domain or subdomain level
Many businesses send every email from their root domain, with marketing campaigns, product updates, and transactional triggers all going out from the same address. The problem is that inbox providers assess reputation at the domain level, so if a promotional campaign drives up complaint rates or triggers spam filtering, that reputation damage applies to every email sent from the same domain, including the transactional emails your customers are actively waiting for. Separating your sending streams from each other is the structural fix that protects your transactional reputation from anything that happens on the marketing side.
If you want to understand how sender reputation works and how damage accumulates, our guide to what sender reputation actually is covers the mechanics in detail.
No dedicated subdomain for transactional sends
- The problem: all sending streams share a single reputation history
- The risk: problems in one stream affect inbox placement across all of them
- The fix: set up a dedicated subdomain such as notifications.yourdomain.com for transactional sends
Building on the previous point, a dedicated subdomain for transactional email, something like notifications.yourdomain.com or mail.yourdomain.com, gives that stream its own independent reputation history so that problems on your marketing subdomain stay contained.
More importantly, inbox providers can assess your transactional sending behaviour separately from your promotional behaviour, which is almost always better for the emails that matter most. Most businesses have not done this, and it is one of the first infrastructure changes worth making.
No dedicated IP for high-volume transactional sends
- The problem: on a shared IP pool, other senders' behaviour affects your reputation
- The risk: you have no visibility into what is influencing your inbox placement
- The fix: at sufficient volume, move transactional sends to a dedicated IP
If you are sending at sufficient volume, a shared IP pool means your transactional email reputation is partly determined by what everyone else on that pool is doing. A dedicated IP for transactional sends removes that dependency entirely and gives you complete visibility into your own sending behaviour without any external noise. This is not necessary for every business, and at lower volumes a well-managed shared pool is fine, but if you are sending tens of thousands of transactional emails per month the case for a dedicated IP is worth examining properly.
Authentication gaps that undermine everything else
- The problem: misconfigured SPF, DKIM, or DMARC tells inbox providers they cannot verify your email
- The risk: even well-structured transactional sends will underperform without correct authentication
- The fix: check alignment across all three records, not just whether they exist
Even a well-structured sending infrastructure will have transactional deliverability problems if SPF, DKIM, and DMARC are not correctly configured. These are the records that tell inbox providers the email claiming to come from your domain was actually sent by you, and gaps or misalignments in any of them will work against your inbox placement regardless of how good your sending behaviour is. Our plain-English guide to SPF, DKIM and DMARC covers what each one does and what the consequences are when they are not set up correctly.
No monitoring in place
- The problem: transactional deliverability issues produce no obvious alert in standard sending data
- The risk: problems run undetected for weeks, quietly suppressing conversion and activation
- The fix: set up Google Postmaster Tools and Microsoft SNDS as a minimum baseline
You almost certainly monitor your API uptime and your error rate, but there is a reasonable chance you are not monitoring whether the emails that trigger trial conversion are actually reaching the inbox. Google Postmaster Tools tracks domain and IP reputation alongside spam rates for Gmail, and Microsoft SNDS covers Outlook and Microsoft 365, which carries particular weight in UK business email environments where Microsoft 365 is the dominant platform. Neither requires complex integration, and both will surface problems you would otherwise have no visibility into. If you are only watching Gmail, you are monitoring roughly half the picture and missing the inbox environment that matters most across UK enterprise.
Marketing content inside transactional email
Inbox providers look at the content of what you send, not just the category you have assigned it in your ESP. If a transactional email contains promotional language, product recommendations, or marketing calls to action, it will be assessed accordingly rather than given the benefit of the doubt as a transactional send.
This creates a specific compliance problem that is worth understanding clearly. Transactional emails do not carry an unsubscribe link, and that is legitimate because the recipient specifically requested the email.
But if that same email contains marketing content, the absence of an unsubscribe mechanism becomes a problem, because the content signals marketing while the infrastructure signals transactional, and inbox providers at both Google and Microsoft will notice the inconsistency. Keep transactional emails transactional. A separate post-purchase or post-activation sequence, sent through your marketing infrastructure with proper preference controls in place, is the right home for anything beyond the core transactional content.
Schema markup and the purchases tab
This is something most teams have never looked at, and it makes a meaningful difference to how Gmail handles receipts and order confirmations in particular. Gmail uses structured data, specifically JSON-LD schema markup embedded in the email HTML, to identify purchase-related emails and surface them correctly for the recipient. An order confirmation with the right schema in place will appear in the Purchases tab and may display as a highlighted card at the top of the inbox, while one without it gets processed as a generic email with no special treatment.
The relevant schema types for e-commerce are Order, DiscountOffer, and ParcelDelivery. For SaaS businesses, ViewAction and ConfirmAction are the ones most worth knowing about. You can test your existing emails using Google's Rich Results Test and the Gmail Markup Tester. The majority of businesses sending order confirmations have no schema in their email HTML at all, which means they are missing a straightforward improvement to how Gmail presents their most important transactional emails to customers.
Where to start
Begin by mapping what you are actually sending. Pull every triggered email from your platform and apply the practical test: would a recipient contact support if this did not arrive? That tells you what is genuinely transactional and what should be treated as marketing regardless of how it is currently configured.
Then check your infrastructure against the areas covered in this post. Are transactional sends going out from a dedicated subdomain, or are all your streams sharing a root domain? Are there authentication records in place and correctly aligned? Is monitoring running across both Gmail and Microsoft, or is half the inbox landscape invisible to you?
If the honest answer to most of those questions is no, there is a good chance your transactional email deliverability has a problem you are not yet aware of, and the only question is how much it has already cost you.
A structured email deliverability audit looks at all of this in one piece of work: your sending infrastructure, authentication setup, subdomain and IP architecture, monitoring gaps, and whether your transactional and marketing streams are correctly separated. It covers the full picture rather than one layer at a time, and it gives you a prioritised set of findings in plain English so you know exactly what to address and in what order.
If you want to understand where your transactional email currently stands,Digistrat can help; a free inbox check-up is a good starting point. It takes 15 minutes and gives you a plain-English assessment of your current setup with no obligation to take it further.
Frequently asked questions
What is the difference between transactional and marketing email?
Transactional email is triggered by something the recipient specifically did, such as requesting a password reset, placing an order, or signing up for an account. The practical test is whether the recipient would contact you if the email did not arrive. Marketing email, including newsletters, promotional campaigns, and re-engagement sequences, is sent at the sender's initiative rather than in response to a direct request. The distinction matters because the two types carry different deliverability risks and should be sent from separate infrastructure.
Why is my transactional email going to spam?
The most common causes are sending transactional email from the same domain or subdomain as your marketing sends, authentication records that are missing or incorrectly configured, and a lack of monitoring that allows problems to build undetected. In some cases, marketing content or promotional links inside a transactional email will cause inbox providers to treat it as a marketing send, which changes how it is filtered. A full review of your sending infrastructure is usually needed to identify the specific cause.
Do transactional emails need an unsubscribe link?
No, provided the email is genuinely transactional. An email the recipient specifically requested, such as a password reset or order confirmation, does not require an unsubscribe mechanism. However, if a transactional email contains marketing content, promotional offers, or calls to action beyond the core transactional message, inbox providers may treat it as a marketing send, in which case the absence of an unsubscribe link becomes a problem. Keep transactional emails strictly transactional to avoid this.
What is a dedicated sending subdomain and do I need one?
A dedicated sending subdomain is a separate domain address used exclusively for one type of email send, for example notifications.yourdomain.com for transactional email and news.yourdomain.com for marketing. It gives each stream its own independent reputation history with inbox providers, so that problems in one stream do not affect the other. Most growing businesses benefit from separating transactional and marketing sends onto dedicated subdomains, and it is one of the first infrastructure changes worth making if they are currently sharing a root domain.
How do I monitor transactional email deliverability?
The two tools to set up as a baseline are Google Postmaster Tools, which tracks domain and IP reputation alongside spam rates for Gmail, and Microsoft SNDS, which covers Outlook and Microsoft 365. Both are free and do not require complex integration. For more detailed inbox placement testing across multiple providers, tools such as GlockApps allow you to send test emails and see exactly where they land. Monitoring both Gmail and Microsoft is important for UK businesses given how heavily Microsoft 365 is used across UK enterprise email environments.
What is email schema markup and why does it matter?
Email schema markup is structured data, written in JSON-LD format, embedded in the HTML of an email. Gmail uses it to identify certain types of email and present them differently in the inbox. An order confirmation with the correct schema will appear in the Purchases tab and may display as a card at the top of the inbox. Most businesses have no schema in their transactional emails at all, which means Gmail treats them as generic messages. Adding the relevant schema types for your email type is a straightforward improvement that most teams have simply never done.
Related reading:
