We've doubled our sending infrastructure in Spain

Transactional email is the mail people are actually waiting for: the password reset, the receipt, the magic link, the "your order has shipped". Nobody notices when it arrives in two seconds. Everybody notices when it doesn't arrive at all.

So the thing we care about most on the sending side is not raw speed or headline volume. It is predictability. We have just finished a project that is entirely about that: we doubled the size of the infrastructure that delivers Buzzmark mail.

You don't need to do anything. There is one quick check worth making, which we cover at the end.

What we added#

Buzzmark splits mail delivery into three separate jobs, each on its own machines:

• Submission. Where your application connects, either through the REST API or over SMTP on port 587 with your hive token.
• Egress relays. The servers that take your processed, signed message and deliver it to the recipient's mail server, from one of the IPs in our sending pool.
• Inbound MX. The servers that receive mail for your domains and bounce reports for ours.

The doubling is on the sending side. There are now twice as many egress relay nodes delivering your mail, and twice as many IP addresses in the sending pool for them to send from. All of it runs on dedicated infrastructure in Spain, like the rest of Buzzmark.

Why double it#

Three reasons, and none of them is "we ran out of room".

Headroom. We want the sending fleet to run well below its ceiling at all times. When one customer sends a burst, or a large mailbox provider slows down and mail backs up for a while, that should be absorbed quietly rather than delaying everyone else's queue.

Redundancy. With more nodes, losing one matters less. A hardware fault, a network blip, or a deliberate maintenance window on a single relay is now a smaller fraction of total capacity. We already deploy to one node at a time with the others carrying traffic; this makes that routine even less eventful.

Reputation isolation. Every message is assigned a sending IP by an allocator that load-balances across the whole pool. Spreading the same traffic over more IPs means each one carries less, and if a single IP is throttled or listed somewhere, the slice of mail affected is smaller and the allocator can route around it while we sort it out.

New capacity is not just switched on#

This is the part that took weeks rather than an afternoon.

A brand-new IP address has no reputation. Mailbox providers treat a sudden stream of mail from an unknown address with suspicion, and they are right to. If we had simply pointed half of all traffic at new IPs on day one, deliverability would have got worse, not better.

So new IPs enter the pool in a warmup state, and the allocator treats them differently:

• A small, deterministic share of real traffic is routed through warming IPs. Real mail from real senders is the only safe way to build reputation.
• Each warming IP has a daily cap that grows one step at a time along a schedule, and that daily cap is spread across the hours of the day rather than used up at midnight.
• If a warming IP's bounce rate for the day crosses our threshold, it is paused automatically and we take a look before it carries anything else.
• Only once an IP has worked through the full schedule does it become a normal "available" IP carrying an uncapped share of traffic.

Before any of that, every new IP gets the plumbing that receiving servers check first: a forward DNS record, a matching reverse (PTR) record, and a HELO name that agrees with both. No IP sends a single message until that chain is confirmed.

Every node also reports a heartbeat and is probed over SMTP continuously, so we see a sick server before its queue does.

What this means for you#

In day-to-day terms, nothing. Same API, same SMTP endpoint, same tokens, same dashboard, same message log.

The one thing worth checking is your SPF record.

If your domain's SPF record authorises Buzzmark the way the dashboard told you to, with include:spf.buzzmarkapp.com, you are already covered. We maintain that record, and the new IPs were added to it before they carried any mail.

If instead you copied our IP addresses directly into your own SPF record, please switch to the include. Mail sent from the new IPs will otherwise fail SPF for your domain, and as the fleet changes over time that record will keep drifting out of date.

DKIM is unaffected either way. Your mail is signed with your domain's key, which has nothing to do with which IP the message leaves from. Your Return-Path CNAME is unaffected too.

What's next#

More of the same, deliberately. We intend to keep capacity comfortably ahead of traffic, and to keep IPs warming in the background so that the next time we grow, the addresses are ready before they are needed rather than after.

If you notice anything unusual in your delivery events over the coming weeks, get in touch. We would rather hear about a false alarm than miss a real one.