# Resend Forge: End-to-end sending infrastructure.

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.

Until now, Resend owned every part of sending except the last one. The API, the queues, the retries, the webhooks: that was all ours. The hop from SMTP servers to the recipient’s inbox unfortunately wasn’t.

Once a message left us it rode a third-party provider’s SMTP servers and IPs, and we learned what happened from reading their APIs. That arrangement served us well because it let us spend years building the best developer experience for emails. In other words, that’s why you can sign up for Resend, grab an API key, and send your first email a few minutes later, with no sales call in between. The time we saved went into the API, the SDKs, and open source work like React Email.

That trade cost us on the other end. When a message slowed down or bounced on that last hop, we could see it happen, and we could ask the provider to look into it, but we couldn’t rotate IPs or tune the mail transfer agent’s configurations, for example.

Deliverability is decided in the SMTP conversation, one response code at a time, and we weren’t in the room. Forge puts us in the room.

Now, every leg of the delivery, from the request you make to the 250 the recipient’s server sends back, runs on addresses and servers we control.

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

## Top notch deliverability

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 last 7 days, 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.

> Resend Forge is so good that I forget it exists. I just make an API call and an email gets to my users’ inboxes, every single time.
>
> — Sahil Lavingia, CEO of Gumroad

## Faster than you can say “send”

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 last 7 days, on the same providers, split by the engine that sent the message: our old engine including the third-party provider, and Forge.

| Receiver | Old engine (median) | Forge (median) | |
| --- | --- | --- | --- |
| All providers | 1.6s | 0.9s | 67% faster |
| Google | 1.4s | 0.8s | 75% faster |
| Yahoo | 1.9s | 1.4s | 41% faster |
| Outlook | 3.2s | 2.3s | 38% faster |
| Apple | 4.8s | 4.9s | On par |

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.

## How we keep it fast and reliable

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.

## Have you ever bought an IP block? We did — multiple ones.

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 wasn’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 were its neighbours, what was it 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 have warm IPs we own, it means 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.

## We catch spammers before they impact your sending

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 for that and called it Guardian. It 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.

Guardian is the newest version of the abuse detection Resend has always run, and it’s 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 Guardian 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.

## We talked to many postmasters so you don’t have to

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.

## We measure each delivery and adjust for every receiver

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.

| Delivered within | Forge | Old engine | Gap (pts) |
| --- | --- | --- | --- |
| 5 seconds | 93.28% | 89.33% | ▲3.94 |
| 30 seconds | 99.54% | 97.21% | ▲2.33 |
| 1 minute | 99.87% | 97.77% | ▲2.10 |
| 3 minutes | 99.97% | 98.03% | ▲1.93 |

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.

## If Forge has trouble, it falls back

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.

Forge sends alongside the engine Resend has used for years, and that engine 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. What the fallback protects against is the one case where we have to “break the glass” and move to the old engine temporarily.

## Frequently asked questions

### Will my deliverability get worse?

No. Your deliverability should improve as more of your mail routes through Forge over time. The pool is curated specifically so shared reputation works in your favor, not against you.

### How do I start using Forge?

If you are already a Resend customer, look for the migration control in your domain’s configuration tab. Add the DNS record we show you. Once that record is verified, you become eligible, and we onboard you after our systems have established you as a good sender.

### Do I need to change anything in my code?

No. Keep calling the Resend API the way you already do. Forge sits behind the same send path: infrastructure, not a new integration project.

### Does Forge support open and click tracking?

Not yet. Click and open tracking can affect sending reputation across tenants, not only the ones using it. We are launching without it because deliverability, reliability, and speed are the priority.

### What happens if a message can’t be delivered through Forge?

Forge can automatically fall back to another provider that can complete the delivery, so messages are not lost to a single-path failure.

### Is Forge available to everyone?

You become eligible after the DNS record is verified and our automated systems have established your reputation as a good sender. We then onboard you onto Forge. That gate exists to protect the pool everyone shares.

## Start with the records. We’ll take it from there.

Forge is Resend’s answer to a simple idea: deliverability is existential for your product, so your email provider should own every hop. Bring your domain. Add the DNS records when you’re ready. Keep shipping with the same API. We’ll run the infrastructure, the MTA, the abuse systems, the postmaster relationships, and the fallback path, so your users keep getting the emails that make your product work.

Sign up at [resend.com/signup](https://resend.com/signup).