Spin up a mail server Friday. Send 10,000 messages to the internet by Saturday morning. By Sunday, every mailbox provider on Earth is convinced you're a botnet. Your email lands in spam. Your IP gets blocklisted. Your team gets paged. Sunday is ruined.
We did this. This is a real thing that happened.
Why New IPs Are Radioactive
Gmail doesn't know who 203.0.113.42is. Microsoft doesn't know. Yahoo doesn't know. To them, this IP appeared from nowhere, started cranking out mail at volume, and shows zero pattern history.
A brand new server hammering mail looks identical to a compromised host to these systems. They don't care about your DKIM or SPF signatures (yet). They see:
- IP we've never encountered before
- Sending thousands of messages right now
- No long-term behavior pattern
- = High probability this is stolen infrastructure
Gmail's response: rate limit this IP. Throttle it to nothing.
Microsoft's response: rate limit this IP. Throttle it to nothing.
Every provider independently decides: this looks bad.
Your mail gets queued. You think it's slow network. You push harder. You send more. Systems see more volume from an unknown IP. They add it to blocklists.
By Monday, you're offline. No recovery plan in the documentation because nobody expects this to happen on day one.
The Actual Fix: Slow Is The Only Speed That Works
You can't fix this with better code. You can't fix it with authentication. You can't buy your way out.
What works: IP warmup schedule. You ramp volume slowly.
Days 1-2: 50 messages/IP/day
Days 3-4: 100 messages/IP/day
Days 5-6: 200 messages/IP/day
Days 7-8: 400 messages/IP/day
Week 2: ~ 1,000/day (if clean)
Week 3: ~ 5,000/day (if clean)
By week 4, assuming zero bounces and zero complaints, you're at production volume.
Why slow? Receivers use volume ramp as a signal. They have two patterns:
*Pattern 1 *(Botnet): Appear → flood → disappear
*Pattern 2 *(Real service): Appear → gradual increase → stay consistent
If you ramp, they believe you. If you spike, they block you.
The hard truth: you can't compress this timeline. Reputation doesn't come from having a good domain. It doesn't come from SPF/DKIM (those are table stakes). It comes from time + clean delivery metrics + showing up regularly at increasing volume.
There's no shortcut. No API to unlock it faster. Every mail provider on Earth does this the same way.
The Real Workaround: Pool Architecture (Not a Hack, a Necessity)
One IP + one warmup schedule = you're capped forever.
The only way to scale: multiple IPs, each warming independently, each tracked separately by each provider.
Gmail looks at 203.0.113.40 → sees 50/day → reputation: building
Microsoft looks at 203.0.113.41 → sees 50/day → reputation: building
Yahoo looks at 203.0.113.42 → sees 50/day → reputation: building
Each provider has its own opinion. Gmail's view of IP #1 has zero connection to Microsoft's view of the same IP.
This matters because: Gmail rate-limiting .40 doesn't slow your Outlook delivery. Without separate pools, the moment Gmail throttles you, everyone else suffers the same slowdown. Your "global cooldown" becomes a global ceiling on throughput.
With separate pools, warmup parallelizes. Four IPs on identical schedules = four times the volume, without breaking the ramp for any single provider.
The Real Problem: Shared Sending Domains Tank Everyone
If we sent all user mail from one domain (mail.atomicmail.com), one bad actor destroys everyone's delivery.
User A sends 100 legitimate messages → +0.01 reputation
User B sends spam → -0.5 reputation
User A wakes up and their real mail is in spam folders
= lawsuit territory
We could spin up per-user domains and IPs (insane cost). Or: enforce reputation at the application layer before anything touches SMTP.
Reputation gets scored before the mail leaves the system. Score below 0.25? Your mail doesn't get queued to send. Gets suspended immediately.
Here's the scoring math:
One spam complaint from a user → multiply by 0.65
(force-account suspend)
One bounce (permanent, bad address) → multiply by 0.5
One SMTP rejection → multiply by 0.9
100 successful deliveries in one day → add 0.01 (capped at +1%)
Translation: it takes months to build reputation (slow additive gain). One complaint from a user who marked you as spam: instant account shutdown.
This asymmetry is intentional. It makes spam economically stupid. The cost of farming a clean reputation is real time + clean metrics. The penalty for blowing it is total account loss.
Gotchas That Actually Bit Us
When All IPs Are Rate-Limited at Once
It happens. All four IPs hit Gmail's limit. All four hit Outlook's limit. Everything throttles to zero.
Do you:
- Queue forever (users wait, some mails timeout)
- Blow through the limit anyway (break the warmup schedule, probably go back to square one with reputation)
We picked: override the limit, send it, log what happened.
The logic is: silently dropping mail is worse than slightly violating a warmup schedule. But you log everything, so you know when you're about to hit capacity.
Reverse DNS Checkpoint (The Gate Nobody Mentions)
Before Gmail/Outlook even consider your DKIM or SPF: they check reverse DNS.
dig -x 203.0.113.40
# Returns: mail-out-001.atomicmail.com
dig mail-out-001.atomicmail.com
# Returns: 203.0.113.40
# Match? ✅ Continue
# No match? ❌ 550 rejection at connection time
This is FCrDNS (Forward-Confirmed Reverse DNS). Fails this check, and the receiver rejects your connection before checking a single signature.
A generic AWS rDNS like mail-out-5.ec2.compute.internal? Dead. Receivers see it, reject at connection, never even run DKIM validation.
Each of our outbound IPs gets a dedicated hostname:
203.0.113.40 → mail-out-001.atomicmail.com
203.0.113.41 → mail-out-002.atomicmail.com
203.0.113.42 → mail-out-003.atomicmail.com
Each one HELOs with its own hostname. Each PTR record points back to itself.
SPF Leaks Your Pool
If your SPF rule lists every IP:
v=spf1 ip4:203.0.113.40 ip4:203.0.113.41 ip4:203.0.113.42 ... -all
Spammers read your SPF. They see your entire IP pool. They know which ones exist. They can probe a half-warm IP and spam from it.
Better practice: minimal SPF (primary IPs only). Use include directives for subdomains if you need to publish secondary pools. Hide the full roster.
The Cost vs. Payoff
What you pay:
- 4-10 dedicated IPs: $20-200/month
- Dedicated reverse DNS: comes with the IPs
- Human time: 3-6 weeks of warmup (not full-speed sending)
What you get:
- 95%+ inbox delivery (vs. 50-70% from cold IPs dumped at volume)
- No angry calls from abuse teams
- Ability to scale without getting blocklisted
One Thing We Got Wrong (And Fixed)
We tried a universal proof-of-work difficulty on signup. One difficulty value for everyone.
Too easy for people with money to farm accounts. Too hard for users on old phones trying to sign up legitimately.
Fixed it: reputation-scaled difficulty. Clean IP signing up? Difficulty 4. Known bad IP? Difficulty 8. This is a separate problem, but the point is the same: there's no one-size-fits-all number.
Same with warmup. There's no cheat code. It's time + monitoring + discipline. You can't negotiate with Gmail's algorithms.
