Email Deliverability for a New SaaS: What Actually Got Us Out of the Spam Folder

A welcome-email survey question — "did you receive our welcome email?" — turned up an uncomfortable answer roughly six weeks after launch: close to a third of respondents said no, and a follow-up check of a handful of accounts using major email providers confirmed why, the emails were landing directly in spam, with no bounce, no error, nothing visible in the sending logs suggesting a problem at all. Fixing this took a genuinely specific combination of DNS configuration and sending-behavior changes, tracked against real inbox placement data rather than guesswork.

Why a brand-new domain starts with a real disadvantage

A domain with no email-sending history has no reputation with major providers, and no reputation is treated cautiously by default — spam filters lean on sender history as one of their strongest signals, and a domain that's never sent email before looks statistically similar to a domain a spammer just registered, from the filter's point of view, regardless of the actual content or intent of the email. This isn't a fixable-in-a-day problem; reputation is built over time through consistent, legitimate sending behavior, which is worth understanding up front so the fix isn't mistaken for a single quick configuration change.

The three DNS records that came first

# SPF: authorizes which servers are allowed to send email on behalf of the domain
TXT  @  "v=spf1 include:_spf.sendgridmail.example ~all"

# DKIM: cryptographically signs outgoing email so receivers can
# verify it genuinely came from the claimed domain, unmodified
TXT  s1._domainkey  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

# DMARC: tells receiving servers what to do with mail that fails
# SPF or DKIM checks, and where to send reports about it
TXT  _dmarc  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

None of these three records existed before the investigation — the transactional email provider's setup guide had mentioned them during onboarding, and in the rush of an early launch, that specific step had been skipped as "something to come back to later," which never actually happened until the survey results forced the issue. Without SPF and DKIM in place, a receiving mail server has no reliable way to confirm the email genuinely came from an authorized source, and treating unverifiable mail with suspicion by default is exactly the behavior every major provider's spam filter is designed to have.

DMARC's policy setting: starting cautious, not aggressive

The DMARC policy above starts at p=quarantine rather than the stricter p=reject, deliberately — quarantine tells receiving servers to treat failing mail with suspicion (typically routing it to spam) rather than rejecting it outright, which matters during the initial rollout specifically because any misconfiguration in SPF or DKIM during this early period would otherwise cause legitimate email to be silently rejected entirely rather than merely flagged, a considerably worse failure mode to discover after the fact. After several weeks of clean DMARC reports showing no legitimate mail failing authentication, the policy moved to p=reject, closing the loop against anyone attempting to spoof the domain — a two-stage rollout that's worth following deliberately rather than jumping straight to the strictest setting from day one.

The sending behavior change that mattered just as much as DNS

DNS records alone didn't fully resolve the issue — inbox placement improved noticeably but not completely in the two weeks following the DNS changes. The second contributing factor: transactional emails (welcome, password reset, receipt) were being sent from the same domain and, in some cases, the same sending infrastructure as early marketing emails to a purchased or scraped list from an earlier, since-abandoned growth experiment — a genuinely bad practice in hindsight, and one that had directly damaged the sending domain's reputation before the product had even properly launched. Separating transactional email onto its own subdomain, with its own SPF and DKIM records scoped specifically to it, isolated the clean, invited, expected transactional traffic from any reputation damage the earlier marketing experiment might have caused, and this separation is standard practice for exactly this reason — a domain's sending reputation isn't uniform across every use case, and mixing high-trust transactional mail with lower-trust bulk mail on the same sending identity is a common, avoidable mistake.

# Transactional email sent from its own subdomain, not the root domain
From: notifications@mail.example.com

# With its own scoped SPF and DKIM records
TXT  mail  "v=spf1 include:_spf.sendgridmail.example ~all"
TXT  s1._domainkey.mail  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Measuring the actual improvement, not just assuming it worked

Rather than relying on scattered anecdotal reports, ongoing inbox placement was tracked using the transactional email provider's own deliverability dashboard, which reports authentication pass rates and — for providers with the feature — approximate spam-folder placement rates across major inbox providers. Before the DNS and subdomain changes: SPF and DKIM pass rates hovered around 60%, meaning a large share of outgoing mail was failing authentication checks entirely, independent of spam filtering decisions made on top of that failure. Four weeks after both changes: pass rates were consistently above 98%, and the informal spot-check across test accounts at major providers showed welcome emails landing in the primary inbox rather than spam in every test performed, a meaningfully different and directly verifiable result compared to the original ad hoc survey that started the whole investigation.

What didn't turn out to matter as much as expected

• Email content and subject line wording — genuinely tested as a hypothesis early on, rewriting subject lines to avoid common spam-trigger words, and it made no measurable difference once the authentication issues were the actual dominant factor. Content-based filtering matters, but it wasn't the actual bottleneck here.
• Sending time of day — also tested, also no measurable effect on inbox placement for this specific case, though this may differ for bulk marketing sends rather than the transactional, individually-triggered emails this investigation focused on.

Worth naming honestly: it's tempting to try several plausible fixes at once under time pressure, and doing so makes it genuinely hard to know afterward which one actually mattered. Testing the DNS and subdomain-separation changes first, in isolation, before touching content or timing, is what made it possible to confidently attribute the actual improvement to authentication and sender reputation rather than a vague, unverifiable "we made several changes and it got better somehow."

What a new SaaS should set up before it ever sends its first real email

• SPF, DKIM, and DMARC (starting at p=quarantine), configured before launch, not added after a deliverability problem is already visibly affecting real users.
• A dedicated subdomain for transactional email, kept separate from any marketing or bulk sending, from the very first email ever sent — retrofitting this separation later, as this post shows, is more work than starting with it in place.
• A recurring, deliberate check of actual inbox placement, not just bounce rates — a bounce means an email failed to deliver at all; landing in spam produces no bounce and no visible error, which is exactly why it went unnoticed for six weeks in the first place.

If onboarding emails are part of a broader automated sequence rather than a single welcome message, what 200 support tickets taught me about fixing onboarding covers the surrounding onboarding experience this email is one piece of, and if you're building the sending logic itself with retry and delivery-confirmation handling, webhook retry logic that doesn't duplicate data covers a closely related reliability pattern worth applying to email delivery pipelines as well.

How the problem stayed invisible for six weeks in the first place

Worth being specific about why nothing in the sending logs raised an alarm during those first six weeks: from the sending provider's perspective, every email had been successfully handed off to the receiving mail server without error — a bounce specifically means the receiving server refused the message outright, which is a distinct, loudly-logged event. Landing in spam is a decision made silently, after successful delivery, by the receiving provider's own filtering logic, entirely invisible to the sender's own logs and dashboards unless something is specifically checking for it. This is exactly why the survey question — asking real users directly whether they'd received the email, rather than trusting the sending platform's own delivery metrics — was what actually surfaced the problem; a dashboard showing "100% delivered, 0% bounced" looked completely healthy the entire time, and technically was, by the narrow definition of delivery that dashboard was actually measuring.

Setting up an early warning system so this doesn't repeat silently

The fix that mattered most going forward wasn't just resolving the immediate spam issue, it was making sure a similar silent failure couldn't hide for six weeks again undetected. A small set of seed accounts — real inboxes at the major providers (a personal account at each of the two or three providers covering the bulk of the actual user base) — now automatically receive every transactional email type on a schedule, and their inbox placement gets checked manually on a regular short interval, specifically because it's the one signal that isn't visible anywhere in the sending platform's own dashboard by default.

• Bounce rate and delivery rate, tracked by the sending platform automatically, catch outright delivery failures but say nothing about spam-folder placement — necessary to watch, not sufficient on their own.
• DMARC aggregate reports, sent to the reporting address configured in the DMARC record, surface authentication failures across all receiving providers in aggregate, which is a genuinely useful ongoing signal once DMARC is fully in place.
• Manual seed-account inbox checks remain the only reliable way to directly observe actual spam-folder placement, since no dashboard metric substitutes for actually looking at where the email really landed.

The uncomfortable part: some early users probably churned silently over this

It's worth naming honestly rather than glossing over: the six weeks this went unnoticed almost certainly meant some early signups never saw their welcome email, never received onboarding guidance that email was meant to deliver, and quietly stopped engaging without ever filing a support ticket or leaving any trace explaining why — support tickets are, by nature, filed by people who noticed something was wrong and cared enough to say so, which is a biased and incomplete signal for a problem like this one that produces no visible symptom for the person experiencing it. There's no way to fully recover that specific lost cohort after the fact, and the honest lesson from it isn't really about email deliverability narrowly — it's a reminder that "no complaints" is a genuinely weak signal for "no problem," for any part of a product where the actual failure mode is silent rather than loud.