Buzzmark Is Opening a Second Sending Location in the Netherlands

Right now, every message Buzzmark delivers leaves from the same place: our servers in Spain. That setup has served us well, and it is where we recently doubled our sending capacity. But however many servers you put in one location, it is still one location.

In December 2026 we are opening a second one, in the Netherlands.

Why a second location#

Adding servers in the same place buys you two things: headroom, and protection against any single machine failing. It does not protect you against the things those machines share. Servers in one site sit behind the same power feeds, the same building network, the same upstream connections and the same provider's maintenance calendar. A rare but real class of incident can touch all of them at once.

A second site, with a different provider and its own network, changes that in a few concrete ways:

• Site-level failure. If one location becomes unreachable, the other keeps delivering. Mail queues briefly on the affected side and the rest of the fleet carries the load.
• Network path diversity. The two sites reach the internet through different providers and different upstream networks. A routing problem between one network and a large mailbox provider no longer takes out every path we have to it.
• Maintenance without trade-offs. We can take a whole site's worth of capacity out for upgrades and still deliver at full pace from the other.
• Reputation isolation. Sending IPs at the two sites live on separate networks. A listing or throttle that catches a range at one location has no effect on the other, and the allocator simply leans on the healthy side while we sort it out.

None of this is a response to a problem. It is the next sensible step after doubling capacity: first make one location bigger, then stop depending on one location.

How we choose where to run#

Buzzmark runs on hand-selected EU cloud providers rather than on hardware we rack ourselves. That is a deliberate choice. It lets us scale our infrastructure in real time, adding capacity where and when it is needed, so the service is always available. It also means that when we want a second location, we can pick a second provider on its own merits rather than being tied to wherever the first one happens to operate.

The Netherlands site is with a different provider from the Spanish one. That is the point.

Why the Netherlands#

It is still the EU. This matters to a lot of the people who choose Buzzmark, so we will say it plainly: nothing about where your data is handled changes. Spain and the Netherlands are both EU member states under the same data protection law. Your messages are processed, logged and stored inside the EU, exactly as they are today. Delivered mail goes wherever your recipients' mailboxes are, as it always has. The infrastructure that handles it, and the data we keep about it, stays here.

It is very well connected. Amsterdam is home to one of the largest internet exchanges in the world, and sits on short, fast paths to the mailbox providers that handle most European inboxes.

It is far enough away, and close enough. The two sites are independent in every way that counts, from power grids to national networks, while staying within one legal and regulatory environment.

What is being built#

For now, the Netherlands site is a sending site: egress relays and a new set of sending IPs that join the same pool the Spanish fleet uses today. The allocator that assigns an IP to each message already balances across every node that reports in, so adding a second location is, mechanically, adding more nodes to the same pool.

Over time it will grow into a full failover location. Inbound mail and the other roles the Spanish site handles today will get a second home in the Netherlands, so that any part of the service can run from either country if it has to.

What does not change is everything upstream of that. Your application keeps talking to the same API and the same SMTP endpoint. Every message is still logged, checked against your suppression list, tracked and DKIM-signed by the same pipeline before it is handed to whichever relay the allocator chooses. You will not know, or need to know, which country a given message left from.

Each new IP gets the usual groundwork before it sends anything: a forward DNS record, a matching reverse record, and a HELO name that agrees with both. Then it goes through the same warmup process as any new address we add. A small, capped share of real traffic at first, a daily limit that grows step by step, and an automatic pause if the bounce rate for the day crosses our threshold.

Timeline#

• Now until the end of November. Provisioning, DNS, monitoring, and internal test traffic.
• December 2026. The Netherlands site goes live and begins carrying a small share of customer mail as its IPs warm.
• Early 2027. Warmup complete. Both locations carry a normal share of traffic, and either can carry all of it if it has to.

What you need to do#

Almost certainly nothing. Same API, same SMTP endpoint, same tokens, same dashboard.

The one thing to check is your SPF record. If your domain authorises Buzzmark with include:spf.buzzmarkapp.com, as the dashboard instructs, you are covered. We maintain that record and the Netherlands IPs will be in it before they send a single message.

If you copied our IP addresses directly into your own SPF record, please switch to the include before December. Otherwise mail leaving from the new location will fail SPF for your domain.

DKIM is unaffected. Your mail is signed with your domain's key regardless of which IP, or which country, it leaves from. Your Return-Path CNAME is unaffected too.

Looking further ahead#

Two locations is the right shape for Buzzmark for the foreseeable future. We would rather run two sites very well than spread ourselves across five. The work after December is depth rather than breadth: bringing inbound and the rest of the service to the Netherlands so that each location can stand in fully for the other.

As the new site settles in, we will share what we learn from running mail across two countries, and what it does to delivery times and bounce rates in practice.

If you have questions about where your mail is handled, or how the two sites will share your traffic, get in touch. We are happy to go into as much detail as you like.