The Resend Alternative, Run For You

Resend hands you an API and leaves the rest with your team: the records, the alignment between them, the warm-up, the bounce handling, the templates, and the watching. We take that on instead. You keep your own sending code, and we run the subdomain, the authentication, the warm-up and the daily read of delivery, bounce and complaint rates. Billing follows delivered mail rather than seats, at a flat monthly figure with a clear rate above it.

Transactional email is the mail your application sends to one person because of something they did. Order confirmations, password resets, shipping notices, account verifications, and receipts all count. It is triggered by an action rather than scheduled by a marketer, and the recipient is usually waiting for it, which is why a delay or a spam folder placement turns into a support ticket.

Marketing email goes to a list on a schedule and people can opt out of it. Transactional email goes to one person because they did something, and they cannot reasonably opt out of a receipt they are owed. The practical difference is tolerance. A newsletter landing in promotions is a missed opportunity, while a password reset landing there is a customer locked out of their account.

Usually because they leave your web server unsigned. WordPress sends through the host by default, from an address on your domain, with nothing proving that server is allowed to send as you. Mailbox providers treat that as possible forgery and filter it. Routing the same mail through an authenticated path with published records fixes most of the problem, and reputation work fixes the rest.

Deliverability is the share of your mail that reaches an inbox rather than a spam folder or a rejection. We track delivery rate, bounce rate, and complaint rate as the core numbers, then watch for placement problems those rates can hide. A message can be accepted by the receiving server and still land in spam, so acceptance on its own is not the measure that matters.

For transactional mail, above 99 percent delivered is normal, and anything under 98 percent deserves investigation. Bounce rate should sit below 2 percent and complaints below 0.1 percent, because both feed directly into how providers treat you. Marketing benchmarks are looser and do not apply here. Receipts go to people who just handed you their address, so those addresses should be good.

We recommend a subdomain and it is included. Keeping application mail on its own subdomain means its reputation is tracked separately from the address your staff email from. If a run of bad addresses causes trouble, it lands on the subdomain rather than your primary domain, so your team can carry on emailing customers normally while we sort it out.

They are three DNS records that prove your mail is really yours. SPF lists which servers may send for your domain, DKIM signs each message so tampering shows, and DMARC tells providers what to do when a message fails the other two. Publishing them is table stakes now. Getting all three aligned with each other is the part that trips people up.

Twenty five thousand delivered emails a month are included. For context, a store handling a few hundred orders a month usually sits well under that once order confirmations, shipping notices, and account mail are counted together. We tell you where your volume actually lands after the first full month rather than asking you to guess at it up front.

Additional volume is one dollar per thousand delivered, added to the same monthly invoice. There is no cliff, no throttling, and no upgrade conversation to sit through. If your volume climbs far enough that a different arrangement would cost you less, we will tell you rather than quietly billing the overage every month.

Yes, and those are usually the emails that prompt the call in the first place. WooCommerce relies on the same WordPress mail function everything else uses, so once that is routed through the authenticated path, order confirmations, shipping notices, and customer account mail all travel it. We test each of those templates during setup rather than assuming they render.