The Buzzmark Creed

Transactional email is a promise. Every time your app says “we’ve emailed you”, someone is trusting both of us to be right. This page is what we owe you in return - written down, in public, where anyone can check it against reality.

What we hold ourselves to

• Independence is the feature. No investors to please, no exit to engineer. The only people we answer to are the ones whose email we carry.
• Sovereignty isn’t an upsell. Your data lives in the EU, under EU law, on infrastructure we disclose in full - as the foundation, not a premium tier.
• Show, don’t promise. Our status page is computed by machines from live monitoring, our infrastructure is published, and our incident reports name what actually broke.
• The inbox is the only metric. Warmed IPs, automatic suppression and managed reputation aren’t add-ons - they are the product, on every plan.
• We’ll take the hard loss. We refuse sends to suppressed addresses even though it costs us volume, because your sender reputation outlasts any single campaign.
• Every feature, every plan. You pay for volume, not for permission. Nothing on the feature list waits behind a sales call.

Why we bother

Most of the email the internet’s apps depend on now flows through a very short list of very large companies, and a decade of consolidation has not been kind to senders: features drifted behind sales calls, deliverability became a black box, and data ended up governed by courts an ocean away. We don’t intend to out-shout anyone. We intend to out-behave them - an independent, Spanish-owned company running email the way we’d want ours run, and proving, sender by sender, that it works.

And this isn’t a newcomer’s manifesto: we’ve been working inside company mailboxes since 2012, on our own platform, our own mail servers and our own MTAs. Read our story - fourteen years of it.

Straight answers to the hard questions

A creed is easy to write. So here are our answers to the questions you should ask any email provider.

Do you publish uptime or a status page?

Yes - and it’s live, not hand-edited. Our public status page is computed from real monitoring data: every sending node reports a heartbeat roughly every 30 seconds, and the page reflects what those heartbeats say right now. There’s also a machine-readable status.json you can poll from your own tooling.

Do you offer dedicated IPs?

Yes, as a paid add-on: €20 / month per dedicated IP, available on any plan, with automated warmup included. On Enterprise plans, dedicated IPs come with managed deliverability support and an uptime SLA.

How do you manage IP warm-up and reputation?

Automatically, and cautiously. A new IP is never thrown straight into full production:

• Graduated schedule. Each warming IP gets a daily sending allowance that grows day by day - starting at a handful of messages and scaling up to full production volume over the schedule.
• Paced through the day. The daily allowance is spread across sending hours with hourly caps, so mailbox providers see a steady drip, not a burst.
• Warmed on real mail. A small, controlled share of live traffic is blended through warming IPs alongside fully-warmed ones - reputation is built on genuine, wanted email, the only kind that builds it.
• Automatic circuit breaker. If a warming IP’s bounce rate spikes above threshold, it is paused for the day - no human needs to catch it.
• Clean lists by default. Hard bounces and complaints are suppressed automatically per server, keeping known-bad addresses off the wire and off your reputation.

What are your redundancy arrangements?

Our sending platform runs on dedicated infrastructure in Spain. Behind it we maintain a fully pre-warmed standby IP range with a second, independent provider in Germany - a separate network, a separate data centre, a separate country.

Crucially, the standby is never cold: a share of live production traffic is routed through it every day, keeping those IPs warm, reputable and continuously proven against real mailbox providers. If the primary platform were ever disrupted, sending shifts to a range that is already delivering - with its reputation intact - rather than to a cold spare that would bounce off spam filters for weeks. Warm-standby beats a redundancy diagram: it’s failover that has already been rehearsed today.

Do you support inbound parsing, webhooks, suppression lists and idempotency?

Yes:

• Inbound parsing. Each server gets an inbound address (or your own domain’s MX); received mail is parsed and forwarded to your webhook, with automatic retries if your endpoint is down.
• Webhooks. Delivery, bounce, open, click and spam-complaint events, delivered with retries and a full per-delivery log so you can see exactly what we sent and when.
• Suppression lists. Per-server, populated automatically on hard bounce and complaint, and enforced at send time - suppressed addresses are blocked before they can hurt your reputation.
• Idempotent pipeline. Sends run through a queued pipeline that is idempotent end to end: an internal retry can never double-send a message.

Hold us to all of it. Watch the status page, read the infrastructure disclosure, and if we ever fall short of anything on this page, tell us: support@buzzmarkapp.com.