What Email Infrastructure Does, and What It Cannot Decide

Email infrastructure is everything a message needs in order to leave your building and be accepted by the receiving server: sending domains, mailboxes, the DNS records that authenticate them, the server or relay that transmits, and the reputation all of it accumulates. It is the layer under the decision, and it settles one question only — whether a message can arrive.

The disclosure first. We build Keaz Signals, which sells buying signals and contacts for ecommerce outreach. We sell none of the layer this article is about. No mailboxes, no domains, no SMTP, no warmup, no sequence engine, and none planned. Our customers send through Instantly, in their own workspace, on their own domains.

The term covers more than most buyers expect when they start shopping for it. A team that says it needs email infrastructure usually means it needs somewhere to send from. What it is actually acquiring is a set of DNS records, a set of addresses, and a reputation — and only the first of those can be configured in an afternoon.

A sending setup has four parts, and they fail in different ways. Domains carry the identity you send as. Mailboxes are the addresses that send. Authentication is the DNS layer that proves the two belong together. Reputation is what receiving servers have learned about all of it over time, and it is the only part you cannot buy.

• Domains. Usually secondary domains bought so that the primary one is not exposed to cold sending. Each one starts with no history at all.
• Mailboxes. The individual addresses on those domains, each with its own daily ceiling. Capacity is a count of mailboxes, not a setting.
• Authentication and DNS. SPF, DKIM, DMARC, and the forward and reverse records that tie a sending IP to a hostname. This is the part with a right answer.
• Reputation and warmup. Accumulated, per domain and per IP, from how recipients have responded. It takes weeks to build and one bad campaign to spend.

The first three are procurement and configuration. The fourth is a consequence — of who you wrote to, and whether they wanted to hear from you. Buying more of the first three does not produce the fourth, which is where most of the confusion in this category lives.

Google's sender guidelines are the closest thing this layer has to a published specification, and they are short. Every sender to personal Gmail accounts must set up SPF or DKIM, give sending domains or IPs valid forward and reverse DNS records, transmit over TLS, format messages to RFC 5322, and keep the spam rate below 0.3% (retrieved 15 September 2026).

Above 5,000 messages a day the list grows: SPF and DKIM both, a DMARC record — the policy may be set to none — alignment between the From: domain and the authenticated domain, and one-click unsubscribe on marketing and subscribed messages. The document also states plainly that the public IP of a sending server must have a PTR record resolving to a hostname, and that hostname an A or AAAA record resolving back to the same address.

What the three records prove, and what they do not, is worth reading separately; we worked through it in SPF, DKIM and DMARC: What the Three Records Actually Prove. The short version is that authentication proves a message came from where it claims to come from. It says nothing about whether the message was welcome.

The infrastructure layer stops at the envelope. It can prove who sent a message, carry it over an encrypted connection and pace its delivery. It cannot know anything about the company receiving it — not that the store started running Meta ads on Tuesday, installed Klaviyo last week or rebuilt its storefront. Those facts live outside the mailbox entirely.

The clearest evidence for where the boundary sits is in the same Google article as the DNS requirements. Under sending practices it says:

Don't purchase email addresses from other companies.

Don't send messages to people who didn't sign up to get messages from you. These recipients might mark your messages as spam, and future messages to these recipients will be marked as spam.

Those two lines sit alongside the SPF and DKIM requirements because they govern the same outcome. Spam rate is the number the whole category orbits, and recipients produce it. Configuration stops you being rejected; it does not stop you being reported. That is a structural point about where each layer's authority ends, not a claim about anyone's compliance.

Infrastructure gets rebuilt after a bad campaign because it is the only part of the stack with a visible fault line. Deferrals, bounces, a reputation graph turning amber: the sending layer produces all of the numbers, so when results disappoint, the layer that reported the problem looks like the layer that caused it.

It is also the cheapest thing to change. Buying eight more domains and forty more mailboxes is an afternoon and an invoice, with a clear before and after. Rebuilding how you choose which stores to contact has no equivalent moment, no receipt and nothing to put in a status update. So the fixable thing gets fixed and the expensive thing stays where it was.

The throughput version of this scales fastest — more mailboxes, more volume, same list. We took that apart in A Bulk Email Sender Solves Throughput, Not Timing, and the mailbox-count version of the same mistake in Gmail Multiple Inboxes Is Not Sending Capacity. Both end in the same place: a wider pipe pointed at the same list delivers the same message to more people who did not want it, and does so faster.

Choosing infrastructure and running it are two different jobs, and conflating them is why the shopping goes wrong. Choosing is a procurement question answered once: how many domains, which registrar, own SMTP or a provider, how many mailboxes per domain. Running it is continuous: watching reputation, pacing volume, retiring a domain that has been burned.

The choosing question has a boring answer for most agencies. Unless you have a specific reason to run your own relay, a provider gives you authentication that is already correct, IP hygiene somebody else maintains, and a support path when a receiving server starts deferring. Running your own is worth it when volume or control justifies a person's ongoing attention, and not before.

The running question is where measurement matters, and the tooling has real limits — what it can and cannot see is the subject of What Email Deliverability Tools Can and Cannot Tell You, and reading the one first-party source properly is covered in Reading Google Postmaster Tools for a Cold Email Domain.

We sit above this layer and sell none of it. No domains, no mailboxes, no SMTP relay, no warmup pool, no sequence engine — and none are planned. If you have no sending setup at all, you have an infrastructure problem first, and nothing on this site solves it. Buy that, then come back.

What we sell is the layer above: which stores are worth contacting this week, with contacts attached. Sending runs through Instantly, in your own workspace, on your own domains, with campaign status and replies syncing back. That is a deliberate boundary. Owning your own sending means the reputation you build stays yours, and so does the responsibility for it.

The rest of where we lose, plainly. We do not export: leads move into campaigns and stay there, which for some teams is a dealbreaker and should be. There are no LinkedIn signals and no LinkedIn sending, and none are planned. We watch Shopify and WooCommerce stores in Europe and North America, and nothing else. Registry, firmographic and hiring triggers are marked planned on our own site, which means they do not exist yet. We are GDPR-conscious by design and will not claim more than that; responsibility for what you send stays with you. The tool layer next to ours is covered in Cold Email Software Is Not a Lead Source.

We are not going to tell you how many domains or mailboxes you need. The honest answer depends on your daily volume, your offer and your reply handling, and we have not run the experiment that would let us publish a ratio. A number here would be a preference wearing arithmetic, and it would travel much further than the caveat attached to it.

We are also not going to tell you how much a signal-led list improves deliverability. It is the claim this article is closest to being able to make, and we cannot make it: that would need the same team, same offer, same domains, same week, one variable changed. We did not measure it.

And we make no deliverability or reply-rate promises of any kind. Your domains, your mailboxes and your sending reputation are yours. A better list does not make a misconfigured domain deliver, and a well-configured domain does not make an unwanted message welcome. The refusal is the point rather than an aside: the claim we cannot support is exactly the one this category is loudest about.

Wired together, the infrastructure carries and the layer above decides. A segment defines the kind of store you sell to. A signal decides which of those stores is worth writing to this week. The message is built from that signal, and only then does the sending setup do its job.

As of September 2026 we watch 4.1 million Shopify and WooCommerce stores, re-scraped weekly, and roughly 41,200 carried a fresh signal in the last seven days. Those are our own figures and they move, which is why they are dated. The buying signal catalogue lists what we watch for, and the ecommerce leads database is where those stores arrive with contacts attached.

Our AI sales agent writes the per-store copy from the signal. The campaign then runs on your infrastructure, not ours.

• Email sender guidelines, Gmail Help — authentication, DNS, TLS, spam-rate and sending-practice requirements, retrieved 15 September 2026
• Keaz Signals store coverage and weekly signal counts — our own figures, as of September 2026
• Keaz Signals product scope, including what is not shipped — our own buying signal catalogue, retrieved 15 September 2026