Sending Infrastructure Practices

This article complements the IP management articles with the infrastructure guidance ESP guides (Postmark, AWS SES, Twilio SendGrid) add: the dedicated-vs-shared decision, domain (as distinct from IP) reputation and warm-up, feedback-loop wiring, and monitoring.

Dedicated vs. shared IPs

The IP allocation articles size dedicated-IP fleets; the prior question is whether to use a dedicated IP at all.

Aspect	Dedicated IP	Shared IP
Other senders' impact	None — reputation is entirely yours	Pool mates can boost or damage your standing
Volume requirement	High, sustained volume mandatory	Any volume
Warm-up	Required — weeks to months	None; send immediately
Cost	Premium	Lower
Reputation management	Yours to manage	Provider-managed
Error forgiveness	Low — every mistake lands on your reputation	Higher — errors absorbed by pool volume

Dedicated-IP volume floors (canonical)

"How much volume justifies a dedicated IP?" has no single answer because the published numbers measure different things. The floors and vendor minimums below span roughly 5–10x, but they are not contradictory — they answer different questions. This is the canonical reconciliation for the KB; the other articles cite this table rather than restating a floor.

Floor	Number	What it measures
Transactional-isolation floor	~1,000 messages/day	The low-end volume at which isolating transactional mail onto its own dedicated IP stays legible to receivers (GreenArrow, Advanced IP Segmentation). Transactional mail is isolated for its high relevance even below the general statistical floor.
General per-IP statistical-legibility floor	40,000 messages/week (~5,700/day)	The minimum sustained volume any IP needs for mailbox providers to gather statistically significant engagement/complaint data (GreenArrow, Basic IP Allocation). Below this, an IP is not sending enough for its reputation to stabilize.

Vendor dedicated-IP thresholds (house-rules). ESPs publish their own minimums, which reflect each vendor's product tiers and support economics as much as receiver statistics. They sit above or below the two floors depending on the vendor's model, and are not mutually contradictory:

Vendor	Threshold	Framing
AWS SES	"a few hundred per day" to allocate the first dedicated IP; below that, steered to shared IPs	Lowest bar — SES auto-demotes low-volume dedicated IPs back to the shared pool (see Multi-Tenant Architecture)
Twilio SendGrid	~50,000/month (~1,650/day) recommended	Below this, a well-managed shared pool is advised
Mailgun	≥ 100,000/month (~3,300/day) recommended	See Reputation Incident Recovery
Postmark	~300,000/month (~10,000/day) to properly maintain a dedicated IP	Highest bar

Reconciliation: a dedicated transactional IP can be justified at ~1,000/day, but any IP carrying a general/bulk stream wants ~40,000/week before its reputation is statistically legible; the vendor minimums are commercial house-rules layered on top of both.

Caveats from Postmark: a dedicated IP is not a silver bullet — for senders below the volume bar it can hurt deliverability, and "a dedicated IP is a way for ESPs to lower their support overhead" as much as a delivery feature. Dedicated IPs also demand consistent, predictable volume; sudden spikes are flagged as suspicious. Modern filtering weights domain reputation increasingly heavily relative to IP reputation.

Domain reputation and subdomain strategy

Domain reputation is the opinion receivers (mailbox providers and anti-spam services) hold of your domain. Unlike IP reputation, it is portable: it follows the domain across sending systems and providers, so a domain with a spam history carries that history to any new infrastructure — and poor domain reputation can drag down even transactional mail (Postmark).

IP and domain reputation are evaluated separately, but interact: a poor IP reputation can harm the domain sending through it even when the domain's own record is good.

Subdomain separation

Both AWS SES and Postmark recommend splitting mail streams by subdomain, the domain-level counterpart of the reputation-realm IP separation in Advanced IP Segmentation:

• Send marketing from e.g. marketing.example.com and transactional from orders.example.com rather than everything from example.com (AWS SES).
• Subdomains develop independent reputations (e.g., notify.example.com vs. newsletter.example.com), so a marketing incident (spam-trap hit, content-filter trigger) doesn't take down transactional delivery. They affect each other only indirectly (Postmark).
• Monitor cousin domains (e.g., company.com vs. company-mail.com) — their reputations and abuse can affect how your brand's mail is judged (SendGrid).

The four domains in every message (Postmark)

1. DKIM signing domain (d=) — sign with your own domain, not a vendor default, so reputation accrues to you.
2. Return-Path domain — use a custom Return-Path (CNAME) matching/aligned with your From domain; required for SPF alignment under DMARC.
3. From/Reply address domain — should clearly identify the brand; publish a DMARC policy on it.
4. Domains in URLs within the content — third-party links harm delivery only when the linked domains are observed doing something deceptive or malicious; still, link only to trusted sites you control (SendGrid).

From-address hygiene (AWS SES)

• Some ISPs attach reputation to the From address itself; it's also recipients' first impression.
• Never send bulk mail from an ISP-based address (e.g., sender@hotmail.com) — large volumes from a consumer-mailbox address are treated with suspicion; send from a domain you own.
• Avoid no-reply@ addresses as From or Reply-To — it signals you don't want recipient feedback, and replies are a positive engagement signal.
• Keep the domain's WHOIS record accurate — an honest, current record signals legitimacy.

Domain warm-up

New domains and subdomains need warm-up just as new IPs do (see IP Warm-Up); the domain accumulates the longer-lived history. Postmark's schedule (volumes are per receiving provider, e.g. per Gmail/Yahoo/Microsoft):

Period	Daily volume per provider
Days 1–2	50–100
Days 3–4	200 (if metrics healthy)
Days 5–7	400
Days 8–10	600–800
Days 11–14	1,000–1,500
Days 15–17	2,000–3,000
Days 18–21	4,000–5,000
Days 22–25	7,500–10,000
Days 26–30	Full intended volume

Growth pacing: roughly double daily at the start; at substantial volumes slow to 20–50% daily increases (30–50%/day in weeks 2–3, then 20–30%/day). Expect an established reputation and dependable full-volume delivery in 3–6 weeks; no single schedule fits every provider's thresholds.

Engagement tiering during warm-up — start with the best data and widen (compare the best-engaged-first rule in IP Warm-Up):

Days	Audience
1–4	Most engaged (previously opened and clicked)
5–7	Opened within last 60 days
8–10	Opened within last 90 days
11–14	Engaged within 120 days
15+	Progressively less recent engagement; re-engagement campaigns last

Cardinal rule: never increase volume before reviewing per-provider engagement and bounce metrics for the prior send. If metrics degrade, cut volume 25–30% until they normalize; the specific corrective triggers are tabulated in Metrics and Benchmarks. Better to take an extra week or two than to rush and damage long-term deliverability.

Feedback loops and notification wiring

A feedback loop (FBL) is a channel through which a mailbox provider reports recipient spam complaints back to the sender. Operational requirements:

• Register for the FBLs of the providers you send to (only some offer them). Word to the Wise maintains a reference of ISP FBL signup points (Postmark). ESP platforms typically pre-wire these and forward complaints automatically (AWS SES does).
• Complaint notifications redact the complainer's address; embed traceable X-headers or body identifiers so complaints can be mapped to an address and campaign (AWS SES).
• The mailbox receiving bounce/complaint notifications must reliably accept mail and must not spam-filter the notifications (AWS SES) — see List Hygiene for what to do with the data.
• Gmail: complaint data arrives via Postmaster Tools rather than a per-message FBL. Tag campaigns with unique Feedback Loop identifiers to see complaint rates broken down by campaign/sender and isolate problem content quickly (SendGrid).

Reputation monitoring tools

Tool	What it gives a sender
Google Postmaster Tools	Domain and IP reputation at Gmail, rated Bad / Low / Medium(Fair) / High (Bad ≈ almost always rejected or spam-foldered; High ≈ rarely filtered); spam-rate dashboard (monitor daily); FBL identifier data
Microsoft (Outlook.com) postmaster tools / SNDS	Reputation and complaint data for Microsoft properties
Yahoo postmaster	Yahoo-side delivery and complaint data
Senderscore.org	Proprietary 0–100 score of overall IP performance
Cisco Talos Intelligence	IP/domain reputation rated Good / Neutral / Poor, with volume history
MXToolbox	Blocklist status checks for IPs and domains plus DNS/domain health; SendGrid calls it "the best free lookup option"

Also verify reverse DNS (PTR) records exist and match for every sending IP — a Google/Yahoo bulk-sender requirement (SendGrid) — and validate authentication (SPF/DKIM/DMARC) with public checkers.

Blocklists (denylists)

• Providers and anti-spam services list IPs/domains that show high spam-trap hits, high complaint volumes, or both (SendGrid).
• Impact varies widely — some lists heavily influence major providers; many are noise.
• If listed on a major blocklist: stop sending immediately, complete the delisting procedure, then resume at significantly reduced volume (Postmark).
• Beware pay-to-play lists that charge for delisting rather than assessing sender behavior (SendGrid).

Troubleshooting framework (Postmark)

When placement or delivery drops, diagnose across five areas in order:

1. Authentication — verify SPF, DKIM, custom Return-Path alignment, and DMARC with public validators.
2. Content — score the message with a SpamAssassin-based checker and seed tests; if a template change preceded the drop, revert changes incrementally (see content rules in Metrics and Benchmarks).
3. Engagement — audit bounce/complaint/open rates against thresholds; suppress hard bounces; avoid noreply@.
4. Reputation — check domain and IP reputation in the postmaster tools and blocklist lookups above.
5. Infrastructure — confirm rDNS/PTR, FBL registrations, IP pool health, and that the sending software DKIM-signs correctly.

There is no silver bullet: deliverability is ongoing monitoring across all five areas, anchored in clean lists and strong engagement.

Related

• Basic IP Allocation and Advanced IP Segmentation — sizing and segmenting IP fleets
• IP Warm-Up — the IP-level counterpart to domain warm-up
• Metrics and Benchmarks — the numbers to monitor
• List Hygiene and Sunset Policies — acting on FBL and bounce data