SaaS Email Deliverability Strategy

Email deliverability is an infrastructure problem wearing a marketing costume. Get the infrastructure wrong and no amount of subject-line optimisation fixes it. Most teams treat a dip in open rate as a copywriting failure, rewrite the subject line, and wonder why nothing changes. The actual fault usually sits three layers down, in DNS records, sending IP history, and list composition, none of which a copywriter can touch.

Why Deliverability Is an Infrastructure Problem

Mailbox providers such as Gmail, Outlook and Yahoo do not read your email before deciding where it lands. They make a placement decision, inbox, promotions tab or junk, based on signals accumulated about the sending IP address and domain long before the message content is parsed in any meaningful way. Those signals include historical complaint rate, bounce rate, engagement pattern and authentication status. Content filtering exists too, but it is a secondary check layered on top of a reputation score that is already mostly decided by the time a message is composed.

This is why a RevOps lead who fixes the subject line and sees no improvement is often looking in the wrong place. The fix that actually moves inbox placement is almost always upstream: authentication records, sending architecture, or list composition. Treat deliverability as you would treat application uptime, something you monitor continuously and design for, not something you tune once at launch and forget.

The Three Root Causes of Inbox Placement Failures

Almost every inbox placement problem traces back to one of three root causes, and they interact with each other, which is why fixing only one rarely solves the whole problem.

Sending Volume Outpacing Domain Reputation

Mailbox providers build a reputation score for a sending IP and domain gradually, based on how recipients on their platform respond to mail from that source. A brand new domain or IP has no history, so mailbox providers treat its early volume with suspicion by default. If a team migrates to a new email service provider and immediately sends a full campaign to the entire contact database on day one, the sudden spike in volume from an unproven source is itself a spam signal, independent of content quality. This is why every credible deliverability guide recommends a gradual warm up: start with a small volume sent to your most engaged contacts, the ones who open and click reliably, and increase volume over successive sends as positive engagement accumulates. Skipping this step is the single most common self-inflicted deliverability failure among SaaS teams switching platforms.

Poor List Hygiene: Bounces, Spam Traps and Dead Weight

Bounces come in two forms that require different responses. A hard bounce means the address does not exist and should be suppressed immediately; continuing to send to it after one hard bounce signals list quality problems to the receiving server. A soft bounce means a temporary issue, a full mailbox or a server timeout, and should only trigger suppression after several consecutive failures, since suppressing on the first soft bounce risks losing a valid contact over a transient blip.

Spam traps are a separate and more damaging risk. A pristine spam trap is an address that was never used to opt in anywhere and exists purely to catch senders using purchased or scraped lists. A recycled spam trap is more dangerous for teams with otherwise legitimate lists: mailbox providers convert genuinely abandoned addresses into traps after a long period of inactivity, so a contact who stopped engaging two years ago and was never removed can silently become a trap that damages your sender score every time you send to it. This is the mechanism that makes “we’ll clean the list eventually” an expensive habit rather than a harmless one.

Incomplete Authentication: SPF, DKIM and DMARC

SPF (Sender Policy Framework) publishes a list of servers authorised to send mail on behalf of your domain, but it has a hard technical ceiling: the receiving server is only permitted to perform ten DNS lookups while evaluating an SPF record, a limit defined in RFC 7208. Teams that add every marketing tool, CRM and outbound platform they use as an SPF include often exceed this limit without realising it, which causes SPF to fail permanently for that domain regardless of how correctly each individual include was configured.

DKIM (DomainKeys Identified Mail) signs each message with a private key so the receiving server can verify the message was not altered in transit and genuinely originated from an authorised sender. DMARC then ties SPF and DKIM together, requiring that at least one of them not only pass but align with the domain shown in the From address, and instructs receiving servers what to do with mail that fails that check. A DMARC record published with no reporting address is close to useless in practice, because you have no visibility into which of your legitimate sending sources might be failing alignment. Publishing a rua reporting address and actually reading the aggregate reports that come back is what turns DMARC from a checkbox into a working control.

Building a Multi Domain Sending Architecture

Why One Domain for Everything Is a Single Point of Failure

Sending marketing newsletters, transactional receipts and sales outbound all from the same root domain means all three share one reputation. A poorly targeted marketing campaign that generates a spike in spam complaints can drag down inbox placement for the password reset emails and invoices that your product depends on to function. That coupling is entirely avoidable and it is one of the more common architecture mistakes RevOps teams inherit from whichever tool was implemented first.

Structuring Subdomains by Send Type

The standard fix is to send each mail category from its own subdomain, for example mail.yourdomain.com for marketing, tx.yourdomain.com for transactional and sales.yourdomain.com for outbound prospecting. Each subdomain gets its own SPF include and DKIM selector, and consequently builds its own independent reputation history at most receiving mail providers. A reputation problem on the marketing subdomain no longer threatens the transactional subdomain’s ability to deliver password resets.

The nuance worth knowing before you assume subdomain separation is a complete firewall: DMARC reporting and policy enforcement still roll up to the organisational domain unless you publish a separate DMARC record specifically for a subdomain. So while the reputation signals mailbox providers use for spam filtering are largely tracked per subdomain, your DMARC aggregate reports (and your compliance posture under regulations such as the UK’s Privacy and Electronic Communications Regulations, which govern consent for direct marketing by email) should still be reviewed at the organisational domain level. Subdomain isolation reduces blast radius, it does not remove the need for organisation-wide oversight.

The Ongoing Hygiene Programme That Protects Reputation

Setting a Sunset Policy for Unengaged Contacts

A contact who has not opened or clicked anything in six months is not neutral. Every send to that address that goes unopened contributes negatively to the engagement rate mailbox providers use to judge whether your mail is wanted, and it raises the statistical odds that the address has quietly become a recycled spam trap. The correct response is a sunset policy applied on a fixed schedule, commonly reviewed quarterly, rather than left as an ad hoc decision nobody owns. Move contacts who fall outside your engagement window into a short re-engagement sequence first, one or two lower-frequency sends asking directly whether they still want to hear from you, and suppress anyone who still does not respond rather than continuing to include them in every regular send.

Monitoring Reputation Before It Shows Up in Open Rates

By the time a reputation problem is visible in your open rate dashboard, it has usually been building for weeks. Google Postmaster Tools gives a more direct view for any domain sending meaningful volume to Gmail addresses, showing domain reputation, IP reputation, spam rate and authentication success rate as separate tracked metrics, which lets you catch a degrading trend before it fully tips into the promotions tab or junk folder. This matters more since Apple’s Mail Privacy Protection made open rate an unreliable engagement signal for a meaningful share of recipients, since Apple pre-fetches images regardless of whether a human actually opened the message. Click-through and reply rate are now more trustworthy engagement indicators for both campaign performance and sunset policy decisions than open rate alone.

Also worth doing early: check whether your bulk sending volume crosses the thresholds mailbox providers now enforce formally. Google’s bulk sender guidelines define a bulk sender as anyone sending more than 5,000 messages a day to Gmail addresses, and require full SPF, DKIM and DMARC alignment plus an easy one-click unsubscribe for any sender that crosses that line. Falling short of these requirements does not just risk a reputation ding, it can result in outright rejection of mail at the server level.

A Five Stage Rollout for a Deliverability Programme

Teams fixing deliverability from a poor starting point tend to do better working through a fixed sequence rather than attacking every issue simultaneously. The order matters because later stages depend on earlier ones being correct: there is no point warming a new subdomain if authentication is not yet passing, and no point monitoring reputation if you have not yet segmented traffic in a way that makes the monitoring data meaningful.

1. Audit: pull current SPF, DKIM and DMARC records, bounce rate by list segment and current sending volume per domain, so you know your actual starting position rather than an assumed one.
2. Authenticate: fix SPF include count, publish or correct DKIM selectors, and move DMARC from p=none to a reporting-only posture with a working rua address.
3. Segment: split marketing, transactional and sales outbound onto separate subdomains, each with its own SPF and DKIM configuration.
4. Warm: ramp volume on any new or recently reconfigured subdomain gradually, starting with your most engaged contacts, before returning to full send volume.
5. Monitor: put Google Postmaster Tools and your ESP’s reputation dashboard into a recurring review cadence, and only then move DMARC toward p=quarantine and eventually p=reject.

Common Mistakes That Undo Good Deliverability Work

Migrating email service providers and sending the full contact database on the first day is the fastest way to burn a reputation that took months to build. The new provider’s IP pool or your new dedicated IP has no history with mailbox providers, so treat migration day like domain warming day one, not full volume day one.

Adding every marketing and outbound tool as an SPF include without checking the cumulative DNS lookup count is a slow-burn mistake. It works fine until the tenth or eleventh lookup, and then SPF fails outright for every sending source, including ones that were configured correctly, because the RFC 7208 lookup ceiling applies to the whole record, not per include.

Publishing DMARC at p=reject before confirming every legitimate sending source, including any third-party tool sending on your behalf, is properly authenticated will silently block genuine mail. Move through p=none and p=quarantine first, and read the aggregate reports at each stage rather than assuming alignment is correct.

Finally, treating open rate as the primary engagement metric for sunset and re-engagement decisions post-dates Apple Mail Privacy Protection inflating that number for a meaningful share of any B2B list. Base sunset and re-engagement logic on click and reply behaviour, which are much harder for a client to fake than an image pre-fetch.

Book your free AI audit