How should B2B SaaS split its email workloads?
A typical B2B SaaS sender has three distinct email workloads: (1) transactional — login codes, password resets, account-action confirmations, billing notifications; (2) lifecycle — onboarding sequences, weekly digests, feature-update alerts; (3) product event notifications — someone shared a document with you, your build failed, your invoice is past due. Each has different latency requirements, different volume profiles, different reputation considerations. The customers who treat them as one workload end up with mediocre delivery across all three. The customers who treat them as three separate workloads (separate IP pools, separate stats, separate webhooks) get top-quartile inbox placement on each.
Why is B2B SaaS the largest customer segment we serve?
A large share of our customers are B2B SaaS — companies selling software to other businesses, with email as a core product surface. The reason it concentrates here is the cost-benefit math: at the volumes typical for a growing B2B SaaS (500K-10M messages/month), per-message pricing from SendGrid Pro or Mailgun adds up faster than a managed dedicated infrastructure plan. The reputation problem also concentrates here: B2B inboxes (corporate Microsoft 365 and Google Workspace) are stricter than consumer inboxes, so the deliverability work has to be done more carefully.
Which integration patterns has OS Domains tested?
Most SaaS B2B customers integrate via REST API rather than SMTP, with webhook receivers that feed back into their product (mark a notification as "delivered" in the in-app UI, retry failed sends with different content). We have validated integrations with the Node.js, Python, Go, Ruby, PHP, and Java SDKs as well as direct API access from any language. Common application frameworks integrated: Rails, Django/FastAPI, Express, NestJS, Spring Boot, Laravel. Webhook delivery is signed with HMAC-SHA256 and includes a 7-day replay buffer so a brief outage of the receiving service does not lose events.
Why is Microsoft the hardest part of B2B deliverability?
Roughly 61% of B2B recipients read mail in a Microsoft client — Outlook, Exchange Online, Microsoft 365 — against about 35% on Google, per Validity's 2025 measurement. That single fact reshapes the deliverability work. Microsoft filters harder than Gmail and filters inconsistently, because every M365 tenant layers its own policy on top of Exchange Online Protection: Mimecast, Proofpoint, Barracuda, or a custom Microsoft Defender ruleset. The same message from the same green-SNDS IP can inbox at Gmail, sit in "Other" on consumer Outlook.com, and land in tenant quarantine at one of your customer's subsidiaries. Microsoft started rejecting non-compliant high-volume mail outright in May 2025 — a hard 550 5.7.515 instead of a silent junking — so a misaligned SPF or a missing DKIM signature shows up as a bounce now, not a slow reputation tax. We monitor placement per major-tenant configuration with seed accounts that mimic the common enterprise Defender setups, tune content against the SmartScreen patterns that trip M365 quarantine, and keep a documented escalation for the case every B2B sender eventually hits: one high-value recipient tenant quarantining your transactional mail while every other receiver inboxes it.
How does OS Domains compare with Postmark, Resend, SendGrid and SES?
We lose deals to four providers, and we will tell you when one of them is the better answer. Resend has the cleanest developer experience in the category right now — React Email templates, a TypeScript SDK that matches the API exactly, a permanent 3,000-message free tier — and for an early-stage product that only needs transactional, it is hard to beat. It is also a deliberately thin layer: no SMTP relay, no inbound parsing, no subscriber management. You grow out of its scope rather than its quality. Postmark built its name on transactional reliability through Message Streams, which keep transactional and broadcast traffic on separate infrastructure so a marketing blast never delays a password reset; below about two million messages a month with no lifecycle or product-event traffic to consolidate, we point people there and do not try to win the deal. SendGrid covers the whole spectrum and prices the highest volumes the lowest, with subusers for multi-tenant separation, though the deliverability hand-holding thins as you move down its support tiers. Amazon SES is the cheapest path at scale at roughly ten cents per thousand, and you operate everything yourself. We are the managed dedicated option for the 500K-to-10M band: where per-message pricing crosses over a flat infrastructure plan, where the corporate-inbox work needs a human who knows what a tenant-level Proofpoint policy does, and where EU data residency is a procurement requirement rather than a preference.
Multi-tenant sending puts the noisy-neighbor problem on your reputation.
If your product sends on behalf of your own customers, the reputation consequences of their behavior land on your domains and IPs. The mailbox providers moved to a domain-first, user-centric reputation model across 2024 and 2025, which means a single tenant with a dirty list or a high complaint rate drags down placement for every other tenant sharing the pool. The fix is governance you have to run, and tooling that makes it possible. We support a bring-your-own-domain model where each tenant authenticates under its own domain with its own DKIM key and return-path, so reputation accrues per tenant instead of pooling into one shared liability. Tenant tiering is common among our larger SaaS accounts: paying tenants on a premium pool, free-tier tenants on a separate one, so a free-tier abuse spike cannot tax the customers who pay you. Per-tenant tagging through the X-OSD-Tenant-ID header feeds a stats API that answers group_by=tenant_id queries — per-tenant inbox placement, complaint rate, bounce rate — which is what lets you find the one tenant generating complaints before the receivers find it for you. When you do, the portal lets you throttle or quarantine that tenant's sending without touching anyone else's.
Microsoft tenant rate limits are a design constraint, not a footnote.
Exchange Online enforces limits that bite the moment your customers relay their own mail through Microsoft 365, or you send into M365 tenants at volume. The Tenant External Recipient Rate Limit caps a whole tenant at 5,000 external recipients per day — per tenant, not per mailbox — so five of your customer's sales reps each sending a thousand external messages exhaust it for everyone in that company. A separate 10,000 daily recipient ceiling counts internal and external together, and a 30-messages-per-minute cap governs automated bursts independently of the daily number. There is a quieter trap for customers who route outbound through a third party for signature management or archiving and then back into Exchange Online for final delivery: Microsoft can double-count those external recipients, and the documented mitigation is a mail-flow rule keyed on the References header. We design pool throughput and per-tenant throttles around these numbers, so a product event that fans out to a few thousand recipients inside one customer's tenant gets paced under the cap instead of tripping it and stalling the rest of that tenant's mail for the day.
Three workloads, three latency budgets, three reputations.
The split between transactional, lifecycle, and product-event mail is not an organizational nicety; the three have incompatible operating characteristics. Transactional mail — login codes, password resets, payment confirmations — needs sub-second queue-to-send and a p99 measured in single-digit seconds, and it cannot share an IP with anything that sends in bulk, because one marketing complaint spike must never delay an authentication code. Lifecycle mail — onboarding sequences, weekly digests, feature announcements — is batched and tolerant of minutes of latency, but it carries the complaint risk, so it earns its own pool where a bad send degrades only itself. Product-event mail is the spiky one: a build finished, a document was shared, an invoice went past due, fanned out as up to roughly fifty million webhook-driven events a day across our B2B base, with bursts that track your customers' working hours rather than yours. Provisioning gives each of the three its own isolated, independently warmed pool with its own stats dashboard from day one. The accounts that collapse all three onto one pool to save a day of setup get middling placement on every type at once, and the conversation that follows is usually a migration to fix what correct provisioning would have prevented.
We are the email sending layer, not a notification orchestration platform.
Multi-channel orchestrators — Courier, Knock, the open-source Novu — sit above providers like us and route a single notification across email, SMS, push, and in-app, handle templating and preference centers, and fail over between channels. For a product that needs that, we name them rather than pretend the API does it. Several of our customers run exactly that topology: Knock or a self-hosted Novu on top, us as the email provider underneath, chosen for EU residency and dedicated-pool economics. The line is clean in procurement. A notification preference center, cross-channel digesting, and channel batching are orchestration concerns, and we integrate beneath them. Email that reaches a corporate Microsoft inbox at two million a month and up, under EU data residency, with the per-tenant data to prove placement, is the part we own. Mechanically the integration is unremarkable, which is the point: the orchestrator calls our send endpoint with the rendered message and a tenant tag, we return a message ID, and our webhooks feed delivery state back so the orchestrator can decide whether to escalate to another channel. Being underneath an orchestration layer changes none of the pool architecture, the per-tenant reputation accounting, or the EU residency guarantees — those hold whether the call originates from your application directly or from a Knock workflow three hops upstream. Keeping that scope is deliberate: a self-hosted Novu plus our API leaves both the notification logic and the email data on infrastructure you control, which is the configuration a privacy-sensitive buyer tends to land on.