Migrate from Resend to Postal

Add the domain in the dashboard and create the DNS records it shows. You can keep the same domain on Resend and Postal at the same time: the records are different, because Postal uses the postal selector in DKIM.

• Postal checks the records on its own for up to 72 hours and notifies you by webhook (domain.updated)
• If the domain doesn't have DMARC yet, the large providers penalize senders of volume: start with p=none and tighten it later
• Create an API key under API keys. For systems that only send, use a sending-only key, restricted to the domain

Resend's official SDKs work when pointed at Postal. In Node.js, pass baseUrl when creating the client or set RESEND_BASE_URL. The email body, the response ({"id"}) and the error format (statusCode, name, message) stay the same.

Through the SDK

- const resend = new Resend(process.env.RESEND_API_KEY);+ const resend = new Resend(process.env.POSTAL_API_KEY, { baseUrl: 'https://api.postal.so' });

Or just through the environment

# No changes to code that already uses new Resend(key)
RESEND_BASE_URL=https://api.postal.so
RESEND_API_KEY=ps_your_key

Over HTTP

- curl -X POST 'https://api.resend.com/emails' -H 'Authorization: Bearer re_...'+ curl -X POST 'https://api.postal.so/emails' -H 'Authorization: Bearer ps_...'

Over SMTP

- Server: smtp.resend.com- User: resend- Password: re_...+ Server: smtp.postal.so+ User: postal (resend is also accepted)+ Password: ps_...

Tested with the resend 6.34 package (Node.js): simple, scheduled, batch and idempotent sending, plus lookup, editing and cancellation, attachments, domains, API keys, webhooks and webhooks.verify. Other SDKs that let you change the base URL speak the same format, but they were not tested one by one: if you find a difference, let us know through the contact form.

Before switching traffic, bring over the suppression list, so you don't write to people who already asked to opt out, and the contacts, if you use the audience. Recreate the templates too: the {{{VAR}}} variables are the same as Resend's.

• Suppression list: POST /suppressions/batch/add, with 100 addresses per request
• Contacts: CSV import, through the dashboard or the API
• Templates: create and publish with the same alias and the same variables; sends always use the latest published version

curl -X POST https://api.postal.so/suppressions/batch/add \
  -H "Authorization: Bearer $POSTAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["[email protected]", "[email protected]"]}'

Event names are the same (email.delivered, email.bounced…), in the format {type, created_at, data}. What changes is the secret: in Postal, each endpoint has its own signing_secret (whsec_…). The signature follows the Standard Webhooks standard, and resend.webhooks.verify accepts both the webhook-* and svix-* headers.

• Create the endpoint under Webhooks (dashboard or POST /webhooks) and choose the events
• Send a test event from the dashboard before switching traffic
• There are 8 attempts over about 27 hours, always with the same webhook-id; manual resending goes out through the dashboard or POST /webhooks/{id}/events/{event_id}/replay
• Other languages: see the signature verification

import { Resend } from 'resend';

const resend = new Resend(process.env.POSTAL_API_KEY, { baseUrl: 'https://api.postal.so' });

// Read the raw request body, without reformatting the JSON
const event = resend.webhooks.verify({
  payload: rawBody,
  headers: {
    id: request.headers['webhook-id'],
    timestamp: request.headers['webhook-timestamp'],
    signature: request.headers['webhook-signature'],
  },
  webhookSecret: process.env.POSTAL_WEBHOOK_SECRET, // whsec_...
});

Change the base URL and the key in the test environment, send an email to yourself and follow it in Logs and in the webhooks. Test addresses accept +rótulo, don't use quota, don't affect reputation and generate real webhooks (depending on the plan). Then switch in production and keep Resend around for a few days.

• Different IDs. Resend's email and webhook IDs don't exist in Postal, and the reverse is also true. Record which provider each email went out through and keep receiving events from Resend for what went out through it
• Mark the origin. Use tags (for example, provider: postal) and your own Idempotency-Key on each send
• One provider at a time per flow. Invitations, password resets and codes should go out through a single path. Watch the bounces in the first few days, because the reputation limit applies to the whole team
• An address that works again. A permanent bounce puts the address on the suppression list; remove it with DELETE /suppressions/{id} or POST /suppressions/batch/remove