We mapped Klaviyo's sending infrastructure

1. There are two networks, not one

Klaviyo is usually described as sending through SendGrid. That is half true. Reverse DNS across their space shows two entirely separate sending networks:

• SendGrid space. Hosts named oNNNN.shared.klaviyomail.com. We probed o1 through o2499 and found 152 live nodes, all inside o1000-o1499, spread across 71 different /24 blocks.
• Klaviyo's own network. 170.203.16.0/20, where shared addresses resolve under kmta.shared.klaviyomail.com. 3,186 shared addresses, which is twenty times the SendGrid footprint.

3,338 shared addresses in total. Any tool that only knows the oNNNNnamespace is looking at 5% of Klaviyo's sending surface. We made that mistake ourselves and it caused a real misclassification: a customer on Klaviyo's own network was reported as having a dedicated IP, which is the opposite of the truth.

2. Dedicated IPs name their customer in public DNS

Inside the same /20, dedicated addresses do not resolve to Klaviyo. They resolve to the customer, in the form kl-203-25-10.k3.mail.horze.com. That makes the dedicated customer list enumerable: 876 addresses naming 287 distinct brands.

Klaviyo requires roughly a million marketing emails a month plus an enterprise plan before a dedicated IP is on the table. Those 287 brands are therefore close to the entire population that has an exit from shared sending. Everyone else does not have one, whatever their deliverability looks like.

3. Rotation is per send, so the IP is noise and the pool is the signal

A brand does not have an IP. In our data a single sender routinely uses a different address on consecutive campaigns, and several used three distinct addresses on one day. The meaningful object is the set a sender draws from.

This is why “check your sending IP” — the advice that replaced Google's reputation dashboards when they were deleted on 31 October 2025 — is close to useless for a Klaviyo sender taken literally. One header gives you one address out of a dozen.

4. Pool membership is not in DNS. We checked twice.

It would be very convenient if pools were contiguous in the address space, or encoded somewhere public. They are not.

• One brand's addresses spanned six different /24 blocks, so the namespace tells you nothing about grouping.
• Every Klaviyo customer on the SendGrid network publishes the identical DKIM CNAME target, kl2.domainkey.u161779.wl030.sendgrid.net. That is Klaviyo's own SendGrid account. It identifies Klaviyo and nothing finer.
• Customers on Klaviyo's own network chain instead to mtd1._domainkey.<id>.klaviyodns.com, where the id is a per-customer number. That zone carries a DKIM key and a generic SPF include. No pool, no addresses.

Useful side effect: two DNS queries identify any Klaviyo customer and tell you which of the two networks carries their mail. Measured against senders we had already confirmed from received mail, that detector runs at 82% recall with a 3.8% false positive rate.

Pool membership appears in received mail or nowhere. That is inconvenient, and it is the finding.

5. What received mail shows

Panel mailboxes subscribe to public newsletters and the headers are read. Over 29 months: 20,894 Klaviyo campaigns from 184 brands across 311 addresses.

294 of those 311 addresses carried more than one brand. The busiest single address carried 58 separate companies. Every one of them is averaged into the same reputation by every receiver that judges the IP, and none of them was told the others were there.

Grouping brands by how much their address sets overlap recovers 9 distinct pools containing 65 named brands. They are published in full. Another 99 brands had enough observed sends to test and matched no pool, and 20 more have been seen too rarely to judge. The honest reading of any pool below is “at least these brands”, never “only these”.

6. The thing we could not measure

We wanted to detect the moment Klaviyo moves a sender between pools. It is the most valuable event in this whole space: a pool move is a verdict Klaviyo has passed on your sending, delivered silently.

Our detector found a change for 22% of testable brands, which looked like a product. So we tested it against nonsense: same brands, same dates, same addresses, but the link between date and address destroyed by shuffling. Any “change” found in that data is sampling noise by construction.

The cause is structural rather than a bad threshold. A panel sees a fraction of any sender's campaigns. Two samples drawn from one unchanged pool of twenty addresses already share almost nothing, so “the set changed” and “we looked twice” are indistinguishable.

A sampling panel cannot detect a pool move. Only complete data can, which means DMARC aggregate reports, which means the sender has to opt in. We removed the feature rather than ship it. If you see a product claiming to alert you when your ESP moves you, and it is not reading your own DMARC reports, ask what it tested against.

Method, and how to check it

Infrastructure figures come from reverse DNS across Klaviyo's ranges, repeatable by anyone in minutes. Sending observations come from the Received: headers of campaigns delivered to mailboxes we own and read, subscribed to public newsletters — the same method Milled and MailCharts have used commercially for years. Headers only: no message bodies are fetched, so no images load and no tracking pixels fire.

We publish which address carried which brand's mail, by day. We do not publish how much anyone sends, when exactly, or where their mail landed. Adjacency on shared infrastructure is a fact about the infrastructure. Performance belongs to the sender.

A brand that would rather not appear is removed on request, same day.