The email infrastructure glossary
Plain-language definitions for the terms that decide how your email is sent, whether it reaches the inbox, and where it is legally allowed to live — written as a neutral reference, with links to go deeper.
The four areas at a glance
- Sending engines & architecture — MTA, VirtualMTA, SMTP relay, MTA vs ESP: the engine layer that moves your mail.
- Authentication & standards — SPF, DKIM, DMARC, BIMI, MTA-STS: the records that prove your mail is genuinely yours.
- Deliverability & reputation — bounces, feedback loops, suppression lists, greylisting, IP warming, sender reputation, blocklists, spam traps: what gets you to the inbox.
- Sovereignty & compliance — data residency vs jurisdiction, EU-US DPF, CLOUD Act, Schrems II: where your email data can legally live.
- The definitions are provider-neutral; links point to deeper material only where a term connects to something concrete.
A reference first, a sales page second
Email infrastructure is full of vocabulary that sounds interchangeable until it costs you a delivery problem. The difference between a hard and soft bounce, between residency and jurisdiction, between an MTA and an ESP — each is small to state and expensive to get wrong. This page collects the terms that come up most when teams design, migrate or audit a sending setup, and defines them in language you can quote without a footnote.
The definitions are deliberately neutral. Where a term connects to something we operate — managed DMARC, IP warming, the engine comparison — there is a link to go deeper, but the entry stands on its own first. Use it as a quick reference, or read a section end-to-end to get oriented in an area you are new to.
Sending engines & architecture
The software layer that actually moves your mail, and the words people use to describe how it is shaped.
- MTA (Mail Transfer Agent)
- The software that routes and delivers email between servers over SMTP. It is the engine underneath any sending setup — Postfix, Exim, PowerMTA, KumoMTA and Halon are all MTAs. Choosing one is mostly about volume, control and licensing rather than raw capability. compare the six engines →
- VirtualMTA (vMTA)
- A logically isolated sending identity — an IP plus its own configuration and reputation — running inside a single MTA. VirtualMTAs let you separate streams (transactional vs marketing) or customers so one stream’s reputation cannot drag another down. The term originates with PowerMTA and is now used broadly. PowerMTA vs KumoMTA →
- SMTP relay
- A server that accepts mail from your application and forwards it to recipient mailbox providers on your behalf. A relay is the hand-off point between code and the wider internet, and where authentication, rate-shaping and reputation management are applied. SMTP relay service →
- MTA vs ESP
- An MTA is the sending engine you (or a provider) operate directly; an ESP (Email Service Provider) is a managed platform layered on top, often with campaign tools and a shared pool. The distinction matters when you need dedicated reputation and control rather than convenience. dedicated alternatives →
Authentication & standards
The DNS-published records that let mailbox providers verify your mail is really yours — the foundation of deliverability.
- SPF (Sender Policy Framework)
- A DNS record listing which servers are authorised to send email for your domain. Receivers check it to confirm the sending IP is one you sanction. SPF alone is fragile — it breaks on forwarding — which is why it is paired with DKIM under DMARC. managed DMARC →
- DKIM (DomainKeys Identified Mail)
- A cryptographic signature added to each message that proves it was not altered in transit and genuinely came from your domain. Unlike SPF, DKIM survives forwarding, which makes it the more durable of the two authentication signals. managed DMARC →
- DMARC
- A policy that ties SPF and DKIM together and tells receivers what to do when a message fails both — monitor, quarantine, or reject — while sending you aggregate reports. DMARC is what turns authentication from advisory into enforceable, and is increasingly required by major mailbox providers. managed DMARC →
- BIMI (Brand Indicators for Message Identification)
- A standard that displays your verified brand logo beside your messages in supporting inboxes. It is built on top of DMARC at enforcement, so BIMI is effectively a reward for getting authentication fully in order. managed DMARC →
- MTA-STS
- A standard that lets a domain require TLS encryption for inbound SMTP and declare that requirement via a published policy. It closes a downgrade gap in classic SMTP, where encryption was opportunistic rather than enforced. deliverability monitoring →
Deliverability & reputation
Whether your mail reaches the inbox is decided here — by signals you build over time and lose in an afternoon.
- Hard bounce vs soft bounce
- A hard bounce is a permanent delivery failure — the address does not exist — and must be suppressed immediately. A soft bounce is temporary, such as a full mailbox or a transient server error, and may be retried. Treating the two the same way is a common cause of reputation damage. deliverability monitoring →
- Feedback loop (FBL)
- A channel through which a mailbox provider reports spam complaints back to the sender, so you can remove complainers promptly. Honouring feedback loops is one of the clearest signals to providers that you manage your list responsibly. reputation recovery →
- Suppression list
- The set of addresses you must never send to again — hard bounces, spam complainers and unsubscribes. A well-maintained suppression list is the single most effective list-hygiene control, because continuing to mail dead or hostile addresses poisons reputation fast. deliverability audit →
- Greylisting
- A receiver tactic that temporarily rejects mail from unfamiliar senders, expecting a legitimate server to retry shortly and a spammer not to. Properly behaved MTAs retry and pass; the technique quietly filters a lot of low-effort spam. how engines handle retries →
- IP warming
- The practice of gradually increasing send volume on a new dedicated IP so mailbox providers build trust in it instead of treating a sudden spike as suspicious. Skipping or rushing warm-up is one of the most common reasons new infrastructure underperforms. IP warming service →
- Sender reputation
- The trust score mailbox providers assign to your sending IP and domain, based on complaint rates, bounce rates, spam-trap hits and engagement. It is earned slowly and lost quickly, and on shared infrastructure it is partly hostage to your neighbours. reputation recovery →
- Blocklist (blacklist)
- A published list of IPs or domains flagged for spam-like behaviour that receivers may consult to reject mail. Landing on a major blocklist can stop delivery outright; getting off one requires fixing the underlying cause, not just requesting removal. reputation recovery →
- Spam trap
- An address that exists only to catch senders with poor list hygiene — either a recycled dead address or one never opted in. Hitting spam traps signals to providers that you are mailing without consent, and is a fast route to a blocklist. deliverability audit →
Sovereignty & compliance
For European senders, where your email data legally lives is as much a decision as how it is sent.
- Data residency vs data jurisdiction
- Residency is where data is physically stored; jurisdiction is which country’s laws can compel access to it. A US company can store your data in an EU data centre and still be obliged to hand it over under US law — which is why jurisdiction, not residency, is the question a compliance review actually asks. EU-sovereign alternatives →
- EU-US Data Privacy Framework (DPF)
- The mechanism that legitimises personal-data transfers from the EU to self-certified US companies. The European Commission deemed it adequate in 2023, and it survived its first legal challenge in 2025 — but its longer-term validity is unsettled, so a posture built on it rests on a foundation that needs watching. Schrems II explained →
- CLOUD Act
- A US law that can compel US-based companies to produce data they control regardless of which country the servers sit in. It is the concrete reason an EU data-centre region does not, by itself, place a US provider’s data beyond US reach. Schrems II explained →
- Schrems II
- The 2020 Court of Justice of the EU ruling that invalidated the Privacy Shield and reshaped the requirements for EU-to-US data transfers, forcing case-by-case assessment of foreign-law exposure. It is the legal backdrop to most EU sovereignty decisions in email infrastructure. Schrems II explained →
The terms connect to one decision: who controls your sending
Read across the four areas and a single thread runs through them. The engine you pick, the authentication you publish, the reputation you build and the jurisdiction you sit under all answer the same underlying question: how much of your sending do you control, and who else can touch it. A shared platform decides most of that for you; dedicated infrastructure puts it in your hands.
That is the lens OS Domains is built around — dedicated IPs and reputation that are yours, an engine you choose from the MTA comparison hub, and EU jurisdiction under an Austrian entity. If you are weighing a move off a shared or US-based provider, the alternatives overview applies the sovereignty terms above to real providers.
Email infrastructure terms, answered
What is the difference between an MTA and an ESP?
An MTA — Mail Transfer Agent — is the sending engine itself, the software that routes and delivers mail over SMTP. An ESP, or Email Service Provider, is a managed platform layered on top of an MTA, usually bundling campaign tools, a dashboard and a shared sending pool. The practical difference is control: with a dedicated MTA setup you own your IPs and reputation and choose the engine, while an ESP trades that control for convenience and often shares infrastructure across many senders.
Do I really need SPF, DKIM and DMARC all three?
For reliable delivery to major mailbox providers in 2026, effectively yes. SPF authorises sending servers but breaks on forwarding; DKIM cryptographically signs messages and survives forwarding; DMARC ties the two together, tells receivers what to do on failure, and reports back to you. Several large providers now require DMARC for bulk senders, so the three are best treated as one authentication baseline rather than independent options.
Why does data residency not equal data jurisdiction?
Residency describes the physical location of a server; jurisdiction describes which laws can compel the company that controls the data to disclose it. A provider can truthfully say your email is sent from an EU region while the account data, keys and logs remain under the control of a US-headquartered entity subject to laws like the CLOUD Act. For a GDPR or Schrems II assessment, jurisdiction is the part that carries weight, and a region setting does not change it.
What is IP warming and why does it matter?
IP warming is the practice of gradually raising send volume on a new dedicated IP address so mailbox providers can build trust in it. A brand-new IP has no reputation, and a sudden surge of mail from an unknown source looks like exactly what spammers do. Warming over days or weeks, starting with your most engaged recipients, lets providers see consistent, wanted mail and assign a positive reputation rather than a suspicious one.
Is this glossary specific to OS Domains products?
No — the definitions here are general email-infrastructure concepts that apply regardless of provider. Where a term connects naturally to something we operate, such as managed DMARC or IP warming, we link to it so you can go deeper, but the glossary is written to be useful as a neutral reference first.
Know the terms — now apply them to your sending.
Tell us what you send and where it has to land. We will translate the vocabulary into a concrete recommendation, on dedicated EU infrastructure under an Austrian entity.