Improve Inbox Placement and Email Deliverability: Technical Aspects (Part 2) | Proofy

Part one of this deliverability series covered the technical foundations: real-time verification, double opt-in, DKIM, SPF, DMARC, DNS, PTR records, and Feedback Loops. Read or revisit part one on technical foundations if you need that baseline first. This second part covers the operational layer - IP allocation, TLS, MX hygiene, unsubscribe handling, and the day-to-day choices that compound into long-term sender reputation.

IP allocation and per-IP volume limits

Multiple IPs are useful when you have distinct mail streams that deserve separate reputations - transactional, marketing, lifecycle, re-engagement - but they are not a fix for poor deliverability. Mailbox providers track reputation by sending pattern, content, complaint rate, and engagement, not by IP alone. Rotating between IPs to escape a reputation problem usually makes things worse: receivers treat erratic IP usage as a signal of a hostile sender.

Per-IP volume matters. Each major receiver has limits on simultaneous connections from a single IP - Gmail caps around 100 connections per IP in practice, Outlook.com around 50, Yahoo similar. Push past those and you'll hit 4xx temporary failures or 5xx rejections. ESPs handle this throttling automatically; senders running their own MTAs need to read each provider's postmaster documentation and tune accordingly.

Retry temporary errors before giving up

Mail servers respond with one of three classes of code. 2xx means accepted, 5xx means permanent failure (do not retry), and 4xx means temporary - try again later. Common 4xx codes include 421 (service unavailable), 450 (mailbox temporarily unavailable), and 451 (local error). The correct response is to queue and retry with backoff: every 5-15 minutes initially, then every hour, up to 48-72 hours total. Configure your ESP or MTA's retry schedule explicitly; the defaults are often too aggressive (and look like spammer behaviour) or too passive (and lose legitimate mail).

One-click unsubscribe done properly

As of February 2024, Gmail and Yahoo require bulk senders to implement RFC 8058 one-click unsubscribe. That means a List-Unsubscribe header with an https POST URL that processes the unsubscribe in a single action - no login, no preference centre, no "are you sure?" interstitial. The visible unsubscribe link inside the message body should also work in one click. Hiding or complicating unsubscribe used to be a "save the subscriber" tactic; today it directly damages your sender reputation because frustrated subscribers click "spam" instead.

Outgoing TLS connections

All major receivers expect mail to arrive over TLS. Outlook.com and Gmail accept plaintext SMTP but flag it as a negative reputation signal; some receivers reject plaintext outright. Configure opportunistic TLS at minimum, and STARTTLS with valid certificates for any custom MTA you operate. Mail flow over TLS is also a prerequisite for MTA-STS, which the major receivers increasingly use to detect downgrade attacks.

Public WHOIS for your sending domain

Privacy proxies (WhoisGuard and similar) hide registrant details. That's fine for personal domains but a meaningful negative signal on a domain that sends bulk mail. Receivers' reputation systems look at WHOIS as one of several "is this sender accountable" data points. Use a transparent WHOIS record for the sending domain - registrar, organization, and accurate administrative contact - and reserve privacy protection for domains that don't send mail at scale.

Don't fragment volume across receivers artificially

Some senders try to "evade" filtering by sending the same campaign at different paces to Gmail vs. Outlook vs. Yahoo. This rarely helps and often hurts: receivers share blocklist data, and inconsistent sending patterns are treated as evasion. Send the same campaign on the same schedule across receivers, and let per-IP throttling handle volume management. If a single receiver is filtering you, fix the root cause rather than papering over it with creative pacing.

Dedicated vs. shared IPs

A dedicated IP only pays back when you have enough volume to keep it warm: roughly 100,000+ messages per month per IP, sent consistently. Below that threshold, a well-managed shared IP pool outperforms a quiet dedicated IP because mailbox providers have richer reputation data on busy IPs. For high-volume senders, dedicated IPs isolate you from neighbour-noise and let you build per-stream reputation. For lower-volume senders, a reputable ESP's shared pool is usually the better default.

Valid MX records for your domain

Even if you never receive mail at your sending domain, you need valid MX records - or at minimum a null MX (RFC 7505) - for the domain to pass receiver-side sanity checks. A sending domain with no MX, broken MX, or MX pointing at a non-existent host is a near-universal spam signal. Verify with a DNS lookup; "should be fine" isn't enough when reputation is on the line. For senders running their own validation infrastructure, the same accountability signals apply to your verification endpoints - see the documentation for the Proofy email validation API for an example of how to expose a verification service the way receivers expect.

Common Mistakes

• Treating IP rotation as a deliverability fix instead of the symptom-masking it actually is.
• Setting overly long retry windows (7+ days) for 4xx errors, which queues stale mail that is no longer welcome.
• Implementing a "preference centre" instead of true one-click unsubscribe, which now violates Gmail and Yahoo bulk-sender requirements.
• Hiding behind WHOIS privacy on a sending domain.
• Forgetting to monitor TLS certificate expiry - a one-day cert lapse can drop you into spam at receivers that require encryption.

FAQ

How long should the IP warm-up window be?

Four to eight weeks for a new dedicated IP, depending on target volume. Start with a few hundred sends per day to your most engaged subscribers, then double daily volume every 2-3 days. Watch open rates, complaint rates, and bounces at each step. If complaints spike, hold volume flat for a week before resuming the ramp.

What's the right retry strategy for 4xx errors?

A common schedule is to retry every 5 minutes for the first 30 minutes, every 15 minutes for the next 2 hours, every hour for the next 24 hours, then every 4 hours up to 48-72 hours total. After that, treat as permanent failure and drop the address.

Will switching to a transparent WHOIS record really affect deliverability?

It is one input among many, not a deciding factor. But on a borderline reputation it can tip the score. Receivers' systems use accountability signals as tiebreakers, and a hidden WHOIS reads as "sender doesn't want to be found." If you send commercial mail, the trade-off favours transparency.

Do I really need MX records on a send-only domain?

Yes. Either point MX at a mailbox you actually monitor (the legally-required reply path under CAN-SPAM and GDPR), or publish a null MX record per RFC 7505 to declare "this domain does not accept mail." Both are valid; "no MX at all" is not.

Conclusion

Operational discipline is what keeps a technically-correct sender out of the spam folder over the long run. The technical fundamentals from part one stop the obvious failures; the practices here prevent the slow reputational drift that eventually pushes good senders into Promotions or spam. Close the loop by reading the dedicated spam-prevention guide, and check the related deep-dive on why sender reputation matters. Before your next major broadcast, audit your list quality with a free email checker run - most reputation problems start with addresses that should never have been on the list in the first place.