Deliverability & sending infrastructure

Delivered does not mean inboxed. A campaign can report 98% delivery and land 40% in the inbox, and the dashboard will not tell you the difference, because “delivered” only means the receiving server accepted the message before its filters decided where to file it. In Q4 2025, cold email placed in the Gmail inbox about 57% of the time, Outlook 45%, Yahoo 57%. Almost half your Outlook sends never reach a human even when nothing bounced. Every reply-rate number you have ever benchmarked was computed on top of that invisible tax.

Every sender who runs cold volume gets flagged eventually, so the entire architecture exists for one reason: to keep the damage contained to a domain you can throw away. That is why nobody serious sends cold from their primary domain. One reputation hit there and your CEO’s real email starts landing in spam, and no amount of warmup buys that back fast.

Authentication is the entry fee

Since Google and Yahoo’s February 2024 rules and Microsoft’s in May 2025, three DNS records decide whether you are read at all. SPF lists which servers may send for your domain. DKIM signs the mail with a key (use 1024-bit or better) so the recipient can verify it was not tampered with in transit. DMARC tells receivers what to do when the first two fail and where to send the aggregate reports. All three must align, meaning the visible From domain has to match what SPF and DKIM authenticated. Start DMARC at p=none to collect reports without blocking anything, then tighten to p=quarantine once your legitimate mail passes cleanly. Add one-click unsubscribe (RFC 8058) and honor it inside two days. Microsoft rejects with a bare 550 5.7.515 and publishes no numeric threshold, so you learn your standing by watching Postmaster data, not by reading a rulebook.

Here is what the records look like in your DNS zone. This is the artifact, not a description of one:

; SPF: authorize your sending platform, hard-fail the rest
example-outbound.com.  TXT  "v=spf1 include:_spf.smartlead.ai -all"

; DKIM: public key the platform signs against (1024-bit minimum)
sl1._domainkey.example-outbound.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

; DMARC: start at none to collect, then move to quarantine
_dmarc.example-outbound.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"

The adkim=s and aspf=s flags force strict alignment. Loose alignment is where a lot of “but I set up DKIM” senders quietly fail: the record exists but is not aligned to the From domain, so the receiver treats it as unauthenticated anyway.

The number that governs everything: 0.30%

Spam complaints are the hard ceiling on your entire program. Google and Yahoo set 0.30% as the line you must never reach and 0.10% as the target you operate under. That single number caps how much you can send, which is why deliverability is a volume constraint and not a growth lever: past a complaint rate, sending more mail does not produce more pipeline, it produces a blocked domain. Bounce rate sits under 2% for a healthy list. Watch opens too, though loosely, because under 15% is an early tell that the list or the copy is wrong before the filters agree with you.

Monitor thresholdsQ4 25 inbox placement

View as table

Stage	Value
Complaint target	0.1%
Complaint hard cap	0.3%
Bounce ceiling	2%
Open-rate floor	15%

The domain and inbox math

Cold outreach runs on secondary domains, lookalikes of your primary at $10 to $15 a year each, so a flag never touches the real one. Then you cap sends per inbox, because one inbox firing hundreds of cold emails a day looks exactly like what it is. Plan on 30 to 50 sends per warmed inbox per day; deliverability specialists run 15 to 25 to stay conservative. The aggressive 100-to-150 numbers vendors quote are how you get flagged, not a target. Run two to three mailboxes per domain. The whole point is to spread 500 sends across 25 inboxes, not to jam them through five.

The capacity math is a single formula, and it drives how many domains you register before you send anything:

The numbers behind that diagram, laid out so you can size any target:

Daily cold target	Sends/inbox/day	Inboxes needed	Domains (~3 mailboxes each)
250	40	7	3
500	40	13	5
1,000	40	25	9
2,000	40	50	17
1,000 (conservative)	25	40	14

The build, once, then monitored forever

Deliverability is not a project you finish. It is infrastructure you stand up and then watch on a daily gauge, because reputation degrades gradually and the only warning you get is the one you go looking for. This is the order I build it, and every step has to hold before the next matters.

1. 1

   1. Register secondary sending domains

   Lookalikes of your primary at $10 to $15 a year. Point DNS at your sending platform and age them two to four weeks before any cold send. Never the primary domain, ever.

2. 2

   2. Configure SPF, DKIM, DMARC with strict alignment

   On every sending domain. Verify alignment (adkim=s, aspf=s), not merely record presence. Start DMARC at p=none, tighten to p=quarantine once clean.

3. 3

   3. Create two to three mailboxes per domain

   Real names, real profile photos, a filled-out signature. An empty mailbox that only sends cold is a tell.

4. 4

   4. Warm up two to four weeks

   Ramp volume no faster than 20% a week while the tool simulates opens and replies. Warmth before load, not after.

5. 5

   5. Verify every list before it sends

   Validate and suppress catch-alls; MillionVerifier runs about $0.002 to $0.01 an email. SMTP cannot validate a catch-all, so verification and suppression are separate jobs.

6. 6

   6. Send capped and rotated

   Spread across the day and across the inbox pool. A burst from one inbox reads as a blast no matter how good the copy is.

7. 7

   7. Watch Postmaster daily

   Google Postmaster Tools is free. Rotate an inbox out at bounce over 3%, complaints over 0.08%, or opens under 15%, before the domain reputation drops.

Warmup is one pillar, not the answer

Warmup earns its two-to-four weeks, and it is also oversold. WarmupInbox studied 4,406 inboxes and found domain age barely correlated with inbox placement (r of about -0.096). A fresh 6-to-12-month domain placed about as well as a 10-year-old one. Worse, a small warmup pool creates a detectable pattern: a tight cluster of accounts emailing each other on a schedule looks like coordinated sending, which is the exact thing you are trying not to look like. Warmup keeps a fresh inbox from face-planting on its first real campaign. It does not rescue bad copy, a dirty list, or an aggressive ramp. Treat it as one pillar in the architecture, not the load-bearing one.

	Primary domain	Dedicated cold pool
What it sends	Warm, transactional, replies	Cold outbound only
If it gets flagged	Whole company email suffers	Burn the domain, spin up another
Volume per inbox	Normal human use	Capped at 30 to 50/day
Reputation shared with	Every employee	Only other cold inboxes you control
Lifespan	Permanent	12 to 18 months high-engagement, ~5 months low

Where deliverability sits in the stack

Deliverability is the binding volume constraint on everything upstream of it, which is why it belongs in the sending layer and not bolted onto whichever tool sends the mail. The flow is one-directional: a clean list feeds authenticated domains, which feed warmed inboxes, which feed the daily cap, which feeds the reputation gauge that governs the whole thing.

Verified list

Authenticated secondary domains

Warmed inboxes (2-3/domain)

Daily cap 30-50/inbox

Postmaster gauge (0.30% ceiling)

None of this matters if the copy is a slop cannon. Deliverability buys you the inbox; it does not buy you a reply. The same signal-first discipline that governs what you send is in signal-based outbound, and the front of the pipe (matching and scoring who is even worth a send) is in scoring and routing.

If you have never checked Google Postmaster Tools for your sending domains, do that before you send another campaign. You cannot manage a 0.30% ceiling you are not watching, and the day you start watching is the day the whole architecture stops being guesswork.