How to tell if a company switched ESP

How to tell if a company switched ESP before the announcement

Most platform moves are never announced at all. The ones that are get a line in a case study eighteen months later, usually written by the vendor that won the account. But the headers move on the first production send, and that send happens while the project is still half-built.

Think about what a migration actually involves. Someone exports the lists, authenticates a new sending domain, warms it over a couple of weeks, and pushes a test campaign to a small segment to check that rendering did not break. That test campaign goes to real inboxes. If you are subscribed, you already have the evidence sitting in your archive, weeks before the new templates ship.

The commercial reasons behind a move are more varied than people assume. Sometimes it is a renewal that got expensive. Sometimes a new person took over the channel and brought their preferred tool with them. Occasionally it is a deliverability problem that someone decided to solve by changing vendors, which rarely works but happens constantly. And a fair share of moves are just a company outgrowing a list-based tool and wanting event-driven flows instead.

The five fields that change, and the order they move in

Return-Path goes first. It is the bounce address, and it has to point at infrastructure the new vendor controls, because the new vendor is the one that needs to process the bounces. When a brand moves from Mailchimp to Klaviyo, the Return-Path stops resolving to a Mailchimp bounce domain and starts resolving to a Klaviyo one, usually on a subdomain of the brand's own domain if they set it up properly.

The DKIM signature moves next, and it moves in two parts. The d= value names the signing domain and the s= value names the selector. A new vendor publishes its own key under its own selector, so both shift together on a genuine migration. This pair is the most reliable thing in the entire header block, because the signature has to verify against a real published key or the mail gets treated as unauthenticated. Nobody fakes it and nobody strips it.

List-Unsubscribe changes host at roughly the same time, and since RFC 8058 one-click became a practical requirement for bulk senders, the POST endpoint in List-Unsubscribe-Post points at the new vendor too. Tracking links change last, or nearly last. Click-through URLs run through a CNAME the vendor owns, so the redirect host in the anchor tags flips from one vendor's click domain to another's.

Vendor X-headers are the fifth field. They are also the one everybody looks at first, which is a mistake.

Why the vendor X-header is the weakest signal

Our ESP detector reads about 21 vendor-specific X-headers, including X-MC-User for Mailchimp, X-SG-EID for SendGrid, plus X-Klaviyo, X-Braze, X-Marketo, X-HubSpot, X-ConvertKit, X-Amazon-SES, X-Pardot, X-Customer-io and the rest. Between those, X-Mailer, Return-Path and List-Unsubscribe, it resolves 14 platforms by name.

Here is the position we hold that most header guides do not: the X-header is the least trustworthy of the five, and it should never be the field you rely on. It is optional. The vendor adds it as a convenience, nothing in the mail standards requires it, and enterprise configurations strip or rename it all the time. Marketo and Pardot instances on heavily customised sending domains routinely arrive with no identifying X-header at all. An absent X-header tells you nothing about which platform sent the mail.

Return-Path and the DKIM selector are the opposite. They exist because the mail has to work. Bounces have to go somewhere. Signatures have to verify. A vendor can hide its branding but it cannot hide the infrastructure the message depends on. So when those two disagree with the X-header, believe the infrastructure.

The migration wobble: what a half-switched sender looks like

This is where per-send storage earns its place. Our detector writes two values for every newsletter it processes, sending_platform and sending_platform_confidence, and because they are stored per send rather than per sender, every brand has a platform timeline rather than a single label. A migration is not a value in that timeline. It is a shape.

The shape looks like this. For months the sends resolve cleanly to one platform at high confidence. Then a handful of sends come through where Return-Path has already moved to a new bounce domain, the DKIM selector is new, and no vendor X-header matches anything the detector knows. Confidence drops to medium, or to nothing at all. A few sends later a new X-header appears and confidence climbs back up under a different platform name.

That dip is the migration. The detector is not failing during those sends, it is reporting honestly that the infrastructure moved before the vendor's optional labelling caught up. If you only ever looked at the current platform value, you would see Mailchimp one month and Klaviyo the next and miss the interesting part, which is exactly when the change happened and how long the brand ran in a mixed state.

One caveat that trips people up constantly. A brand showing two platforms at once is often not mid-migration at all. Transactional mail on Amazon SES alongside campaigns on Klaviyo is a deliberate and completely normal architecture. Receipts and password resets have different volume patterns and different reputation needs than a weekly newsletter, so plenty of teams keep them apart on purpose. Before you call something a migration, check whether the two platforms are sending different kinds of mail.

How to tell if a company switched ESP by hand

You do not need a tool for a one-off check. In Gmail, open the message, hit the three-dot menu and choose Show original. In Apple Mail it is View, then Message, then All Headers. Outlook buries it under File and Properties, where it will show you an internet headers box roughly four lines tall that you will want to paste somewhere else immediately.

Record five things per send and nothing more: the send date, the Return-Path domain, the DKIM d= and s= values, the first vendor X-header that appears, and the List-Unsubscribe host. Do that for an old message and a recent one. If Return-Path and the selector both changed, you have your answer, and the date range between the two messages brackets when it happened.

Pull a third and fourth message from between those dates if you want the actual switch date. This is the part where subscribing to competitors early pays off, because you cannot go back and collect headers you never received. Our guide on how to spot which ESP a competitor uses from the email alone covers the per-vendor signal details, and the free method and tool walkthrough goes further on the manual process.

What a switch does not tell you

A migration is a fact about plumbing. People love to read it as a story about trouble, and the headers do not support that reading.

It is not evidence of a deliverability problem. Companies move platforms for renewal pricing, for an integration they need, or because someone new took over. It is not a spending signal either, in either direction. A move from Mailchimp to Braze suggests a bigger budget, a move to ConvertKit might mean a smaller one, and both guesses are wrong often enough that you should not build anything on them. It is not a headcount signal at all.

The honest cost of header-based detection is that it sees the pipe and not the reason. You get precise timing and a reliable before-and-after, and you get no insight whatsoever into why. Anyone selling you a narrative about a competitor's email crisis on the basis of a Return-Path change is inventing the interesting half. If you want the why, watch what changed in the sends themselves: cadence, segmentation, whether the flows got smarter. That is the part that shows a team's intent, and it is the reason we built the market data on which ESPs top newsletters use around behaviour rather than logos.

Turning one observation into a habit

A single check is a curiosity. The value shows up when you have a year of headers from the same senders, because then a switch is not a discovery, it is a dated event you can line up against everything else that changed.

Start narrow. Pick the six or seven senders you genuinely care about, subscribe with an address you keep clean, and let the archive build. Once a quarter, run the five-field check against the oldest and newest message from each and note anything that moved. That is maybe twenty minutes a quarter done by hand. If you would rather not do it by hand, that timeline is what platform-level tracking is for, and the comparison against MailCharts covers how the archived-history approach differs from a snapshot-based one. Terminology on any of the header fields lives in the glossary.

The one thing worth doing today: go find the oldest email you still have from a competitor, open the original, and write down its Return-Path. You will need that line in six months and you cannot go back and get it.

Frequently asked questions

How can I tell if a company changed its email service provider?

Compare the headers of an old send against a recent one. The Return-Path domain and the DKIM signature's d= and s= values are the two fields that must change when the sending vendor changes, because bounces have to route somewhere and the signature has to verify against a published key. If both moved between two sends, the company changed platforms. A new vendor X-header confirms it, but its absence proves nothing.

Which email header shows the ESP?

There is no single field. Vendor-specific X-headers such as X-MC-User for Mailchimp, X-SG-EID for SendGrid, X-Klaviyo, X-Braze and X-Marketo name the platform directly when they are present. Return-Path, the DKIM d= domain, the List-Unsubscribe host and the tracking-link CNAME identify the vendor indirectly and are far harder to remove. Our detector reads all of them together rather than trusting any one.

Does a DKIM selector change mean an ESP migration?

Usually, but not always. A new vendor signs with its own selector, so a selector change is a strong signal. Key rotation inside the same platform also changes the selector while the d= domain stays put. Check the d= value and the Return-Path together. If the selector moved and both of those stayed identical, it was a rotation, not a migration.

Can a brand use two ESPs at once?

Yes, and it is common. Plenty of companies run transactional mail through Amazon SES or SendGrid while campaigns go out from Klaviyo, Braze or Mailchimp. Receipts and password resets follow a different path from the weekly newsletter. Two platforms on one domain is a normal architecture, not a half-finished migration.

How long does an ESP migration take to show up in headers?

The first production send from the new account already carries the new headers, which is often weeks before new templates ship or anything is announced. What varies is how long the mixed state lasts. Some senders flip everything in one weekend, others run both platforms for a quarter while they move flows across one at a time.

Related reading