Choosing a Transactional Email Service

Every transactional email provider claims excellent deliverability, and none of them can promise it, because most of what decides delivery is on your side of the connection.

Your domain's reputation, your authentication, your content, your bounce and complaint rates. A provider supplies infrastructure and hygiene. It cannot supply a reputation you have not built. What actually determines delivery.

So the comparison worth making is not whose homepage claims the highest number. It is which service fits how you send. Eight questions decide that.

---

First: is a dedicated service the right answer at all?

Three options, and the smallest one is legitimate.

Your existing mailbox provider's SMTP. Google Workspace, Microsoft 365 or your host's mail service. Reasonable for low volume, already authenticated if your domain is set up there, and free with what you have. The constraint is sending limits designed for a person typing, not a server generating — and no proper bounce reporting or delivery logs.

A dedicated transactional service. Built for application email. Proper logs, bounce and complaint handling, webhooks, an API alongside SMTP. Worth it once email arriving matters commercially, which for most sites means as soon as there is a checkout or a login.

Your marketing platform's transactional feature. Possible where one exists. Watch what it does to your streams — the point of separating transactional from marketing is that campaign complaints do not degrade password reset delivery, and a shared platform can undo that if it shares the sending domain.

A useful threshold: if a message failing to arrive costs you a customer rather than an open, you have outgrown the first option.

---

The eight questions

1. Can you complete domain authentication?

The most important question, and the one that is rarely asked.

Every service will let you send immediately using their own domain. That means your mail authenticates as them, not as you — no alignment with your From domain, and none of the reputation accrues to you.

Ask: does the service support DKIM signing for your own domain, and can you publish the DNS records? If you cannot edit DNS for your domain, no service will fix your deliverability, and that constraint should be resolved before choosing anything. What the records do.

2. What do the logs show, and for how long?

A log is the difference between diagnosing and guessing.

What to look for: per-message status — accepted, delivered, bounced, deferred, complained — with the receiving server's actual response text. The response text is the valuable part, because it names the reason.

Retention matters more than people expect. A problem reported by a customer three weeks after the fact is undiagnosable on a seven-day log.

3. How are bounces and complaints handled?

Sending to an address that hard bounced is one of the fastest ways to damage a sending reputation.

Ask: does the service suppress hard bounces automatically, is the suppression list visible and exportable, and are complaints fed back where the receiving provider supports it?

Automatic suppression protects you from your own retries, which on a WordPress site are usually a plugin re-attempting a failed notification. Why bounce handling matters.

4. Shared or dedicated sending IPs?

Shared is right for almost every small site, and the intuition runs the other way.

A dedicated IP has no reputation until you build one, which requires consistent volume — enough that receivers can form a judgement. Below that volume a dedicated IP performs worse than a shared pool, because a well-managed shared pool carries an established reputation you benefit from immediately.

Ask instead: how does the provider manage its shared pools, and does it segregate by sender quality? A provider that puts careful senders in with careless ones is passing you someone else's reputation.

5. API, SMTP, or both?

Both, and use the API where the plugin supports it.

The API avoids outbound port restrictions entirely, which matters on shared hosting where port blocking is common, and it usually returns better error information than an SMTP conversation does.

Keep SMTP available as a fallback and for tools that only speak it.

6. Does it support subdomain separation?

Sending marketing and transactional mail on the same domain means campaign complaints degrade password reset delivery.

Ask: can you authenticate and send from a subdomain, and can you separate streams within the account so reputation and reporting stay distinct?

Some services handle this natively with separate streams or sub-accounts. On others you configure it yourself. Either is fine; not doing it is the problem.

7. What happens when volume spikes?

Two failure modes worth asking about before they happen.

Rate limits. What is the per-hour or per-second cap, and what happens on exceeding it — queued, or rejected? A store running a sale generates a burst of order confirmations, and a rejection at that moment is the worst possible timing.

Account review. Most providers review accounts whose volume changes sharply, because that pattern also describes a compromised account. Ask how a review is communicated — a pause with an email is manageable; a silent pause is a crisis.

8. How do you get support when mail stops?

The question to ask is not whether support exists but what channel and what hours.

Email support with a one-day response is adequate for configuration and inadequate for an outage. For a store, ask specifically what happens on a weekend.

---

What not to choose on

Three things that look like differentiators and are not.

Headline deliverability percentages. Self-reported, methodology unstated, and measuring the provider's whole customer base rather than your domain. A number with no denominator is marketing copy.

Free tier size. It determines the first month and nothing after. Choose on fit, then check the pricing is tolerable at the volume you expect in a year.

Template builders. Transactional email is generated by your application, not designed in a builder. A good builder on a service with seven-day logs is a bad trade.

---

A reasonable default

For a small WordPress site or store, without naming anyone:

• A dedicated transactional service, on a shared IP pool
• Domain authentication completed, with DKIM records published and SPF updated
• API integration where the plugin supports it, SMTP otherwise
• A subdomain for marketing, the main domain for transactional
• Bounce suppression on, and the suppression list checked occasionally
• Logs long enough to diagnose something reported a month late

Then verify it worked rather than assuming, by reading the Authentication-Results header of a message that arrived. How to check.

---

Frequently asked questions

What is a transactional email service?
A service built for application-generated email — password resets, receipts, order confirmations, notifications — as distinct from marketing campaigns. It provides authenticated sending infrastructure, delivery logs, bounce and complaint handling, and usually an API alongside SMTP.

Do I need one, or is my mailbox provider enough?
Your mailbox provider's SMTP is workable at low volume and gives you no delivery logs or bounce reporting, with sending limits designed for a person rather than a server. Once a message failing to arrive costs a customer rather than an open, a dedicated service is worth it.

Should I get a dedicated IP address?
Almost certainly not at small volume. A dedicated IP starts with no reputation and needs consistent volume to build one, so below that threshold it performs worse than a well-managed shared pool that already carries an established reputation.

Does a transactional service fix my deliverability?
It fixes transport and gives you the tools. Delivery still depends on your domain's authentication, reputation, content and complaint rates — all of which sit on your side. A service cannot supply a reputation you have not built.

Should transactional and marketing email use the same service?
They can, provided the streams and sending domains are separated. The reason to separate them is that complaints from marketing degrade the reputation your password resets depend on, so a shared sending domain undoes the protection regardless of how many services are involved.

How do I compare providers' deliverability claims?
You largely cannot. The figures are self-reported, the methodology is unstated, and they measure the provider's whole customer base rather than your domain. Compare on authentication support, log depth and retention, bounce handling, stream separation and support hours instead.