Most SaaS teams discover email deliverability the same way: a customer says "I never got the password reset", someone checks, and the welcome emails have been landing in spam for a month.
The rules changed a lot in the last two years. Gmail and Yahoo introduced bulk sender requirements in February 2024, Microsoft followed for Outlook.com in May 2025, and all three have moved from "we'll route you to spam" toward rejecting mail outright. The good news is that the requirements are concrete. If you work through this list once, you avoid most of the problems.
Who the bulk sender rules apply to
The headline threshold is about 5,000 messages a day to one provider's consumer mailboxes (personal Gmail, Yahoo or Outlook.com/Hotmail addresses). Google has said that once you cross it, it treats you as a bulk sender from then on.
Plenty of early-stage SaaS products sit below that. Do the checklist anyway: providers apply the same signals to everyone, the thresholds only decide how strictly they enforce, and a product launch or a big newsletter send can push you over in a day.
1. Send from your own domain
Shared sending domains (the default @yourprovider-mail.com address on many tools) are fine for testing and nothing else. Your reputation gets mixed with everyone else's, and you can't pass DMARC alignment for a domain you don't control.
Use a subdomain for sending, for example mail.example.com or updates.example.com. That gives the sending stream its own reputation, and a mistake there won't damage the root domain your team uses for regular email.
2. SPF
SPF lists which servers may send mail for a domain. It's a TXT record on the domain used in the envelope sender (the Return-Path), which with most providers is a subdomain they ask you to set up.
example.com. TXT "v=spf1 include:_spf.google.com include:spf.yourprovider.com ~all" Common mistakes:
- More than 10 DNS lookups. Every
include:counts, and so do the includes inside it. Past 10 the result is apermerror, and to receivers that is the same as having no SPF. This is the most common SPF failure I see in practice. Remove tools you no longer use, or give each sending provider its own subdomain. - Two SPF records on one name. Only one
v=spf1TXT record is allowed. Merge them. - Using
+all. That authorizes the whole internet.
3. DKIM
DKIM signs each message with a private key. Receivers check the signature against the public key published in DNS. Your email provider generates the key pair and gives you one or more CNAME or TXT records:
s1._domainkey.example.com. CNAME s1.domainkey.yourprovider.com. Use 2048-bit keys where your provider supports them, and make sure every tool that sends as your domain signs with your domain: your transactional provider, your marketing tool, your helpdesk, your billing system's receipt emails. Tools you forgot about are the usual reason DMARC reports show failures.
4. DMARC, with alignment
DMARC ties SPF and DKIM to the domain the recipient actually sees in the From: header. A message passes DMARC when SPF or DKIM passes and the domain that passed matches (aligns with) the From domain.
Start with monitoring:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" p=none meets the Gmail, Yahoo and Outlook.com requirements. The rua address receives daily aggregate reports from receivers. They are XML, so point them at a free or cheap DMARC report viewer rather than reading them by hand.
Once the reports show that all your legitimate mail passes, move to p=quarantine and later p=reject. That's what actually protects your domain from spoofing. Don't jump straight to reject: you'll find out about the forgotten invoice tool when customers stop getting invoices.
Alignment is the part that trips people up. If your provider signs DKIM with d=yourprovider.com and the Return-Path is bounces.yourprovider.com, SPF and DKIM can both "pass" while DMARC fails, because neither domain matches example.com. Setting up a custom DKIM domain (step 3) fixes it.
Microsoft is the strictest here. Since May 5, 2025, Outlook.com rejects high-volume mail that fails these checks with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. If you see that bounce, check your three DNS records before you touch the email content.
5. Reverse DNS and TLS
If you use an email service provider, they handle this. If you run your own MTA (Postfix, Haraka, a cloud VM), every sending IP needs a PTR record that resolves to a hostname, and that hostname needs to resolve back to the same IP (forward-confirmed reverse DNS). Send over TLS. Gmail lists both as requirements for everyone, not only bulk senders.
6. One-click unsubscribe for marketing mail
Marketing and promotional messages need RFC 8058 one-click unsubscribe, meaning both headers:
List-Unsubscribe: <https://example.com/unsubscribe?token=abc123>, <mailto:unsubscribe@example.com?subject=abc123> List-Unsubscribe-Post: List-Unsubscribe=One-Click The https URL must accept a POST and unsubscribe the recipient immediately, with no login and no confirmation page. Gmail and Yahoo expect the opt-out to take effect within two days. Keep a visible unsubscribe link in the email body too.
Transactional email (password resets, receipts, security alerts) is exempt. That's one reason to keep the two streams separate (next item).
7. Separate transactional and marketing streams
Send password resets and newsletters from different subdomains, and ideally from different IP pools:
| Stream | Example From | Example sending domain |
|---|---|---|
| Transactional | no-reply@example.com or support@example.com | tx.example.com |
| Product and lifecycle marketing | hello@example.com | mail.example.com |
When a marketing campaign drives complaints up, the damage stays with that stream and password resets keep arriving. Most providers that do both let you configure separate sending domains per stream.
8. Keep the spam complaint rate low
This is the requirement you can't fix in DNS. Gmail's threshold is a 0.3% user-reported spam rate, and Google recommends staying below 0.1%. Above 0.3% you should expect throttling, then spam foldering, then rejections.
What keeps complaints down in a SaaS context:
- Only email people who expect it. Signup confirmations and onboarding are expected; a newsletter blast to every trial user from two years ago is not.
- Sunset inactive contacts. Stop marketing to people who haven't opened or clicked in 90 to 180 days (note that Apple Mail Privacy Protection inflates opens, so weigh clicks more heavily).
- Make unsubscribing easier than reporting spam. If unsubscribing is hard, people press the spam button instead.
- Remove hard bounces immediately, and suppress addresses that complained.
9. Monitor
Set these up once and check them weekly:
- Google Postmaster Tools: spam rate and compliance status for Gmail recipients. Verify your sending domain there; it's free.
- Microsoft SNDS: reputation data for your sending IPs at Outlook.com (relevant if you have dedicated IPs).
- DMARC aggregate reports: which sources send as your domain and whether they pass.
- Bounce codes in your provider's logs.
5.7.26from Gmail and5.7.515from Outlook mean authentication problems;4.7.xdeferrals usually mean you're being rate-limited.
10. Warm up new domains and IPs
A new sending domain or dedicated IP has no reputation. Don't send 50,000 emails from it on day one. Start with your most engaged recipients (recent signups, active users), increase volume over two to four weeks, and watch the complaint rate and deferrals as you go. If you're on a shared IP pool with a reputable provider, the domain still needs a gentler start, but the IP side is handled for you.
Quick checklist
- [ ] Sending from your own (sub)domain
- [ ] One SPF record, under 10 lookups
- [ ] DKIM signed with your domain, by every tool that sends as you
- [ ] DMARC published with
ruareporting, aligned, moving towardquarantine/reject - [ ] PTR and TLS (handled by your provider if you use one)
- [ ] RFC 8058 one-click unsubscribe on marketing mail
- [ ] Transactional and marketing on separate subdomains
- [ ] Spam rate under 0.1%, inactive contacts sunset
- [ ] Postmaster Tools and DMARC reports checked weekly
- [ ] Gradual warmup for new domains and IPs
If you want most of this handled for you, Sequenzy adds the one-click unsubscribe headers, gives you the exact DNS records to publish, and lets you send each stream from its own subdomain (how we recommend structuring them), but the checklist applies to whatever you send with.
