Maybe it’s a WordPress contact form wired through a Gmail address. Maybe it’s a CRM, an invoicing app, or a scanner in the office. It worked for weeks. Then this morning it started bouncing everything with an error like 550 5.4.5 Daily user sending limit exceeded, and now you’re trying to figure out what the limit actually is and when it resets.

Here’s the whole picture in one table. If the number is all you came for, you’re done. If you want to know how each cap really works, what error string you’ll see, how long you’re locked out, and what to do about it before end of day, keep reading.

Every major provider’s sending limit

All figures verified against each provider’s official documentation as of August 2026. These change. We’ll keep this table current, the same way we do for our own limits page.

Two things before the provider-by-provider detail, because they trip up almost everyone.

How the counting actually works

Nearly every limit runs on a rolling 24-hour window, not a calendar day. If your app burned through Gmail’s 500 by 2pm, you don’t get a fresh 500 at midnight. You get sends back gradually as the messages from 24 hours ago age out of the window. This is the single most common misunderstanding we see in support tickets about provider limits.

Providers don’t all count the same thing. Microsoft’s headline 10,000 is a recipient count, layered with a separate 30-messages-per-minute rate. Yahoo counts each recipient separately too. Google runs two meters at once, messages per day and recipients per day, and blocks you at whichever fills first: one message to 100 people is one message but 100 recipients, so recipient-heavy sending drains the recipient caps long before the message cap. iCloud does the same double-metering, with messages and total recipients as independent daily caps.

So “how many emails can I send” is usually the wrong question. The right one is “how many recipients, how fast.”

There’s also a scheduling trap hiding in the rolling window. Quota returns exactly 24 hours after it was spent, so an automated system that fires its whole daily volume at the same time every morning (a 6am digest cron, a nightly batch invoice run) ends up chasing its own tail: capacity comes back at precisely the moment the next burst wants it, and any overrun compounds into tomorrow. Spreading sends across the day keeps quota trickling back continuously. Or, honestly, stops the cap from being your scheduling problem at all, which is the relay argument in one sentence.

Gmail (free accounts): the 500 that ends most DIY setups

The free Gmail limits, per Google’s own documentation:

• 500 messages per rolling 24 hours through the web interface, and Google also meters total recipients, so a message to 30 people burns 30 recipient slots
• 100 recipients per message when sending through SMTP, POP or IMAP, which is how your WordPress plugin, script, or CRM connects
• 500 recipients per message on the web

Hit the cap and Gmail rejects further sends with 550 5.4.5 Daily user sending limit exceeded (or the in-browser banner “You have reached a limit for sending mail”). The block lasts up to 24 hours, there’s no counter showing how close you are, and there is no way to buy, request, or negotiate a higher number on a free account. None.

Worth being straight about one thing: the daily SMTP allowance is genuinely murky. Half the articles on this topic state 100 emails per day over SMTP as fact; others say SMTP draws from the same 500 pool as the web interface and only the per-message recipient cap is 100. Google’s help page doesn’t settle it. So we tested it, and our test account hit the wall just past 100 SMTP sends (full write-up below). Whatever the documentation implies, plan on ~100 as the practical SMTP ceiling.

Two more Gmail realities worth knowing if you’re relaying an application through it:

You need an app password now. Google removed “less secure app” access, so any script or device authenticating with your normal password will fail. You’ll need two-step verification enabled plus a 16-character app password. If your device predates TLS 1.2, it may not connect at all.

Your mail may say “via gmail.com” or show sent “on behalf of” your address, which looks off to recipients and hurts trust. We covered that quirk (and the fix) in this post on avoiding Gmail’s “on behalf of” message.

Honestly, Gmail SMTP is fine for what it’s designed for: a person, sending person-sized volumes. It was never meant to be application infrastructure. The 500 cap (really ~100 over SMTP) is where most people discover that.

Google Workspace: 2,000 per day, with sub-limits underneath

Paying for Workspace roughly quadruples the headline number, per Google’s Workspace limits page:

• 2,000 messages per rolling 24 hours per user (1,500 if you’re using mail merge; only 500 while your account is on a trial)
• 10,000 total recipients per day, of which at most 3,000 external and just 2,000 unique external
• Per message: 2,000 recipients total, 500 of them external. But that’s via the web. Over SMTP, POP or IMAP the per-message cap drops to 100 recipients, and via the Gmail API it’s 500

That unique-external sub-limit is the one that catches businesses. Your update to 2,500 customers is over the cap even though it’s nowhere near 10,000 total recipients. And the penalty is the same as free Gmail: up to 24 hours of blocked sending, mid-campaign, with no override. One more trap for anyone setting up a fresh account: the trial-tier 500 ceiling doesn’t lift the moment you add a card. It lifts only after the account has genuinely converted to paid, so a “new mailbox” plan built on the 2,000 figure can quietly run at a quarter of that.

Workspace admins do have one extra lever: Google’s SMTP relay service (smtp-relay.gmail.com), which carries a separate quota of up to 10,000 messages per day per user for devices and apps. It helps. But it’s fiddly to configure per-IP, and it still ties your application’s deliverability to your staff mailboxes’ domain reputation, which is exactly the coupling you want to avoid.

One date-stamped note: since February 2024, Google and Yahoo require any sender pushing 5,000+ messages a day to Gmail addresses to have SPF, DKIM, and an enforced DMARC policy, one-click unsubscribe on bulk mail, and a spam complaint rate under 0.3%. We wrote up the full requirements in Gmail and Yahoo’s inbox protection rules. If you’re approaching Workspace’s caps, you’re approaching those thresholds too.

Microsoft 365 / Exchange Online: generous on paper

Microsoft’s published numbers look roomy. The layers underneath are where sending actually breaks. From Microsoft’s Exchange Online limits documentation and their outbound sending limits troubleshooting guide:

• 10,000 recipients per mailbox per rolling 24 hours (the “recipient rate limit”)
• 2,000 of those can be external (the External Recipient Rate limit, phased in across tenants from 2025). Hit it and external sends block until the window rolls over, while internal mail keeps flowing
• 30 messages per minute per mailbox. Exceed it and Exchange doesn’t bounce your mail, it delays it, carrying the excess into the following minutes. This is why “Microsoft 365 is sending slowly” tickets are usually not a Microsoft outage
• 500 recipients per message by default, though an admin can raise individual mailboxes to 1,000
• 3 concurrent connections for SMTP AUTH submission

Then there’s the layer most articles miss entirely: the Tenant External Recipient Rate Limit (TERRL), a cap on how many external recipients your whole organization can email per day, scaled to your license count (Microsoft’s formula is 500 × licenses^0.7 + 9,500, with trial tenants held to 5,000). Blow through it and every mailbox in the company starts generating 550 5.7.233 bounces (550 5.7.232 on trial tenants). A single runaway script or a compromised mailbox can exhaust the tenant’s entire external quota and take everyone’s outbound email down with it. You can check your tenant’s number in the Exchange admin center’s Tenant Outbound External Recipients report.

And if you’re wondering whether Microsoft intends any of this headroom for application or bulk sending, their limits documentation answers it directly: “Exchange Online isn’t suited to accommodate bulk-mailing scenarios.” Their words.

And the authentication clock is ticking. As of Microsoft’s January 27, 2026 update, Basic authentication for SMTP AUTH keeps working until the end of December 2026, at which point it’s disabled by default for existing tenants (admins can temporarily re-enable it), unavailable entirely for new tenants, with final removal to be announced in the second half of 2027. When it goes, every printer, scanner, and legacy app authenticating to smtp.office365.com with a username and password gets 550 5.7.30 Basic authentication is not supported for Client Submission. We keep a full timeline and migration options in our guide to the end of Microsoft’s Basic authentication.

Fair’s fair: Microsoft does offer its own paths for higher volume, High Volume Email and Azure Communication Services. If your mail is entirely internal to your tenant, HVE is worth a look before you pay anyone anything. For external, customer-facing mail from apps and devices, both options involve more Azure plumbing than most IT teams want for the job a relay does in twenty minutes.

Outlook.com (consumer accounts): the limit Microsoft won’t publish

Free Outlook.com, Hotmail, and Live accounts have deliberately fuzzy limits. Microsoft states them as “variable, based on account history and reputation.” In practice, established free accounts land around 300 recipients per day, new accounts get far less, and Microsoft 365 Personal/Family subscribers can reach up to 5,000 recipients per day with 500 per message. There’s a catch inside that 5,000, though: only 1,000 per day can be non-relationship recipients, meaning addresses the mailbox has never emailed before. For anything automated, where nearly every recipient is new to the mailbox, 1,000 is the real number, not 5,000.

The bigger issue for anyone relaying an app through a consumer account: Microsoft removed Basic authentication from personal accounts back on September 16, 2024. If your device or script stopped sending through smtp-mail.outlook.com around then and never recovered, that’s why, and no setting brings it back.

Yahoo Mail: 500 a day, 100 per message

Yahoo documents limits on sending at 500 messages per day with a maximum of 100 recipients per message, and each recipient counts toward the daily total. There’s an unofficial hourly throttle most senders peg around 100. Yahoo requires an app password for SMTP, same as Google.

There’s not much more to say, which is sort of the point. Yahoo SMTP is for a person with a Yahoo inbox. Nobody should wire a business system to it in 2026.

iCloud Mail: two counters, and whichever fills first wins

Apple documents iCloud’s limits cleanly: 1,000 messages per day, 1,000 total recipients per day, 500 recipients per message, 20MB per message (up to 5GB via Mail Drop). What’s unusual is the failure mode. On an iPhone or Mac, over-limit messages don’t bounce with a server error; they quietly park in your Outbox with “A copy has been placed in your Outbox.” People assume the mail went. It didn’t. If you’re troubleshooting “sent but never arrived” from an Apple device, check the Outbox before you check anything else. We see this constantly, and we wrote up the broader pattern in emails stuck in the Outbox and won’t send.

Shared hosting: hourly caps and silent queues

If your website sends through your web host’s mail server (the default for most cPanel WordPress installs), your caps are set by the hosting plan, they’re usually hourly, and they’re usually low. Commonly published figures: Bluehost around 150 emails/hour, DreamHost 100 recipients/hour, SiteGround up to 800/hour with 80 recipients per message, HostGator 500/hour, GoDaddy’s email plans in the 250–500/day range.

Hosts fail differently than mailbox providers, and worse. Some bounce with a 550 quota error. Plenty just queue the overflow and dribble it out, so your “instant” order confirmations arrive four hours late and nobody tells you. And because you share the server’s IP with hundreds of strangers’ websites, your deliverability rides on their behavior. One compromised site on the box and everyone’s mail starts landing in spam. That reputation problem doesn’t show up in any limits table, but it’s the real reason host SMTP mail underperforms, cap or no cap.

I hit the caps on purpose, so you don’t have to

To document the failure modes rather than paraphrase them (and to settle the 100-versus-500 SMTP question the rest of the internet keeps contradicting itself on), I set up a fresh free Gmail account, connected it to a test WordPress site with an SMTP plugin over port 587, and pointed a form-fill script at it.

The messy details are the useful part. The account sent cleanly at a steady pace until send number 102, at which point the server started returning 550 5.4.5 Daily user sending limit exceeded on every attempt. Not 500. Just over 100, because SMTP submission has the lower ceiling, which the plugin’s documentation never mentioned. The plugin retried each failed message three times, so the WordPress error log filled with triplicate failures, and the site owner (me) got no notification at all. A visitor filling in that contact form would have seen a friendly “thanks, we’ll be in touch.” The message went nowhere.

The lockout wasn’t a tidy 24 hours either. Sends started succeeding again in a trickle as the earliest messages aged out of the rolling window, which is exactly the behavior the “resets at midnight” folk wisdom gets wrong.

Repointing the same site at a relay took 14 minutes end to end: create the account, add the CNAME records for domain verification, wait for DNS, swap the SMTP credentials in the plugin. The form backlog cleared in under a minute.

The real cost isn’t the cap, it’s what silently doesn’t send

A marketing email arriving tomorrow is annoying. A password reset that never arrives is a support ticket. An order confirmation that never arrives is a chargeback. When a provider limit trips, it doesn’t pick which of your messages matter; the invoice bounces right alongside the newsletter.

That’s why the businesses that outgrow provider SMTP are rarely “big senders” in the marketing sense. StoredTech, an MSP, has routed mail from phone systems, copiers, and client infrastructure through SMTP2GO since 2011, because a voicemail-to-email notification that arrives four hours late may as well not arrive. And Group IMD grew from 10,000 to over a million emails a month across six years on the same account, without ever re-architecting around a new ceiling. Both stories are on our customer success page.

When you’ve outgrown provider SMTP

You don’t need a relay because a blog told you to. You need one when the symptoms show up:

• You’ve hit a daily cap more than once, or you’re planning volume that will
• Your mail comes from software or hardware (forms, CRMs, ERPs, scanners, alarms) rather than a person at a keyboard
• Recipients say things land in spam, or headers show “via” some other domain
• You’re staring down Microsoft’s Basic auth cutoff with a fleet of devices that will never speak OAuth
• A delayed message costs you money or trust

A relay flips the model. Instead of borrowing capacity from a mailbox designed for humans, your systems send through infrastructure built for exactly this, with authentication (SPF, DKIM, DMARC) set up on your own domain, real bounce reporting, and limits that are business decisions rather than anti-abuse walls. If the concept is new, start with our plain-English introduction to SMTP relays. For SMTP2GO specifically, every one of our caps, and how to lift each, is documented on our own sending limits page: free accounts get 1,000 emails a month at up to 200 a day (plenty for testing or a small site), and paid plans scale to millions with a default speed of 200,000 an hour.

And to be straight with you about the other side: if you’re a person sending 20 emails a day from your own mailbox, you don’t need us or anyone else. If your Microsoft 365 mail never leaves your tenant, look at Microsoft’s High Volume Email first. Provider limits only become your problem when your sending stops being personal. For most people reading a page like this one, that day was today.

This guide does both jobs. If you’re setting up a printer or scanner from scratch, start right here. If yours was working and stopped, or errors out mid-setup, jump to the troubleshooting section and match the exact message on the screen to its fix.

The five settings every device needs

Every scan-to-email setup, on every brand, comes down to the same five values. Your printer builds the email; an SMTP server delivers it. The settings just tell the printer which server, how to connect, and who it’s allowed to send as.

1. SMTP server (host): the mail server’s address, like mail.smtp2go.com.
2. Port: the door the printer knocks on. 587 is the modern default.
3. Encryption: STARTTLS (usually shown as “TLS”) on 587, or SSL on 465. This must match the port.
4. Authentication: a username and password the server accepts. This is where most setups fail, and where most working setups later break.
5. From address: who the scans appear to come from. Increasingly, this address’s domain needs SPF and DKIM records or the scans land in junk.

Everything else on the settings screen is cosmetic.

A complete worked setup, filled in

Here’s a full configuration using SMTP2GO as the sending service, because it works identically across brands and doesn’t depend on which email provider your office uses. The same five fields apply if you point the device elsewhere; only the values change.

Step 1: Create credentials for the device. In your SMTP2GO dashboard, go to Sending > SMTP Users and add a user just for this device, something like office-copier-01. Two deliberate choices here: it’s not a person’s email account, so nobody’s password change can break it, and it contains no “@” symbol, because some printer panels mishandle usernames that look like email addresses, a quirk our support team has run into more times than anyone would like.

Step 2: Verify your sending domain. Under Sending > Verified Senders, add the domain the scans will send from and publish the SPF and DKIM records it gives you. Skip this and your scans may still send, straight into junk folders. The verified senders guide walks through the DNS records.

Step 3: Open the printer’s admin interface (see the per-brand table below) and enter:

If 587 won’t connect on your network, don’t fight the firewall. SMTP2GO also accepts TLS or unencrypted connections on 25, 2525, 8025, and 80, and SSL on 465, 8465, and 443. Port 2525 gets copiers out from behind stubborn firewalls more often than any firmware update, and 443 looks like ordinary web traffic to almost every network. Details in the ports and secure connections guide. It’s the reason device manufacturers like it here: OPW Electronic Systems, which sends alerts from proprietary fuel-monitoring equipment on customer networks it doesn’t control, put it plainly: “The flexible number of available communication ports allows our equipment to work on almost all network configurations.”

Step 4: Send a test scan to an external address, not just a colleague on your own domain, for reasons covered in the FAQ.

Step 5: Confirm delivery on the SMTP2GO Activity page, which shows the scan as delivered, bounced, or deferred with the receiving server’s exact response. “Did it actually send?” stops being a mystery.

The settings take about two minutes to enter. Finding the settings screen is the slow part, which is what the next section is for. And when a first test scan fails, it’s nearly always one of the same three things: a panel that silently truncated a long password, port 587 filtered on the office network (switching to 2525 fixes that in seconds), or an unverified From domain sending the test straight to junk. Check those three before assuming anything is broken.

Where the settings live, brand by brand

Menu names drift a little between models and firmware versions, but every brand puts SMTP settings in its web-based admin interface, reached by typing the printer’s IP address into a browser.

More device and software walkthroughs live in the setup guides library.

Choosing what the printer sends through

You have three realistic options for the server in that table, and the right one depends on how much fragility you can live with.

Your Microsoft 365 tenant (smtp.office365.com). Works, for now, with a licensed mailbox and its password. But this is exactly the configuration Microsoft is retiring, covered in the next section, and it means a machine’s ability to send email depends on a human account’s password never changing.

Gmail or Google Workspace (smtp.gmail.com). A lot of small offices go this route because the account already exists. Know the constraints going in. Plain password sign-in from apps is gone, so the printer needs an app password, which requires 2-step verification on the account and gets revoked whenever the account password changes. Every password rotation becomes a printer outage. And Google caps sending at 500 messages a day on a free Gmail account and 2,000 a day on Google Workspace, which sounds like plenty until a document-heavy office or a fleet of devices shares one account and hits the wall mid-afternoon. Fine for one home-office device. Fragile for anything more.

A dedicated SMTP relay (SMTP2GO). The device gets its own credentials that no human password rotation can touch, one set of settings works across every brand and every site, eight ports mean firewalls stop being an argument, and provider deprecation timelines become someone else’s problem. This is the durable option, and it’s the one thing in this list actually designed for machines that send email.

Honest caveat: if your fleet is new, OAuth-capable, and scans mostly stay inside your own organization, Microsoft’s native methods are supported and free, and you should use them. The relay earns its keep with mixed-age hardware, multiple sites, no static IP, or a preference for configuring this once and never thinking about it again.

The Microsoft 365 deadline, and why it’s coming for your copier specifically

If your devices send through smtp.office365.com with a username and password, put this on the calendar.

Microsoft is retiring basic authentication (password sign-in) for SMTP. Personal outlook.com accounts already lost it in September 2024. For business tenants, Microsoft’s current timeline, revised in January 2026, runs: no change through December 2026, then disabled by default for existing tenants at the end of December 2026 (admins can re-enable it, for now), unavailable entirely on tenants created after that, and a final removal date to be announced in the second half of 2027. When it bites, the device shows some variant of authentication failure and the server logs 550 5.7.30 Basic authentication is not supported for Client Submission.

Multifunction printers are the most exposed devices in the building, for a boring reason: an installer configured them once, years ago, with a mailbox password nobody has touched since. They’ll keep working until the exact moment a tenant setting flips. And “disabled by default” means the flip can come early, from a security cleanup, Security Defaults being enabled, or a Conditional Access change, not just from Microsoft’s deadline.

How to tell if you’re affected: sign in to the Exchange admin center and open Reports > Mail flow > SMTP AUTH Clients Submission Report. Any device or app showing “Basic” is on borrowed time.

Whether your hardware can move to OAuth: support is genuinely uneven. HP offers OAuth scan to email on FutureSmart 5.7 or newer, but only on its Enterprise and Managed lines; consumer and Pro models like the OfficeJet Pro don’t get it. Lexmark added it in FW24, Canon on its unified Firmware Platform 3.18 or newer, and newer Sharp models include it. Xerox doesn’t support OAuth for scan to email at all, and Ricoh and Konica Minolta support is limited and model-dependent. Even inside a “supported” brand it varies by model, so validate on one device before planning a rollout.

Why re-enabling basic auth per mailbox is not the fix: it’s a snooze button. Admins can re-enable it today, but new tenants already can’t, the final removal date is coming, and every re-enable is a security exception someone has to remember, document, and defend at the next audit. You’d be spending effort to stay on a sinking configuration.

The durable fix for devices that can’t do OAuth (and for fleets where per-device OAuth setup is its own project) is an authenticated relay: point every device at mail.smtp2go.com on 587 with its own credentials, and Microsoft’s timeline stops applying to your copiers at all. Full background in our guide to the end of Microsoft’s basic authentication.

This is exactly why managed service providers standardized on relays years before any deadline forced the issue. Mark Shaw of Stored Technology Solutions, an MSP, has run client devices through SMTP2GO for well over a decade: “Since 2011, StoredTech has used SMTP2GO to help phone systems, copiers and printers, and other devices send emails with no headaches and no downtime.” One relay across every client site beats maintaining per-tenant Microsoft configurations that shift underneath you, and there’s a dedicated MSP program if that’s your world.

Troubleshooting: match the error on the screen to the fix

The error message tells you which stage failed. Find yours:

Before touching anything: get the device’s admin password and find out which account or service it’s configured to send through. Without those, troubleshooting stops in about ninety seconds.

Fix 1: “Cannot resolve SMTP server”

The printer can’t turn a hostname into an IP address. Nine times out of ten, someone assigned the printer a static IP and left the DNS fields blank. It prints fine (printing is local) and can’t email at all (email needs the internet, which needs DNS).

In the admin interface, check four values together: IP address, default gateway, preferred DNS, alternate DNS. On a business network, use the DNS servers the network already uses; on a simple one, 8.8.8.8 and 8.8.4.4 will do. Fix DNS and the error will often change to an authentication error. That’s progress, not a new problem: the printer found the server, and now the server is rejecting the login, so move to Fix 3.

Some older devices have DNS handling that’s simply broken. For those, skip the hostname and point the device at an IP address directly using SMTP2GO’s static IP options, which most mail providers don’t offer.

Fix 2: “Connection refused,” gateway not responding, or timeouts

DNS resolved, but the connection never completes. Almost always a port problem. ISPs routinely block port 25 outbound, plenty of networks block 587, and an encryption setting mismatched to the port (SSL selected on 587, or STARTTLS on 465) fails in ways the error won’t explain.

Test the path from any computer on the same network before blaming the printer:

telnet mail.smtp2go.com 2525

A 220 greeting means the door is open. Silence means the network is blocking it, and no printer setting will change that; switch ports instead (2525 and 443 are the great escape artists here). If connections open but die partway through, that’s a different animal, covered in our guide to SMTP timeouts.

While you’re in the admin interface, check the device’s date and time. Sounds unrelated. It isn’t. TLS certificates have validity windows, and a printer whose clock reset to 2019 after a power cut will fail every secure connection with maddeningly vague errors.

Fix 3: “Authentication failed” (535 errors)

The printer reached the server and the server said no. In order of likelihood:

The password changed. If the device authenticates with a person’s account and that person changed their password or left the company, scan to email died at that moment. Update the stored credentials, then read the worked setup above for why a machine shouldn’t borrow a human’s account in the first place.

The username has special characters. Some panels mishandle usernames containing “@” or store invisible trailing spaces. If you’re certain the credentials are right and it still fails, this is worth suspecting. SMTP2GO usernames don’t need to be email addresses (yours are under Sending > SMTP Users), which sidesteps the whole bug class.

The account requires an authentication method the printer doesn’t speak. The 2026 problem. See the Microsoft deadline section, and if the device can’t do standard SMTP authentication at all, there are alternatives, including authenticating by IP address.

One warning: don’t keep retrying guessed passwords against a Microsoft 365 or Google account. Repeated failures can lock it, and now you have two outages.

Fix 4: “550 Relay access denied” or “Unable to relay”

The server accepted the connection but refuses to carry your message. Two usual causes. Either authentication is switched off on the device (some setups “work” unauthenticated for internal mail only, then throw this the first time someone scans to an outside address), or the From address isn’t one the server permits. Turn SMTP authentication on with valid credentials, and make sure the From address belongs to a domain the service allows you to send as. On SMTP2GO that means a verified sender. More on the whole 550 family in our 550 error guide.

Fix 5: The panel says “Complete” but nothing arrives

The printer did its job; the message got filtered, bounced, or quarantined downstream. Three suspects:

File size. Scanner PDFs balloon fast. A 20-page color scan at 600 dpi can blow past the 25 MB cap common at major mailbox providers, and many devices report success anyway. Test with a one-page black-and-white scan. If the small one arrives and the big one doesn’t, drop resolution to 200 or 300 dpi and scan documents in black and white. More in the Goldilocks theory of email file sizes.

The From address is failing authentication. If the domain’s SPF and DKIM records don’t authorize the sending server, receiving servers treat every scan as a possible forgery. Some junk it, some silently drop it. Verify the sending domain (Step 2 of the worked setup) even if scans are currently arriving; it’s the difference between arriving and arriving in the inbox.

Recipient-side filtering. Check spam and quarantine. Scans are attachment-heavy messages from an unfamiliar sender, which also describes a lot of malware, so filters distrust them by design.

With a relay in the middle there’s no guessing at this stage: the Activity page shows delivered, bounced, or deferred with the receiving server’s exact words.

Fix 6: Works for some recipients, not others

The printer, network, and configuration are fine. Check the failing addresses for typos and stale address book entries first; a surprising number of “broken” copiers are faithfully emailing someone who left in 2022. If the addresses are right, the receiving domain is filtering you, and the verified sender fix is your strongest lever. Test one known-good external address, then add failures back one at a time until the pattern shows itself.

It worked yesterday. What changed?

When something that ran for years stops overnight, resist the factory reset. It erases the address book, network config, and SMTP settings, and fixes nothing if the change happened outside the printer. Run this list instead: Did anyone’s password change? Did IT enable Security Defaults or tighten Conditional Access? New firewall, new ISP, new VLAN? Firmware update? Power cut (clock drift, Fix 2)? Provider requirement change (the Microsoft section)? The date scan to email died is your best clue. Something changed that day, and finding it beats rebuilding everything and rediscovering it later.

Keep it from breaking again

Five minutes of discipline prevents most future 7 a.m. “copier’s down” calls. Give each device (or each site, if you’re an MSP) its own SMTP user, so one revoked credential never takes down the fleet. Verify the sending domain so scans go out SPF-aligned and DKIM-signed. Write the working configuration down somewhere that isn’t the printer. And update firmware on a schedule rather than in a panic, because updates occasionally reset SMTP settings, and you want to notice on your own terms.

[FAQ]

Still stuck?

Some of these failures are genuinely miserable to diagnose from a two-line touchscreen. If you’ve worked through the fixes and the device still won’t send, contact our support team. They’re humans, they’re around 24/7, and printer tickets are something they untangle every day. And if you’d rather take the email provider variable out of the equation for good, SMTP2GO is free to try for up to 1,000 emails a month, which covers a lot of scanning.

We’re proud of that. But a ranking on its own doesn’t help you choose an SMTP server, and most award announcements stop exactly where they should start. So this page gives you the rest: the full test scores, every major free tier laid out with its real limits (daily caps, credit cards, expiry dates, the catch), and honest notes on where a competitor is genuinely the better fit. Yes, we sell one of the services below. The deliverability numbers come from EmailToolTester’s testing, and every allowance was checked against each provider’s own documentation in August 2026. Where we couldn’t confirm something, we’ve said so instead of guessing.

If you just want the answer:

• Best free SMTP server, per independent testing: SMTP2GO, ranked #1 by EmailToolTester three years in a row. 1,000 emails a month, no credit card, no expiry, 96% average deliverability across their four Glockapps rounds.
• Best for developers on modern stacks: Resend. 3,000 a month, lovely API, hard 100/day ceiling.
• Best for testing without sending: a capture sandbox (Mailtrap’s testing product, or free local tools like Mailpit), not a real relay. More on that below, because it’s a different job.
• Skip: SendGrid, whose free plan no longer exists, and Amazon SES if you’re opening a new AWS account, for reasons that surprise most people.

The rest of this guide is the fine print, starting with the test itself.

The test that put SMTP2GO at #1 for email delivery

EmailToolTester doesn’t hand out that ranking on vibes. They ran four separate rounds of deliverability testing across nine transactional email providers, using Glockapps to send test emails to a seed list of more than 20 international mailbox providers (Gmail, Outlook, Yahoo, and the rest), then recorded what reached the inbox, what hit spam, and what never arrived. Along the way they checked each provider’s server reputation, SPF, DKIM, and DMARC authentication, and blocklist status.

The averages across all four rounds:

Source: EmailToolTester’s free SMTP server testing, most recently updated August 2026. SendPulse and Mailtrap appear in their scores but sit outside our comparison table below; their write-up covers both.

Three honest notes on those numbers, because a winner quoting a test owes you the caveats. First, the one place SMTP2GO’s mail got flagged was Yandex.ru, and every provider in the test failed there too. Second, EmailToolTester’s own view is that once you’re sending real volume, your domain’s reputation matters more than the relay carrying it; they put the provider’s share of the outcome at roughly 30%. Third, Elastic Email’s 60% doesn’t mean 40% of every sender’s mail vanishes forever, it means a lot of seed-test mail landed in spam folders. Directionally, though, that spread is the whole story. On a free plan you can’t buy your way off a bad shared IP, so the provider’s baseline is the biggest lever you control. A free allowance that lands in spam is worth nothing. 1,000 emails delivered beats 9,000 emails filtered.

One more reason an independent #1 matters on this particular topic: look at who publishes the other “best free SMTP server” lists sometime. Nearly all of them are providers ranking themselves first. Brevo’s list crowns Brevo, UniOne’s crowns UniOne, Mailtrap features Mailtrap prominently. We’re a provider too, which is exactly why we’d rather point at someone else’s test than grade our own homework.

Now, what each free tier actually gives you.

Free SMTP servers compared

Sources: provider documentation and pricing pages, August 2026; deliverability averages from EmailToolTester’s four-round Glockapps testing of nine transactional providers.

Per-day caps vs. monthly allowances

Here’s the thing the headline numbers hide. Transactional email is bursty. Nobody resets their password on a schedule.

Brevo’s ~9,000 a month sounds nine times more generous than SMTP2GO’s 1,000. But it arrives as a hard 300-per-day drip. If your store sends 450 order confirmations on a busy Saturday, 150 of them wait until Sunday. For a newsletter, that’s annoying. For receipts and password resets, it’s a support queue.

A monthly allowance with a high daily ceiling behaves the opposite way: it absorbs spikes and runs out gracefully, with warning, at the end of the month. So the right question isn’t “which number is bigger.” It’s “does my sending arrive in bursts or a drip?” Apps burst. Newsletters drip. Pick the shape that matches, then the size.

One more piece of arithmetic worth doing before you choose anything: 1,000 a month is about 33 emails a day. 500 a month is 16 a day. If your app has 300 active users and sends each of them a welcome email, a verification email, and the occasional reset, you’ll clear 500 in the first week. Count your emails per user per month, multiply, and be honest.

The fine print, provider by provider

SMTP2GO (that’s us). The free plan is 1,000 emails a month with no card and no expiry, and it includes things most providers gate behind payment: 24/7 human support via ticket, team access for multiple users, and the option of EU-hosted sending servers if GDPR data residency matters to you. The honest limitations: reporting history is 5 days on the free tier, new accounts start with a 25-per-hour rate limit (a quick support ticket lifts it), and the plan tops out at 200 a day. And the deliverability isn’t our claim to make: EmailToolTester has ranked this free plan #1 for three consecutive years now, full scores above. Any relay can have one good testing round. Three years of them is the part we’re actually proud of, because it means the result survives IP changes, volume growth, and whatever the mailbox providers changed that quarter.

Brevo. If you want the most free volume plus a full marketing suite (campaign editor, automations, CRM), Brevo is genuinely the right pick, and we’d rather tell you that than have you find out later. The trade-offs are the 300/day cap and deliverability that tested mid-pack at 80%, with rounds where Outlook and Hotmail junked a lot of its mail. Fine for a newsletter you can resend. Riskier for a receipt someone’s waiting on.

Mailjet. Similar shape to Brevo: 6,000 a month, 200 a day, newsletter tooling included, decent 85% average in testing. Two things to know before you commit. Free emails carry Mailjet branding, and free-plan support is documentation-only, so when delivery to one mailbox provider goes sideways you’re on your own.

Resend. The developer favorite, and deservedly so if you live in a modern JavaScript stack: clean API, React Email templates, quick setup. The free plan is 3,000 a month with a hard 100/day cap, one verified domain, and a quota that counts received emails too, which surprises people running inbound. Do the math and 100 a day is the real number; the 3,000 is mostly decorative.

MailerSend. A solid product with a shrinking welcome mat. The free allowance went from 12,000 a month to 3,000, then dropped to 500 a month with a 100/day cap in December 2025, and new accounts need approval before full sending. Activity data is retained for one day on the free plan, which makes debugging yesterday’s bounce an act of memory. It tested well for deliverability (87%), so if you’re paying anyway it’s a fair choice. As a free plan, it’s now for trying the product, not running on it.

Amazon SES. The cheapest way to send email at scale, full stop: $0.10 per 1,000 emails, pay as you go. But the “free SMTP server” framing is now mostly a memory, and a lot of roundups haven’t caught up. The famous 62,000-free-emails-from-EC2 tier died in August 2023. Its replacement, 3,000 free message charges a month for your first 12 months, was then closed to new customers: AWS accounts created since July 15, 2025 get up to $200 in general AWS credits instead, usable for 6 months, and as of July 2026 the SES-specific free tier isn’t offered to new signups at all. Add the sandbox (new accounts can only email verified addresses until you file a production access request and wait on a human review), no support without a paid support plan, and DNS you configure entirely yourself, and SES is best understood as excellent plumbing for engineering teams, not a free plan for a small business. We’ve onboarded plenty of ex-SES users; ThinkPorch moved to SMTP2GO after waiting days on AWS support during a delivery incident, which is the failure mode to price in: SES is cheap right up until you need a person.

Postmark. Beautiful deliverability (94% average, second in testing) and a strong reputation among developers. But the free tier is 100 emails a month. That’s an evaluation allowance for testing the API, and Postmark is upfront that quality costs money, with paid plans from $15. One more consideration for European senders: Postmark hosts data in the US only, with no EU residency option.

Elastic Email. Cheap paid plans, likable live chat support, and the worst free-tier deliverability in the independent tests at 60%, which Elastic’s own support attributed to the shared IPs free accounts sit on. A free plan that lands in spam isn’t free. It costs you every email it eats.

Gmail’s free SMTP server

Yes, Gmail gives you a real SMTP server (smtp.gmail.com) for nothing, and for a personal script that emails you a daily report, it’s honestly fine. Here’s where it stops being fine.

A personal account can send around 500 emails per rolling 24 hours, with a cap on recipients per message. Blow the limit and Google doesn’t queue your mail; it locks sending for up to 24 hours, mid-burst, no appeal. Your From address has to be your @gmail.com address, which looks exactly as professional as it sounds on an invoice. The 2,000/day tier everyone cites belongs to Google Workspace, which is a paid product, so it’s not a free SMTP server, it’s an SMTP server you’re already paying for. And application email needs things Gmail’s relay simply doesn’t do: bounce categorization, suppression lists, delivery logs you can search, webhooks. When an email fails, you find out from a customer.

So: hobby scripts, yes. Anything a business depends on, no. If you’re currently wiring a web app or a printer to Gmail SMTP, an actual relay (here’s a plain-English intro to what a relay does) will cost you the same $0 and fail you far less often.

Free SMTP for testing: you might not want a real server at all

“Free SMTP server for testing” is a different question from “free SMTP server,” and mixing them up is how test emails end up in real customers’ inboxes. Ask anyone who’s run a staging environment against production credentials exactly once.

For development and QA, what you usually want is a capture tool: something that accepts SMTP traffic and shows you the email without delivering it. Mailtrap’s testing sandbox is the best-known hosted option, and open-source tools like Mailpit or smtp4dev do the same job locally for free, no account at all. Your app thinks it sent the email. Nobody receives it. Perfect.

You need a real relay in testing for exactly one class of problem: verifying the production path itself, meaning SPF, DKIM, and DMARC alignment, TLS negotiation with a legacy device, actual inbox placement. For that, use a real provider on a dedicated subdomain so your experiments can’t bruise your main domain’s reputation. SMTP2GO also has a sandbox mode that accepts and logs messages through the real pipeline but never delivers them, which is the middle ground: real authentication, real logging, zero risk of emailing a human.

I set up a free plan from scratch…

I’ve walked a lot of customers through this since 2015, but for this article I did it clean: new account, new test domain, timer running.

Sign-up needs a work email and no card. The step that actually matters, and the one people skip, is adding a sender domain: three CNAME records covering DKIM, the return path, and link tracking. Skip this and your mail goes out technically, but authenticated against a shared domain instead of yours, and in 2026 that’s a spam-folder lottery. Google and Yahoo have required DMARC-aligned authentication for bulk senders (5,000+ messages/day to their mailboxes) since February 2024, and the direction of travel for smaller senders is identical.

The messy reality, because there always is some: my registrar auto-appended the domain to the CNAME host value, so the record briefly published as em1234.example.com.example.com. A classic. The dashboard’s verification check caught it, I trimmed the host field, and re-verified. If your registrar supports it, SMTP2GO can now add the DNS records for you automatically, which removes this entire category of typo.

Then: create an SMTP user, point your app or device at the server on port 587, and send. If 587 times out you’re almost certainly behind a firewall or ISP that blocks it; switch to 2525, which exists for exactly this reason, and which several cloud hosts prefer anyway. Watch the first sends land in the Activity page, check the DKIM pass, done.

Two things I tell every new free-plan user. First, the initial 25/hour rate limit is real and it will queue a burst; open a ticket and we remove it, usually quickly. Second, when an address hard bounces we suppress it automatically, so if a test address “stops working,” check the suppression list before you check anything else. That behavior protects your sender reputation, but it confuses people on day one. (More on hard vs. soft bounces here.)

When free is enough, and when it isn’t

Free is genuinely enough for a lot of senders, and we’d rather you use our free plan forever than pay for volume you don’t send. Under about 30 emails a day, any of the monthly-allowance providers above will carry you indefinitely.

The upgrade trigger usually isn’t volume. It’s consequence. You should pay for email the day a failed email starts costing money: missed order confirmations becoming support tickets, a password reset that didn’t arrive becoming a churned customer, a copier’s scan-to-email silently dying at month’s end because the free quota ran out on the 26th. At that point the things worth paying for aren’t more emails, they’re longer log retention, support that answers at 3 a.m., and a sane path to warming up higher volumes when you grow. Rough rule: past 1,000 to 2,000 emails a month, or the first time you screenshot a delivery log for a customer, look at paid plans. If you’re weighing full paid services against each other, we’ve written an honest comparison of the best transactional email services too.

[FAQ]

Whichever provider fits, set up your sender domain before you send anything that matters. It’s twenty minutes that decides whether the next year of your email lands in inboxes or in spam.

And if what you want is the free plan an independent tester keeps ranking first (real deliverability on a small volume, humans answering support, no card, no clock), the SMTP2GO free plan is here. It’s free for as long as you like.

The 5 picks in 60 seconds

If you don’t have time for the full piece, here’s the shortlist.

How we narrowed the field

Honest disclosure first. We’re SMTP2GO. We’re not going to pretend the ranking is unbiased, and we’re not going to invent test data we didn’t run. What we have done is read the providers’ docs, configured most of them ourselves over the years, pulled the most current independent test data we trust, and weighted picks toward what we see customers actually need.

Two third-party sources do most of the heavy lifting on numbers:

1. EmailTooltester’s 2026 transactional email test. Four rounds, GlockApps seeding, the major mailbox providers (Gmail, Outlook, Yahoo, AOL, GoDaddy, Zoho). Real inbox placement, not opens. We cite their per-round numbers in each provider section.
2. Knock’s API performance benchmarks (Feb 6 - May 7, 2026). Hundreds of millions of real production sends across ten providers. Median (p50) and tail (p99) API response time, plus error rates. Useful when API latency actually matters to your product, which is more often than you’d think.

A few providers in the field weren’t in either dataset (Mailgun, SES). Where that’s the case, we say so and judge them on architecture, documentation, support track record, and customer feedback from G2, Trustpilot, and Capterra. We don’t make up scores.

We also weighted by what we see day to day in the trenches: not every reader is a Resend-using Next.js dev. Many are sysadmins setting up a copier to email scanned PDFs, an MSP running 80 client accounts, or a SaaS founder who just wants password resets to land.

1. SMTP2GO - Best overall for most senders

Best for: mixed-team senders (devs + ops + marketing); MSPs running multi-tenant deployments; businesses with device-generated email (copiers, MFPs, phone systems, security cameras, ERPs); SMBs that don’t want to be their own postmaster.

Not for: AWS-native teams sending 50M+/month who treat deliverability as an in-house ops problem (use SES). Teams whose entire job is the lowest possible time-to-inbox on critical app email and have budget to match.

Free plan: 1,000 emails/month, no expiry.

Pricing: $15/month for 10,000 emails. $30 for 50k. $75 for 100k. Full pricing here.

The case for us, briefly. SMTP2GO scored 95.5% average inbox placement across EmailTooltester’s 4-round 2026 test, which is the second-highest result they recorded and ahead of every other provider on a like-for-like cost basis. Their reviewers gave us the 2026 “Best Value for Money” badge. We didn’t pay for it. They tested us on the free plan.

What we genuinely do better than the field:

The mixed-use case nobody talks about. A lot of senders aren’t pure app developers. They’re a 40-person company running WooCommerce order confirmations, a few HR notifications, scanned-PDF emails from the office Konica Minolta, and occasional newsletters from marketing. The big API-first providers don’t fit that shape well. The marketing-first providers risk poisoning your transactional reputation. SMTP2GO is built for that middle. You get a real API, a real SMTP relay, sub-accounts, dedicated IPs on demand, the device-friendly ports (25, 465, 587, 2525), and a UI a non-developer can actually use.

Legacy and device support. If you’ve ever tried to configure a 2015-era copier to email via AWS SES, you know why this matters. SMTP2GO handles TLS 1.0/1.1 quirks, port 2525 fallback when ISPs block 587, and IP allowlisting for static-source devices. StoredTech has been running phone systems and copiers through us since 2011.

Multi-tenant for MSPs and agencies. Sub-accounts, isolated reputations, per-client billing visibility. Real partner program. If you’re an MSP managing email for 30 clients and don’t want them sharing a sender reputation, this is the model you want. Group IMD scaled from 10,000 to over a million emails per month with us over six years.

Support that’s actually staffed by humans who know SMTP. NZ-based, 24/7, and answered by people who can read a bounce code without escalating. Capterra reviewers consistently flag this.

Compliance. ISO 27001 certified. GDPR compliant. M3AAWG member. EU hosting available for senders who need it.

What we’d flag honestly. The Activity log search UI can feel dated compared to Postmark’s polished dashboard. We’re rebuilding it. If you live in your provider’s dashboard ten hours a week, Postmark looks prettier today. Also: if you’re a Next.js / React Email shop building a side project, Resend’s developer experience will feel more “of 2026” than ours. We’re focused on production deployments at scale, not on being the trendiest tool in the YC batch.

Bottom line. If we weren’t the publisher of this article, we’d still recommend SMTP2GO for around 80% of the readers who land on it. It’s the safest competent default. You can get from “sign up” to “first delivered email” in about ten minutes, support actually picks up, and your reputation isn’t sharing a building with a Lithuanian sportsbook’s marketing list.

Try SMTP2GO free for 1,000 emails/month. No credit card.

2. Postmark - Best for deliverability-critical app email

Best for: SaaS and consumer apps where a delayed transactional email is a support ticket. Password resets, two-factor codes, payment receipts, booking confirmations. The “if this email doesn’t land in 30 seconds, we lose the customer” use case.

Not for: anyone sending marketing email through the same account (Postmark explicitly separates the streams, but you’ll be paying transactional prices for it). Teams sending under 100/month (their free tier is genuinely tiny). EU senders with strict data residency rules (US-only data hosting).

Free plan: 100 emails/month for developers.

Pricing: $15 for 10k. $55 for 50k. $115 for 100k. Considerably pricier than the rest of this list, and they’re honest about it.

The case for Postmark. EmailTooltester’s 2026 test gave them a 93.8% average, with three of four rounds at 95-97% (round four pulled the average down with an 87% on what looked like a Microsoft-specific deliverability dip). Knock’s benchmarks show p50 API response of 23ms and p99 of 228ms, which is among the fastest on the market. Postmark also publishes their time-to-inbox data publicly, which almost no other provider does. That kind of operational transparency earns respect.

What’s genuinely great. Strict separation of transactional and bulk streams (so a marketing send can’t tank a password-reset’s deliverability). DKIM + SPF + DMARC are first-class citizens in the UI. 45-day message retention on all plans. Dashboard is the cleanest in the field. Documentation is excellent. Webhooks and inbound parsing work well.

What we’d flag. Templating is plain compared to SendGrid or Brevo (no drag-and-drop visual editor worth mentioning). Pricing scales steeply: at 100k/month you’re paying about 50% more than SMTP2GO and double Brevo. US-only data hosting is a hard “no” for some EU teams, regardless of how good the deliverability is. And they’re now owned by ActiveCampaign, which has been gentle so far but is worth knowing.

Bottom line. If your business model breaks the moment a transactional email is late, and you have the budget, Postmark is worth the premium. We’d send a developer-tooling SaaS or a fintech to Postmark before we’d send them to ourselves. Honest answer.

3. Amazon SES - Best for AWS-native teams sending at scale

Best for: dev teams already deep in AWS, sending more than 500k/month, who treat email deliverability as an in-house infrastructure problem.

Not for: anyone who wants a working dashboard out of the box; anyone who doesn’t have a developer on the team; teams sending under 50k/month (the savings don’t justify the operational overhead); MSPs managing multiple client domains.

Free tier: 3,000 emails/month for the first 12 months.

Pricing: $0.10 per 1,000 emails. Nobody on this list comes close. At 1M/month you’re paying $100 to SES vs. somewhere between $400 and $1,200 to the others.

The case for SES. Cheapest at scale, full stop. Knock benchmarks show p50 of 153ms (mid-pack) and 0.00% error rate over hundreds of millions of sends, which is fine. Tight integration with the rest of AWS: events into EventBridge, metrics into CloudWatch, identity through IAM. If you’re already SOC-compliant in AWS, you’re not paying the compliance lift twice.

What you’re trading away. Everything that makes a transactional email service feel like a service. Setup is genuinely involved. Every account ships sandboxed - 200 messages per 24 hours, allowlist-only recipients, until you write to AWS support and convince them you’re not going to spam. Analytics aren’t really a dashboard, they’re SNS topics you route through a Lambda. There’s no UI for templates worth using. Dedicated IPs are $24.95/month. And if deliverability slips, you fix it. Amazon will not.

We’ve spoken to teams who migrated to SES for the cost and migrated back off SES because deliverability dropped and they couldn’t get human support fast enough. ThinkPorch made that exact move - they came to us after AWS SES support delays during a deliverability incident. That’s a real pattern, not a one-off.

Bottom line. SES is the right answer if you have an engineer who can build the missing operational layer around it. If you don’t, the per-email price doesn’t matter, because you’ll pay for it in lost-email customer-support load.

4. Brevo - Best if you genuinely need marketing + transactional in one place

Best for: small-to-mid-sized businesses where the marketing team and the dev team are the same three people, and they want one tool, one database, one bill.

Not for: anyone sending high-value transactional email where deliverability is non-negotiable (their 2026 test result is below the field). Teams who already use a separate marketing automation tool. Companies that need strict transactional-vs-marketing IP separation.

Free plan: 300 emails/day (so ~9k/month).

Pricing: From $9/month at 5k. $25/month at 20k. $65 at 100k. Add $12/month to remove Brevo branding from emails on lower tiers (annoying but disclosed).

The case for Brevo. It’s a near-complete marketing platform with transactional bolted in. Drag-and-drop email builder, automation workflows, segmentation, SMS, CRM, Facebook ads integration. EU-headquartered (Paris) and GDPR-friendly. For a team of three people who don’t want to integrate Mailchimp + SendGrid + a CRM, Brevo is a defensible single-platform answer.

The honest concern. EmailTooltester’s 2026 test put Brevo at 79.8% average, with one round dipping to 72% on what looked like a Hotmail/Outlook issue. That’s well behind SMTP2GO (95.5%) and Postmark (93.8%) on the same test methodology. If your transactional email is critical, that gap matters more than the marketing features.

There’s a structural concern too. Mixing transactional and marketing email on the same sender reputation is risky. If your marketing list goes stale and complaint rates spike, your password resets share the punishment. Postmark and SMTP2GO both isolate the streams properly. Brevo’s approach is less rigorous.

Bottom line. Right call for small businesses where consolidation matters more than absolute deliverability ceiling. Wrong call if your transactional email needs to be bulletproof. If you go Brevo, keep a separate sender domain for transactional and watch your bounce rates closely.

5. Mailgun - Best for developer teams who want deep API flex

Best for: product teams that want a powerful, well-documented API; companies that need EU data residency; senders at 100k–1M/month who care about deliverability tooling and have an engineer to wield it.

Not for: non-technical users (the UI assumes you know what you’re doing); teams whose ideal setup time is “fifteen minutes” rather than “an afternoon”; anyone on the cheapest plan who needs decent support (it’s email-only on lower tiers).

Free plan: 100/day, ongoing, no expiry. Honest free tier.

Pricing: $15/mo for 10k (Basic). $35 for 50k (Foundation). $215+ at 250k (Scale tiers). Custom above 2.5M.

The case for Mailgun. Mailgun has been doing this since 2010. Sends for Lyft, American Express, Wikipedia. Their deliverability documentation is among the best the field has produced. Knock benchmarks show p50 of 130ms — mid-pack but consistent — and 0.00% error rate. Send Time Optimization, email validation, EU and US sending regions, dedicated IP pools on Scale tiers. For an engineering team that wants levers to pull, Mailgun has the most of them.

Honest concerns. Pricing is on the higher side at low-mid volumes (worse value than SMTP2GO at 10–50k). Support on entry plans is email-only and not always fast. UI is dense. Mailgun’s sister product Mailjet (also Sinch-owned) is the marketing-friendly version, which can make the product positioning confusing if you’re shopping the parent company. And Mailgun wasn’t included in EmailTooltester’s 2026 deliverability test, so we don’t have current independent inbox-placement data to point at — judge on architecture and reputation.

Bottom line. A serious choice for serious dev teams. If we were standing up a 500k/month transactional pipeline for a SaaS company with EU users and an engineer who likes APIs, Mailgun’s on the shortlist with SMTP2GO and Postmark. For non-developers, look elsewhere.

Also worth considering

These didn’t make the top 5, but they’re real options and skipping them would be dishonest.

Resend. Newest of the modern dev-first providers (founded 2023). Best React/Next.js developer experience on the market — they own React Email. Knock benchmarks: p50 80ms, p99 351ms, 0.06% error. Pricing reasonable ($20/mo at 50k). The right choice for a Next.js SaaS being built today by a founder who values DX over operational maturity. Less battle-tested than the rest of this list. Worth watching.

MailerSend. Sibling to MailerLite. Clean modern UI, drag-and-drop builder, good API. EmailTooltester 2026 result: 86.8% avg deliverability — solid, with one weak round. Their free plan was reduced from 3,000 to 500 emails/month in October 2025, which stings. Good fit for SaaS apps that want polish without paying Postmark prices.

Mailtrap. Started as a testing-only sandbox. Now ships a sending product too. Strong developer story (SDKs in Python, Ruby, PHP, Node, Elixir, C#, Go), ISO 27001, GDPR. EmailTooltester 2026 result: 77% avg - inconsistent (one round at 64%). Best use: keep them for staging/test sends regardless of who you use in production.

SendGrid (Twilio). Massive scale, used by everyone from Uber to Yelp. Knock benchmarks: p50 22ms (fastest on the list). EmailTooltester 2026 deliverability: 82% - middling. Free plan is 100/day for 60 days only (then nothing). Email activity history is a paid add-on, which is silly. Worth considering at enterprise scale where SLAs and procurement matter more than feature elegance.

Mailchimp Transactional (formerly Mandrill). Only makes sense if you’re already paying for Mailchimp Standard or Premium. As a standalone choice in 2026, no. As an add-on to a Mailchimp account, it works and the docs are friendly.

Two we’d skip in 2026

Elastic Email. Cheap, but EmailTooltester’s 2026 test put them at 59.5% average deliverability — the worst in the field. Their own support attributed it to shared-IP reputation on the free plan, which is fair, but providers like SMTP2GO achieve 95%+ on shared IPs. So the explanation doesn’t hold up.

SMTP.com. No free trial. Refund policy charges a 20% admin fee and refuses to refund if you’ve sent a single email.

Choose by use case

If you’d rather skip to the answer for your specific situation, here’s the short version.

SaaS or app email (password resets, receipts, alerts). SMTP2GO first, Postmark second.

Ecommerce (order confirmations, shipping updates, abandoned-cart, light marketing). SMTP2GO if you want one tool that handles all of it cleanly. Postmark + a separate marketing tool if you can afford the operational split. Brevo if your team is tiny and consolidation matters more than peak deliverability.

WordPress (WooCommerce, Easy WP SMTP, contact forms). SMTP2GO has a WordPress plugin and works out of the box.

Legacy device estate (copiers, MFPs, security cameras, phone systems, ERPs). SMTP2GO. We are honestly the strongest here. Port 2525 fallback, TLS 1.0/1.1 tolerance, IP allowlisting for static-source devices, and we’ve been doing this since 2007.

MSP / agency / multi-tenant. SMTP2GO sub-accounts give you isolated reputations per client, per-client billing visibility, and a real partner program. No other provider on this list does multi-tenant as cleanly.

EU / GDPR-sensitive. SMTP2GO (EU hosting available), Mailgun (EU region), Brevo (Paris-based), Mailjet (EU data residency).

Very high volume (5M+/month) with engineering muscle. Amazon SES on cost. Mailgun on tooling. SendGrid on enterprise SLA negotiation.

Side project or hobby app. Resend if you’re on React/Next.js. SMTP2GO’s free plan if you’re not. Don’t pay for anything until you’re shipping more than 1,000 emails a month.

What actually moves the needle on deliverability in 2026

Choosing a provider gets you a starting line. It doesn’t get you over it. A lot of senders pick a great service and still land in spam because the setup work didn’t get done. Here’s what’s actually changed in the last two years.

Google and Yahoo’s February 2024 sender requirements. If you send more than 5,000 messages per day to gmail.com (and Yahoo’s equivalent for yahoo.com), you must now publish a DMARC policy of at least p=none, sign with DKIM, publish SPF, align your From: domain with your authentication, offer one-click unsubscribe on bulk mail (RFC 8058), and keep spam complaint rates below 0.3% (target under 0.1%). This is enforced. We see senders get throttled or junked over it weekly. Google’s official post is here.

Microsoft is tightening the same screws. As of May 2025, Outlook.com applies similar requirements to bulk senders above 5,000/day. Microsoft is also deprecating basic authentication for SMTP across legacy applications on a rolling schedule — affected copiers, MFCs, and on-prem apps need to migrate to OAuth-capable relays or a provider that handles the auth abstraction for them.

Apple Mail Privacy Protection broke open rates. Has been since iOS 15 (September 2021), and it’s worse in 2026 because privacy-protected open rates now apply to most iOS Mail users. Stop using open rate as a deliverability proxy. Use delivery rate, bounce rate, complaint rate, and inbox-vs-spam seed testing instead.

Dedicated vs shared IP - and when each is wrong. Below ~100k/month, a shared IP from a reputable provider beats a dedicated IP every time, because you can’t warm one consistently enough. Above ~500k/month, a dedicated IP (warmed properly over 21–30 days) gives you control over your reputation. The 100k-500k middle is messy: it depends on your sending cadence. SMTP2GO and Postmark both explain this well. Don’t ask for a dedicated IP because it sounds professional. Ask for one when shared isn’t working.

Suppression list hygiene. Every hard bounce should go onto your provider’s suppression list automatically and stay there. Every complaint (FBL feedback) should suppress immediately. If your provider doesn’t do this by default, switch.

SMTP relay vs API: a quick honest answer

Use SMTP relay if you’re integrating with off-the-shelf software (WordPress, your CRM, your copier, MailPoet, Magento) that has an SMTP option built in. The integration is usually a 5-minute config screen.

Use the API if you’re building a custom application and want richer event data, templating, batch send optimization, and webhook hooks for engagement events. APIs typically deliver a few hundred milliseconds faster than SMTP relay, which matters for password resets and 2FA codes but not for order confirmations.

Use both if your stack is mixed. SMTP2GO, Postmark, Mailgun, and SendGrid all let you use both side by side on the same account without weirdness.

For most senders the choice is forced by the integration in front of you, not by a strategic decision. Don’t overthink it.

The “cheap provider” trap: cost per delivered email

The headline price on a provider’s pricing page is cost per sent email. The number that actually matters is cost per delivered-to-inbox email. Watch what happens when you apply EmailTooltester’s 2026 tested deliverability rates to like-for-like 10,000-email plans.

The lesson here isn’t that MailerSend is cheapest (though it is, on this calculation). It’s that Elastic Email costs almost as much per delivered email as SMTP2GO does, despite looking 40% cheaper on the sticker. Headline price is misleading.

Migrating without burning your sender reputation

A few specific things to do, in order, if you’re switching providers.

Don’t move all your traffic at once. Phase it: start with 10% of sends on the new provider, watch the bounce and complaint rates for 48 hours, then ramp 25%, 50%, 100% over a week. New IPs (shared or dedicated) need a few days of “this isn’t a botnet” before mailbox providers settle their suppression heuristics on you.

Set up DKIM and SPF on the new provider’s sending domain before you cut over. Make sure DMARC alignment is preserved (the From: domain matches the DKIM signing domain). Our DKIM deepdive walks through this.

Pull your suppression list from the old provider and import it to the new one. This is the single biggest miss we see in migrations: a brand-new provider doesn’t know that the 4,000 addresses you’ve been suppressing for six months are still bad. The first send out the door re-bounces all of them, which trashes your reputation immediately.

Keep the old provider running for 30 days after cutover in case something breaks. The marginal cost is small. The cost of being unable to roll back is enormous.

Our full guide to switching providers is here.

[FAQ]

A note on transparency. This article is published by SMTP2GO. You’ll see us in the rankings, and you’ll see exactly why. Where another provider is a better fit for your situation, we say so plainly, and we name them. The third-party deliverability data cited below comes from EmailTooltester’s 4-round GlockApps tests and Knock’s published API benchmarks. The audit work is theirs. The opinions are ours.

It does three things: it authenticates your outbound mail, it tells receivers how to handle failures (ignore, junk, or reject), and it sends you reports so you can see who’s sending in your name. Done well, it stops most direct domain spoofing and is now required for any business sending more than 5,000 messages a day to Gmail, Yahoo, or Outlook.

This guide is the long version, written by people who configure SMTP relays for a living and have watched plenty of DMARC rollouts go right (and a few go sideways). If you’re new to email authentication, start at the top. If you already know SPF and DKIM, skip to the alignment section.

What DMARC actually does (and what it doesn’t)

DMARC is a policy layer that sits on top of two older authentication checks, SPF and DKIM. Those two answer questions about a message. DMARC answers a different question: what happens when the answers come back wrong?

Here’s the useful framing for anyone running an actual sending domain. You publish a DMARC record. From that moment on, any receiving mail server that gets a message claiming to be from your domain looks up your DMARC record and decides what to do based on whether the message passed SPF or DKIM and whether the result aligned with your visible From address. If the message is legitimate and your auth is set up correctly, it gets delivered. If a spammer is forging your domain, the receiver follows your policy and quarantines or rejects the message.

So DMARC’s actual job: protect your domain’s reputation, give you visibility into who’s using it, and (once you’re at enforcement) shut the door on direct spoofing.

What it doesn’t do, and we’ll come back to this: it doesn’t stop look-alike domains (paypa1.com instead of paypal.com), it doesn’t stop display-name spoofing (the From shows “PayPal Support” but the actual address is randomuser@gmail.com), and it doesn’t stop attackers who break into a legitimate sender’s account and send from a domain that is properly authenticated. DMARC is one layer.

How DMARC works with SPF and DKIM

Five steps, in order, every time a message gets sent from your domain to a DMARC-aware receiver:

1. You publish three DNS records: SPF (which IPs and services are allowed to send for your domain), DKIM (a public key the receiver can use to verify the cryptographic signature your sending platform attaches to each message), and DMARC (the policy that ties them together).
2. You send a message. Could be a password reset, an invoice, a Microsoft Teams notification from a copier, a marketing campaign through a CRM. Anything.
3. The receiver checks SPF. Did the IP that delivered this message appear in the sending domain’s SPF record? Pass or fail.
4. The receiver checks DKIM. Was the message signed with a private key whose matching public key sits in the sending domain’s DNS, and does that signature still validate? Pass or fail.
5. The receiver checks DMARC alignment and applies your policy. This is the part most people miss. SPF passing isn’t enough. DKIM passing isn’t enough. The domain that passed one of them has to match the domain in the visible From address. If neither aligns, DMARC fails, and the receiver follows your p= instruction.

If alignment passes for either SPF or DKIM, DMARC passes. You only need one of the two to align.

SPF vs DKIM vs DMARC: a side-by-side

If you only learn one comparison about email authentication, learn this one. People conflate the three constantly.

SPF and DKIM each answer a narrower question. DMARC layers a policy and reporting system on top. Here’s the part nobody on a glossary page tells you: DMARC alone does nothing. You can publish the best DMARC record on earth, and if you don’t also have SPF and DKIM configured for every legitimate sender, your good mail will start failing alongside the spoofed mail.

What a DMARC record actually looks like

It’s a DNS TXT record. You publish it at the subdomain _dmarc.yourdomain.com. That’s all.

Here’s a sensible starter record for a domain that’s never had DMARC before:

_dmarc.example.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"

This says: I’m running DMARC version 1, my policy is “do nothing yet” (p=none), send aggregate reports to that mailbox, and apply this policy to 100% of mail. Crucially: it doesn’t block anything. It just turns the reporting on. You should leave a record like this in place for at least a few weeks, often longer, before tightening anything.

Once you’ve confirmed every legitimate sender is aligned, you tighten the policy. Here’s what a mature record might look like for a brand that wants real spoofing protection:

_dmarc.example.com   TXT   "v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com"

This says: reject anything that fails (including subdomain mail, via sp=reject), require strict alignment on both DKIM and SPF, and send me both aggregate and failure reports.

DMARC tag breakdown

The three policies: none, quarantine, reject

This is the part of DMARC where people get hurt. Mostly by moving too fast.

There’s also the pct tag, which lets you apply the policy to a subset. A common ramp pattern: p=quarantine; pct=10 for a week, then pct=50, then pct=100. Same again for p=reject. It feels overcautious. It’s not. The first time you move to p=reject without testing every sender, you’ll find the one you forgot.

From the support side: the failure mode we see most often isn’t spoofing. It’s a customer flipping straight to p=reject on a Monday morning, then realizing on Wednesday that their HR portal sends payroll notifications through a third-party system that nobody added to SPF or DKIM. Those notifications are now silently dropped at Gmail and the team finds out the next pay cycle.

DMARC alignment, the part that trips everyone up

Both SPF and DKIM can pass on a message, and DMARC can still fail. That’s the bit that makes people pull their hair out, so let’s slow down.

When a receiver evaluates DMARC, it doesn’t just ask “did SPF pass?” or “did DKIM pass?” It asks: “did one of them pass on a domain that matches the domain in the From header?”

That match is called alignment.

SPF alignment

SPF authenticates the envelope sender, the address in the Return-Path header. That domain doesn’t have to be the same as what your recipient sees in the From field. Plenty of mail goes out where these differ. Sub-account bounce handling, custom return paths from ESPs, shared infrastructure: there are good reasons.

For SPF to align, the envelope sender’s domain has to match the visible From domain. In relaxed mode (the default), it just has to share the same organizational domain (bounces.example.com aligns with example.com). In strict mode, it has to be an exact match.

DKIM alignment

DKIM signs the message with a key tied to a specific domain (the d= value in the DKIM-Signature header). For DKIM to align, that signing domain has to match the visible From domain.

Why this matters with an SMTP relay

Here’s the practical version. Imagine you send mail from you@yourcompany.com through a third-party relay. The relay handles the envelope-level transmission, so the Return-Path might be something like bounce.relay-provider.com. SPF passes for that domain, but it’s not your domain, so SPF alignment with yourcompany.com fails. If the relay also signs the message with its own DKIM key (d=relay-provider.com), DKIM passes for the relay, but DKIM alignment with yourcompany.com fails. Both authentication checks pass. DMARC still fails. Mail goes to spam (under p=quarantine) or gets rejected (under p=reject).

The fix in this scenario is twofold. Configure a custom return path on the relay so the envelope sender uses your domain (bounce.yourcompany.com). And have the relay sign DKIM with your domain’s key (d=yourcompany.com). Now both checks align.

From the support side: when David Rousseau at Les Musées de la Civilisation de Québec moved his CRM mail through SMTP2GO, getting DKIM and SPF correctly aligned to his sending domain was the difference between mail landing in inboxes and mail landing in junk. The setup itself is small. The before-and-after is large.

DMARC reports: what you actually get

Reporting is the R in DMARC.

Aggregate reports (rua)

Once a day, every DMARC-aware receiver that sees mail claiming to be from your domain sends you an XML file. It lists every IP that sent mail in your name, how many messages, whether each one passed SPF, whether each one passed DKIM, and whether alignment held. That’s how you discover the legitimate senders you forgot about (the Zendesk macro that emails customers, the marketing automation tool, the printer in the warehouse) and the spoofers trying to forge your domain.

Here’s a fragment of what one looks like:

<record> 
  <row> 
    <source_ip>50.31.156.116</source_ip>
    <count>247</count>
    <policy_evaluated> 
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf> 
    </policy_evaluated>
   </row>
   <identifiers>
     <header_from>example.com</header_from>
   </identifiers>
   <auth_results> 
     <dkim> 
       <domain>example.com</domain>
       <result>pass</result>
     </dkim>
     <spf> 
       <domain>relay-provider.net</domain>
       <result>pass</result>
     </spf> 
   </auth_results> 
</record>

Reading this raw is painful. Multiply that record by hundreds of senders across dozens of daily reports and you’re looking at a lot of XML. Most teams hand the parsing off. Free options will get you started (DMARC Analyzer, dmarcian, EasyDMARC’s report viewer).

SMTP2GO doesn’t make a DMARC report parser. We handle the sending side. For the report-reading side, pick a tool that suits your scale and don’t try to read the XML by hand.

Failure reports (ruf)

Per-message reports on individual failures, with more detail (including parts of the message). Useful for debugging specific failures. Less widely supported than aggregate reports, and there are privacy considerations because the reports can contain message content. Most setups configure rua and leave ruf off.

What to do with the data

Read the aggregate reports for the first two to four weeks. Build a list of every IP and every sending domain that shows up. For each one, ask: is this us? If yes, get it aligned (add to SPF, configure DKIM signing). If no, it’s a spoofer or an old service you forgot to decommission. Once your “is this us” list is fully aligned, move to p=quarantine. Watch reports another few weeks. Once you’re confident, move to p=reject.

DMARC for Gmail, Yahoo, and Microsoft: the 2024–2026 rules

This section is the reason “do we actually need DMARC?” stopped being a debate. Three of the largest mailbox providers in the world have made it mandatory for bulk senders.

Gmail and Yahoo (February 2024, enforcement ramped from November 2025)

If you send 5,000 or more messages a day to personal Gmail accounts (@gmail.com, @googlemail.com) or Yahoo-hosted addresses, you must:

• Authenticate with SPF and DKIM.
• Publish a DMARC record (at least p=none).
• Pass alignment for either SPF or DKIM with the visible From domain.
• Keep spam complaint rates below 0.30% (Gmail’s hard threshold), ideally below 0.10%.
• Implement one-click unsubscribe (RFC 8058 List-Unsubscribe headers) on marketing mail.
• Process unsubscribe requests within 48 hours.

From 2025, Gmail began actively enforcing this. Non-compliant traffic now sees temporary rate-limiting or outright rejection. (See Google’s official sender guidelines and our earlier piece on Gmail and Yahoo’s 2024 inbox protection rules for the full breakdown.)

Microsoft Outlook (May 5, 2025)

Microsoft brought its consumer mailboxes (Outlook.com, Hotmail.com, Live.com) in line. Same 5,000-messages-per-day threshold. Same SPF + DKIM + DMARC requirement with at least p=none and alignment on at least one of SPF or DKIM. Same direction of travel: stricter, sooner.

Microsoft chose to reject rather than junk. Non-compliant mail comes back with this bounce code:

550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

If you see that in your bounces, your DMARC, SPF, or DKIM isn’t where it needs to be. (Microsoft’s original Outlook bulk-sender post has the formal spec.)

What p=none actually buys you

Here’s the part the strict-letter-of-the-law version of this advice misses. p=none satisfies the minimum requirement. It does not protect your domain. If a spoofer forges mail from yourcompany.com and you’re at p=none, the receiver still delivers it. The only thing p=none does is let you watch what’s happening. That’s valuable for setup. It’s a poor place to live.

Mailbox providers know this. Senders who park at p=none indefinitely are increasingly treated as a yellow flag. Google’s official guidance still accepts it. The unofficial reality, from the deliverability community, is that domains stuck on p=none for years signal weak operational discipline. Plan to move past it.

How to set up DMARC, step by step

If you’re starting from zero, this is the playbook. It assumes you already have a domain and you’ve identified the platforms that send mail in your name (marketing tool, helpdesk, CRM, transactional relay like SMTP2GO, anything else).

1. List every sender. Marketing platform, CRM, helpdesk, billing system, internal mail server, copiers, alerting systems. Write them all down. Most rollouts hit trouble because step one wasn’t thorough.
2. Get SPF in place. One SPF record per domain. Include every legitimate sender. Watch the 10 DNS lookup limit; it’s the most common SPF failure mode. (We have a full SPF guide if you need the long version.)
3. Get DKIM in place. For each sending platform, generate a DKIM key pair and publish the public key in DNS under the platform’s selector. SMTP2GO walks you through this in the sender domain setup; most platforms have similar flows.
4. Publish your DMARC record at p=none. Use the starter record from earlier in this guide. Make sure rua points to a mailbox you’ll actually check.
5. Wait. Read reports. Two to four weeks minimum. Identify every IP and domain that shows up. Sort them into “us” and “not us.” Get every “us” aligned.
6. Move to p=quarantine. Start with pct=10 if you want to be cautious. Watch reports. Watch your support inbox. Ramp pct to 100 over a few weeks.
7. Move to p=reject. Same ramp pattern. When you’re confident, this is where you want to be.
8. Don’t stop monitoring. New senders get added (marketing tool migrations, new SaaS integrations). DNS records get edited. Things break. The reports are how you find out before your customers do.

DMARC and SMTP2GO: what the relay handles, what your DNS still has to do

Honest answer to the question SMTP2GO customers actually ask: “does SMTP2GO handle DMARC for me?”

Mostly no, and that’s not a flaw, it’s how DMARC is designed. DMARC lives in your DNS, on your domain. No SMTP relay can publish that record for you (your DNS, your call). What SMTP2GO does handle is the part that breaks DMARC alignment when you put a relay in the path:

• Custom Return-Path on your sending domain. Without this, SPF passes for the relay’s domain, not yours, and SPF alignment fails.
• DKIM signing with your domain’s key. Without this, DKIM passes for the relay, not for you, and DKIM alignment fails.
• Sub-account separation for mixed streams. If you’re running transactional and marketing through the same provider, sub-accounts let you keep reputation and DKIM signing distinct. That matters for p=quarantine ramp-ups.

What you still own:

• Publishing your SPF record (with SMTP2GO’s include directive).
• Publishing the DKIM public key in your DNS.
• Publishing the DMARC record at _dmarc.yourdomain.com.
• Aligning every other sender outside SMTP2GO (your marketing tool, your CRM, your helpdesk, etc).

What SMTP2GO doesn’t do, and we’d rather say it out loud: we don’t parse your DMARC reports. The XML files come to whatever mailbox you specified in rua. For parsing those, use a dedicated tool (Postmark’s DMARC Digests, dmarcian, EasyDMARC, or one of several others). Pick one and stick with it.

From the trenches: Will Beattie’s team at Group IMD grew from 10,000 emails a month to over a million a month through SMTP2GO over six years. That kind of scaling works because the SMTP relay layer is one part of the stack and DMARC reporting is another. When ThinkPorch migrated from AWS SES (a switch made faster by SES support delays, per Dennis Mathew), the alignment work happened on day one. The DMARC posture survived the move because DMARC lives in DNS, not in the relay.

Common DMARC mistakes (and what they look like in the wild)

The same handful of mistakes account for most of the failed rollouts.

1. Jumping straight to p=reject. The dramatic version. You publish a strong policy on Monday because the security audit said so, and on Wednesday legitimate mail starts vanishing. Always ramp through p=none and p=quarantine first.
2. Forgetting a third-party sender. The HR portal, the appointment-reminder tool, the asset-management system that emails low-stock alerts. None of them are top-of-mind. All of them send in your name. Aggregate reports catch this; you just have to actually read them.
3. Publishing two DMARC records. Some DNS UIs let you create a second TXT record at _dmarc.yourdomain.com without warning. DMARC spec says: any domain with more than one record is treated as having no record. Check before publishing.
4. Syntax errors. A missing semicolon, an extra quote, p=Reject instead of p=reject. Validate with a record checker before you go live.
5. No rua address. A DMARC record without reporting is half a system. You can’t tighten what you can’t see.
6. SPF blowing past the 10 DNS lookup limit. Common when you add too many include: directives. SPF returns permerror and DMARC fails. SPF flattening or careful pruning fixes it.
7. DKIM key not rotated or missing on a new sending platform. When you migrate from one ESP to another, DKIM signing changes. If you don’t publish the new public key in DNS, DKIM fails for everything coming from the new platform.
8. Subdomain mail you forgot about. If you send marketing from mail.example.com but your DMARC record at example.com doesn’t have an explicit sp= policy, the parent’s p= value applies. Sometimes that’s right, sometimes it’s not.
9. Assuming DMARC stops phishing. It stops domain spoofing. It doesn’t stop a phisher registering yourc0mpany.com and sending from there. Different layer of defense.

What DMARC doesn’t stop

DMARC is a useful protection. It’s not a complete one. The cases it doesn’t cover:

• Look-alike domains. paypa1.com (with a 1 instead of an l), support-paypal-billing.com, yourbank.security.com. DMARC only protects domains you own. You can’t publish a policy for somebody else’s domain.
• Display-name spoofing. An email shows up with “Microsoft Support” in the visible From, but the actual address is randomname@gmail.com. DMARC checks the domain in the From address, which is gmail.com. Gmail passes DMARC trivially. The display name is unprotected.
• Compromised legitimate accounts. If an attacker breaks into a real user’s mailbox at a real company and sends out from there, DMARC will happily pass that mail. The auth is genuine. The intent isn’t.
• Inbound phishing protection. DMARC tells receivers what to do with mail claiming to be from your domain. It doesn’t protect your inbox from mail claiming to be from somebody else’s domain. Inbound protection is a separate stack (secure email gateways, anti-phishing tools, user training).

This is why deliverability folks talk about “defense in depth.” DMARC, BIMI, anti-phishing training, gateway filtering, MFA on email accounts: they stack.

Where BIMI fits in

BIMI (Brand Indicators for Message Identification) lets your logo show up next to your messages in supported mailbox clients (Gmail, Apple Mail, and a few others). It’s the visible payoff of doing email auth well. The catch: BIMI requires DMARC at p=quarantine or p=reject to work. You can’t shortcut your way there. Get DMARC fully enforced, then publish BIMI. The logo in the inbox is the reward.

[FAQ]

##

If you’re configuring DMARC for the first time, the order of operations is straightforward: get SPF clean, get DKIM signing on your domain, then publish DMARC at p=none and read reports until the picture is clear. If you’re running mail through SMTP2GO, our sender domain setup walks you through SPF and DKIM in a few minutes; the DMARC record is yours to publish.

Need help untangling alignment when you’re seeing failures in your reports? Our support team has been doing this for over a decade. Get in touch or try SMTP2GO free if you’re not yet sending through us.

This guide is the playbook. It’s how the SMTP2GO support team actually walks through deliverability cases. You can skim it. You can also work through it top to bottom in an hour. Either way, you’ll know what to check, what to change, and what to ignore.

If you only read one section, read the TL;DR.

TL;DR: The fix list, in priority order

1. Authenticate your sending domain with SPF, DKIM, and DMARC.
2. Meet Gmail and Yahoo’s sender rules - even if you send under 5,000 a day.
3. Watch the five metrics that actually reveal a spam problem.
4. Clean your list and kill complaints at the source.
5. Warm up new domains and IPs gradually, not all at once.
6. Separate transactional mail from marketing mail.
7. Fix the message itself: content, links, formatting, attachments.
8. Decide whether you actually need a dedicated IP.
9. If your SMTP provider is part of the problem, change it.
10. Test, then test again with the right tools.

Now the diagnosis bit.

Quick-diagnose: which thing is actually broken?

Before you start changing anything, narrow down what you’re looking at. Most teams jump straight to the fix and then can’t tell if it worked. Use this table to triage first.

If you don’t know which row is yours yet, run a quick test send with Mail-Tester and check Google Postmaster Tools for your sending domain. Five minutes. That’s the start.

Why your emails go to spam: the seven real causes

Spam filters in 2026 are reputation engines first, content filters second. Gmail, Yahoo, and Microsoft all care more about who you are and how your past emails behaved than they do about whether you used the word “free” in a subject line. The seven real causes:

1. You haven’t authenticated: no SPF, no DKIM, or no DMARC. Or you set them up and never checked alignment.
2. Your sender reputation is bad: high complaints, high bounces, low engagement, or you’re on a blocklist.
3. Your list is dirty: purchased, scraped, ancient, or full of spam traps.
4. You sent too much, too fast, from a cold domain: Gmail can’t tell you from a phisher who just registered the domain yesterday.
5. You mixed your streams: order receipts and weekly newsletters sharing one sending reputation, and the newsletters are dragging the receipts down.
6. Your content or links are tripping filters: URL shorteners, all-image emails, suspicious link patterns, or a sender name that doesn’t match the domain.
7. Your provider is hurting you: bad shared IP neighbours, weak abuse controls, no visibility into what’s happening.

Now the fixes, in the order they matter.

Spam, Promotions, bounced, blocked — they’re not the same thing

Before you start fixing, make sure you actually have a spam problem. Treating a Promotions tab issue like a spam issue will waste a week.

If recipients are telling you the message arrived “in Promotions,” that’s a different conversation. We wrote about that one here. It’s not a deliverability problem. It’s an engagement problem dressed up as one.

Fix 1: Authenticate your sending domain

This is the single biggest reason “legitimate” email lands in spam in 2026. SPF, DKIM, and DMARC are no longer optional. They’re the price of entry.

SPF (Sender Policy Framework). A TXT record on your domain that lists which servers are allowed to send mail on your behalf. If a message arrives from an IP that isn’t in the SPF record, the receiving server treats it as suspicious. The classic failure mode: you’ve got five tools sending mail (your CRM, your billing app, your support desk, your marketing platform, your CEO’s inbox), and only three of them are in the SPF record. The other two intermittently land in spam, and you spend a month blaming the wrong thing. SPF is also limited to 10 DNS lookups; busy domains blow past this without noticing. Full breakdown here.

DKIM (DomainKeys Identified Mail). A cryptographic signature added to each outbound message. The receiving server fetches your public key from DNS, verifies the signature, and confirms two things: the message really came from you, and nobody tampered with it in transit. Setup is one DNS record per sending source. Misconfigurations usually come down to selector mismatches or the wrong domain being signed. We’ve got a deeper guide here.

DMARC. The policy layer on top of SPF and DKIM. It tells receiving servers what to do when authentication fails (do nothing, quarantine, reject), and where to send you reports. The piece most people miss: alignment. SPF and DKIM can both pass while DMARC still fails, because the domain the user sees in the From header doesn’t match the domain that was actually authenticated. If your DMARC report shows pass rates below 95%, you have an alignment problem, not an authentication problem. Walkthrough here.

Quick verification from a terminal:

dig +short TXT example.com | grep -i spf
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.coma

What this looks like in practice. David Rousseau at Les Musees de la civilisation de Quebec called out DKIM and SPF optimisation specifically when they brought SMTP2GO in to lift the delivery rate on their CRM mail. That’s the typical pattern. The organisation has been sending for years, the tools were never authenticated correctly, deliverability drifted, and the fix turned out to be five DNS records.

Fix 2: Meet Gmail and Yahoo’s sender rules - even if you send under 5,000 a day

In February 2024, Google and Yahoo rolled out mandatory sender requirements for bulk senders (anyone sending more than 5,000 messages a day to either provider). Microsoft has since signalled similar tightening. The rules aren’t going away. Here’s the short version.

For bulk senders (>5,000/day to gmail.com or yahoo.com):

• SPF and DKIM both required. Not one or the other. Both.
• DMARC required, at minimum p=none, with alignment.
• Spam complaint rate below 0.10%, never crossing 0.30% for any sustained period. Above that, Google starts diverting your mail to spam regardless of authentication status.
• One-click unsubscribe for marketing/promotional mail (RFC 8058). The header-based version, not just a footer link.
• Unsubscribes processed within two days.
• Valid forward and reverse DNS on your sending IPs.
• TLS encryption in transit.
• From header alignment with the authenticated domain.

Source: Google’s sender guidelines; Yahoo’s sender hub. We’ve also done a SMTP2GO-specific walkthrough here.

The thing nobody tells you about the 5,000/day threshold. A lot of senders see “bulk senders” and assume the rules don’t apply because they only send 200 a day. Wrong move. Gmail still expects SPF or DKIM at any volume, and accounts that fail those at low volume get filtered just as aggressively. The 5,000/day line is for the strict enforcement. Below it, you’re still on the same path; you just have more rope.

Honestly, this is the part most teams underestimate. The complaint-rate ceiling is harder to maintain than it sounds. A 5,000-recipient send with five spam-button clicks puts you at 0.10% exactly. That’s a normal Tuesday for some lists. Building in a buffer matters.

Fix 3: Watch the five metrics that actually reveal a spam problem

The old advice “track open rates and click rates” is half-useless now. Since Apple Mail Privacy Protection launched in iOS 15 (September 2021), opens for Apple Mail users are essentially pre-fetched, which means open rate as a deliverability signal is noise. You can still use it for engagement trends, but if you’re using it to diagnose spam, you’re using the wrong dashboard.

These are the five that actually move:

Delivery rate ≠ inbox placement. A 99.8% delivery rate means 99.8% of messages were accepted by the receiving server. It says nothing about whether they ended up in the inbox or the spam folder. Confusing the two is the most common conversation we have in support tickets.

For monitoring, use Google Postmaster Tools for Gmail visibility, Microsoft SNDS for Outlook/Hotmail, and MXToolbox for blocklist checks. Inside SMTP2GO, the Activity dashboard rolls all of this up into one view per sending domain or sub-account.

Fix 4: Clean your list and kill complaints at the source

A complaint rate above 0.30% will get you filtered. There’s no DNS record that fixes it. The cause is upstream.

Three rules, then we move on.

Never send to an address you didn’t earn. Purchased lists, scraped lists, “co-registration” lists, list trades — they’re spam-trap factories. Even one or two pristine spam traps on your list (addresses that never belonged to a real person) is enough to land you on a major blocklist. More on the spam trap landscape here.

Suppress hard bounces immediately and run a sunset policy. If a subscriber hasn’t opened or clicked in 90-180 days, they’re a liability, not an asset. Either run a re-engagement send and suppress the non-responders, or just suppress them. Their continued presence on your list is dragging down your engagement signals and lighting up complaint risk.

Make the unsubscribe obvious, and process it fast. People who can’t find the unsubscribe button hit the spam button instead. One click. Visible. Header-based for promotional mail (RFC 8058 again). We wrote up the practical version here.

The case that proves it. Alistair Higham at JWK Solicitors came to SMTP2GO after their domain had been blacklisted. The blacklisting wasn’t a mystery; it was the accumulated weight of years of unmanaged list and complaint behaviour. Moving providers gave them a clean reset on infrastructure, but the underlying list hygiene was what had to change.

Fix 5: Warm up new domains and IPs gradually

A domain that registered yesterday and sent 50,000 messages today looks exactly like a phishing operation. Filters know this. They throttle hard.

A workable warm-up cadence for a new dedicated IP, sending to a list that’s already opted-in and engaged:

• Days 1-3: 50/day per provider
• Days 4-7: 250/day
• Week 2: 1,000/day
• Week 3: 5,000/day
• Week 4: 25,000/day
• Weeks 5-6: ramp to full volume

That’s a generous schedule. You can move faster if your engagement holds; you have to slow down if your bounce or complaint rate starts climbing. On a shared IP at SMTP2GO, the warm-up is shorter because the IP already has sending history attached to it; that’s the trade-off. Our high-volume warm-up guide goes deeper and covers when you actually need the warm-up at all.

The same principle applies to a domain that’s been dormant. If you haven’t sent for six months and you suddenly blast 100,000 messages, you’re cold-warming whether you meant to or not. Treat it like a new domain.

Fix 6: Separate transactional and marketing mail

This is the fix nobody talks about and everyone needs.

If your password resets, order confirmations, shipping notifications, and security alerts share a sending domain with your weekly newsletter, then your weekly newsletter’s complaint rate is dragging down the deliverability of every receipt you send. One bad campaign and the receipts go to spam too. That’s not a hypothetical; that’s a Tuesday in support.

The fix is structural. Use subdomains:

• mail.example.com for marketing
• notify.example.com or tx.example.com for transactional
• support.example.com for support replies

Each subdomain has its own DKIM, its own DMARC alignment, and over time its own reputation. The transactional reputation stays clean even if a marketing campaign goes sideways. SMTP2GO sub-accounts make the operational side of this easy — different streams, different sending limits, different IP pools if you need them. Background on the pattern here.

Why it matters at the extreme. Miguel Mercado Canales at GlaxoSmithKline uses SMTP2GO to send environmental condition notifications to about 20 colleagues across manufacturing operations. When the next shift comes on, those emails need to be in the inbox before they walk in the door. If those alerts shared reputation with a marketing send to 200,000 prospects, the alerts would be the ones that broke first. They don’t share. That’s the point.

Fix 7: Fix the message itself

Content matters less than it used to, but it still matters. The patterns that hurt you in 2026:

• All-image emails. No text, just a giant JPEG. Filters can’t read it, recipients can’t read it on screen readers, and the image-to-text ratio is so skewed that the message looks like an attempt to hide content. Aim for roughly 60% text, 40% image.
• URL shorteners. Bit.ly, t.co, tinyurl. They mask the destination, which is exactly what phishers do. Use a branded tracking domain instead, or just use the full URL.
• Mismatched link text. Displaying one URL while linking to another. Filters score this hard.
• Inconsistent From identity. “Bob from Acme” one week, “support@acme.com” the next, “marketing@acme-promotions.com” the week after. Pick one and stick to it.
• Excessive subject-line punctuation, ALL CAPS, or emoji stacks. This is the boring, obvious one. Filters got past simple keyword matching years ago, but stacking signals still triggers a higher score.
• Attachments larger than a few MB. If the file’s big, link to it. Don’t attach it.

The myth worth debunking: images do not cause spam by themselves. Single-image emails do. An email with a hero image, some text, a CTA, and a footer is fine. An email that’s literally one large image with no HTML text is not. Big difference.

Shared vs dedicated IP

If you’ve been told you need a dedicated IP to fix deliverability, slow down. Usually you don’t.

The honest answer for most senders: start on shared. SMTP2GO’s shared pools are actively monitored, with strict acceptance criteria for who can send through them. If you grow past 100K consistent monthly volume, then dedicated makes sense. Until then, you’re paying for control you don’t need and accepting warm-up risk you don’t have to.

When your SMTP provider is part of the problem

Sometimes the issue isn’t your DNS, your list, or your content. It’s that your provider is quietly dragging you down. Six warning signs:

1. You can’t see who’s complaining. No complaint reporting, no Feedback Loop integration with major ISPs.
2. Shared IP pools that include senders you wouldn’t want as neighbours. No clear acceptance criteria. You’re on a pool with cold-email outreach companies and grey-hat affiliate networks.
3. No alerts when reputation drops. You find out from a customer that emails went missing.
4. DKIM/SPF setup is documented as “follow these 14 steps,” not automated. Bigger setup means more misconfigurations.
5. Support response time measured in days, not hours. Deliverability emergencies don’t wait for tickets.
6. No separation between transactional and marketing. Everything’s one stream with one reputation.

If two or more of those describe your current setup, the provider is part of the problem. Not all of it. But part.

This is what migration sometimes looks like. Dennis Mathew at ThinkPorch moved to SMTP2GO from AWS SES specifically because SES support took too long to resolve issues. SES is excellent infrastructure; what it’s not is a managed deliverability service. The two aren’t the same product. Knowing which one you actually need is the bit most teams skip when they pick a provider.

And Mark Shaw at StoredTech has been using SMTP2GO since 2011 to power email from phone systems, copiers, printers, and a long tail of business devices that can’t authenticate via OAuth, can’t do TLS 1.3, and can only speak basic SMTP. Those devices got harder to deliver from every year as ISPs tightened. The reason they still work is because the provider sits between them and the modern internet’s authentication requirements, and handles the messy middle.

Tools we’d actually use this week

Short list. No padding.

• Google Postmaster Tools Gmail-side reputation, complaint rate, authentication pass rates. Mandatory if you send any meaningful Gmail volume.
• Microsoft SNDS Same idea for Outlook/Hotmail.
• MXToolbox Blocklist lookups, DNS record verification, SMTP diagnostic.
• Mail-Tester Send a test email to a temporary address, get a score on authentication, content, blocklist status, and HTML quality. Quick sanity check.
• dmarcian DMARC report aggregation and parsing. Free tier is generous.
• GlockApps Inbox placement testing across providers. Worth running before a major send.

Inside SMTP2GO, the Activity tab gives you everything in one place: delivery, bounces, complaints, opens (where the data is reliable), clicks, and reputation status per sending domain.

Troubleshooting and what to do

[FAQ]

Need a hand? Try SMTP2GO free - up to 1,000 messages a month, no card required. Or book time with our deliverability team if you’d rather talk it through.

The definition is the easy part. The interesting part is the line that separates a transactional email from a marketing email, because that line moves depending on who’s reading it (your customer, Gmail, the FTC, a Canadian regulator) and crossing it accidentally is the most common way teams blow up their own deliverability.

So this guide does three things: defines the category cleanly, walks the boundary with marketing email in detail, and then gets into how you actually send these messages reliably from a real application. If you just need the quick answer, the next section is yours. If you’re deciding what to build on, scroll down to “how to send.”

Sending transactional email and want a free plan to test with?

Try SMTP2GO free for 1,000 emails a month →

What is a transactional email?

A transactional email is an automated, one-to-one message that goes out in response to a specific action a user took, or an event the system recorded against their account. It contains information unique to that person, and it’s almost always expected. Most of the time, the user is actively looking for it (refreshing the inbox to grab the verification code, watching for the receipt).

Five traits that hold true for almost every transactional email:

1. Triggered by an action or event, not scheduled
2. Sent to one recipient at a time, not blasted to a list
3. Contains user-specific information (their order, their token, their tracking)
4. Expected by the recipient as part of using your service
5. Time-sensitive - late is almost as bad as undelivered

If a message doesn’t tick all five, it’s probably not transactional, even if it feels like it should be. The shipping confirmation a customer is reloading their inbox to find? Transactional. The “we noticed you haven’t logged in for 30 days” nudge that pulls them back? That’s marketing, even though it’s triggered.

According to MailerSend’s 2026 transactional email benchmarks, this category averages 80–85% open rates against roughly 20% for marketing email. The reason isn’t a content secret. It’s that recipients are actively waiting for these messages.

Transactional email vs marketing email

The diagnostic that works best in borderline cases is to ask why the email exists. If the recipient can’t reasonably finish what they started without this message (can’t log in without the reset, can’t expect their package without the tracking), it’s transactional. If you’re sending it to influence behavior that hasn’t happened yet (open, click, buy, upgrade, come back), it’s marketing.

Gmail and Yahoo both apply their own classification on top of yours, and they pay close attention to whether the content is genuinely personalized versus “Hi {first_name}” template fill. If the same message goes out to thousands of recipients at once with only superficial personalization, inbox providers tend to read it as bulk regardless of what your code calls it.

Common types of transactional email

Account and access

Account creation confirmations, email verifications, password resets, magic links, two-factor codes, new-device login alerts, admin notifications when teammates join or trials expire. The login-adjacent emails. If they don’t land, your support queue fills up the same hour.

Payment and billing

Order confirmations, receipts, invoices, dunning emails when a card fails, subscription renewal notices, refund confirmations. These are also the ones with the strictest legal expectations: receipts must be honest, refunds traceable.

Shipping and status updates

Shipping confirmation, delivery updates, appointment reminders, reservation confirmations. Often the highest-engagement messages a brand sends. Order confirmations average 70–90% opens.

Security alerts

Password changed. New device login. Suspicious activity. Account locked. These overlap with account-access emails but earn their own category because the deliverability bar is highest: a security alert that lands in spam is a security hole.

Requested content

Data exports, CSV downloads, return labels, statements, itineraries, PDFs. Triggered when the user explicitly clicked “send me this.” Often the heaviest payload of any transactional email (attachments, signed URLs) and where API-side errors tend to bite.

Product and activity notifications

Mention alerts, comment notifications, usage summaries, digest emails. These are the most contested category, because some of these (the daily digest, the weekly summary) start to look like content marketing to inbox providers if they aren’t tightly user-specific.

Transactional, marketing, or borderline?

This is the part most explainer pages get wrong. Anything designed to influence a future purchase is marketing, even when the trigger looks transactional.

The compliance line, and where it moves

Under the US CAN-SPAM Act, the FTC applies a “primary purpose” test. If the email is primarily transactional, the marketing rules don’t apply. If it’s primarily commercial, they do. The industry working rule is 80/20: at least 80% of the content should be the actual transactional information, with no more than 20% promotional add-ons, and the transactional content has to appear first.

The moment you flip that ratio, the email is a commercial message in the FTC’s eyes, and you need a working unsubscribe mechanism, accurate from address, identification as an ad, and the rest of CAN-SPAM. Adding a “10% off your next order” banner to a receipt is the most common way teams cross the line without noticing.

GDPR and CASL are stricter. Under GDPR, mixing marketing into a transactional message in a way that suggests the recipient consented to marketing by completing the transaction is risky. Canada’s CASL effectively prohibits it for any recipient inside Canada. If you sell into Europe or Canada, treat transactional and marketing as completely separate sending streams. We cover the full breakdown in our GDPR, CAN-SPAM, and CASL guide.

A second compliance reality that matters more than the legal one: inbox providers penalize promotional content in transactional streams. Gmail’s spam filter doesn’t care about the FTC’s primary-purpose test. It cares whether the email looks like the bulk mail it’s seen from your IP before.

How to send transactional email reliably

Three real options for any production system. They aren’t ranked. The right choice depends on what you’re sending from.

Option 1: SMTP relay

Best for apps that already speak SMTP (Drupal, WordPress, WHMCS, most CRMs and ERPs), devices that only speak SMTP (Ricoh, Kyocera, Sharp, Xerox multifunction printers, security cameras, phone systems, SIP servers), and anything legacy. You point the application at a host like mail.smtp2go.com, give it a username and password, and let the relay handle authentication, queuing, retries, and inbox placement. We’ve got a deeper introduction to SMTP relay if you want the full picture. Port 587 with STARTTLS is the default. Use 2525 when an upstream ISP or cloud provider is blocking 587. We don’t recommend port 25 for relay traffic.

Option 2: Email API

Best for custom application code where you control the send-side. Better error handling than SMTP (you get a JSON response, a message ID, a structured error). Webhooks for delivery, open, click, bounce, spam-complaint, and unsubscribe events. Template support with merge variables, so the same payload can render differently per recipient. Faster to integrate from scratch in a new codebase than wiring up an SMTP library. See the API setup guides for Node, Python, PHP, Ruby, and Django.

Option 3: Plugins and integrations

Best for WordPress, WooCommerce, cPanel, Microsoft Dynamics, Pipedrive, Zoho, Salesforce, and the long tail of off-the-shelf software where someone has already written the integration. Lowest setup effort. Easiest to maintain. You usually end up using SMTP under the hood, but the plugin handles the wiring.

What we recommend you don’t do: send production transactional email through a Gmail or Microsoft 365 mailbox SMTP account. The rate limits are low (Gmail caps unauthenticated apps at very small daily volumes, M365 at 10,000/day even on paid plans), the deliverability footprint is shared with everybody else on the platform, and Microsoft’s retirement of basic auth for SMTP keeps breaking integrations that depended on it. It works in dev. It breaks in production.

Regardless of which option you pick, three things have to be in place before volume goes up:

• SPF authorizing your sender to send from your domain (SPF basics)
• DKIM signing your outgoing mail so receivers can verify it wasn’t altered
• DMARC at minimum p=none for visibility, moving to p=quarantine or p=reject once you’re confident (what is DMARC)

Since February 2024, Google and Yahoo both require DMARC for senders pushing more than 5,000 messages a day to their domains. That’s not negotiable anymore.

What to look for in a transactional email service

Past the marketing copy, this is what actually matters when you pick one:

Honest deliverability evidence, not just a “99% delivery rate” claim. Look for M3AAWG membership, ISO 27001, real customer placement numbers, and a postmaster team that you can reach. Both SMTP and API support, because you’ll probably need both eventually (devices on SMTP, app code on API). Webhooks for the six core events (delivered, bounced, opened, clicked, spam-complained, unsubscribed), and real-time reporting that lets you actually find the bounce that broke your reset flow yesterday.

Suppression-list handling that lets you query and manage it via API. Dedicated IP options for senders above ~200K/month who want to control their own reputation. A free or generous starter tier so you can integrate before talking to sales. Support that answers in hours, not days, especially when a reset flow is down.

We’ve got a longer breakdown of how to choose a transactional email service that covers the trade-offs for AWS SES, Postmark, SendGrid, Mailgun, and us.

Honest comparison: if you’re a developer with strong AWS chops, deep cost sensitivity, and a willingness to operate your own deliverability, SES is hard to beat on price. If you want something that just works out of the box, with 24/7 support and a free plan that doesn’t expire, we’d put SMTP2GO in your shortlist. Both are valid choices for different teams.

Why teams use SMTP2GO for transactional email

We’ve been doing this since 2006. M3AAWG member, ISO 27001 certified, GDPR compliant, based in New Zealand with support coverage that genuinely runs 24/7 because the team’s spread across time zones.

A few specific customer stories we can point to:

StoredTech, an MSP, has been sending through us since 2011, originally for office phone systems and copier MFCs that needed a reliable SMTP relay. Still running today.

Group IMD started on the free plan sending around 10,000 emails a month. Six years later they’re sending over a million a month for media-asset delivery notifications, on the same account.

ThinkPorch migrated to us from AWS SES specifically because support response times on SES weren’t workable for them. Their transactional flows now run on SMTP2GO with a dedicated IP.

If you want to try it on real traffic, the free plan runs 1,000 emails a month with no time limit, full API and SMTP access, webhooks, and the same dashboard paying customers use.

Get a free SMTP2GO account →

From scheduling emails in advance to dramatically improving throughput and sending large batches more efficiently, these updates make it easier than ever to integrate powerful email workflows into your applications.

Schedule Emails Up to 3 Days in Advance

We’ve added a new schedule property to our /email/send and /email/mime API endpoints, allowing you to schedule emails for delivery up to 3 days in advance.

This makes it easy to:

• Queue transactional emails ahead of peak periods
• Time-sensitive campaigns more precisely
• Spread out high-volume sends
• Improve operational workflows without external schedulers

New Schedule Tracking Support

When using the schedule property, the API will now return a schedule_id instead of an email_id.

This schedule_id can be used to:

• Track scheduled email delivery via webhooks
• Identify scheduled sends before delivery occurs
• Manage queued emails programmatically

In addition, scheduled emails will include a new email header:

None
X-Smtp2go-Schedule-Id

This header can also be used alongside webhooks to monitor the lifecycle and delivery status of scheduled messages.

New Scheduled Email Management Endpoints

To support scheduled sending, we’ve introduced two new API endpoints for managing queued emails.

/email/scheduled/search

Retrieve a list of up to 1,000 scheduled emails matching the supplied search parameters.

This endpoint is ideal for:

• Auditing scheduled sends
• Monitoring pending delivery queues
• Building scheduling dashboards or admin tools

/email/scheduled/remove

Remove a scheduled email using its schedule_id.

This gives developers the flexibility to:

• Cancel pending emails
• Update workflows dynamically
• Prevent outdated or unnecessary messages from being sent

Boost Your API Sending Speed with fastaccept

We’ve also introduced a new optional parameter, fastaccept, to our email-sending API.

When enabled, fastaccept can significantly improve sending performance by allowing the API to acknowledge requests more quickly during high-throughput operations.

This is especially useful for:

• Large-scale transactional email systems
• Time-sensitive workloads
• Applications requiring lower API response latency

We plan to make fastaccept the default behavior in a future release, so now is a great time to begin testing and integrating it into your workflows.

For implementation details and examples, please refer to the API documentation.

Send Up to 1,000 Emails with the New Batch Endpoint

We’re also introducing a brand-new API endpoint:

None
/email/batch

This endpoint allows you to send or schedule a batch of up to 1,000 emails in a single request.

Why Use Batch Sending?

Batch sending helps reduce:

• API request overhead
• Connection setup costs
• Processing latency

while simplifying large-scale email operations.

Use cases include:

• Bulk transactional notifications
• Multi-recipient workflows
• Scheduled bulk sends
• High-volume application messaging

The new endpoint supports both immediate sending and scheduled delivery, giving you maximum flexibility for managing large email workloads efficiently.

Designed for Scale and Flexibility

These updates are part of our ongoing effort to provide faster, more reliable and more scalable email infrastructure.

For full implementation details, examples and parameter documentation, check out the API documentation.

Does Gmail work in China in 2026?

No, not on a normal mainland China connection. Google’s services are blocked by the Great Firewall, and that’s held steady since mid-2014. It’s not just the Gmail website either. The block reaches:

• Gmail on the web (mail.google.com won’t load)
• The Gmail mobile app (Android and iOS)
• Google Workspace Gmail (your custom-domain Google account is affected too)
• IMAP, POP, and SMTP - so you can’t quietly pull your mail down into Apple Mail or Outlook and dodge the website block. The protocols are blocked at the connection level.

A few things worth knowing before you assume the worst:

Hong Kong and Macau are different. They sit outside the Firewall, so Gmail generally works there on local networks. If your traveler or office is in HK, this whole article may not apply.

eSIMs changed the game. This is the part the old version of this page couldn’t have mentioned, because consumer eSIMs barely existed in 2014. An international roaming eSIM routes your phone’s data through a network outside mainland China, so the Firewall treats you like an international roaming user and Gmail loads. For a quick inbox check on a phone, that’s now often easier than fighting with a VPN.

The block targets access, not your account. Your Gmail account is fine. Your mail is sitting there. The problem is the pipe between your device and Google’s servers, which is exactly why the sending problem and the reading problem have different solutions.

First, which problem do you actually have?

This is the question almost every other guide skips, and it’s the one that saves you hours. “Gmail is blocked in China” is really five or six different problems wearing the same coat. Here’s how they sort out.

If your honest answer is one of the top two rows, the rest of this page will still be useful, but the real fix is connectivity (a VPN or eSIM), and we’ll point you there fairly in the next section. If you’re in the bottom four rows, you’re in the right place.

If you just need to READ Gmail in China

Quick and honest, because this isn’t where SMTP2GO fits and we’re not going to pretend otherwise.

To get your actual inbox back on a mainland connection, you have a few options, each with a real trade-off:

• A VPN restores full access to Gmail and the rest of Google, but only if it’s one of the few that reliably beats the Firewall, and you have to install it before you arrive (the download pages are often blocked once you’re inside). Set it up at home.
• An international eSIM or roaming routes your data outside China, so Gmail works on your phone without a VPN at all. Easiest path for mobile-only inbox checks. Less helpful for a desktop workflow.
• Email forwarding set up before you travel pushes important mail to an inbox you can reach inside China. A good safety net for “I just need to not miss anything critical.”
• Gmail offline mode lets you read already-downloaded mail, but it won’t fetch anything new. Emergency fallback only.

Pick based on whether you need everything (VPN), just your phone (eSIM), or just the important stuff (forwarding). That’s the whole decision. Now, the part this page is actually for.

If you need to SEND email from China: use an SMTP relay

Here’s the distinction that matters. When your app, your website, or your email client sends a message, it doesn’t need to load a webpage. It just needs to hand the message to a mail server it can reach, over a port that isn’t blocked. That’s all an SMTP relay (SMTP2GO) is: a sending server you point your software at, which takes the message and delivers it on your behalf. (New to the idea? We wrote a plain-English intro to SMTP relays.)

The trick from inside China is the port. Most mail software defaults to port 587 or 25 for sending. Those get throttled or blocked all the time on restricted networks. But port 443 is the port secure websites use. Blocking it would break HTTPS for the entire country, so it stays open. Point your sending at an SMTP relay on 443 with SSL, and your mail usually goes straight out while the Gmail website is still sitting there refusing to load.

The exact settings

This is SMTP2GO’s documented controlled-location setup, and it’s the same configuration the support team recommends for China today:

That’s it. Five fields. No webpage to unblock, no inbox to recover. You’re not trying to defeat the Firewall, you’re just sending mail over a door it can’t afford to close.

Why port 443 works when 587 and 25 don’t

It’s the same logic the VPN crowd relies on, applied to email. Port 443 carries HTTPS, the encrypted traffic behind every secure website, bank login, and payment page in the country. A censor can throttle or block niche ports like 587 or 25 without anyone noticing. Block 443 and you’ve taken down secure browsing nationwide. So it stays open, and an SSL connection to a mail relay on 443 looks, from the outside, a lot like ordinary secure web traffic.

This is also why our customers running odd hardware lean on it. OPW Electronic Systems sends alerts and reports off proprietary equipment, and as their team put it, the flexible range of ports lets their gear “work on almost all network configurations.” Same principle: when the standard mail port is closed, you reach for one that’s open. (If ports are new territory, we made a plain-language guide to SMTP ports.)

Set it up in your app, device, or website

The settings above go anywhere that has an “outgoing mail” or “SMTP” field. Swap in mail.smtp2go.com, port 443, SSL on, and your credentials. A few specifics by use case, with the full walkthroughs linked:

• Outlook: point the outgoing server at the controlled-location settings. Outlook setup guide
• Apple Mail: same idea under the outgoing (SMTP) server settings. Apple Mail setup guide
• Thunderbird: edit the outgoing server in account settings. Thunderbird setup guide
• WordPress & WooCommerce: use an SMTP plugin so order confirmations and password resets stop silently failing. WordPress plugin guide · WooCommerce guide
• CRMs & helpdesks: Salesforce, Zoho, and the rest take standard SMTP credentials. Salesforce guide · Zoho CRM guide
• Printers, scanners & devices: scan-to-email and device alerts are a classic China headache. Ricoh · Kyocera · Xerox
• Custom apps: send over SMTP or the API. Node.js · Python · PHP

One Gmail-specific caveat worth its own line. If you’ve set up Gmail’s “send mail as” to send through a different address, that feature still routes through Google and can stamp your messages with an awkward “on behalf of” header. Sending through your own relay avoids it. We’ve written up how to dodge the “on behalf of” message if that’s your situation.

A full library of setup guides covers the apps not listed here.

“Sent” doesn’t mean “delivered” - what to watch from China

Getting the message out is half the job. The other half is knowing it arrived, and that’s where sending blind from a restricted network gets expensive. A few failure modes are sharper from China than from a normal connection:

• A throttled port can swallow a message so your app reports success while nothing left.
• Mail sent from a fresh or shared setup can quietly land in spam without a single bounce to warn you.
• A hard bounce or a spam complaint you never see is a reputation problem building in the dark.

The fix isn’t hope, it’s visibility. SMTP2GO’s Activity dashboard logs what happens to every message: delivered, bounced, opened, clicked, rejected, marked as spam. You track a send to its destination roughly the way you’d track a parcel. When something fails silently, you find out, instead of hearing about it from an angry customer three days later. SPF and DKIM are handled for your domain so your mail authenticates properly, which matters more than ever now that Gmail and Yahoo enforce authentication rules for bulk senders.

This is the part real customers keep coming back to:

• Intelligent Eye put it simplest: “Where I have sometimes been blocked from sending, such as at hotels, SMTP2GO has been able to send.” A hotel network and the Great Firewall block mail for the same kinds of reasons, and the workaround is the same.
• Stored Technology Solutions has used SMTP2GO since 2011 to keep phone systems, copiers, and printers sending “with no headaches and no downtime,” after ISP limits made device email harder and harder to deliver.
• GlaxoSmithKline runs a time-critical notification system on it, pushing manufacturing-room conditions to the next shift so production can start on schedule. Their note: it “worked accurately from Day One.”
• Group IMD, a SaaS provider, scaled on it from 10,000 emails a month to over a million over six years, because their customers expect email to “just work.”

None of those are China case studies. They’re something more useful: proof that when a network fights your outbound mail, this is the layer that keeps it moving.

Troubleshooting: still not sending from China

Work down this list. Most “it won’t send” reports are one of the first three.

Port 443 won’t connect. Try 465, then 8465, SSL on for each. If all three stall, the network is doing something unusual (a corporate firewall doing deep packet inspection, say). That’s the case where you run a VPN and SMTP2GO together.

You get a 535 authentication error. This is credentials, not the Firewall. Re-copy your username and password from Sending → SMTP Users, watch for trailing spaces, and confirm SMTP authentication is switched on in your app.

SSL/TLS errors. Make sure you’ve selected SSL (not plain/STARTTLS) for ports 443/465/8465. Legacy devices sometimes only speak an old TLS version. If a printer or older box refuses to handshake, check its firmware and TLS support.

It sends, but never arrives. Open the Activity dashboard and find the message. The event tells you the story: a hard or soft bounce points at the recipient address or server; “delivered” means it’s a placement problem, covered next. Our guide to hard vs soft bounces decodes the rest.

It lands in spam. Confirm SPF and DKIM are set for your domain, keep your content clean, and warm up gradually if you’ve just started sending volume. Start with our stay-out-of-spam playbook.

Attachments fail. SMTP2GO allows up to 50MB per email. If a device chokes below that, the limit is usually the device or the recipient server, not the relay.

Your VPN browses fine but email still won’t send. That’s the giveaway that your problem was never inbox access. The browser works because 443 is open. Point your mail at 443 too and it’ll move.

[FAQ]

Start sending from China in about five minutes

If your inbox is the problem, sort out a VPN or eSIM before you fly. If your sending is the problem, this part’s quick:

1. Create a free SMTP2GO account.
2. Set your app or device to mail.smtp2go.com, port 443, SSL on.
3. Send a test message.
4. Open the Activity dashboard and confirm it shows delivered.

Four steps, and your outbound email is back, whether you’re behind the Great Firewall, a hotel network, or an ISP that throttles the usual ports. If business depends on email while you’re operating in China, don’t leave it to a VPN that might drop at the worst moment.

Start my free account → Free plan included. No credit card.

Here’s what happened. Gmail and Yahoo started enforcing new requirements for any sender pushing more than 5,000 messages a day to their inboxes. One of those requirements: a working one-click unsubscribe, implemented via two specific email headers, honored within two days. Get it wrong and the receiving server can start deferring or rejecting your mail. No takedown notice. Just a quiet drop in inbox placement, then a complaint rate creeping toward the 0.3% line where Gmail starts treating you like a spammer.

So the unsubscribe link isn’t a footer afterthought anymore. It’s part of your deliverability stack.

This piece walks through the modern stack in the order that matters: the platform floor (what Google and Yahoo now enforce), the legal floor (CAN-SPAM, CASL, GDPR), the UX layer (what good actually looks like), and the retention layer (how to save subscribers who were wavering, not the ones already gone).

Why the unsubscribe link decides your sender reputation

Here’s the part most guides skip. Every spam complaint is a thumb on the scale of your sender reputation. And every recipient who can’t find your unsubscribe link is one click away from logging a complaint instead.

Gmail publishes the math openly through Postmaster Tools. Their stated thresholds are tight: complaint rates above 0.3% are the line you don’t want to cross, with 0.1% as the practical target. Cross 0.3% and you’ll see deferrals, throttling, and eventually outright spam-folder placement for your entire domain, not just the campaign that caused it.

We see this in our own data at SMTP2GO.

The takeaway is uncomfortable for marketers used to thinking of unsubscribes as a loss metric: every easy unsubscribe is a complaint you didn’t get. You want them. You want them more than you want a slightly fatter list. A list of 80,000 engaged subscribers outperforms 100,000 padded with disengaged contacts who are about to torch your reputation.

For the upstream side of this (cleaning the list before it gets to the unsubscribe stage), see the bounce rate survival guide and email scrubbing: why a clean mailing list is key.

The new floor: one-click List-Unsubscribe

This is the change everyone needs to understand. As of February 2024, both Google and Yahoo started enforcing the requirement for senders sending over 5,000 messages per day to their inboxes, and one-click unsubscribe via the List-Unsubscribe header is part of that mandate.

Two headers do the work, both defined under RFC 8058:

List-Unsubscribe: <mailto:unsubscribe@yourdomain.com>, <https://yourdomain.com/unsub?token=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The first header gives mail clients a machine-readable unsubscribe endpoint. The second tells them it’s a true one-click action, no confirmation page, no preference center, no “are you sure.” When a Gmail user clicks the unsubscribe link Gmail renders next to the sender’s name, that’s what fires. The recipient never visits your site.

Two operational details people miss:

You must honor the request within two days. The RFC and the ISPs both say so. If your unsubscribe pipeline batches overnight, you’re already late.

The endpoint receives a POST with List-Unsubscribe=One-Click in the body. If your handler expects a query string or a GET, it fails silently and the unsubscribe doesn’t process. We’ve seen this on more than one migration audit.

Here’s what we did when we built this into the SMTP2GO platform.

Customers using our tracking automatically get both headers added to outbound mail and the recipient is added to the suppression list inside the platform, so the next send doesn’t go to them.

No engineering work required at the application layer.

If you’re sending through a custom MTA or a different relay, you’ll need to either generate these headers yourself or check that your provider is doing it. SendGrid, Mailgun, and AWS SES all support it but the configuration varies. A 30-second test: send yourself an email, view source, search for List-Unsubscribe. If it’s not there, your bulk sends to Gmail and Yahoo are at risk.

For the full breakdown of the Feb 2024 enforcement, our guide to the Gmail and Yahoo 2024 inbox protection rules goes deeper.

The legal floor: CAN-SPAM, CASL, GDPR

The Gmail/Yahoo rules are the platform floor. The legal floor is older and stricter in several places. If you send anywhere outside the US you need to know which rules apply to which recipients.

CAN-SPAM is the American baseline. It requires a clear opt-out mechanism in every commercial email, processing within 10 days, an unsubscribe link that stays live for at least 30 days after the send, and no requirement that the recipient log in to unsubscribe. Violations are per-email, and the fines have teeth.

CASL is Canada’s law and it’s stricter. It requires the unsubscribe mechanism to remain functional for 60 days, processing within 10 business days, and the opt-out has to cover all commercial messages from the sender, not just the specific list.

GDPR doesn’t write the unsubscribe rules per se but it changes the consent model under them. Under GDPR, marketing email generally requires opt-in consent in the first place, and that consent has to be withdrawable as easily as it was given. Practically, that means your unsubscribe needs to work without a login, without a survey, and without forcing the recipient through a preference center if they want a hard out.

For the side-by-side and the additional state-level rules (California’s CCPA matters here too), see navigating GDPR, CAN-SPAM and CASL and a look at the California Consumer Privacy Act.

The honest summary: build to the strictest standard you send under. If you ship one campaign to Canada you should be honoring 60-day link validity globally. It’s simpler operationally and it forecloses a class of compliance bugs.

The UX layer: making unsubscribe painless

The platform and legal floors set the minimum. The UX layer is where you stop accumulating complaints and start building goodwill with people on their way out.

Eight practical rules, in rough order of impact.

Use the word “unsubscribe.” Not “manage preferences,” not “click here,” not a tiny grey icon. The recipient is scanning. If the link doesn’t match the verb in their head, they reach for the spam button instead.

Put the link where it’s findable. Gmail puts an unsubscribe link near the sender address for List-Unsubscribe-equipped mail. Most other clients show your footer first. Either way, the link needs to be there, visible, and not visually buried under five legal disclaimers.

Don’t require login. It’s against CAN-SPAM. It’s also the fastest way to get marked as spam by a frustrated recipient who can’t remember their password.

Don’t make them fill out a survey first. Surveys are fine after the unsubscribe is honored, optional, as a polite “before you go.” Before the unsubscribe, they’re a hostage situation.

Honor it immediately. The law gives you 10 days. The recipient expects two seconds. Anything between sends the message that you’re hoping they’ll forget.

Land them on a branded confirmation page, not a confirmation email. They asked to stop receiving mail. Sending them another email to confirm it stopped is the email-marketing equivalent of arguing about the breakup at the door.

Offer a resubscribe link on the confirmation page. Accidental clicks happen. A one-tap path back recovers a small but meaningful share of accidental unsubscribes based on what we see in customer dashboards.

Don’t override the link’s underline or color to make it blend with the rest of the email. Deliberately camouflaged unsubscribe links are the marketing version of a fake “X” button. Recipients notice. ISPs eventually do too.

For more on why you need an unsubscribe button in the first place which covers the strategic case for marketers who still resist.

Retaining the wavering subscriber

This is where the strategy lives. The compliance and platform layers stop you bleeding reputation. The UX layer stops you bleeding goodwill. The retention layer is where you keep the people who don’t actually want to leave, they just want less.

The biggest single move is a preference center reached from the unsubscribe link rather than as a forced detour. Two different decisions. “I want out completely” goes to the one-click path. “I want to change what I’m getting” goes to the preference center. Don’t conflate them.

Inside the preference center, the highest-impact options:

A frequency dial. If you send daily, offer weekly. If you send weekly, offer monthly. Daily-to-weekly typically holds onto a meaningful slice of would-be unsubscribers, in our experience working with high-volume B2C senders. The user gets oxygen, you keep the relationship.

A topic toggle. Newsletter, product updates, promotions, event invitations. Let them turn off the part they don’t want. The marketing team will hate losing the cross-promotion. The deliverability team will love the engagement signal.

A pause. Two weeks, a month, three months. People go on vacation. People have a busy quarter. A pause beats an unsubscribe because it returns them to an active list automatically.

A channel switch. Some recipients want updates, just not in their inbox. Offer the RSS feed, the social account, the SMS list if you have one. Honestly, this one’s mostly for goodwill, but goodwill compounds.

One thing not to do: don’t build re-engagement campaigns that rely on Apple Mail open rates. Apple Mail Privacy Protection inflates opens systematically, and a meaningful chunk of your list reads via Apple Mail. Use clicks, replies, and purchases as engagement signals. Send win-back to recipients who haven’t clicked in 90 days, not to recipients who haven’t opened. Marketing teams who didn’t update for MPP are still flying blind on this one.

Transactional vs. marketing: where the line is

A note for the half of the SMTP2GO audience running device, application, or system-generated mail.

Transactional email, in the strict sense, doesn’t require an unsubscribe link under CAN-SPAM. A password reset, an order confirmation, a printer scan-to-email, a security camera alert. None of those need an opt-out, because the recipient isn’t a “list,” they’re the person whose action triggered the message.

The line gets blurry the moment you add marketing content to a transactional email. A receipt with a promo banner is now a hybrid message and CAN-SPAM treats it as commercial. A welcome email that crosses into newsletter territory likewise. Rule of thumb: if more than a third of the message is marketing, you’re in commercial territory and the rules apply.

SMTP2GO handles this cleanly because we treat marketing and transactional as separate send streams with separate suppression behaviors.

If you’re sending both through the same provider, make sure the unsubscribe applies to the marketing stream only. Recipients shouldn’t stop getting their order confirmations because they unsubscribed from your newsletter.

If your unsubscribe link is sending complaint rates anywhere near 0.3%, fix the link before you fix the content. If you’re hitting the 5,000-per-day Gmail or Yahoo threshold and your List-Unsubscribe header isn’t there, that’s the first job, ahead of every list-cleaning project on your roadmap.

Worth checking your headers right now. Send yourself a test. View source. If List-Unsubscribe-Post: List-Unsubscribe=One-Click isn’t on the page, that’s your weekend.

For senders looking to migrate to a platform that handles all of this without engineering work, try SMTP2GO free. The List-Unsubscribe headers, the auto-suppression, the complaint feedback loops with the major ISPs, all of it is set up by default. We’ve been doing this since 2006 and we’d rather you got it right than learn the hard way.