VibeWeek
Home/Grow/Email Deliverability: Land in the Inbox, Not in Spam

Email Deliverability: Land in the Inbox, Not in Spam

⬅️ Growth Overview

Email Deliverability for Your New SaaS

Goal: Configure your domain, sender identity, and infrastructure so that 95%+ of your transactional and lifecycle emails reach the inbox — not spam, not promotions, not the dreaded unknown sender warning. Catch deliverability problems before they silently kill your activation funnel.

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: SPF/DKIM/DMARC + dedicated sending domain configured in 1-2 hours. Sender warming + first month of monitoring runs in the background. Quarterly deliverability review baked into the calendar from launch onward.

Why Most Founder Email Programs Silently Bleed Activation

Three failure modes hit indie SaaS founders the same way:

  • Sending from the apex domain. The founder configures Resend/Postmark/SendGrid to send from noreply@yourcompany.com and feels good about clean sender names. Six months later, a single careless cold-outreach blast (or a single batch of welcome emails to a stale list) tanks the apex domain's reputation. Now password resets, billing receipts, and onboarding emails all go to spam — silently — because every email type shares the same sender reputation. By the time you notice, you've lost weeks of activation.
  • DMARC is at "p=none" forever. The founder set up SPF and DKIM and never went back to enforce DMARC. Spoofers blast their domain; mailbox providers see misaligned mail and start suspecting the legitimate mail too. The fix is enforcement (p=quarantine or p=reject), but founders don't make the change because they're afraid of breaking something. They're right to be afraid; the answer isn't to skip enforcement, it's to monitor for two weeks first.
  • No deliverability instrumentation. Email service providers report "delivered" — meaning the receiving server accepted the message. They don't report "landed in inbox." A 99% delivered rate can hide a 40% inbox rate (the rest are in spam, promotions, or bulk folders). Without seed-list testing or inbox-placement monitoring, you can't see the leak.

The version that works is structured: send transactional and marketing email from separate subdomains, set up SPF/DKIM/DMARC properly with monitoring, warm up new sender identities slowly, and instrument inbox placement directly so you see the problem before customers tell you.

This guide assumes you have already shipped an Onboarding Email Sequence (the emails are written) and have an email service provider chosen (email providers comparison covers Resend / Postmark / SendGrid / Loops / Customer.io). If you haven't, do that first — this guide configures the deliverability layer underneath.

1. Set Up the Subdomain Strategy

Before any DNS records, decide which domains send which mail. Most indie SaaS get this wrong.

I'm building [your product] at [your-domain.com]. Help me set up the email subdomain strategy.

The principle: every kind of mail with a different reputation profile gets its own subdomain. Bad reputation on one subdomain doesn't drag down the others.

Standard 4-subdomain split:
1. **Apex domain** ([your-domain.com]) — keep this clean. Send NO mail from it. Use it only for the website. This means even your "hi@[your-domain.com]" reply-from address should not actually be the sending domain — it's a friendly From header that points back to a sending subdomain via DKIM/Return-Path alignment.

2. **Transactional subdomain** ([mail.your-domain.com] or [tx.your-domain.com]) — receipts, password resets, magic links, billing, security alerts. Tiny volume per user, near-100% engagement, never flagged. Use a dedicated ESP (Postmark or Resend) for this.

3. **Lifecycle / marketing subdomain** ([news.your-domain.com] or [hello.your-domain.com]) — welcome series, onboarding, product updates, weekly digests, drip campaigns. Higher volume, lower engagement than transactional, more spam-flag risk. Use a separate ESP account or different Resend audience.

4. **Sales / cold outreach subdomain** ([reach.your-domain.com] or [team.your-domain.com]) — only if you're doing cold outreach. Highest spam-flag risk; isolate completely. Often a separate provider (Instantly, Smartlead, lemlist) that handles its own warming.

Output:
- The exact 4 subdomains for my product (transactional / lifecycle / sales / what-not-to-use)
- Which ESP each subdomain points to
- The DNS records I'll need to add for each (covered in the next step)
- The "From" address format for each: e.g., transactional from "[Your Product] <hello@mail.your-domain.com>"

Then sanity-check: if I'm only sending transactional + lifecycle (no cold outreach), recommend collapsing to 2 subdomains. If I'm only sending transactional (early-stage product), recommend a single subdomain with the option to split when lifecycle volume grows.

Three principles:

  • Subdomain isolation is reputation insurance. Mailbox providers (Gmail, Microsoft, Apple) score reputation per sending domain. Splitting subdomains means a cold-outreach blunder doesn't tank password-reset deliverability.
  • Never send from the apex. Once you do, you can't undo the reputation entanglement. The cost of starting clean is 5 minutes of DNS configuration; the cost of fixing entangled reputation is months.
  • Keep the apex visually consistent in the user's mailbox. Using hello@yourcompany.com as the From and mail.yourcompany.com as the actual sending domain is fine — DKIM-aligned signatures keep it deliverable while users still see the friendly apex.

2. Configure SPF, DKIM, and DMARC

The three foundational records. Get them right or every other deliverability tactic is wasted.

For my sending subdomain [mail.your-domain.com] using ESP [Resend / Postmark / SendGrid / Loops], generate the exact DNS records I need to publish.

1. **SPF record** (TXT at root or subdomain) — declares which servers are allowed to send on behalf of this domain
   - Format: `v=spf1 include:[esp_spf_include] ~all`
   - For Resend: `v=spf1 include:amazonses.com ~all`
   - For Postmark: `v=spf1 a mx include:spf.mtasv.net ~all`
   - For SendGrid: `v=spf1 include:sendgrid.net ~all`
   - The `~all` (softfail) is the right ending. `-all` (hardfail) breaks third-party forwarding. `+all` is wide open and wrong.
   - Critical limit: SPF lookups can't exceed 10. Each `include:` counts. If I send through multiple ESPs from the same subdomain, I may need to flatten or split.

2. **DKIM records** (CNAME or TXT, ESP-specific) — signs each outbound message with a private key whose public counterpart is published in DNS. Receivers verify the signature, proving the message wasn't modified and came from an authorized sender.
   - Resend / Postmark / SendGrid all provide CNAME records pointing to ESP-managed key infrastructure. Use those, not raw TXT keys, so the ESP can rotate keys without DNS changes.
   - Use 2048-bit keys, not 1024. Most ESPs default to 2048 in 2026, but verify.

3. **DMARC record** (TXT at `_dmarc.your-domain.com`) — tells receivers what to do with mail that fails SPF/DKIM alignment, and where to send aggregate reports.
   - Start with: `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1; adkim=s; aspf=s`
   - `p=none` means "monitor only — don't block anything yet." Run for 2 weeks while you read aggregate reports.
   - Then move to `p=quarantine` for 2 weeks.
   - Then move to `p=reject` permanently.
   - `adkim=s` and `aspf=s` are strict alignment — recommended for transactional. Use `r` (relaxed) only if necessary.
   - `fo=1` means generate failure reports for any auth failure (more verbose but more useful).

4. **MX records on the sending subdomain** — needed by some receivers to verify the subdomain is "real" and bounceable. Even if you never receive mail at the sending subdomain, point MX to a black-hole endpoint or your ESP's bounce handler.

Output:
- The 4-record set as a copy-paste DNS table (Type / Name / Value / TTL)
- A verification command for each record using `dig` (e.g., `dig TXT mail.your-domain.com +short`)
- The DMARC report processing strategy: I'll receive XML reports at the rua address; recommend a tool to parse them automatically (Postmark's free DMARC monitoring, dmarcian, or Valimail)

Generate the records.

Three rules I've watched founders re-learn the hard way:

  • DKIM with CNAME (ESP-managed) is non-negotiable. Hard-coded TXT keys mean every key rotation requires DNS changes. ESPs rotate keys for security; you don't want to be in the loop.
  • DMARC enforcement is the goal, not the start. Two weeks at p=none, two weeks at p=quarantine, then p=reject permanently. Skipping the monitoring phase causes outages; skipping the enforcement phase leaves you spoofable.
  • Aggregate report processing is mandatory. Reading raw XML once a week is misery. Use Postmark's free DMARC monitoring, dmarcian's free tier, or Valimail. The reports tell you which legitimate senders you forgot to authorize and which spoofers are abusing your domain.

3. Add BIMI for Brand Display (Optional but High-Leverage)

BIMI (Brand Indicators for Message Identification) lets your logo appear next to the sender name in Gmail, Apple Mail, Yahoo. Trust signal. Free if you already have DMARC at enforcement.

For my domain [your-domain.com], help me set up BIMI.

Requirements:
1. DMARC at `p=quarantine` or `p=reject` (must be enforced, not p=none)
2. SVG logo following the BIMI Tiny PS spec (square, on a solid background, simple, no transparency, no gradients in some renderers)
3. A Verified Mark Certificate (VMC) for Gmail display — costs $1,500-$1,900/year from DigiCert or Entrust. OR a Common Mark Certificate (CMC) which is cheaper but only works for some receivers.
4. BIMI DNS record: TXT at `default._bimi.your-domain.com` pointing to the SVG URL and the VMC URL.

For an indie SaaS in 2026:
- If you have a registered trademark for your logo: get a VMC ($1,500-1,900/year). The trust lift in Gmail / Apple Mail is real.
- If you don't have a registered trademark: skip the VMC route; BIMI without a VMC works in some receivers but not Gmail. Revisit when trademark is filed.

Output:
1. The required SVG spec to send to my designer (square viewbox, solid background, no transparency, valid SVG 1.2 Tiny PS)
2. The VMC application path: pick a CA, submit trademark documentation, complete the validation
3. The DNS record format
4. Sanity check: is BIMI worth the cost for me? (Recommendation: yes if I send 10K+ marketing emails per month to Gmail audiences; defer if pre-launch)

BIMI is the single best "you're a real company" signal in 2026 inboxes. The VMC cost is real but the trust lift in B2C-heavy audiences is measurable. For B2B with Gmail-Workspace customers, recipients may not even see BIMI by default. Calibrate to your audience.

4. Warm Up the Sending Domain

A brand-new sending subdomain has no reputation. Send 50,000 emails on day 1 and Gmail flags every one as spam. Warm slowly.

Help me design the sending warm-up plan for [mail.your-domain.com].

Inputs:
- New ESP account / new sending subdomain
- Total email volume I'll eventually send: [N transactional/day + M lifecycle/day]
- Audience: [B2B / B2C / mix], primarily [Gmail / Microsoft / mix]

Standard 4-week warm-up plan:

Week 1: 50-100 emails/day. ONLY to highly engaged recipients — people who explicitly opted in within the last 30 days OR existing employees who will open the test mail. The goal is open-rate proof, not volume.

Week 2: 500 emails/day. Same engagement quality. Watch for bounces and spam complaints. If spam complaint rate >0.1%, slow down.

Week 3: 2,000-5,000 emails/day. Now you can include warm subscribers (last 90 days). Continue to exclude any list older than 90 days.

Week 4 onward: scale to full volume. Continue monitoring. Re-warm if you pause sending for >2 weeks (mailbox reputation is short-memory).

Anti-patterns:
- Sending to a re-engaged dormant list during warmup. Stale lists have high bounce rates and tank reputation.
- Buying lists. Period. Never. The damage to your sending domain is irreversible.
- Importing all your mailing lists from a previous ESP on day 1. Slow drip; warm fresh.

Output:
1. The 4-week schedule with specific volumes per day
2. The audience filtering for each week (recency + engagement criteria)
3. The pause triggers (spam complaint > X, bounce > Y, open rate < Z)
4. The check-in cadence: review reputation daily during weeks 1-2, weekly thereafter
5. Tools: Google Postmaster Tools (free, required) and Microsoft SNDS (free, required) — both must be set up before warming starts so I can see reputation building in real-time.

Then handle the corner case: if I'm sending only transactional (e.g., password resets) and volume is naturally low, I don't need a separate warm-up plan — natural growth is the warm-up. This applies if I'm under 1,000 emails/month for 6+ months.

Two patterns that prevent disasters:

  • Google Postmaster Tools is non-negotiable. Sign up before you send the first warmup email. The reputation graphs Google shows you are the closest thing to ground truth on Gmail deliverability.
  • Microsoft SNDS for Outlook/Hotmail audiences. Less polished UI than Google's but the same purpose. Smart Network Data Services (SNDS) shows reputation for Outlook/Hotmail/Live customers. If you have any Microsoft-tenant audience, set this up too.

5. Instrument Inbox Placement, Not Just "Delivered"

Your ESP says "delivered." Gmail says "spam folder." Instrument the actual landing.

Help me set up inbox placement monitoring for [your-domain.com].

Three tools I should evaluate:

1. **GlockApps** ($79-$300/mo) — seed-list testing. You send a campaign through your normal pipeline; GlockApps has hundreds of seed inboxes across Gmail, Outlook, Yahoo, etc. They report exactly where your message landed (inbox / spam / promotions / unknown). Best for marketing/lifecycle email monitoring.

2. **Mail Tester** (free + paid tiers) — single-message scoring. Send one message to their unique address; they score it 0-10 based on SPF/DKIM/DMARC/content. Great for diagnosing a specific email template.

3. **Postmark Inbox Insights / SendGrid Inbox Placement** — built into some ESPs. Useful if your ESP includes it.

For ongoing monitoring, set up:
- A monthly seed-list test of each major email template (welcome, onboarding email 3, password reset, billing receipt) using GlockApps or equivalent
- An automated weekly job: send the welcome email to a controlled test inbox in Gmail Workspace, Outlook 365, Apple Mail. Use a script + headless inbox check to confirm placement. Alert if landing changes.
- Quarterly: a full seed-list audit covering every active sending subdomain

Output:
1. The recommended tool stack for my volume and budget
2. The cron/automation schedule for the weekly check
3. The KPIs I'll track in my deliverability dashboard:
   - Inbox rate (target: >95% Gmail, >90% Outlook)
   - Spam rate (target: <2%)
   - Spam complaint rate (target: <0.1% — Gmail throttles aggressively above 0.3%)
   - Bounce rate (target: <2% — anything above 5% is a list-quality problem)
   - Sender reputation (Postmaster Tools "Domain Reputation" should be High)
4. The alert thresholds: when to investigate, when to pause sending

Two non-negotiables:

  • The "delivered" rate from your ESP is meaningless on its own. It only means the recipient SMTP server accepted the connection. The mail can be in spam, promotions, bulk, or a custom filter. Always pair it with seed-list inbox-placement testing.
  • Spam complaint rate is the single most important metric. Gmail's tolerance is roughly 0.3%; sustained complaints above that flip you to bulk. Make unsubscribe one-click, easy, and obvious. Customers who can't unsubscribe report as spam, and reporting as spam is reputation-deadly.

6. Authenticate Reply-To and Friendly From

The friendly From header is what users see. Get the alignment right.

Help me audit the email header configuration for my main email types.

For each of these mail types in my product:
- Welcome email (lifecycle)
- Password reset (transactional)
- Billing receipt (transactional)
- Weekly digest (lifecycle)
- Support reply (1:1 from a real human)

Show me the recommended:
1. **Friendly From** (what the user sees): "[Your Product] <hello@your-domain.com>" — uses apex for visual familiarity
2. **Return-Path / envelope From** (where bounces go): "<bounce@mail.your-domain.com>" — uses sending subdomain
3. **Reply-To** (where replies go): "support@your-domain.com" or a real human's address — apex is fine here because we're not sending from it, only receiving
4. **DKIM signing domain** (`d=` in the DKIM-Signature header): `mail.your-domain.com` — must align with Return-Path for DMARC alignment
5. **Authenticated identity declared in SPF**: matches Return-Path

The critical alignment rule: at least one of {SPF, DKIM} must align with the Friendly From's domain (or its parent). For DKIM alignment, the DKIM `d=` must be the same as or a subdomain of the From domain. Strict alignment means exact match; relaxed means parent-child match.

Most ESPs default to relaxed alignment, which is fine. The trap: some ESPs let you set Friendly From freely without configuring matching DKIM, leading to misalignment that fails DMARC silently.

For each mail type, output:
- The exact header configuration in my ESP's UI
- The DMARC alignment check: would this pass strict alignment? Relaxed?
- A test you can run: send the message to mail-tester.com and verify alignment passes

Then handle the special case: support replies sent from a real human's email client (e.g., founder replies from `you@your-domain.com` directly via Gmail Workspace). These need their own SPF + DKIM authorization for Gmail Workspace — the ESP's DKIM doesn't cover them. Verify Workspace's DKIM is published.

The most common deliverability bug I see: friendly From says hello@yourcompany.com but the ESP's DKIM signs as d=resend.dev. DMARC alignment fails silently, mailbox providers downgrade trust over time. Fixing this once usually unlocks 10-30 points of inbox rate.

7. List Hygiene and Engagement-Based Sending

Mailbox providers reward engaged audiences and penalize stale ones.

Design the list hygiene rules for [your product]'s lifecycle email program.

Rules to implement:

1. **Hard bounce removal**: any address that hard-bounces is permanently suppressed within 1 hour. ESPs do this automatically; verify it's enabled.

2. **Soft bounce limit**: 3 consecutive soft bounces in a 30-day window → suppress. Most ESPs let you configure this.

3. **Engagement-based segmentation**:
   - **Active**: opened or clicked any email in last 30 days
   - **Drowsy**: opened or clicked in last 31-90 days
   - **Dormant**: 91+ days no engagement
   - For weekly newsletters and marketing campaigns, send only to Active. Skip Dormant entirely.
   - For Drowsy: send a re-engagement campaign once per quarter; if still no engagement, move to Dormant.
   - For Dormant: never send marketing email. Send only transactional (those are triggered, not bulk).

4. **Unsubscribe handling**:
   - Every marketing email must have a one-click unsubscribe (List-Unsubscribe header in addition to footer link). Gmail/Yahoo enforce this for senders >5K/day since Feb 2024.
   - Suppress within 5 minutes of unsubscribe click (legal requirement in most jurisdictions; deliverability requirement everywhere).
   - Do NOT make unsubscribe require login.

5. **Spam complaint handling**: any feedback-loop (FBL) report from a mailbox provider → immediate suppress + flag for cohort analysis (which campaign generated the complaint?)

6. **Re-engagement campaign**: quarterly, send a "do you still want to hear from us?" email to Drowsy. Click yes → mark Active. No click → suppress.

Output:
1. The exact suppression rules as code in [your stack — likely SQL queries or ESP segment definitions]
2. The cron job that moves contacts between segments daily
3. The unsubscribe endpoint code that handles List-Unsubscribe POST in addition to standard one-click GET
4. The re-engagement campaign template + schedule

Then handle Apple Mail Privacy Protection: Apple Mail proxies opens, so the "open" event is unreliable for ~50% of audiences. Use clicks as the primary engagement signal; opens are secondary.

The big rule: never send marketing email to dormant addresses. Even if your platform gives you the technical ability to. Sending to dormant addresses raises bounce rates, lowers engagement rates, and suppresses your reputation. The "we paid for these names so we should mail them" instinct is the single most expensive deliverability mistake.

8. Build the Quarterly Deliverability Review

Set the cadence so the program doesn't decay silently.

Generate the quarterly deliverability review template I'll run every 90 days.

Sections:

**1. Authentication health** (5 minutes)
- SPF: still under 10 lookups? Run `dig TXT mail.your-domain.com +short` and count includes.
- DKIM: still publishing? `dig CNAME [selector]._domainkey.mail.your-domain.com +short`
- DMARC: still at `p=reject`? `dig TXT _dmarc.your-domain.com +short`
- Any DMARC report anomalies in the last 90 days?

**2. Reputation snapshot** (10 minutes)
- Google Postmaster Tools: Domain Reputation (target: High). IP Reputation (if dedicated IP).
- Microsoft SNDS: Filter Result percentages.
- Compare to last quarter — trending up, flat, or down?

**3. Inbox placement audit** (15 minutes)
- Run a seed-list test of each active mail type (welcome, password reset, weekly digest)
- Compare to last quarter's results
- Identify any template that dropped >5 inbox-rate points

**4. List health** (10 minutes)
- Bounce rate trend: should be <2%
- Spam complaint rate trend: should be <0.1%
- Active / Drowsy / Dormant ratios — what % of the list is engaged?
- Any segments that have spiked in unsubscribes? (Often a content problem.)

**5. New subdomain or sender review**
- Did we add any new sending domains this quarter? Are they warmed?
- Any new ESPs added? SPF still under 10 lookups?

**6. Action items**
- One specific deliverability fix to implement in the next 30 days
- Any escalation needed (e.g., contact ESP support about IP reputation issues)

Total time: 60 minutes per quarter. Calendar block it as a recurring meeting with myself.

Output the review as a markdown template I save to /docs/email-deliverability-review-Q[N]-[year].md and append findings to over time.

The single most valuable habit in deliverability is the quarterly check that nothing has rotted. Domains forget good behavior in 60-90 days; if you go quiet for two quarters, the warm-up gains evaporate. The 60-minute review prevents the slow drift to the spam folder.

What Done Looks Like

By end of week 2 of email deliverability work:

  1. Subdomain strategy implemented — transactional and lifecycle on separate subdomains
  2. SPF, DKIM, DMARC published and validated with dig for each subdomain
  3. DMARC at p=quarantine or p=reject with monitoring active
  4. Google Postmaster Tools + Microsoft SNDS signed up and verified
  5. Warm-up plan running for any new sending subdomain
  6. Inbox placement testing baseline captured for the 4 most-used templates

Within 90 days:

  • Inbox rate >95% on Gmail, >90% on Outlook
  • Spam complaint rate <0.1%
  • Bounce rate <2%
  • DMARC enforcement at p=reject
  • Quarterly review on the calendar

The compounding payoff: the activation step that depends on email (verification, magic link, password reset, welcome) hits inbox reliably. Activation rate ticks up 2-10% across the funnel. That's revenue you couldn't have otherwise.

Common Pitfalls

  • Sending from the apex domain. The single most consequential mistake. Once entangled, reputation is hard to disentangle.
  • DMARC at p=none permanently. Monitoring without enforcement leaves you spoofable and slowly erodes trust.
  • Skipping the warm-up. Sending 50K emails on day 1 from a new domain tanks reputation for months.
  • Not reading DMARC aggregate reports. The reports tell you which ESPs/services you forgot to authorize. Ignore them and you ship outages disguised as deliverability mysteries.
  • Treating "delivered" as success. Always pair with inbox-placement testing.
  • Ignoring Apple Mail Privacy Protection. Opens are inflated by Apple's proxy fetches. Use clicks for real engagement.
  • No List-Unsubscribe header. Mandatory for senders above 5K/day to Gmail/Yahoo. Without it, deliverability tanks fast.
  • Unsubscribe requires login. Illegal in CAN-SPAM and CASL; also mailbox-provider penalty. Make it one click.
  • Cold outreach from your transactional subdomain. The fastest way to nuke your password-reset deliverability.

Where Email Deliverability Plugs Into the Rest of the Stack

  • Onboarding Email Sequence — these emails fail silently if deliverability is broken
  • Reduce Churn — save sequences depend on inbox delivery
  • Customer Support — support replies must reach customers; subdomain hygiene matters here too
  • Incident Response — deliverability incidents (sudden inbox-rate drops) have their own playbook
  • Email Providers Comparison — choosing the right ESP for the layer you're sending
  • Resend — most popular indie SaaS ESP for transactional + lifecycle in 2026
  • AWS SES — cheapest at scale; more setup work
  • PostHog Setup — instrument email click events into the analytics layer
  • Activation Funnel — email is one of the top activation pathways; deliverability is a hidden funnel killer

What's Next

Deliverability is one of those infrastructure topics that compounds silently. The team that gets it right at week 2 of launch saves itself 6-12 months of activation drag. The team that ignores it spends the same year wondering why activation is below benchmark and chasing UX changes that don't fix the real leak.

Build the discipline now. Set the quarterly review on the calendar. Audit inbox placement before you scale up sending volume. The hour of work pays off in revenue you'd otherwise leave on the table forever.

⬅️ Growth Overview