# Resend Forge

Our own Mail Transfer Agent (MTA), delivering from IP blocks we own and operate. Built for speed and deliverability.

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.

This page is about how Forge works and what that means for your email. **But first, some numbers.**

## Top-notch deliverability

Deliverability is the first thing anyone asks a sending provider about, and usually the hardest thing to check before you have moved your mail. The numbers below are **the ones we watch ourselves**, updated live, so you can see how your email would have fared this week.

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.

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 are all counted as bounces, and they are the majority of what you see in the chart.

Numbers like these depend on **a clean pool and careful senders**, and on Forge the careful part is mostly built in: suppression lists keep you from retrying an address that already bounced, and our guidance helps you keep your lists healthy. Every sender who stays careful keeps the pool clean for everyone else, you included.

In other words, **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.

> Faster time-to-inbox, fewer retries, and better observability. That's the kind of infrastructure we want underneath us.
>
> Sam Lambert, CEO of PlanetScale

## 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.

These are live too. Each number below is **how long your users would’ve waited today** between your API call and the receiver accepting the message. Most of them would probably not have even noticed the wait.

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.

| Receiver | Legacy (median) | Forge (median) | |
| --- | --- | --- | --- |
| All providers | 1.6s | 0.9s | 67% faster |
| Google | 1.4s | 0.8s | 75% faster |
| Yahoo | 1.9s | 1.3s | 41% faster |
| Outlook | 3.1s | 2.3s | 36% 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. For you that means a page that pulls them from our monitoring every hour without anyone checking first, which is the kind of boring you want from the software that sends your password resets.

## 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**.

Delivery like this has to be kept up, every week, for every receiver. We did not invent the work: warm up the IPs, watch the metrics, read the logs each provider sends back, keep abuse out of the pool, keep talking to the postmasters. That said, we do it with the best tools available, including a few we had to build, and we do it so you can treat email as solved and get back to your product.

The sections below take each piece in turn. It starts with the IP blocks your mail leaves from, how spammers get kept out of the pool, the postmasters we talk to, what we measure for every receiver, and what happens if Forge itself has a bad day.

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

## Buying IP blocks and why that matters

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. That is why Forge sends from IP blocks Resend owns.

**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. So, like most senders that run their own infrastructure, we bought ours on the transfer market.

That means finding a seller through a broker, showing ARIN what the addresses will be used for over the next two years, and waiting for the transfer to be approved. It takes a few weeks and a fair amount of paperwork, and at the end you own a range of addresses that nobody else can touch, which matters because receivers sometimes treat a whole block as one when a single address in it misbehaves. **Owning the block means we can keep it clean.**

The buying is the easy part to explain. The more interesting question was which blocks to buy.

Before paying for anything, we looked into each block’s history: who had held it 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 with had been **sitting unused for years with reputable owners**, which is exactly what you hope to find.

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.

For you, warm IPs that Resend owns mean your mail never gets moved onto a range someone else got blocked from last month, and nobody outside Resend sends from the addresses your email leaves from. When a receiver starts treating one of them differently, **we can see it in our logs within minutes and fix it ourselves** because we have full control over which addresses are used and how. That way, your email keeps going out, no matter what happens to a particular IP or block.

## 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 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 is the newest version of the abuse detection Resend has always run. It collects many signals and blocks bad senders as early as it can, sometimes **before they send their first phishing email**, which is what keeps someone else’s bad sending from ever showing up in your 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**.

## 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. That takes years, and they are years you would otherwise have to put in yourself. Across support, engineering and the rest of the company, the people doing it here have **more than a century of email experience** between them, so we can save you that time.

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 | Legacy | Gap (pts) |
| --- | --- | --- | --- |
| 5 seconds | 93.49% | 89.63% | ▲3.86 |
| 30 seconds | 99.68% | 97.49% | ▲2.18 |
| 1 minute | 99.90% | 97.90% | ▲2.00 |
| 3 minutes | 99.97% | 98.10% | ▲1.87 |

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.

## Migrating to Forge is safe and secure

**Moving to Forge puts little to nothing at risk on your side.**

Before you can migrate to Forge, we check that your domain is set up correctly and that our systems have established you as a good sender. Once you are eligible, we onboard you onto Forge, and your email starts leaving from the same IP blocks other Resend customers use. That way, your email benefits from the shared reputation of the pool, and you don’t have to wait for your own IPs to warm up.

Additionally, 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 sections above are why we don’t, but the fallback is there anyway.

Finally, if you have any questions about how Forge works, or if you want to know more about the numbers at the top of this page, our team is happy to answer them and put you at ease.

For the past few months, we’ve been sending hundreds of thousands of emails through Forge every day, and we look forward to sending yours too.

## Frequently asked questions

### 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.

### 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.

### 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).