Email Deliverability for SaaS: A Practical, Evidence-Safe Guide

What a provider's plan changes about deliverability

Authentication, list quality and suppression are configuration you carry out whichever provider you pick, so a higher tier does not buy a better reputation. It buys evidence and control: how many days of events you can search, whether a dedicated IP is available, how quotas and sandbox limits work, and how cleanly the provider separates mail streams. Put both finalists through the same bounce and complaint drill and compare what each one let you see and change, then read the pricing page for the tier that unlocked it.

Is there a lower-risk way to move production mail?

Yes: move one message class at a time and keep the previous provider configured as a fallback route. Google's sender guidelines recommend ramping the modified portion of your traffic on its own after significant changes to sending infrastructure, so the first batch through the new provider should be small and made of engaged recipients who will notice a problem quickly.

What fails first in a deliverability migration?

Usually DNS: an SPF record that lists only the old provider, a DKIM selector that was never published for the new one, or a DMARC policy that now rejects mail from a system nobody remembered. Google notes that third-party senders missing from your SPF record are more likely to be marked as spam, so test authentication results before any real recipient is included.

What does a DMARC rollout look like, step by step?

DMARC tells receiving servers what to do with mail that fails SPF or DKIM, and it passes only when SPF or DKIM passes and the authenticating domain is the same as the one in the From header. Publish the record with a monitoring policy first, because Yahoo's best practices ask only for a valid policy of at least p=none, and set up aggregate reports so you can see every system that sends, or pretends to send, as your domain.

Read those reports for a few weeks. Each source that fails alignment is either a legitimate sender missing a record, such as a forgotten billing or support tool, or something you should not allow. Fix the first group, keep an owner for the second, and tighten the policy only when the reports show your own mail passing. Google also recommends DMARC reports for monitoring who impersonates your domain, so the same data doubles as an abuse alarm.

How do I read a Gmail 5.7.26 rejection?

The 5.7.26 code is Google's way of saying the message was not authenticated well enough. Its sender guidelines list it as one of two outcomes for mail that fails the required methods, the other being delivery to the spam folder, and the cure is in DNS rather than in the message. Check that the sending domain has SPF or DKIM, plus DMARC if you count as a bulk sender, and that the domain in the From header aligns with the one that authenticated.

Test with a message you send yourself to a Gmail account and open its original headers: the Authentication-Results line shows each method as pass or fail for the exact domain. If you use an email service provider, confirm it signs with DKIM for your domain rather than only for its own, since Google asks senders to verify exactly that. Fix one record at a time and resend after each change so the cause stays visible.

How do I know whether Gmail counts me as a bulk sender?

Google defines a bulk sender as anyone sending close to 5,000 messages or more to personal Gmail accounts within 24 hours, and it adds up everything sent from the same primary domain. Its own example is 2,500 messages a day from solarmora.com and 2,500 from promotions.solarmora.com: together that is 5,000, so the sender counts as bulk even though neither subdomain reaches the figure alone. A SaaS company whose product mail, billing mail and marketing mail share one domain should therefore add the three together.

Once you cross it, the stricter rules apply: SPF, DKIM and DMARC, one-click unsubscribe on marketing mail, and a spam rate that stays below Google's limits. Google's FAQ also defines a new domain as one that has not sent more than 5,000 emails a day to personal Gmail accounts since January 1, 2024. Read the daily Gmail volume from your provider's logs before the launch that would tip you over, not after.

Which message types need their own stream?

Anything a user needs in order to use the product: password resets, receipts, security alerts. Those must survive a promotional complaint, so they get their own From address, ideally their own subdomain, and where available their own provider stream or IP. Google's sender guidelines say that messages of one category should share a From address and that promotions do not belong inside receipts, which is the same split described from the receiving side. The transactional versus marketing guide covers how to classify the gray areas.

Reputation is tracked per domain and per IP address, so a shared IP carries other senders' habits with it. On a plan with shared IPs, check that the address is not on a blocklist and watch its reputation in Postmaster Tools; on a plan with a dedicated IP, remember that it starts without history and needs the gradual ramp set out in the bulk email sending guide.

How should I use Google Postmaster Tools for a SaaS domain?

Google points senders to Postmaster Tools for three readings: the spam rate, the reputation of the sending domain and the reputation of its IP addresses. Spam rates are calculated and updated daily there, and the guidance is to keep the user-reported rate below 0.1% and never let it reach 0.3%. Make the number visible to the team that ships email: a weekly look at the chart is enough for steady traffic, and a daily look is justified in the week after a launch or a template change.

The 0.3% line matters beyond reputation. Google's sender FAQ says bulk senders above it are ineligible for delivery mitigation and become eligible again after their spam rate stays below 0.3% for 7 consecutive days. Treat that as a reason to pause the stream early rather than to wait for the number to reach it.

What should a bounce and complaint webhook handler do?

Three things, in this order: record the event with the recipient, message class and timestamp, add the address to your suppression list if the bounce is permanent or the recipient complained, and alert a person if the rate for one recipient domain jumps. Google lists automatic unsubscription of recipients with multiple bounced messages as an acceptable practice, and Yahoo runs a complaint feedback loop that reports complaints back to registered senders.

Test the handler with deliberate failures before relying on it: a hard bounce to a nonexistent address on your own domain, a webhook endpoint that returns an error, and a duplicate delivery of the same event. The handler should be idempotent, so the same event arriving twice leaves one suppression entry, and it should keep working while your provider retries. Check how long your plan retains events, because a handler that was down for a weekend needs the logs to catch up.

What belongs in a deliverability incident checklist?

Start with containment: pause the affected stream so the damage stops growing, and tell the people who own the audience and the templates. Then look at what changed. Did authentication still pass on a fresh test message, did a template or list change ship in the last few days, did one recipient domain begin deferring while others did not, and is the sending IP on a blocklist? Read the response codes and the spam rate before you form a theory, because the codes usually name the cause.

Resume in steps, following Google's advice for a rate-limited sender: reduce volume until the SMTP error rate falls, then increase slowly again, beginning with engaged recipients. Write the incident down with the timeline, the cause and the one change that would have prevented it. That record is also the evidence you need if you later compare providers on how quickly each helped you find the problem.