Resend Forge

Resend Forge is Resend’s own sending infrastructure.

It improves your emails’ deliverability and speed by sending directly from an infrastructure we control end-to-end, from our own IP blocks all the way up to the API you send a request to.

Here you’ll learn about what it took to build Forge, and how it improves your deliverability and speed. But first, some numbers.

Deliverability is the first thing anyone asks a sending provider about. Ours is good, and we can show the numbers publicly.

The chart below is real Forge traffic from the 7 days ending Sep 30, split by receiving provider. Delivered means their server accepted the message. Bounced means it refused. Every message ends up as one or the other, and this is how they split.

It’s worth noting that bounces include everything the receiver turned away, not only reputation refusals, which we barely have: addresses that don’t exist, mailboxes that are full, and domains that stopped accepting mail.

Numbers this high mean the pool is clean and the senders on it are careful. We keep it that way on both ends because we have suppression lists that stop you from retrying a dead address, and we offer the guidance to keep your lists healthy in the first place.

Those are pool numbers. Every sender on Forge shares them, and any one sender could drag them down. A shared pool is only as good as its worst tenant, and keeping the worst tenant out is a good part of the job, as you will see later.

Speed is more than a vanity metric for transactional email. For example, password resets and magic links only work if they arrive while the user still cares. Ideally, they should arrive before the user even has time to type gmail.com into their browser.

Again, our numbers are really good here and we don’t mind showing them live.

Now, some of these numbers may mean nothing without anything to compare them to. So here is the same measurement over the 7 days ending Sep 30, on the same providers, split by the engine that sent the message: our legacy engine including the third-party provider, and Forge.

What we like most about these numbers is how boring they’ve become. A few months ago we watched them every morning; now we mostly glance at the p99 to make sure nothing is stuck, and the fact that a public page can pull them straight from our monitoring every hour without anyone checking first is probably the best summary of how Forge has been going.

Now that you’ve seen the numbers, the rest of this page is about how we keep them where they are, and, in a way, an explanation of why you can’t vibecode your way to fast and reliable email delivery.

In short, this level of quality is something you keep earning, receiver by receiver, week after week. We earned these numbers after spending months warming up IPs, obsessing over metrics, inspecting logs from different providers, keeping abuse out of the pool, and building relationships with postmasters who can vouch for us.

If you want to learn more about how we do that, read on.

You shouldn’t have to think about which IP address your email leaves from, and with Forge you don’t. The servers receiving your email do think about it, though. Each IP address has a history with them, and that history decides how much of your mail they’ll accept, and how quickly, before they look at the message itself. And that’s why we had to buy some IP blocks.

Unfortunately, the free pool of IPv4 addresses ran out years ago. The registry that hands them out in our region, ARIN, still keeps a waiting list, but it moves slowly and only gives out small blocks that someone returned. We didn’t want to wait and couldn’t just get any block, so we had to buy one from the marketplace.

That means finding a seller through a broker, proving to ARIN what we’ll do with the addresses over the next two years, and waiting for them to approve the transfer. It’s slow and it’s expensive, but at the end you own a range of addresses that you fully control, and that nobody else can touch, which is important because sometimes multiple IPs in the same block get “banned” because a single one did something bad. Owning the block means we can keep it clean.

As if buying the block weren’t already bureaucratic enough, it’s not all we had to do to send email fast and reliably.

We also had to dig up the history of each block ourselves before paying for anything. We basically looked at who had held each block before us, where it had been routed, who its neighbors were, what it was used for, and whether any blocklist or receiver still remembered it for the wrong reasons. The ones we ended up buying had been sitting unused for years, and came from reputable owners, so we were able to get them clean.

The slowest part came after that. A clean history only means a receiver has nothing against an address yet, but that’s not enough to start sending at high volumes because providers throttle mail from addresses they don’t know. So we warmed each block up, sending a little more every day and watching how each provider responded before sending more. That took weeks for some providers and months for others, and there is no shortcut, because what you’re waiting for is to be seen behaving well for a long time.

Now that we own warm IPs, we fully control what happens to them from here on. Nobody else sends from them, and we never get moved onto a range that someone else got blocked last month. When a receiver starts treating one of our IPs differently, we can see it in our logs within minutes and fix it ourselves.

Clean addresses stay clean only if everyone sending from them behaves, because receivers score the IP, not the customer. Forge is a shared pool, so your email leaves from the same IP addresses as other Resend customers’. That is what lets a brand new domain send well on day one, and it is also why we have to be careful about who sends through it: if someone kept sending phishing from the pool and we let them, receivers would eventually start treating the whole pool with suspicion.

So a good part of keeping the pool clean is noticing quickly when someone shouldn’t be in it. We built a system that watches every account and the mail going through the pool, and when it recognizes the patterns phishing and fraud leave behind, it stops that sender.

It’s the newest version of the abuse detection Resend has always run, and the fastest. It collects many signals and blocks bad senders as soon as it can, sometimes even before they send their first phishing email. At Forge’s volume, this system is critical for keeping a single bad sender from ever showing up in anyone else’s bounce numbers.

We don’t publish how it decides, for obvious reasons. You can see what it achieves, though. The acceptance rates at the top of this page are the rates of a shared pool, and they hold because very little bad mail ever leaves it.

There’s no written contract between a sender and a receiver. Gmail, Outlook, Yahoo and the others each run their own filters, change them whenever they like, and don’t owe anyone an explanation. What exists instead is a network of people: the postmasters who run mail at those providers, the teams at other large senders, the people who maintain blocklists. They talk to each other, and over the years they learn which senders can be trusted to fix a problem when told about it.

You can’t buy your way into that network. You get in by handling abuse reports properly for a long time, and by being the kind of sender a postmaster is willing to answer an email from. Our support team alone has more than 85 years of email experience between them, and if you count engineering and the rest of the company it adds up to more than a century.

That network is what we leaned on while warming Forge up. Especially during warm-up, when we had any issues or couldn’t get past a certain threshold for one of our addresses, we didn’t have to guess the reason from a response code. We could ask, and there was someone on the other side willing to answer. Most warm-up problems get solved much faster that way, and some only get solved that way.

None of this shows up as a feature in the dashboard. It shows up in the acceptance rates at the top of this page, and in the fact that you don’t need a deliverability team of your own to get them.

Gmail, Outlook, Yahoo and Apple don’t behave the same way, so Forge doesn’t talk to them the same way. Each receiver has its own idea of how many connections one sender should open, how many messages to send down each one, how long to keep it open, and how to say “slow down” when it’s had enough.

Those limits are not published anywhere, and they move. We keep a separate configuration for every major receiver, and a lot of our time goes into monitoring and adjusting it: a connection limit here, a retry interval there, a rule that recognizes a specific response from a specific provider and backs off before it turns into a block, and a myriad of other small adjustments that add up to a big difference in how fast and reliably your mail gets through.

We can do that because we measure everything that happens between your API call and the receiver’s final answer. We track how long each step takes, from the request being accepted to the message being handed over, and we track it separately for every receiver and every one of our IP addresses, at the median, at the tail, and the percentiles in between.

We know what share of mail each receiver accepts within sixty seconds and within three minutes, how often each one asks us to wait, how long a message sits in the queue before we try it, how long the SMTP conversation with the receiver takes, and how a retry compares to a first attempt. The numbers at the top of this page are a small piece of that.

Some of the adjusting is done by people, and increasingly it’s done by AI agents working on the same data. They watch the per-receiver metrics for the shape of a bottleneck, such as a queue growing for one provider while the others stay flat, work out which setting is responsible, and propose the change along with the evidence. The warm-up schedule, the connection limits and the retry timing have all been tuned that way.

Moving to Forge puts little to nothing at risk on your side. If Forge ever has an incident, your email still goes out, because delivery moves to the engine Resend has used for years without anyone having to do anything. We don’t expect to need that, and the rest of this page is why we don’t, but the fallback is there anyway.

That engine runs alongside Forge, and it isn’t going anywhere. If a Forge server can’t take a message, or a receiver starts refusing a range of our addresses, or something goes wrong that we didn’t predict, delivery of the affected messages moves to the other engine on its own. Nobody at Resend has to flip a switch, and nothing changes on your side.

We don’t expect to need this, though. Everything in the sections above exists so that it stays unused, and when it runs more than we’d expect, that is something we look into. But other companies’ products depend on this working, so we keep a path ready that we hope to leave alone.

There are limits to what any fallback can do. If a receiver rejects a message because the address doesn’t exist, a second engine won’t change its mind, and a bounce like that looks the same anywhere. The fallback protects against the cases where we have to “break the glass” and move to the legacy engine temporarily.