ESP: what an email service provider is and what it takes care of

An ESP (Email Service Provider) is a company that sends email on behalf of its customers: newsletters, marketing campaigns, transactional messages triggered by an application. It runs the MTAs, the IP addresses, the queues and the tracking tools, and leaves the customer in charge of lists, content and DNS records.

What an ESP takes care of#

Behind a web interface or an API, an ESP provides a set of functions that a company would struggle to maintain on its own:

• an MTA fleet sized for millions of messages a day, handling queues, retries and each mailbox provider's limits;
• IP ranges whose reputation is maintained continuously, with DNSBL and feedback-loop monitoring;
• DKIM signing of messages and publication of the required SPF records;
• bounce and complaint processing, with automatic suppression of the addresses concerned;
• open and click tracking, through a tracking domain and rewritten links;
• List-Unsubscribe headers and the one-click unsubscribe required by Google and Yahoo since 2024.

Marketing ESPs (Brevo, Mailchimp, Salesforce Marketing Cloud, Klaviyo, Adobe Campaign and others) differ from transactional or "SMTP relay" providers (SendGrid, Amazon SES, Mailgun, Postmark, Mailjet and others) by their editing and segmentation tools, but the underlying infrastructure faces the same constraints. Some vendors cover both uses.

Shared and dedicated IPs#

An ESP places each customer in one of two arrangements.

Shared IPs: hundreds or thousands of customers send from the same address range. Reputation belongs to the group: it benefits small senders who would never have enough volume to build their own, and it is protected by the ESP, which monitors and removes customers whose traffic degrades the range. In return, a blameless customer can suffer the consequences of a careless neighbour, and has no direct lever on the IP's reputation.

Dedicated IPs: one or more addresses reserved for a single customer. That customer builds its own reputation, answers alone for its mistakes, and must warm the addresses up when they go into service. A dedicated IP only makes sense above a regular volume, often put at a few tens of thousands of messages a week; below that, traffic is too thin for providers to establish a stable history.

In both cases, domain reputation, attached to the DKIM signing domain and the visible From domain, remains the customer's own. It is the one that weighs most with the large mailbox providers, and it is not transferred to the ESP.

What the customer publishes in DNS#

An ESP almost always asks its customer to delegate part of its DNS identity:

; SPF: authorise the ESP's IPs for the envelope domain
example.com.                IN TXT   "v=spf1 include:spf.esp.example -all"

; DKIM: public key, or CNAME delegation to the ESP
esp1._domainkey.example.com. IN CNAME esp1.dkim.esp.example.

; Custom return path: bounces come back to a subdomain of the customer
bounce.example.com.         IN CNAME bounce.esp.example.

; Tracking domain for clicks and images
link.example.com.           IN CNAME track.esp.example.

The custom return path enables SPF alignment in the DMARC sense: the envelope domain (bounce.example.com) belongs to the same organisational domain as the From (example.com). Without it, SPF passes but is not aligned, and only the DKIM signature carries DMARC compliance. A tracking domain under the customer's own domain avoids links pointing at a generic ESP domain, shared with every other customer and occasionally listed.

Recognising the provider behind a domain#

A domain's DNS records give away its providers. MX records say who receives the mail, and SenderRadar identifies that provider from the MX hostnames. SPF include mechanisms, DKIM CNAMEs and the return-path domain reveal who sends it. A single domain can thus receive mail at Google Workspace, send its newsletters through a marketing ESP and its application notifications through a transactional relay, each one showing up in a different part of the configuration.

What to check#

• The records requested by the ESP are published and verified in its interface before the first send.
• The SPF record stays under ten DNS lookups after adding the ESP's include.
• The DKIM signature uses the customer's domain (d=example.com), not the ESP's, so that DMARC is aligned.
• The custom return path is enabled, both for SPF alignment and so that bounces are processed.
• The ESP gives access to sending logs, per-provider rejection codes and complaints, not only to aggregate rates.
• The contract states what happens in case of a reputation incident on a shared IP.

Common mistakes#

• Letting the ESP sign with its own DKIM domain: the message passes DKIM but fails DMARC for the customer's domain.
• Using several ESPs without separate subdomains, so that an incident at one of them hits the reputation of the whole domain.
• Moving to a dedicated IP with too little volume, then seeing spam-folder placement for lack of history.
• Switching ESP without a gradual migration, cutting traffic over to brand-new IPs overnight.
• Forgetting to remove the DNS records of a former provider, which then keeps the authorisation to send on the domain's behalf.