What an ESP does

An ESP (Email Service Provider) is the service that owns the email channel. Its responsibilities come down to five blocks:

Block What it covers
Sending Queues, send rate, retries, bounce handling
Deliverability Domain setup with SPF, DKIM and DMARC, IP and domain reputation, warm-up
Subscriber base Address storage, statuses, opt-ins and opt-outs, complaint handling
Content Template editor, field substitution, subject-line A/B tests
Automations Welcome sequences, reactivation, scheduled and event-based series

The main thing an ESP is paid for is not the email editor. It is deliverability: the set of technical and reputational factors that decide whether a message lands in the inbox or in spam. That is exactly why an ESP cannot be improvised in-house — mailbox providers judge the sender’s history, not the quality of the HTML.

A separate obligation of the ESP is correct subscription handling. An unsubscribe must take effect at the moment of the click and apply across every campaign; spam complaints must be processed automatically. Breaking that mechanic damages deliverability for the entire base.

What an ESP is not

The term is often used as a synonym for “the marketing system”, which lumps four different classes of product together. The easiest way to separate them is to ask what each system owns.

Class of system What it owns Typical jobs What it does not do
ESP The email channel Sending, deliverability, templates, subscriptions, basic sequences Does not build a behavioural profile from site activity, does not personalize onsite
CDP The customer profile Event collection, identity stitching, unified profile, segments Does not send email, does not own domain reputation
MAP The scenario Multichannel sequences, branches, waits, channel choice per step Usually does not build product recommendations or re-rank the catalogue
Personalization platform Content and selection Recommendations, listing sort order, dynamic content on site and in app, A/B tests Does not send email, push or SMS — it has no transport
ℹ

A formulation worth keeping in mind when designing the stack: the ESP owns the channel, the CDP owns the profile, the MAP owns the scenario, and the personalization platform owns the content. Feature overlaps will always exist, but when an incident happens, ownership is defined by exactly this split.

How these systems work together

The standard arrangement for an online store looks like this:

Site / app -> events -> CDP (unified profile, segments)
                               |
                    MAP / ESP automations -> choose the moment and the audience
                               |
      Personalization platform -> a product block for this specific recipient
                               |
                          ESP -> assemble the message -> send -> deliver
                               |
              opens and clicks -> back into the CDP

How the roles divide in practice:

  • Whom to send to — decided by the segment from the CDP or a scenario condition in the MAP.
  • When to send — decided by the trigger: a site event, an order status, the schedule of a drip campaign.
  • What to show inside — decided by the personalization platform: a product selection matched to the recipient’s profile, rather than the same bestsellers block for everyone.
  • How to deliver — decided by the ESP: assembly, sending, bounce and unsubscribe handling.

To be explicit: a personalization platform does not replace an ESP and does not send email on its own. It has no sending infrastructure, no domain reputation and no subscription mechanics. Its contribution to the email channel is limited to two things — the content of product blocks and the exchange of segments. That applies to Gravity Field too: the platform supplies recommendations for insertion into messages sent by a third-party ESP, and does not handle sending itself.

Common mistakes in the setup

  1. Duplicated segmentation in two systems. Segments live in both the CDP and the ESP, diverge within a month, and nobody knows which one to trust. There must be a single source of truth.
  2. Unsubscribes recorded only in the ESP. If the withdrawal of consent never reaches the CDP and the other systems, the person keeps receiving communications in other channels.
  3. Expecting onsite personalization from the ESP. Site behaviour arrives in an ESP truncated and delayed; real-time product selection cannot be built on it.
  4. Expecting email campaigns from the personalization platform. The mirror-image mistake: it has no transport, and any attempt to save money on an ESP runs into the absence of deliverability altogether.
  5. A static recommendation block in the message. The same selection for the whole base has the same effect as any unchanging banner — people stop noticing it.
  6. No return flow of data. Opens and clicks from the ESP must come back into the profile, otherwise first-party data stays incomplete and segmentation stays crude.

Selection and setup checklist

  1. Check support for SPF, DKIM and DMARC, and the availability of a dedicated IP at volumes from hundreds of thousands of messages.
  2. Clarify the pricing model — per subscriber or per send — and match it against your planned sending frequency.
  3. Confirm that APIs and webhooks exist: without them the ESP cannot be connected to a CDP or a personalization platform.
  4. Define a single source of truth for segments and for consent status.
  5. Set up the return flow of events (opens, clicks, unsubscribes) into the customer profile.
  6. Verify that personal blocks in the message are generated per recipient rather than being identical across the base.
  7. Fix the boundaries of responsibility between systems before launch — when a deliverability incident or a wrong product selection happens, it saves days of investigation.