Email Infrastructure at Scale: Decisions that Matter from 10K to 10M

Most companies that send more than one kind of email ended up with their setup by accident. Someone picked a provider in year one, and nobody looked at it again until deliverability broke.

Both our teams have watched the same pattern play out. A marketing campaign draws complaints and password resets start landing in spam. A domain that was warming nicely gets burned because outreach was sharing it with order confirmations.

The setup you choose at 10,000 emails a month decides how far you get before something like this happens. This article walks through the decisions that matter from day one, from Hunter's side and from Mailtrap's.

A quick note on who does what. Hunter is built for email outreach, which we treat as its own separate setup throughout this piece. Mailtrap is an email delivery platform for transactional and marketing email, focused on deliverability at scale. Between the two, that covers every kind of email you'll send.

Separate your sending streams first

When a company comes to either of us with a deliverability problem, something is usually working fine and dragging the rest down with it. Email types that should never share infrastructure are sharing it.

Three kinds of email, three sets of rules

Transactional email is triggered by something the user did: a password reset, a purchase confirmation, an account alert. Consent is built into the product relationship. Urgency is high, because a user waiting on a verification link is stuck until it arrives. Volume is low and predictable. Reputation builds slowly here and disappears fast.

Opt-in marketing email goes to people who subscribed. Volume is the whole point, and a single campaign can reach hundreds of thousands of inboxes in a few hours. Complaint rates swing more, unsubscribes are normal, and big volume spikes move your standing with Gmail and Microsoft.

Outreach goes to people who haven't subscribed. Complaint rates run higher than opt-in marketing as a matter of course, and receiving providers know it. You scale outreach by adding sending domains and mailboxes. Pushing more volume through one domain gets it burned.

So you have three consent models, three volume patterns, and three complaint tolerances. Infrastructure tuned for one of them works against the other two.

The blast radius problem

When a marketing campaign underperforms, complaint rates can rise on the IP pool or sending domain carrying those sends. If that infrastructure is shared with product email, the blast radius extends immediately. Password resets and account alerts start landing in spam or getting deferred. Users who never opted into marketing are penalized by a campaign they never saw.

You can't send your way out of this once it's happened. The fix is to keep the streams apart from the start, with authentication in place on each of them.

The domain architecture

Keep your root domain out of bulk sending entirely and route each stream through its own authenticated subdomain.

• Product email goes through something like app.yourdomain.com or mail.yourdomain.com.
• Marketing goes through news.yourdomain.com.

Each subdomain builds its own reputation, so a rough month on the marketing side doesn't touch your receipts and resets.

Outreach shouldn't sit on a subdomain of your main brand at all. Register a separate root domain (getyourdomain.com, tryyourdomain.com) and keep outreach entirely on that. If it takes damage, your product and marketing email never notice.

At 10,000 sends a month, this costs you an afternoon of DNS work. At 500,000, splitting things up means migrating reputation, re-warming everything, and eating a deliverability dip while you do it. Decide early.

Transactional and marketing email: infrastructure that scales

The architecture from the previous section defines what should be separate. This section covers what happens inside each lane as volume grows.

Shared IP pool or dedicated IP

The choice between a shared IP pool and a dedicated IP is about volume and consistency - not about which option sounds more serious.

• Below roughly 25,000 emails per month, a premium shared IP pool from a reputable provider consistently outperforms a dedicated IP. A shared pool carries reputation built across many quality senders; a fresh dedicated IP carries none. At low volumes you cannot generate enough sends to build meaningful history quickly, and you are more exposed to fluctuations when volume is uneven.
• Between 25,000 and 100,000 emails per month, dedicated IP is potentially viable; but only with consistent daily volume. One large campaign per month followed by silence builds reputation poorly. Consistency matters more than total monthly volume at this stage.
• Above 100,000 emails per month, dedicated IP is the standard approach. Plan for roughly one IP per 100,000 to 200,000 daily sends to major providers. Warm-up is required.

Once marketing volume crosses 100,000 per month, sharing IP infrastructure with triggered product email is an active liability. One underperforming campaign can carry asymmetric blast radius to your highest-urgency email type. 

What changes at each tier:

Authentication before scale

SPF, DKIM, and DMARC are the foundation of email authentication, and the question is not whether to implement them, but whether you enforce a mature policy or not.

For instance, the DMARC progression is a signal of infrastructure maturity:

• p=none: monitoring mode; you receive reports but no mail is filtered
• p=quarantine: messages that fail DMARC checks go to spam
• p=reject: messages that fail DMARC checks are blocked entirely

Note that Google shifted from temporary deferrals to permanent rejections for non-compliant bulk senders in November 2025. Microsoft followed with its own enforcement in May 2025. 

Tip: Set up Google Postmaster Tools alongside your authentication records - it surfaces how Gmail sees your sending domain, including reputation signals and authentication pass rates, before problems show up in delivery data.

Also, plan to set up BIMI (Brand Indicators for Message Identification). It requires DMARC at p=quarantine or p=reject with pct=100; monitoring mode does not qualify. At volumes above 500,000 per month, the brand signal compounds with sender reputation in ways that make BIMI strategically worthwhile. But, getting DMARC to enforcement level takes time; so set it up before you need BIMI, not after.

List quality as infrastructure

Every address on your list that shouldn't be there is a future bounce or complaint. Double opt-in catches those at the door instead of after they've done damage. Treat it as a requirement, the same as SPF.

“Most deliverability problems we see start before the first send. Contact lists that were never properly qualified are the leading cause of domain reputation damage — and double opt-in is the mechanism that stops that from happening at the point of entry, not after the fact,” says Miglė Padelytė, Product Manager at Hostinger Reach.

Complaint rates in numbers: 

• 0.1% is the action threshold at any meaningful volume. Not a warning zone; the number that triggers immediate investigation. 
• At 0.3%, Gmail enforcement kicks in actively. 
• The absolute numbers matter as volume scales: 0.1% of 100,000 emails per month is 100 complaints; 0.1% of 1,000,000 is 1,000. The rate looks identical; the reputation impact does not.

Suppression is day-to-day work and belongs in the send pipeline. Hard bounces get suppressed immediately. Soft bounces get a threshold: 2-3 in a row moves the address to the suppression list. A list that grows faster than your suppression discipline will become unmanageable no matter how good the rest of the setup is.

The warm-up decision

A new dedicated IP has no history with receiving providers. Warm-up is the process of building that history incrementally, so receiving servers see a consistent pattern before you ask them to accept significant volume.

Plan for four to six weeks. Start with your highest-engagement segments - people most likely to open, click, and reply. Those positive signals tell receiving servers that your mail is wanted, which builds the trust that carries higher volume later. 

Send smaller amounts in week one and increase consistently each week. Consistency matters more than hitting a specific number on any given day; a smooth six-week ramp outperforms an aggressive push that stalls midway and then surges.

Mailtrap in practice

At some point, the architectural decisions above require infrastructure that can actually enforce the separation. Mailtrap runs transactional and bulk sends as separate streams on separate infrastructure - same account, isolated at the sending layer. A campaign that underperforms on the bulk stream does not create risk for triggered product email, because the two streams do not share IP pools.

The API versus SMTP relay decision matters as volume grows. API integration gives programmatic control over headers, metadata, and delivery events, and makes webhook-driven list hygiene straightforward: bounce and complaint events surface in real time and feed directly into suppression logic rather than requiring periodic cleanup runs. SMTP relay is simpler to integrate but limits operational visibility at scale.

And Mailtrap Email Marketing runs as a separate product, on it’s own stream, with the same isolation model. 

Email outreach: the isolated infrastructure lane

Outreach infrastructure is its own category and should be treated that way from the start.

Why outreach needs its own infrastructure

As a reminder:

• Email outreach reaches people who have not subscribed. 
• Complaint rates are higher by nature; an expected property of the channel. 
• The most common mistake is routing outreach through the same domain (or the same subdomain) as product email. 

A campaign that reaches the wrong person, or catches someone at the wrong moment, generates a complaint. That will happen at some rate regardless of how carefully the list was built.

But, I want to stress that outbound infrastructure needs to be isolated not because the sends are low quality, but because the channel’s structural properties are different. Isolation protects everything else.

The outreach domain architecture

A few structural principles to consider:

• Domain aging: allow two to four weeks between domain registration and first send. Newly registered domains that send immediately trigger filtering.
• Mailboxes per domain: three to five inboxes per domain is standard. Beyond five, risk increases without proportional benefit.
• Daily volume per inbox: 20 to 50 emails per inbox per day is the safe operating range. During warm-up and for domains without established history, stay at the lower end; 20 to 30 per day.
• Provider diversification: a mix of Google Workspace and Microsoft 365 inboxes distributes sends across provider ecosystems, reducing exposure when filtering behavior tightens on one side.

Scaling outreach means adding domains and inboxes as volume grows. Multiple domains and accounts are necessary to reach meaningful scale the structural reality of how outreach email works at volume. 

When a domain’s sending reputation degrades past a sustainable threshold (bounce rate consistently above 2%, complaint rate above 0.3%), that domain is retired and the rest of the infrastructure continues unaffected. Track outreach domain health separately from your main infrastructure dashboards; these are distinct reputation pools.

The Hunter.io infrastructure workflow

Hunter is built specifically for outreach at this level of infrastructure discipline. Its tools function as inputs to the sending workflow.

• Verification as bounce prevention. Hunter’s Email Verifier runs a multi-step check on every address: format validation, MX record verification, SMTP server detection, and an existence check against the receiving server without sending an actual email. Results come back as Valid, Risky (catch-all or role-based), or Invalid. 

Running this check before addresses enter your outreach queue is the primary mechanism for keeping bounce rates below the 5% threshold where algorithmic reputation damage becomes serious. Verified lists typically run well below 2% bounce rate; unverified lists regularly exceed 5%.

• Domain search as infrastructure due diligence. Before adding contacts from a target company, Hunter’s Domain Search reveals the company’s email pattern, MX configuration, and contact data with confidence scoring. Understanding a target’s email setup before you send surfaces information that affects deliverability before the send goes out.
• Campaign pacing as reputation management. Hunter Sequences includes built-in sending limits that act as infrastructure guardrails. The pacing controls prevent volume spikes that would otherwise create sudden shifts in sending reputation — the kind a warm domain can absorb briefly but cannot sustain without damage.

The full workflow: 

1. Hunter domain search to understand the target company and source contacts with confidence scoring, 
2. Email verification to filter invalid and risky addresses, 
3. List cleansing before contacts enter the queue, 
4. Sends from a properly warmed dedicated outreach domain, with pacing controls keeping daily volume within safe range. 

Each step is an infrastructure decision, not just a workflow preference.

Conclusion

The teams that scale email cleanly made the separation decision early. Not because they had perfect foresight, but because they understood that email infrastructure compounds. Good decisions build into reliable delivery. Bad ones build into fragile systems that fail at the worst possible time.

Three rules, applied consistently: separate your sending lanes before you need to. Set up authentication before a problem forces your hand. Treat data quality (list hygiene, suppression, verification) as infrastructure input, not periodic cleanup.

For transactional and marketing email infrastructure, Mailtrap provides the sending architecture with proper stream isolation. For verified outreach, Hunter gives you the workflow to build and execute from a clean foundation.