Yeah… you need to keep your transactional email deliverability high.<\/p>\n
First of all, because they’re essential<\/strong> (emails with password changes and account updates are things customers need<\/em> to receive).<\/p>\n But second of all… because they really\u00a0aren’t<\/em> spam<\/strong>.<\/p>\n In virtually every case, your customers both need and (yes) want to get transactional emails.<\/p>\n If you suspect your transactional emails are going to spam, there’s a standard checklist for fixing things<\/strong>: get a dedicated IP, warm it up thoroughly, separate your marketing and transactional sending streams, monitor your reputation.<\/p>\n But that’s not the universal solution. That checklist makes sense for high-volume senders; for others, it can range from a waste of effort to actually causing more harm than good<\/strong>.<\/p>\n What’s right for you depends on two things:<\/p>\n In this article, I’ll cover the\u00a0right<\/em> approach to transactional email deliverability based on your sending volume. And I’ll also cover some tips for spotting when your transactional emails might be going to spam and why it might be happening.<\/p>\n (Note: This article is about deliverability specifically and assumes you know what a transactional email is. For the fundamentals, like how they differ from marketing emails, start with our guide to what transactional email is<\/a>, then come back.)<\/em><\/p>\n You’ll find the right setup here based (again) on two things:<\/p>\n If you’re blasting out transactional emails all day, every day, the “standard checklist” I alluded to in the intro is right for you, and you should follow it.<\/p>\n At this volume, the infrastructure pays for itself. But for lower volume senders, it’s almost certainly overkill…<\/p>\n This is the trickiest level, because it sure\u00a0feels<\/em> like you’re sending a ton of transactional emails \u2014 but you’re actually a level down from where you might think.<\/p>\n I’m serious. I know it feels like you should be moving up into the dedicated IP world with the other big transactional senders. But if you do that prematurely, it can do more harm than good. (Plus it’s way more expensive.)<\/p>\n If you’re sending a relatively low volume of transactional emails \u2014 plus some days you send a ton and other days just a few \u2014 you shouldn’t go anywhere near dedicated IPs.<\/p>\n Instead, you can use a shared pool… or, even better, just ride Google.<\/p>\n If your transactional volume fits inside a normal Google account’s daily sending (up to 500 a day on regular Gmail, up to 2,000 a day on Google Workspace) your reputation problem is largely solved for you<\/strong>.<\/p>\n Yes, you\u00a0really<\/em> can send transactional emails through Gmail<\/strong>.<\/p>\n If you don’t know GMass, it’s a Chrome extension that actually transforms Gmail into a full email sending platform<\/strong>. So you can send marketing emails, newsletters, cold outreach, mail merge, and, yes, transactional emails all through a Gmail\/Google Workspace account.<\/p>\n That way your transactional emails piggyback off Google’s sender reputation. Plus you can stop paying separate bills for all your different types of emails (and juggling separate apps) and just do\u00a0all<\/em> of your emailing from Gmail.<\/p>\n You can actually test it out in Gmail for free, for both email campaigns and transactional emails. You can get started with campaigns by downloading the Chrome extension<\/a>; you can test the transactional SMTP<\/a><\/strong> by following these quick instructions.<\/p>\n So let’s put send volume and consistency aside for a moment.<\/p>\n Regardless of\u00a0how<\/em> many you’re sending, there are some universal reasons why your transactional emails might be going to spam<\/strong>.<\/p>\n It’s usually NOT because some spam filter figured the recipient wouldn’t want it \u2014 as I’ve already said a few times, people usually do<\/em> open and act on transactional emails.<\/p>\n Instead, it’s generally because of larger reputation problems or some missing fundamentals.<\/p>\n Setting up authentication is one of those deliverability fundamentals \u2014 maybe\u00a0the<\/em> fundamental. So I’ve got to talk about it here (but if you’ve already heard this broken record before, go ahead and skip on ahead.)<\/p>\n Take the five to 10 minutes to set up SPF<\/a>, DKIM<\/a>, and DMARC<\/a>. If you don’t know what those are, they basically help prove you are who you say you are and you’re authorized to send emails from your domain<\/strong>.<\/p>\n Google, Yahoo, and Microsoft all now require them \u2014 and\u00a0your emails, including transactional emails, will likely not get delivered without them<\/strong>.<\/p>\n Here’s Google’s explicit bulk sender rules (though Yahoo and Microsoft don’t spell them out exactly the same, assume they’re operating pretty similar):<\/p>\n Wondering if you already have some or all of these set up? Here’s a free email authentication tester<\/a> you can run.<\/p>\n Deliverability is weirdly anecdotal. Yes, there are ways to definitively test (I’ll get into those here) \u2014 but a lot of the time, you won’t know until a customer complains. Or until your friend tells you that one of your messages went to their spam folder.<\/p>\n Here are two signals you can use to spot potential deliverability issues early<\/strong>.<\/p>\n Transactional emails usually have pretty high open rates and click-through rates, because people want their receipts and reset links.<\/p>\n That means their open rate is usually pretty high and pretty stable.<\/p>\n So if there’s a sudden drop in your transactional email open rates, that’s a red flag<\/strong>.<\/p>\n (And no, you can’t blame it on the whole “open rates are dead I heard Apple automatically opens all your messages<\/a> and some guy on Reddit said relying on open rates shows I’m an amateur and I don’t want to be an amateur.” Again, transactional open rates are high. So a\u00a0relative<\/em> drop means something, because the pre-fetching number stays consistent.)<\/p>\n The open rate drop is usually a “canary in the coal mine” situation \u2014 once you see that drop, it’s time to get some more definitive information.<\/p>\n Google Postmaster Tools<\/strong> is the first one. While it won’t tell you exactly your spam percentage, it\u00a0will<\/em> show you how your sender reputation is doing. And if it’s in the “poor” range… then yeah, you’re having deliverability issues and need to rebuild.<\/p>\n The other more definitive answer is an inbox placement test<\/strong> (like GMass’s Spam Solver<\/a>). That’s a tool that actually sends your emails to real addresses<\/strong> to monitor if it’s going to the inbox or spam folder.<\/p>\n Transactional emails should<\/em> have high deliverability.<\/p>\n If yours don’t, there are a handful of common reasons why.<\/p>\n Authentication is the one universal; every sender needs SPF, DKIM, and DMARC at any volume. Everything else scales with how much you send to keep your reputation strong:<\/p>\n\n
Transactional Email Deliverability: Table of Contents<\/h2>\n
\n
\n
The Right Approach to Transactional Email Deliverability, Based on Your Volume<\/h2>\n
\n
High volume (~7,500\/day and up): Go with the full playbook<\/h3>\n
\n
Medium volume (>1,000\/day): The trap of the middle<\/h3>\n
\n
Low Volume (<1,000\/day): Piggybacking off an established reputation<\/h3>\n
\n
Can I really<\/em> just send transactional emails through Gmail?<\/h4>\n
Why Transactional Emails Land in Spam<\/h2>\n
\n
Transactional Email Authentication: SPF, DKIM, and DMARC<\/h2>\n
\n
How to Tell If Your Transactional Emails Are Going to Spam<\/h2>\n
Deliverability signal one: Open rates<\/h3>\n
Deliverability signal two: The authoritative sources<\/h3>\n
Transactional Email Deliverability: Takeaways and Next Steps<\/h2>\n