Email Deliverability for SaaS: A Practical Guide

Deliverability is boring until your password reset emails start landing in spam. Then it's suddenly very interesting.

This guide covers what actually matters for SaaS email deliverability, without the paranoia-inducing complexity that most articles pile on. Every sender requirement below is taken from the mailbox providers themselves: Google's email sender guidelines and its sender guidelines FAQ, Yahoo's Sender Requirements & Recommendations, and the RFCs they point to. Where neither Google nor Yahoo publishes a number, this page says so instead of inventing one.

What Gmail and Yahoo require

Both providers split senders into two groups, and the line between them is the first thing to check. Google defines a bulk sender as "any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period", counts all mail from the same primary domain toward that figure (so a marketing subdomain does not give you a fresh allowance), and says that senders who meet the criteria even once are permanently considered bulk senders. Yahoo lists separate "Requirements for All Senders" and "Requirements for Bulk Senders" without publishing a daily volume figure.

• All senders: Google requires SPF or DKIM; Yahoo says to "implement SPF or DKIM at a minimum". Yahoo also asks every sender to keep its spam rate below 0.3% and to have valid forward and reverse DNS for sending IPs.
• Bulk senders: Google requires SPF, DKIM and DMARC. Yahoo requires both SPF and DKIM plus "a valid DMARC policy with at least p=none", with the From: domain aligned to the SPF or DKIM domain.
• One-click unsubscribe: Google says that if you send more than 5,000 messages per day, marketing and subscribed messages must support one-click unsubscribe. Its FAQ adds that transactional messages such as password resets are excluded. Yahoo requires a functioning list-unsubscribe header supporting one-click for bulk senders, calls the RFC 8058 POST method "highly recommended", and says to honor unsubscribes within 2 days.
• Spam complaints: Google says to keep the spam rate shown in Postmaster Tools below 0.10% and to avoid ever reaching 0.30%. Yahoo says to keep it below 0.3%.

In practice, a startup sending password resets and a monthly product update to a few thousand people can sit below the bulk threshold today and above it after one good launch week. Build to the bulk standard from day one; it costs nothing extra.

DNS authentication: SPF, DKIM, DMARC

Three DNS records matter. Set them up correctly once and mostly forget about them. Google's guidance for senders who use an email service provider is to verify that the provider authenticates your domain with SPF and DKIM, and to make sure your SPF record includes every sender for the domain.

SPF (Sender Policy Framework)

SPF tells receiving servers which mail servers are allowed to send email for your domain. It's a TXT record that lists authorized senders.

Your email provider will give you the specific value. It looks something like:

v=spf1 include:_spf.provider.com ~all

Common mistake: Having multiple SPF records. You can only have one. RFC 7208 says that if the lookup returns more than one SPF record, the check produces a "permerror" result, so a second record added by a second tool breaks both. If you use multiple email services, combine them into one record.

Second mistake: Too many includes. The same RFC (section 4.6.4) limits SPF evaluation to 10 terms that cause DNS queries (include, a, mx, ptr, exists and redirect), and over the limit the result is again a permerror. Every SaaS tool that asks you to "add our include" uses up one of those ten, so count them before you add the next one. A dedicated sending subdomain per tool keeps each record short.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your emails. The receiving server can verify the email wasn't tampered with and actually came from you.

Your email provider generates DKIM keys. You add their public key as a DNS record. They sign outgoing emails with the private key.

Setup: Follow your provider's instructions. It's usually adding a CNAME or TXT record with a specific selector name. Because each key lives under its own selector, an old tool and a new tool can both sign mail for your domain at the same time, which is what makes a low-risk migration possible (see the checklist below).

Key length: Google says that sending to personal Gmail accounts "requires a DKIM key of 1024 bits or longer" and recommends 2048-bit keys if your domain provider supports them. Yahoo also names a 1024-bit minimum. If a provider offers both, pick 2048.

DMARC (Domain-based Message Authentication)

DMARC tells receiving servers what to do when SPF or DKIM fail. It also enables reporting so you can see who's sending email as your domain.

Start with a monitoring-only policy:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Google explains that to pass DMARC a message must be authenticated by SPF or DKIM, or both, and that the authenticating domain must be the same domain that appears in the From: header. That alignment rule is why a tool that signs with its own domain (for example a shared "sent via" domain) can pass DKIM and still fail DMARC for you. Ask each provider for a custom DKIM signing domain, not just a shared one.

Yahoo strongly recommends including a "rua" tag that is properly set up to receive reports, and Google recommends setting up DMARC reports to see who sends mail as your domain. The reports are XML files, so point rua at a mailbox you will not read by hand or at a DMARC reporting service. After monitoring for a few weeks and confirming everything's working (every legitimate sender in the reports passes), move to enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Or strict rejection:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Sender Reputation

Email providers (Gmail, Outlook, etc.) track your sending reputation. Good reputation = inbox. Bad reputation = spam folder.

Reputation attaches to two things at once: your sending domain and the IP address the mail leaves from. Google states that on a shared IP "the activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address", which is why the choice of provider and plan matters. Yahoo says the same about the IP and the DKIM domain: "each IP and DKIM domain has a reputation".

What builds good reputation:

• Mail people asked for. Both providers say to send only to recipients who opted in, and Yahoo recommends a confirmation email so nobody is signed up by accident or by a bot.
• Low spam-report rate. This is the one number both Google and Yahoo publish a ceiling for (see the monitoring section below).
• Clean addresses. Yahoo advises monitoring hard and soft bounces and inactive recipients, and removing invalid recipients promptly.
• Consistent, gradual volume. Google recommends sending at a consistent rate rather than in bursts.
• Authenticated, aligned mail. SPF and DKIM aligned with each other at the organizational level, per Google's sending practices section.

Note what is not on the list: open rate. Google's guidelines say "Google doesn't track open rates" and that low open rates "aren't necessarily an accurate indicator of deliverability or spam classification issues." Treat open rate as a content signal inside your own dashboard, not as proof of inbox placement.

What damages reputation:

• Spam complaints. Google: "over time, user spam reports can lower your domain's reputation."
• Bought or scraped addresses. Both Google and Yahoo tell senders not to purchase lists, and Yahoo names pre-checked opt-in boxes as something to avoid.
• Sudden volume spikes. Google's example: suddenly doubling previously sent volumes "could result in rate limiting or reputation drops."
• Mixing mail types. Google says not to include promotions in receipt messages; Yahoo says not to send bulk marketing from the same IPs as transactional mail and alerts.
• Sending a bounce-heavy list. Google advises reducing volume when messages start bouncing or being deferred, until the SMTP error rate decreases.

Practical Guidelines

For transactional email

Transactional emails (password resets, receipts) are expected by the person who triggered them, which makes complaints rare. Your main risks:

• Sending to bad addresses. Implement email verification at signup, so a typo in the address bounces once at confirmation rather than on every later receipt.
• Slow delivery. A password reset that arrives after two minutes is a support ticket. Compare providers on delivery speed and logs in our Postmark and Resend pages.
• Getting mixed with marketing. Google's guidance is that messages of the same category should share a From: address (it suggests sales receipts, promotions and account notifications each get their own) and that, if you must use several IPs, each message type gets a different one. Yahoo says the same about separating bulk marketing from transactional mail by IP or DKIM domain. For a startup this usually means notify@ and news@ on different subdomains. The transactional vs marketing article covers the product side of that split.

For marketing email

Marketing emails face more scrutiny. Guidelines:

• Only email people who opted in. Never buy lists. Never scrape addresses. Google: "don't send messages to people who didn't sign up to get messages from you." Our list-building guide covers opt-in forms that work.
• Make unsubscribe easy. Technically that means two headers (see the one-click section below) plus a visible link in the body. Yahoo wants the link clearly visible and the process free of any login.
• Clean your list regularly. Remove bounced addresses immediately. Google suggests considering unsubscribing recipients who don't open or read your messages; Yahoo suggests a periodic reconfirmation email to inactive subscribers.
• Warm up new sending domains. Start with small volumes to engaged subscribers, gradually increase. The section below turns this into steps.
• Send consistently. Regular sending patterns build reputation better than sporadic blasts. Yahoo adds: honor the frequency of the list's intent, so don't start sending daily to subscribers who signed up for a monthly update.

One-click unsubscribe, step by step

One-click unsubscribe is specified in RFC 8058. The sender places one List-Unsubscribe header and one List-Unsubscribe-Post header in the message. Per the RFC, the List-Unsubscribe header "MUST contain one HTTPS URI" (it may also contain a mailto: address), and the List-Unsubscribe-Post header "MUST contain the single key/value pair" below. Google's guidelines show the same pair:

List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Three details from the RFC trip up homegrown implementations:

• The message must carry a valid DKIM signature that covers at least the List-Unsubscribe and List-Unsubscribe-Post headers. Without it, the RFC says the receiver "SHOULD NOT offer a one-click unsubscribe".
• The URI must identify the recipient and the list on its own, because the POST carries no extra arguments, and the RFC advises including an opaque, hard-to-forge component rather than a plain email address. The POST must not include cookies or HTTP authorization.
• The endpoint must not answer with an HTTPS redirect; the RFC notes that redirected POSTs have historically not worked reliably.

If you use a sending platform, it should add these headers for you; confirm it by viewing the raw source of a test message and finding both header names. If you send marketing mail through your own code, the unsubscribe handler is yours to build, and so is the 2-day processing window Yahoo asks for.

A rollout order for a brand-new domain or subdomain

Order matters because several steps depend on the one before. This sequence assumes you are starting a dedicated sending subdomain such as mail.yourstartup.com alongside your main domain.

1. Decide the split before you buy anything. Pick one subdomain for transactional mail and one for marketing, with separate From: addresses. Remember Google counts bulk volume across the whole primary domain, so the split protects reputation, not your bulk-sender status.
2. Add the domain in your sending platform and publish exactly the SPF include and DKIM records it gives you. Prefer a custom DKIM signing domain so DKIM aligns with the From: domain.
3. Publish DMARC at p=none with a rua address, as Yahoo's bulk requirement and Google's recommendation both point to. Leave it there while every sender is identified.
4. Check reverse DNS and TLS. Google requires a valid PTR record for sending IPs and a TLS connection; on a managed platform that is the provider's job, so ask rather than assume.
5. Register the domain in Postmaster Tools so reputation and spam-rate data starts accumulating from day one.
6. Send transactional mail first. Signup confirmations and receipts go to people who asked for them, which is the safest first traffic a new domain can have.
7. Start marketing mail with your most engaged contacts and follow the warm-up steps below.
8. Move DMARC toward quarantine or reject only after the reports show every legitimate source passing.

Warming up a new sending domain

Neither Google nor Yahoo publishes a day-by-day warm-up schedule, and any table that claims "day 3: 400 emails" is the author's rule of thumb. What Google does publish are the principles, and they are enough to build a schedule from:

• "Start with a low sending volume to engaged users, and slowly increase the volume over time."
• Send at a consistent rate and avoid bursts; you can increase volume faster when you send daily than weekly, and the more you send, the more slowly you should ramp.
• Avoid sudden spikes if you have no history of high volume; Google's own example is immediately doubling previously sent volumes.
• Monitor server responses, spam rate and domain reputation as you grow, so you can adapt "if your sending is rate limited".

For a startup, a workable version: for the first sends, mail only people who signed up in the last few weeks and have been active in the product; hold each volume step for several sends before raising it; raise by modest steps rather than doubling; and pause the ramp the moment you see deferrals or a rising spam rate. If you are importing an old list, send to the engaged slice first and leave the rest for later, or not at all.

What Your Email Provider Handles

A good email provider takes over a lot of the plumbing:

• IP reputation management
• Bounce processing
• Feedback loop processing (spam complaints)
• List-Unsubscribe headers
• Automatic suppression of problem addresses

You don't need to build these yourself, but you do need to check them before you commit, because Google tells senders using a provider to "verify that the provider follows the guidelines on this page" and adds that it can't guarantee mail sent by email providers will pass Gmail's spam filters. Questions to put to any vendor (Resend, Postmark, Customer.io, Sequenzy and the rest are all fair game): is DKIM signing on your own domain? Are the unsubscribe headers added automatically for marketing sends? Is the IP shared, and does a dedicated IP cost extra? Are bounces and complaints suppressed automatically, and can you export the suppression list? Our guide to choosing an email tool compares those answers across vendors.

Testing Deliverability

Before major campaigns:

1. Send test emails to your own Gmail, Outlook, Yahoo accounts
2. Check if they hit inbox or spam
3. Open the raw message source and confirm SPF, DKIM and DMARC show as passing for the From: domain, and that both unsubscribe headers are present on marketing sends
4. Use tools like Mail-Tester.com for detailed analysis
5. Check your domain reputation at Google Postmaster Tools (if you send significant volume to Gmail)

How to read bounce and complaint data

Your platform's dashboard and Google Postmaster Tools measure different things, and mixing them up is the most common way to misdiagnose a problem.

• Spam rate (Postmaster Tools). This is the number Google holds you to: keep it below 0.10% and avoid ever reaching 0.30%. Google's FAQ says it is calculated daily and that "rates of 0.3% or higher have an even greater negative impact on email inbox delivery". It also says bulk senders above 0.3% are ineligible for mitigation until the rate stays below 0.3% for 7 consecutive days. Because it is a percentage of Gmail traffic, a small list can move it with a handful of reports, so judge the trend over several days, not one send.
• Complaint rate (your platform or Yahoo's feedback loop). Yahoo says its spam rate is calculated "based on mail delivered to the inbox", so a rate you compute against all sent messages will differ slightly from Yahoo's. Enroll in Yahoo's Complaint Feedback Loop once your mail is DKIM-signed; Yahoo says an active CFL is needed for every DKIM domain.
• Hard bounces. Permanent failures for addresses that do not exist. They should be suppressed after the first one. A cluster of hard bounces right after an import means the list was bad at the source.
• Soft bounces and deferrals. Temporary failures. Google's SMTP codes help here: 4.7.28 means you exceeded a rate quota, in which case Google says to stop for at least 10 minutes and then resume from a single connection; 4.7.30 and 4.7.31 are rate-limits for failing DKIM or missing DMARC; 5.7.26 is unauthenticated mail; 5.7.1 on a shared IP can mean the IP has a poor reputation.
• No published bounce-rate limit. Neither Google nor Yahoo gives a bounce percentage to stay under. Watch for a change from your own baseline and for any bounce error that names a policy or authentication reason; those are fixable.

Red Flags to Watch

• Open rates dropping suddenly. Might be deliverability, might be content. Cross-check with Postmaster Tools before assuming.
• Bounces climbing on one send. Segment the bounces by error text: "user unknown" points to list quality, while a policy or authentication message points to your setup.
• Spam rate above 0.10% in Postmaster Tools. Google says this is already the line to stay under; review whom you send to and how easy the unsubscribe is.
• Emails going to spam for specific providers. Check authentication and content for that provider's guidelines.

What Doesn't Matter Much

Things people worry about that neither Google's nor Yahoo's published requirements mention (so they rank below everything above):

• Email length and images vs text ratio. Google's formatting rules ask for valid HTML and a single address in the From: header; they set no length or image-ratio limit.
• Certain "spam trigger words." Google's rules target deception instead: fake "Re:" or "Fwd:" subject lines, emojis next to a name to imply verification, and HTML or CSS used to hide content. Write honest subject lines and you are covered.
• Sending time optimization. Matters more for opens than delivery.

Before you migrate to another email tool

Switching platforms resets part of your sending history, because the IPs, and sometimes the signing domain, change. Google's guidance for changes is direct: after making any significant change to sending infrastructure or header structure, "increase the modified segment of traffic separately." A migration checklist that follows from that:

1. Export every suppression list from the old tool: hard bounces, spam complaints and unsubscribes. Import them into the new tool before the first send, or you will re-mail people who already opted out.
2. Add the new tool's DKIM records next to the old ones. Different selectors can coexist, so nothing breaks while both tools are live.
3. Merge the SPF record into a single record and count the DNS-lookup terms; do not publish a second SPF record.
4. Keep DMARC at p=none through the overlap and read the reports to confirm both tools pass alignment.
5. Verify the unsubscribe headers on a test send from the new tool.
6. Move one stream at a time. Move transactional mail first, then the engaged part of the marketing list, then the rest, using the warm-up rules above.
7. Leave the old tool's unsubscribe pages and tracking links running for a while, because earlier messages sit in inboxes with links that point back to it.

Cost and feature comparisons for the tools you might move between are on the compare pages.

The Bottom Line

1. Set up SPF, DKIM, and DMARC correctly
2. Separate transactional and marketing mail, ideally by subdomain
3. Use a reputable email provider and ask it the questions above
4. Only email people who want to hear from you
5. Make unsubscribe one click, with the headers RFC 8058 describes
6. Remove bad addresses promptly
7. Watch the spam rate in Postmaster Tools: under 0.10%, never 0.30%

Those seven habits cover what Google and Yahoo actually put in writing. Everything else is an edge case you can handle when it shows up in your bounce or complaint data. Requirements change, so re-read the Google and Yahoo pages linked at the top before a major launch.