SMTP Server: What Breaks First When You Scale Sends

A team that has been sending 500 cold emails a week from five mailboxes decides to go to 5,000. They buy more domains, spin up more mailboxes, and the campaign starts. Two weeks later, delivery is worse than it was at 500. Nothing in the copy changed, nothing in the list changed, and the sending tool reports no errors worth reading. What changed is that a set of limits nobody was near before are now the thing deciding how many messages arrive.

Most of those limits sit at the SMTP layer, and almost none of them announce themselves. This is what an SMTP server actually is in a cold email stack, which of the four different things people call one you are probably running, and what each of them does first when volume climbs.

Four different things get called an SMTP server

The protocol is defined in RFC 5321, and it describes a conversation rather than a product: a client connects, identifies itself, names an envelope sender with MAIL FROM, names recipients with RCPT TO, and hands over the message. Any software on either side of that conversation can be called an SMTP server, which is why the phrase means four different things depending on who says it.

Your mailbox provider's submission server. smtp.gmail.com or smtp.office365.com. You authenticate as a user and the provider sends on your behalf. This is what almost every cold email tool is using when you paste in a mailbox.

A relay or transactional service. Brevo, Mailjet, SMTP2GO, Amazon SES. You authenticate as an account rather than a person, and the service sends from its own infrastructure. Built for password resets and receipts.

Mail server software you run yourself. Postfix, hMailServer, Xeams, Exim. You own the machine, the IP address, and every reputation consequence that follows.

The receiving side. The MX host that accepts mail for a domain. When somebody says a message was rejected by the SMTP server, this is usually the one they mean.

These are not interchangeable, and the differences only start to matter at volume. At five mailboxes any of them appears to work.

1. Step 1Your sending tool

   Authenticates to a submission server as the mailbox owner, usually on port 587

2. Step 2Submission server

   Applies per-user and per-account limits, then queues the message

3. Step 3Sending MTA

   Opens a connection to the recipient domain's MX host on port 25

4. Step 4Receiving filter

   Checks authentication, reputation and content, then accepts, defers or rejects

5. Step 5Mailbox

   Inbox or spam, decided by the receiver, not by the sender

Ports, and the one that is probably blocked

Port 587 is submission: an authenticated client handing a message to a server that will send it onward. Port 465 is the same job over an implicit TLS connection. Port 25 is server to server, which is the hop your provider makes on your behalf.

If you were planning to run your own mail server on a cloud instance, port 25 is where that plan meets reality. AWS documents that it blocks outbound traffic on port 25 for all EC2 instances by default and requires a request to lift the restriction. Other cloud providers apply similar defaults. The block exists because a fresh cloud IP with no sending history is what spam operations are made of, which is the same reason a fresh IP delivers badly even after the block is lifted.

The limits that appear between 1,000 and 10,000 a day

Per-user and per-account sending limits. These are provider policy rather than protocol, and they are usually the first hard stop. Google's own documentation for its SMTP relay service publishes a limit of 10,000 messages per user in a 24 hour period and 10,000 unique recipients per user in the same window, plus a 100 recipient limit per SMTP transaction against smtp-relay.gmail.com. Exceeding one returns an SMTP error rather than a silent drop, which is the good case. The published limits for ordinary Workspace and Microsoft 365 mailboxes are different again, and we have written those up in full in email sending limits by provider.

Authentication requirements that change at a volume threshold. Google's sender guidelines set a floor for everyone and a stricter set for anyone sending more than 5,000 messages a day to Gmail accounts: SPF and DKIM and DMARC on the sending domain, valid forward and reverse DNS, TLS in transit, and spam rates reported in Postmaster Tools kept below 0.30%. A stack that was compliant at 1,000 a day can be out of compliance at 6,000 without anybody touching the DNS. The setup itself is covered in SPF, DKIM and DMARC for cold email.

Reputation, which is counted per domain rather than per account. Google's Postmaster Tools documentation notes that the domain reputation dashboard only displays messages sent from the exact domain used for DKIM and SPF authentication. Split your sending across eight domains and you have eight reputations, each built and damaged separately. That is the mechanism behind running a pool rather than a single hard-working domain, and it is why domain reputation is the number that actually gates a cold email programme.

Throttling, which looks like an error and is not one. Google describes temporary failures plainly: temp fails are a throttling tool intended to slow down sending rates. A well built sending tool backs off and retries. A badly built one treats the deferral as a bounce and burns a good address. Email throttling is the receiver managing you, and the correct response is to send less, not to retry harder.

What scaling actually does to results

Volume is not free even when every message is delivered. Our own published cold email benchmark report, built from 1,413,405 sends across 356 campaigns, groups campaigns into cohorts by their own send volume. Campaigns sending between 500 and 2,000 messages returned a human reply rate of 0.88%. Campaigns sending 25,000 or more returned 0.33%.

That gap is not primarily a deliverability effect. Bigger campaigns reach further down a list, into companies that fit the profile less well and people who are a worse match for the offer. The practical reading is that adding sending capacity does not add proportional replies, and a stack sized for a number nobody has justified is expensive in a way the invoice does not show.

Mailbox providersGoogle Workspace, Microsoft 365

• Sends as a real person from a real mailbox
• Per-user limits, and a separate limit per account
• Reputation is per sending domain, so a pool spreads risk
• Replies land in a mailbox somebody can answer

Relay or transactional serviceSES, Brevo, Mailjet, SMTP2GO

• Built for receipts and resets, priced per thousand
• High throughput on shared or dedicated IPs
• Acceptable-use terms that usually exclude cold outreach
• Reply handling is your problem to build

Your own mail serverPostfix, hMailServer, Exim

• Full control of the queue and the headers
• Port 25 blocked by default on major clouds
• You own PTR records, IP warmup and every blocklist listing
• No support to escalate to when a receiver stops accepting

The question that decides which server you need

Ask what happens after somebody replies. A transactional relay is built to push messages out at high throughput and has no opinion about the answer coming back, because password reset emails do not get answered. Cold outbound is the opposite shape: the entire value of the send is the reply, and the reply has to arrive somewhere a person reads and can respond from, under an address the recipient will recognise if they check.

That single requirement rules out most of the relay category before price or throughput enters the discussion. It also explains why acceptable-use terms at transactional services generally exclude unsolicited outreach. They are not being squeamish. A relay pools many customers behind shared sending infrastructure, so one customer's complaint rate lands on everyone else's delivery, and cold outreach carries a complaint profile that a receipts pipeline does not.

Reading SMTP errors instead of guessing

The protocol is unusually honest for something people find opaque. A 4xx response is temporary and the sending server should retry. A 5xx response is permanent and the address or the policy will not change on a retry. The text after the code is written by the receiving organisation and frequently names the actual reason: a blocklist, a missing PTR record, a policy against the content, or a mailbox that no longer exists.

Two habits are worth more than any tool here. Read the full text of a rejection rather than the classification your sending platform applied to it, because platforms compress several genuinely different failures into the word "bounce". Our benchmark report found that 12.59% of the bounce notifications in that dataset were delay notices rather than failures at all, which is enough to move a bounce rate from acceptable to alarming for no real reason. And check whether the failure is concentrated in one receiving organisation, which points at a filter, or spread evenly, which points at your own setup. The mechanics of that read are in email blacklist checks and recovery.

Before adding sending capacity

• ✓Yes: You know which of the four SMTP roles your stack actually uses
• ✓Yes: SPF, DKIM and DMARC are aligned on every sending domain, not just the main one
• ✓Yes: Forward and reverse DNS resolve for every sending host
• ✓Yes: You can see spam rate per domain rather than one blended number
• ✓Yes: Your tool backs off on 4xx deferrals instead of retrying immediately
• ✓Yes: Somebody reads and answers replies the same day they arrive
• ~Depends: The volume target is derived from a pipeline number rather than a round figure

The shape that holds

The stack that survives scale is a lot of ordinary mailboxes sending modest volumes from separate authenticated domains, rather than one server sending hard. It costs more per message than a relay and it is the arrangement receiving filters are least hostile to, because it looks like what it is.

That shape also constrains the campaign design. We run one message per campaign and no follow-up sequences, so the send count is the number of people we are contacting rather than a multiple of it. In the benchmark dataset, 346 of 356 campaigns were single-message, and the reply rate across that subset was statistically indistinguishable from the whole. Capacity planning is simpler when a campaign of 2,000 leads means 2,000 sends.

If you want the arithmetic run against your own list size and offer before you buy anything, we will build the first campaign with you and you can see the numbers on real sends.

Provider limits and pricing verified as of August 2026. Verify current terms with the vendor before relying on them.