About

Why we run our own mail servers

Most transactional email providers are a good interface on top of infrastructure they rent. That arrangement decides what they are able to tell you, and it is the reason this exists.

The problem we kept hitting

Every provider shows you a status. Sent. Delivered. Bounced. None of them show you the conversation that produced it — the receiving server’s response code, its diagnostic text, why a retry was scheduled instead of a failure recorded.

When your password reset does not arrive, a status of “delivered” is not an answer. It is the beginning of a support ticket that ends, days later, with somebody pasting you a log line they could have shown you at the start.

They mostly cannot show you because they do not have it. The conversation happened on infrastructure they rent, and what comes back to them is a summary. You can only hand somebody the receiving server’s own words if you were the one talking to it.

So we own the pipe

Posthaste runs its own mail transfer agent on its own IP. We accept your API call, check it, sign it with your domain’s key, open a connection to the recipient’s mail server and conduct the conversation ourselves. Then we keep the transcript and hand it to you.

That decision costs us things. Reputation has to be built from zero rather than inherited. Retry logic, bounce parsing and warmup are our responsibility instead of somebody else’s problem. We took it anyway, because the alternative is a product that structurally cannot deliver on its own pitch.

Where the product actually is

In private testing. The sending path, the bounce loop, signed webhooks and the delivery record are built and tested. The dashboard is not built yet. The sending IP is new, which means placement is a work in progress and the warmup ladder is deliberately conservative.

We would rather say that plainly than imply a maturity we do not have. If you need an audited provider with years of IP reputation today, we are not that yet — see security for exactly what is and is not true.

What we will not build

Who is behind it

A very small team — currently one engineer building it in the open, with the architecture decisions written down as they are made rather than reconstructed afterwards. If you want to know why something works the way it does, ask and you will get the actual reason.

Get in touch if you want early access, or if you have been burned by an email provider and want to tell us what it should have done instead. The second one is genuinely useful.