Resend

In short: A service for sending transactional emails (confirmations, password resets, newsletters) from your own domain.

In more detail: So that emails don’t land in spam and are recognised as “genuinely” coming from your own domain, certain DNS records have to be set — including a DKIM record (a digital signature) and SPF (which servers may send mail on behalf of the domain). Optionally, a tracking subdomain can be set up through which Resend records whether emails were opened or links in them were clicked.

Our context: Had to be moved completely to a dedicated Resend account — including deleting the old DKIM/SPF records (which still pointed to the partner account) and entering new ones at OVH.

In Depth

Email deliverability has historically been a trust problem: in theory, any server can claim to send mail on behalf of any domain (the sender address in the From field can be set freely), which is why email providers such as Gmail or Outlook demand additional proof before they don’t classify a mail as spam. Three DNS records form the standard trio for this:

• SPF (Sender Policy Framework) — a TXT record listing which server IPs may send mail on behalf of the domain.
• DKIM (DomainKeys Identified Mail) — every mail sent is cryptographically signed; the public key for checking this signature is available as a DNS record so that the recipient can verify the signature.
• DMARC — determines what should happen if SPF/DKIM fail (deliver the mail anyway, move it to spam, or reject it entirely), plus an address for reports on failed checks.

If these records are missing or (as in Emzett’s case) still point to someone else’s account, emails are either not delivered at all or reliably end up in the spam folder — a failure pattern that can’t be diagnosed in your own code alone, since the sending itself is technically successful.

Bounces and complaints

Two kinds of feedback are decisive for long-term deliverability: a bounce means the target address doesn’t exist (any more) or the mailbox is full — a hard bounce (the address permanently doesn’t exist) should immediately exclude the address from future sends, while a soft bounce (a temporary problem, e.g. a full mailbox) allows later retries. A complaint means the recipient explicitly marked the mail as spam. Sending services like Resend evaluate both signals and can downgrade the sender reputation of the entire domain if the bounce/complaint rate gets too high — which then affects ALL future mails from this domain, not just the address concerned. That’s why it’s important to actively remove bounces from your own recipient list instead of silently ignoring them.

Webhooks for delivery status

Instead of regularly asking yourself whether a mail was delivered, you can set up a webhook: on every status change (delivered, opened, link clicked, bounce, complaint), Resend sends an HTTP request with the details in the body to a URL you define — this lets your own application show, for example, whether a confirmation mail actually arrived, without polling.

See also: DNS records, DNS entries, TXT record, Emails