Most teams inherit their email sending infrastructure rather than designing it. Someone connected a marketing platform to the company domain years ago, the product team wired up transactional mail through whatever the developers preferred, sales added an outreach tool, and nobody drew the diagram. It works until the day a promotional campaign generates complaints and password reset emails start landing in spam.
Infrastructure decisions are deliverability decisions. The domains you send from, the IPs you send through, and the platforms you send with together determine how much damage any single problem can do — and whether you can even tell which system caused it. This guide covers the four choices that matter, when each one should change, and the thresholds that tell you it is time.
Reputation does not attach to your company. It attaches to specific identifiers — a sending domain, a subdomain, an IP address — and mailbox providers evaluate each of them separately.
That mechanic is the whole argument for architecture. If every stream of mail your organisation sends leaves through the same domain and the same IP, they share one reputation, and the riskiest stream sets the ceiling for all of them. A marketing campaign that generates complaints does not damage marketing; it damages your password resets, your invoices and your onboarding sequence, because to a filter they are the same sender.
Good infrastructure is therefore mostly about isolation: putting boundaries between streams so that a problem in one is contained, attributable, and fixable without taking the rest down with it.
Before touching DNS, list every distinct type of mail your organisation sends and who owns it. Most teams find more streams than they expected, and at least one nobody has thought about in years.
| Stream | Examples | Risk profile | Where it should live |
| Transactional | Receipts, password resets, order confirmations, account alerts | Lowest — expected, rarely reported as spam | Its own subdomain, protected from everything else |
| Lifecycle / product | Onboarding sequences, usage digests, renewal notices | Low to moderate — permissioned but promotional in tone | Its own subdomain, or shared with marketing at small scale |
| Marketing | Newsletters, campaigns, promotions, re-engagement | Highest — the main source of complaints and unsubscribes | Its own subdomain, never the root domain |
| Sales outreach | Cold and warm prospecting from individual reps | Very high — unsolicited by definition | A separate domain entirely, not a subdomain |
| Corporate / employee | Human-to-human mail from staff mailboxes | Low, but business-critical | The root domain, kept clear of bulk sending |
Two entries in that table deserve emphasis. Transactional mail is your lowest-risk and highest-stakes stream — people expect it, rarely report it as spam, and notice immediately when it fails. It should be the most insulated thing you run.
Sales outreach is the outlier. Cold prospecting is unsolicited by definition and generates complaint rates that would be catastrophic anywhere else. It belongs on a separate root domain, not a subdomain of your brand, so that a burned outreach domain can be replaced without touching anything else you own.
The standard pattern is to send each bulk stream from a purpose-named subdomain and keep the root domain for human employee mail. A new subdomain begins with no sending history of its own, which is precisely the isolation you want: a marketing subdomain that develops problems does not automatically drag the transactional subdomain down with it.
Use a subdomain dedicated to sending rather than one already pointing at web infrastructure. news.yourbrand.com or mail.yourbrand.com keeps DNS tidy and the reputation unambiguous. Avoid anything that looks disposable or machine-generated — recipients see this domain, and a string of random characters reads as suspicious to humans and filters alike.
Start with two: one for transactional, one for marketing. Add more only when you have genuinely distinct programmes with different audiences or risk profiles. Every subdomain is a separate reputation that has to be warmed and monitored, and a proliferation of barely-used subdomains is worse than a well-run pair.
It is worth being precise here, because sources in this field state it too strongly in both directions. A subdomain does not inherit the root domain's reputation, and it does not automatically pass its own back up. But the separation is not a firewall: there is an organisational relationship through DMARC, recipients recognise the brand regardless of the subdomain, and sustained problems on a marketing subdomain will eventually erode trust in the brand more broadly.
Treat subdomain separation as damage limitation rather than immunity. It buys you containment and attribution, not permission to send badly from one of them.
For marketing and transactional, use subdomains. Keeping both connected to your brand domain helps providers understand they are related, preserves brand recognition, and keeps DNS manageable. A completely separate root domain is warranted only for a specific brand, legal or risk reason — and cold outreach is the clearest example of one.
The dedicated-versus-shared question generates more bad advice than any other infrastructure decision, mostly because vendors sell dedicated IPs and "dedicated" sounds better than "shared".
| Monthly volume | Recommendation | Why |
| Under 100,000 | Shared IP pool | A dedicated IP cannot accumulate enough consistent signal; senders at this volume typically see worse results on dedicated than shared |
| 100,000 - 300,000 | Depends on consistency | Viable if you send at meaningful volume 3-4 days a week or more; stay shared if your sending is bursty or seasonal |
| 300,000 - 1,000,000 | Dedicated IP | Enough volume to keep the IP warm and enough at stake to justify isolating your reputation from poolmates |
| Over 1,000,000 | Multiple dedicated IPs, segmented by stream | Separate pools let transactional mail continue unaffected when a marketing campaign misfires |
The counterintuitive part is that a dedicated IP below the threshold is actively worse than a shared pool. Reputation on an IP needs consistent volume to stay warm. Sending 50,000 messages on Monday and nothing for the rest of the week reads as burst behaviour, and an IP that goes cold between campaigns never accumulates the steady positive signal it needs. Senders below 100,000 a month who pay for dedicated IPs typically see worse deliverability than they would have had on a shared pool.
The trade-off running the other way is real too. On a shared pool your reputation is partly a function of your poolmates' behaviour, and you have less direct control. That is a genuine cost — it is simply a smaller cost than an underused dedicated IP for most senders. Choose a provider that manages its pools actively and segments by sender quality.
Above a million messages a month, the question stops being whether to use dedicated IPs and becomes how to divide them. The standard division mirrors your streams: a pool for transactional, a pool for marketing, and separate pools for anything genuinely high-risk. This is what lets a misfiring campaign burn one pool while receipts continue to arrive untouched.
There are three broad options, and the common mistake is using one where another fits better — typically routing transactional mail through a marketing platform because it was already there.
| Marketing ESP | SMTP relay / email API | Self-hosted MTA | |
| What it is | A full campaign platform with templates, segmentation and automation | Infrastructure only — you send via API or SMTP and build the rest | Your own mail servers running Postfix, PowerMTA, KumoMTA or similar |
| Best for | Marketing and lifecycle streams | Transactional and product mail | Very high volume, multi-brand, or restricted categories |
| Deliverability work | Largely handled for you | Shared — they manage IPs, you manage practice | Entirely yours, including IP acquisition and feedback loops |
| Team required | Marketer | Marketer plus developer | Dedicated engineering time — commonly cited at 0.2-0.4 FTE |
| Indicative cost at ~1.4M/month | Varies widely by feature set | Roughly €250-600 per month | Roughly €1,300-4,400 per month, all-in |
| Breakeven | n/a | n/a | Generally around 3M messages a month, once ESP per-message pricing outpaces fixed costs |
Most organisations end up with two: a marketing ESP for campaigns and lifecycle mail, and an SMTP relay or email API for transactional and product notifications. That pairing matches each stream to a platform built for it, and it naturally reinforces the stream separation described above.
Self-hosting looks cheaper than it is. Published cost analysis at around 1.4 million messages a month puts a self-hosted setup at roughly €1,300 to €4,400 monthly all-in, against €250 to €600 for a managed equivalent — with MTA software licensing accounting for only about a tenth of true cost. The expense sits in staffing (commonly 0.2 to 0.4 of a full-time engineer), monitoring, and the feedback-loop and postmaster relationships a managed provider handles invisibly.
The breakeven generally arrives around 3 million messages a month, when per-message ESP pricing outpaces fixed infrastructure costs. Below roughly 200,000 a month, self-hosting is close to indefensible on economics alone. Between those figures, the deciding factors are usually not cost: multi-brand or white-label requirements, data residency mandates, a restricted industry category that managed providers decline, or a prior suspension that has closed those doors.
Once you have two or more sending platforms, a specific technical trap appears, and it catches teams who believe they have separated their streams when they have not.
Give each platform its own subdomain and its own DKIM selector. Different visible From addresses do not guarantee separate reputations. If two ESPs sign with the same DKIM domain, providers see one identity regardless of what the From line says, and the streams you carefully separated are pooled again.
Check return-path alignment, not just the From address. SPF authenticates the return-path domain, which is often set by the platform rather than by you. Confirm each provider can use a return-path that aligns cleanly with your sending subdomain — otherwise you are relying entirely on DKIM for DMARC alignment.
Start every new platform at DMARC p=none and read the aggregate reports before enforcing. A new platform is a new sending source, and it will appear in your reports as one.
The exception to separation is when two platforms genuinely serve one operation — the same audience, the same mail type, the same controls — in which case sharing a subdomain is reasonable and simpler to manage.
Multi-provider redundancy is frequently recommended and rarely implemented well. The theory is sound: if your ESP has an outage, traffic fails over to a second provider and campaigns continue.
The practical problem is that a dormant backup is not a backup. Its IPs and domains go cold within weeks, so failing over during an incident means sending your most time-sensitive mail from your least established infrastructure, at full volume, with no warm-up. That is a reliable way to convert a temporary outage into a lasting reputation problem.
Redundancy only works if the secondary carries a meaningful share of traffic continuously — commonly 10% to 30% — so that it stays warm. That means paying for two platforms, maintaining two integrations, keeping suppression lists synchronised between them, and accepting that reporting is now split across two systems.
For most senders this is not worth it, and the honest alternative is to accept that a rare ESP outage delays a campaign by a few hours. Where it genuinely matters is transactional mail — a password reset that cannot be sent is a support incident — and there, a warm secondary relay carrying a steady minority of traffic is a defensible investment.
Nearly every organisation reading this already has infrastructure — it simply was not designed. Before changing anything, find out what exists, because the gap between the architecture people describe and the one actually in use is usually wide.
Start with DMARC aggregate reports. Publish a record at p=none if you have not, point the rua address at a parser, and wait a fortnight. The reports name every IP and service sending under your domain. Most teams running them for the first time discover between three and ten sources they cannot immediately account for — an old webinar tool, a payroll system, a survey platform someone trialled.
Then ask the departments. Reports catch what is sending now; they miss what is configured but dormant, and the contract renewing next month. A short question to each team about what tools send email on their behalf usually surfaces the rest.
Map each finding to a stream and an owner. For every source, record what it sends, which domain it sends from, which platform it uses, and who inside the organisation depends on it. That document is the actual architecture, and it is the thing to redesign from.
Expect the audit to reveal one or two genuinely awkward cases: a critical system sending from the root domain, or a tool nobody owns that cannot be turned off because an unknown process depends on it. Resolve those before moving DMARC to enforcement, because enforcement will break them.
Restructuring is riskier than building fresh, because you have an established reputation to preserve and live streams that cannot fail. Three principles keep a migration safe.
Move one stream at a time. Migrating transactional and marketing simultaneously means two unwarmed subdomains and no way to attribute a problem to either. Do the lower-risk stream first, confirm it is stable for a fortnight, then start the next.
Run old and new in parallel. Shift a growing share of traffic to the new subdomain or platform on a warm-up schedule while the existing one carries the remainder. A hard cutover puts full volume onto an unwarmed identity, which is the exact failure this whole article exists to prevent.
Carry the suppression list across first. Every unsubscribe, hard bounce and complaint from the old configuration must exist in the new one before its first send. This is the most commonly skipped migration step and the most damaging, because mailing someone who opted out years ago produces a complaint at precisely the moment your new subdomain can least afford one.
Infrastructure decays through undocumented change. Keep a current record of the following for every sending domain and subdomain, and review it quarterly.
Infrastructure should change at thresholds, not continuously. These are the milestones worth planning for.
Well-designed email sending infrastructure is mostly an exercise in drawing boundaries: separating streams by subdomain so a bad campaign cannot take down a receipt, matching each stream to a platform built for it, and adding IP isolation only when you have the volume to sustain it.
The two decisions with the best return are unglamorous. Split transactional mail away from marketing, onto its own subdomain and its own platform — it is usually the single highest-value change a growing sender can make. And name one owner for the sending estate, so the architecture you design this quarter still exists in two years. Everything above those two is optimisation.
Q1. What is email sending infrastructure?
Email sending infrastructure is the combination of sending domains and subdomains, IP addresses, DNS records and sending platforms that carry your mail. It is a deliverability decision rather than a purely technical one, because the way you separate streams determines how much damage any single problem can do.
Q2. Should I send marketing email from my root domain?
No. Keep the root domain for human-to-human employee mail and send bulk streams from purpose-named subdomains such as news.yourbrand.com. Reputation largely accrues at the subdomain level, so this keeps a poorly performing campaign from jeopardising the mail your business depends on.
Q3. When should I move to a dedicated IP?
Generally above roughly 300,000 messages a month, provided you send at meaningful volume at least three or four days a week. Below 100,000 a month a dedicated IP typically performs worse than a shared pool, because it cannot accumulate the consistent positive signal it needs and goes cold between sends.
Q4. Does a subdomain inherit my root domain's reputation?
Not directly — a new subdomain starts with no sending history and must be warmed like any new sender. But the isolation is not absolute: providers and recipients still associate the mail with your brand, so persistent problems on a marketing subdomain can erode trust in the organisation more broadly.
Q5. Is a self-hosted MTA worth it?
Rarely below 3 million messages a month. Published cost analysis puts a self-hosted setup at roughly €1,300 to €4,400 a month at 1.4 million messages against €250 to €600 for a managed equivalent, with software licensing accounting for only around a tenth of true cost. Staffing, monitoring and feedback-loop management are the real expense.
Q6. Can I use the same sending domain with two different ESPs?
You can, but give each platform its own subdomain and its own DKIM selector. Two ESPs signing with the same DKIM domain share one reputation regardless of what the visible From address says, which defeats the point of separating them and makes troubleshooting far harder.
Q7. Should I run a second ESP for redundancy?
Only if you have the volume and the operational maturity to keep both warm. A dormant backup platform is not a backup — its IPs and domains will be cold when you need them, so failing over to it during an incident means sending your most urgent mail from your least established infrastructure.
Q8. How many sending subdomains should I have?
Start with two: one for transactional and one for marketing. Add more only when you have genuinely distinct programmes with different audiences or risk profiles, because every subdomain is a separate reputation to warm and monitor.
Every provider requirement, threshold and date in this article was verified against the sources below. Re-check them before publication if more than a quarter has passed, since mailbox provider rules continue to change.
 |
