From 78% to 99.5% Inbox Placement. One SaaS Team's Email Fix.

The Password Resets That Never Arrived

A B2B SaaS platform -- let us call them InvoiceStack -- sends roughly 2 million transactional emails per month. The following is a composite scenario illustrating common deliverability patterns, not a specific customer engagement. Invoices, payment receipts, password resets, account notifications, and onboarding sequences. The kind of emails that customers need to receive.

InvoiceStack's support team noticed a pattern. Customers were opening tickets saying they never received password reset emails. At first, it seemed like a trickle -- maybe 10 tickets a month. Then it was 50. Then 200.

Their previous email provider's dashboard showed a 97% delivery rate. Looks great on paper. But "delivered" means the receiving server accepted the email. It does not mean the email reached the inbox.

When inbox placement tests were run across Gmail, Outlook, Yahoo, and corporate mail servers, the real number was 78%. Nearly one in four emails was landing in spam or being silently dropped.

For a B2B platform sending invoices and payment notifications, that is a business-critical problem.

Root Cause Analysis

A root cause analysis of InvoiceStack's email infrastructure revealed three compounding issues.

Issue 1: Shared IP Reputation

InvoiceStack was on their previous provider's shared IP pool. This means their sending reputation was tied to every other customer on the same IPs. If one customer on the pool sends spammy marketing emails, everyone's deliverability suffers.

Checking the reputation of the IPs InvoiceStack was sending from revealed the extent of the problem. Two of the four IPs had been listed on Spamhaus' PBL (Policy Block List) in the past 90 days. Not because of InvoiceStack's behavior, but because of other senders on the same pool.

The IP reputation score on Google Postmaster Tools was "Low" for two IPs and "Medium" for the other two. For transactional email that needs near-100% delivery, you need "High."

Issue 2: Missing DKIM Alignment

InvoiceStack had SPF configured correctly. They had a DKIM signature. But the DKIM signature's d= domain did not align with the From: header domain.

Their emails were sent from notifications@invoicestack.com, but the DKIM signature used their previous provider's domain. This meant DMARC alignment failed for DKIM. SPF aligned because they had the provider's include in their SPF record, but relying on SPF alone is fragile -- any email forwarding breaks SPF.

# What their headers looked like
From: notifications@invoicestack.com
DKIM-Signature: d=emailprovider.com  <-- MISALIGNED
Return-Path: bounce-123@emailprovider.com

# DMARC check:
SPF: PASS (aligned via include)
DKIM: PASS (but NOT aligned - different domain)
DMARC: PASS (via SPF only)

This configuration technically passes DMARC, but it is the weakest possible pass. Many mail servers give lower trust scores to emails that only align on SPF. And the moment an email gets forwarded (common in B2B where assistants forward to executives), SPF breaks and there is no aligned DKIM to fall back on.

Issue 3: No Feedback Loop Handling

InvoiceStack was not processing feedback loop (FBL) reports from mailbox providers. When a recipient marks an email as spam, the mailbox provider sends an FBL report to the sender. If the sender ignores these reports and keeps sending to recipients who marked them as spam, their reputation degrades.

InvoiceStack had 340 unprocessed spam complaints over the past 60 days. They were still sending emails to every one of those addresses. Each send reinforced the spam signal.

The Fix

InvoiceStack migrated to Transactional's email infrastructure over a 6-week period. Here is exactly what the process looked like.

Week 1-2: Dedicated IP and Warming

InvoiceStack was assigned a dedicated IP address. No shared reputation. Their sending behavior and theirs alone determines their reputation.

But a brand new IP has no reputation at all, which is just as bad as a negative reputation. Mailbox providers are suspicious of IPs they have never seen before. The IP needed to be warmed gradually.

The warming schedule:

During warming, we prioritized sending to engaged recipients -- users who had opened or clicked an email in the last 30 days. This ensures the early sends generate positive engagement signals, building reputation from the start.

Monitoring Google Postmaster Tools daily showed steady progress. By day 10, the new IP was showing "Medium" reputation. By day 22, it hit "High."

Week 1: Authentication Fix

Proper DKIM was configured with InvoiceStack's domain:

# DNS records added
invoicestack.com TXT "v=spf1 include:spf.transactional.so -all"

tx1._domainkey.invoicestack.com CNAME tx1.dkim.transactional.so
tx2._domainkey.invoicestack.com CNAME tx2.dkim.transactional.so

_dmarc.invoicestack.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@invoicestack.com"

Now the email headers look correct:

From: notifications@invoicestack.com
DKIM-Signature: d=invoicestack.com  <-- ALIGNED
Return-Path: bounce-abc@invoicestack.com

# DMARC check:
SPF: PASS (aligned)
DKIM: PASS (aligned)
DMARC: PASS (via both SPF and DKIM)

A custom Return-Path domain was also configured so even the bounce address aligns with their brand.

Week 2: Feedback Loop Processing

Automated FBL processing was set up. When a recipient marks an InvoiceStack email as spam:

1. The FBL report is received and parsed automatically
2. The recipient is added to a suppression list
3. All future sends to that address are blocked
4. The event is logged in InvoiceStack's dashboard

The 340 existing complainants were also imported into the suppression list immediately. No more sending to people who do not want to hear from you.

Week 3-4: Content Optimization

With the infrastructure fixed, attention turned to the email content itself. A few patterns were triggering spam filters:

• Image-to-text ratio: Some invoice emails were mostly images with very little text. Spam filters are suspicious of image-heavy emails.
• Missing unsubscribe headers: Even transactional emails benefit from the List-Unsubscribe header. Gmail and Apple Mail use it to offer a visible unsubscribe option, and its presence is a positive signal to spam filters.
• Inconsistent From names: InvoiceStack used different From names for different email types ("InvoiceStack", "InvoiceStack Notifications", "InvoiceStack Billing"). Inconsistency is a spam signal.

The From name was standardized, List-Unsubscribe headers were added, and every email was ensured to have a healthy text-to-image ratio.

Week 5-6: Monitoring and Fine-Tuning

With the infrastructure changes in place and the IP fully warmed, inbox placement was monitored daily across all major providers.

By week 5, inbox placement was consistently above 98%. Two final adjustments were made:

• Reduced sending rate to Yahoo/AOL during their peak hours (they are more aggressive about throttling)
• Added a dedicated bounce processing pipeline that categorizes bounces and suppresses hard bounces within minutes

By the end of week 6, inbox placement stabilized at 99.5%.

The Results

Measured over a 30-day period at the same sending volume:

The password reset support tickets dropped by 96%. That alone saved InvoiceStack roughly 50 hours of support time per month.

What InvoiceStack Learned

The key lesson from InvoiceStack's experience is captured in this common realization: "We thought email deliverability was a solved problem. We had SPF and DKIM set up. Our provider said delivery rate was 97%. We had no idea that 97% delivered and 78% inbox placement could coexist."

That gap between "delivered" and "in the inbox" is where transactional emails go to die. The receiving server accepts the email, so the provider counts it as delivered. Then the spam filter puts it in junk. The sender never knows.

The fix is not complicated. Dedicated IP. Proper authentication. Feedback loop processing. Content hygiene. These are not cutting-edge techniques. They are table stakes that most email providers do not set up correctly by default because they optimize for ease of onboarding, not deliverability.

The Takeaway

If you are sending transactional emails -- password resets, invoices, order confirmations, anything your users need to receive -- your delivery rate is not your inbox placement rate. Check your actual inbox placement. If it is below 99%, you are losing emails that matter.

Start with authentication. Check DKIM alignment specifically, not just SPF. Set up a dedicated IP if you send more than 100K emails per month. Process your feedback loops. Monitor inbox placement, not just delivery rate.

Explore Transactional Email to see how we handle all of this out of the box.