Transactional email

Transactional email is the mail your application sends to one person because they did something: verify this address, reset this password, here is your sign-in link, here is what happened this week. Resend is an API for that, with domain authentication, a delivery log and templates. It is not a marketing platform and should not be used as one. The reason we use a service rather than an SMTP server is that reputation is the actual product, and running your own outbound mail means inheriting a reputation problem you did not have.

How we use it

ClassProfile sends the verification link that completes registration, the magic link that signs someone in without a password, and the reset flow. That puts email on the critical path: if the message does not arrive, the account does not exist as far as the user is concerned, so bounce handling and a visible resend control are part of the feature rather than a later addition.

Objectify sends the same class of mail on behalf of its own users' applications, verification, reset and magic links, which means the sending domain and the reputation attached to it are shared across tenants. Jonosakti adds a scheduled weekly digest on top of its transactional mail, and digests are where volume appears without anyone deciding to increase it.

What it costs you

Deliverability is your responsibility, not the vendor's. SPF, DKIM and a DMARC policy on the sending domain are the minimum, and a domain that publishes p=none is a domain anybody can send as. We have built a whole product around that argument, so the case is set out in from p=none to p=reject rather than repeated here. Warm a new domain gradually, keep transactional and bulk on different subdomains, and never let a digest job share a subdomain with password resets.

Operationally, a send is an outbound HTTP call. Doing it inline means a user waiting on someone else's API before their registration completes, and a provider outage turning into failed sign-ups. Anything that is not strictly required before the response goes behind a queue with retries and a dead letter path. Costs are modest until they are not: free tiers are sized for a side project, and a weekly digest to a real user base is a different order of volume from password resets.

Two more gotchas. Templates in code are versioned and reviewable but need a rendering test, because a broken template ships as an empty email that nobody notices for a fortnight. And suppression lists are real state living at the vendor; if you migrate providers, the list of addresses you must not email again does not come with you automatically.

When we would choose something else

If the platform already underneath the application can send mail, that is one less vendor, one less key and one less bill. It matters more when the product has to receive mail as well: routing an inbound message straight into a Worker so it can be parsed is a job a send-only API does not do at all, and we have built report ingest that way.

For newsletters, campaigns, segmentation and unsubscribe management, a transactional API is the wrong shape, and we would put marketing mail on a platform built for lists. And for a brochure site with an enquiry form, we frequently send no email at all: a chat link beats a contact form for a business that answers on a phone anyway.