What is an ESP, and what is an ESP-agnostic email editor?

An ESP, or email service provider, is the platform that sends your marketing email. Salesforce Marketing Cloud, Braze, Marketo, Klaviyo, HubSpot, Iterable and Mailchimp are all ESPs. You give one a list of subscribers and an email, choose who gets it and when, and it delivers the message, records opens and clicks, and runs the automated flows that go out on their own, such as a welcome series or an abandoned-basket reminder.

If you searched for “what is an ESP” and got a page about car safety systems and extrasensory perception, this is the marketing one.

An ESP-agnostic email editor builds the email outside the ESP and exports standard HTML, so the same templates work whichever platform sends them. The editor handles design and content. The ESP still handles everything to do with sending. Modular Mail works this way, and so, with different ideas about how an email should be built, do Stripo, Beefree and Taxi for Email.

The rest of this post covers what an ESP does, where its built-in editor tends to run out, what “ESP-agnostic” changes day to day, and what happens to your templates when you move from one ESP to another.

---

What an ESP does

Every ESP does four jobs:

• Sending and deliverability. Mail servers, sending reputation, and the authentication records (SPF, DKIM and DMARC) that keep your email out of the spam folder.
• Lists and segments. Who is subscribed, what they have bought or clicked, and which group should get this send.
• Automation. Flows that trigger on behaviour, such as someone signing up or leaving a basket behind.
• Reporting. Opens, clicks, revenue, unsubscribes and complaints, per campaign and over time.

Almost every ESP adds a fifth thing: an editor for designing the email itself. That is the part this post is about, because it is where the trouble starts for teams whose emails are custom-designed.

Where the ESP’s editor runs out

ESP editors are built for the templates the ESP ships with. You pick a layout, drop in some blocks, change the colours and send. For a small team sending a newsletter a month, that is all the editor anyone needs, and it would be odd to add a tool on top.

The problem arrives with custom HTML. Most brands that care how their email looks have a hand-coded template: a developer or agency built it to match the brand, tested it in Outlook and handed it over. Most ESP visual editors can’t open that file. They show the design, but the only way to change a headline is the code editor, so a routine content change becomes a ticket for whoever understands the markup.

Teams work around it by rebuilding the design in the ESP’s blocks, which costs them the design, or by copying last week’s HTML and editing it by hand, which works until a missing tag breaks the layout in Outlook. The careful ones queue every change with a developer instead, and the campaign ships when the developer is free.

What “ESP-agnostic” means in practice

“Agnostic” is borrowed from software, where it describes a tool that doesn’t care which platform it is paired with. An ESP-agnostic editor doesn’t know or care whether the HTML it produces is going to Klaviyo or to Marketo. It produces HTML that any of them can take.

Day to day it looks like this. The template lives in the editor rather than the ESP. Someone on the team builds the campaign there, and when it is approved they export the HTML and paste or upload it into the ESP as a new campaign or template. The ESP does the sending, the segmentation and the reporting exactly as before. Nothing about your lists, your flows or your deliverability changes.

Job	Where it lives
Lists, segments and consent	Your ESP
Automated flows and scheduling	Your ESP
Sending, deliverability and authentication	Your ESP
Reporting	Your ESP
The template’s design and its rules	The editor
Building each campaign’s content	The editor
The finished HTML	Exported from the editor, uploaded to the ESP

Two things are worth being clear about. The editor is not an ESP: it doesn’t send anything, so there are no per-send or per-contact charges, and it can’t replace the ESP. You need both. And there is usually no integration to maintain, because the export is a file or a copied block of HTML, which is dull and very reliable. Some editors also offer direct connectors to particular ESPs. They save you a paste, and they are one more thing to keep working when either side changes.

When your ESP’s own editor is enough

Not every team needs an editor outside the ESP. Yours probably doesn’t if:

• You send a handful of campaigns a month and one or two people build them.
• Your design fits the ESP’s blocks, or you’re happy for it to.
• You’re not planning to change ESP, and you don’t mind that your templates are stored in its format.
• Another subscription on top of the ESP would need a reason you don’t yet have.

If that is you, stay where you are. ESP editors have improved a great deal in five years, and having one less tool has a value of its own.

When it pays to separate building from sending

The case for an ESP-agnostic editor grows with the size of the email operation:

• Your emails are custom HTML and you want them to stay that way.
• Several people build emails, and you want the layout protected from whoever is in a hurry on a Friday afternoon.
• You send through more than one ESP: an agency with clients on different platforms, or a company with transactional email in one tool and marketing in another.
• You send every week, so a two-day wait for a developer is a two-day wait for the campaign.
• An ESP move is somewhere in the next couple of years. Keep the templates out of the ESP now and the move gets a lot smaller.

What happens to your templates when you switch ESP

This is worth knowing even if a move is nowhere in the plan. Switching ESP sounds like a data transfer: export the list, import it, point the signup forms at the new platform. The list does move. It is everything attached to it that doesn’t.

• Automations are stored as platform-specific configuration, not as portable files. Every welcome series and abandoned-basket flow is rebuilt by hand in the new ESP and tested again.
• Templates built in the old ESP’s editor are stored in its own format. There is no “export to Braze” button in Klaviyo. You rebuild them in the new editor, or you export whatever HTML the old ESP will give you and hope it is clean enough to reuse. It often isn’t, because builders write HTML for their own renderer rather than for someone else’s.
• Hand-coded HTML templates survive better: paste them into the new ESP and they render. But any edits the team made inside the old ESP since the handover are gone, and so is the module library everyone had learned.
• Sender reputation starts again if the sending IP changes, which means weeks of warming up with smaller sends.

An ESP-agnostic editor takes the template problem off that list. The templates were never in the ESP, so there is nothing to rebuild: the next export goes to the new platform instead of the old one. The automations, the forms and the warm-up are still yours to do, but one large and very visible part of the job disappears.

Merge tags and personalisation

Each ESP has its own syntax for pulling a subscriber’s details into the email. The first name alone looks like this:

ESP	First name
Mailchimp	*|FNAME|*
Klaviyo	{{ first_name }}
HubSpot	{{ contact.firstname }}
Salesforce Marketing Cloud	%%FirstName%%
Marketo	{{lead.First Name}}
Braze	{{${first_name}}}

In an ESP-agnostic editor this is simpler than it sounds. Merge tags are content rather than layout, so you type your ESP’s syntax straight into the text field and it comes out in the exported HTML as written. If you send through more than one ESP, keep the tags out of the shared template and add them per campaign, or write a placeholder such as [FIRST_NAME] and replace it after upload. Either way, send yourself a test from the ESP before the real send, because a wrong tag renders as the tag itself.

Getting the HTML into your ESP

Every major ESP accepts pasted or uploaded HTML when you create a template or a campaign. Mailchimp calls it “Code your own”, Klaviyo “Import HTML”, Salesforce Marketing Cloud’s Content Builder “Paste HTML”, and Braze, HubSpot and Marketo each have an HTML editor for the same job. It takes a couple of minutes, and from then on the ESP treats the email like any other: you pick the segment, set the schedule and send.

Where Modular Mail fits

Modular Mail is an ESP-agnostic editor built as a CMS for email. Setup is done by us, your agency or your developer: one data-mm attribute on each part of your existing HTML template that should change from campaign to campaign, and a field set up for it in the form builder. Your team then builds campaigns by filling in those fields and arranging the modules the template allows, reviewers comment and approve on the email itself, and the approved HTML is copied or downloaded into whichever ESP you send from. The layout, fonts and spacing are written into the template’s HTML, so nobody can move them by accident. If the idea is new to you, What is an email CMS? and What are modular email templates? explain it properly.

---

Common questions

Is Gmail an ESP?

No. Gmail, Outlook and Apple Mail are mailbox providers and email clients: they are where your subscribers read email. An ESP is the platform a business sends from. The two meet in the inbox, which is why the deliverability work your ESP does matters so much.

What is the difference between an ESP and a CRM?

A CRM stores the relationship: contacts, their history and the orders or deals attached to them. An ESP sends email to those contacts. Some platforms do both (HubSpot and Salesforce, for instance), and many CRMs push segments to a separate ESP. An ESP-agnostic editor sits alongside either, because all it needs is somewhere to paste the HTML.

Do I still need an ESP if I use an ESP-agnostic editor?

Yes. The editor builds the email. It doesn’t store subscribers or send anything, and it has no idea who opened what. Sending stays with the ESP.

Does “ESP-agnostic” mean I need an integration?

No. The export is a standard HTML file. There is nothing to connect, which also means there is nothing to fix when the ESP changes its API.