Built for reliable delivery.

Deliverability isn’t a feature you switch on. It’s a property of the infrastructure underneath, the reputation of the addresses you send from, and how aggressively abuse is kept off the network. This page describes how Eusend earns it — the authentication we require, the feedback loops that run on every send, and the limits that keep one sender’s mistakes from becoming everyone’s problem. It’s an engineering description, not a claim.

Why an email platform has to say no

An email platform is a shared resource. Mail leaves through a pool of IP addresses whose reputation is built slowly and spent quickly. When mailbox providers see spam, high bounce rates, or complaints from one of those addresses, they don’t isolate the responsible sender — they throttle or block the address itself. Everyone sending through it inherits the damage.

So the most consequential thing the platform does is refuse traffic. No to unverified domains. No to a new account that wants to send a million messages on its first day. No to the sender whose complaint rate has quietly crossed the line. These aren’t obstacles bolted on after the fact — they’re the reason the platform stays deliverable at all.

We’d rather refuse a send than let it degrade delivery for every other customer on the same infrastructure. Everything below is built on that trade.

How Eusend protects deliverability

Every message — whether it enters through the REST API or over SMTP — passes through one pipeline. The same authentication, suppression, reputation, and sending limits apply either way; SMTP is a different door into the same building, not a bypass around it.

Verified senders

You can’t send from a domain until you’ve proven you control it. When you add a domain, Eusend generates a dedicated 2048-bit DKIM key for it and returns the exact DNS records to publish. Sending stays blocked until the DKIM record resolves and verifies.

• DKIM signs every message with a key unique to your domain, so receivers can confirm the mail really came from you and wasn’t altered in transit.
• SPF authorizes our sending infrastructure through an include record. Because it’s an include, our IP changes never require you to touch your DNS again.
• DMARC ties the two together and tells receivers what to do with mail that fails authentication. We guide you to start at p=none to observe, then tighten to quarantine and reject once your authentication is confirmed aligned.

Automatic suppression

Every send is checked against your suppression list first. Two things put an address there automatically — and once an address is suppressed, Eusend will not send to it again.

• Hard bounces. A permanent rejection — the mailbox doesn’t exist, the domain doesn’t resolve — means the address is dead. Continuing to send to it is the fastest way to damage reputation, because providers read repeated bounces as a sign you don’t clean your list. We classify every bounce by its IANA status code, so a permanent failure suppresses the address while a transient one — a full mailbox, a temporary defer — is retried instead of being mistaken for a dead address.
• Spam complaints. When a recipient marks your mail as spam, their provider reports it to us through a feedback loop. That recipient didn’t want your mail; sending again only generates more complaints. The address is suppressed on the first complaint.

Suppressed addresses are never retried — on any send, through the API or SMTP. That permanence is the whole value of the list.

Gradual sender ramp-up

A brand-new domain sending large volume looks exactly like a compromised account or a spammer, because that’s the pattern they follow — and mailbox providers respond by deferring or junking the mail. Reputation is built by sending consistent, wanted mail in growing volume over time, not by opening a firehose.

New accounts start with a conservative daily ceiling. As an account demonstrates healthy sending — low bounces, low complaints, real engagement — that ceiling lifts automatically over roughly the first week. You don’t file a ticket to be trusted; you earn it by sending well. The Free plan is held at a low fixed daily rate by design.

Reputation monitoring

Bounce and complaint rates are computed continuously from your own delivery data, and they gate how much you can send:

• Below roughly 2% bounces and 0.04% complaints, you’re in good standing and your limits continue to ramp.
• Cross those, and your daily ceiling is automatically halved — a brake applied before the damage compounds, not after.
• A sustained bounce rate above 4% or complaint rate above 0.08% over a rolling seven-day window automatically suspends sending.

These numbers aren’t arbitrary; they track the thresholds mailbox providers enforce themselves. Applying them automatically is what catches a degrading sender early — while the fix is still “clean your list,” not “rebuild a burned reputation.”

Shared infrastructure

Most mail goes out through a shared pool of warmed IP addresses. That’s what makes good deliverability available to a new account on day one — you inherit reputation the platform has already built. It also means every safeguard above is protecting the same thing: the reputation of addresses many customers share.

To keep one customer’s risk from becoming another’s, untrusted and free-tier traffic is routed through separate, isolated egress addresses rather than the warmed shared pool — a sender who hasn’t earned trust yet can’t spend reputation that isn’t theirs. Delivery itself is encrypted: outbound mail uses TLS and honors recipients’ MTA-STS and DANE policies, validating certificates when the receiver offers STARTTLS.

Operational principles

• Protect deliverability before maximizing volume. A send we refuse is cheaper than a reputation we can’t rebuild.
• Prefer automatic safeguards over manual intervention. Suppression, limits, and throttling apply the same way at 3am as at noon, with no human in the loop.
• Fail safely. When a check can’t run, the safe default is to hold the send, not to let it through unchecked.
• Keep customers informed. Delivery, bounce, complaint, open, and click events are all exposed as signed webhooks — your systems see what ours see.
• Build for long-term sender reputation. Every default is set for the sender who’s still here in a year, not the one trying to send everything today.

Why we built Eusend

Eusend exists because the existing options asked for one of two compromises. Either you trusted infrastructure that ultimately runs on a US cloud — with the legal exposure that carries for European data — or you accepted an abstraction so thick that the actual email stack, the part that determines whether mail arrives, was someone else’s black box.

We run our own mail infrastructure, in the EU, rather than forwarding requests to another provider’s API. That’s more work, and it means deliverability is ours to solve rather than something we’ve outsourced. But it also means we can see the entire delivery pipeline — the SMTP conversation with the receiving server, the reason a message deferred, the reputation of each egress address — and make engineering decisions based on what we observe. When something goes wrong in delivery, we look at the layer where it happened instead of opening a ticket with a provider we’re built on top of.

Owning the stack is the point. It’s what lets everything on this page be a design decision rather than a setting we hope an upstream honors.