Transactional email deliverability checklist

Updated

Deliverability is two questions: did the message get accepted, and did it land in the inbox rather than spam. Providers can help with the first and give you tools for the second, but most of the second is decided by things you control.

1. Authenticate your domain

Publish SPF and DKIM for the domain in your From address, and a DMARC record. Without alignment, you are asking mailbox providers to trust an unverified claim. Full details: SPF vs DKIM vs DMARC.

2. Use a stable, recognisable identity

  • One From address per purpose (security@, billing@), kept constant.
  • A real display name that matches your brand.
  • A subdomain dedicated to application mail, separate from campaign mail.
  • Warm up gradually if you are moving high volume to a new domain, since new senders have no reputation.

3. Send only what was asked for

Account email is judged on how people react to it. Messages that are short, expected and acted upon build reputation. Add promotions and complaint rates go up.

4. Write plainly

  • A subject that says what it is: "Your Acme verification code".
  • Plain-text part included.
  • Few links, all pointing at your own domain.
  • No attachments (the Inboxili API does not support them anyway).
  • Do not use link shorteners.

5. Handle bounces and complaints

  • Hard bounce (address does not exist): stop sending to it.
  • Soft bounce (mailbox full, temporary failure): retry later, but give up eventually.
  • Complaint (recipient pressed "report spam"): stop sending to that address.

Inboxili emits bounced, complained and delayed webhook events. Wire them to your user table so your application learns about bad addresses.

6. Do not retry blindly

Without an idempotency key, retrying a request after a timeout can duplicate the message, and repeated duplicates annoy users. Retry only on 429, with backoff.

7. Watch the numbers

Track per sender: delivered, bounced, complained. Sudden jumps in bounces usually mean a bug (sending to a malformed list) or abuse of a public form.

8. Protect your forms and endpoints

Public "send me a code" and "contact us" forms are used by spammers to send mail through you. Rate-limit by IP and by recipient, and add a challenge where abuse appears.

Quick diagnostic

| Symptom | Likely cause | Check | |---|---|---| | Rejected with sender_not_verified | From address not on a verified domain | Deliverability Center | | Arrives but in spam | Weak authentication or reputation | Authentication-Results header | | Arrives late | Provider delay or recipient greylisting | delayed webhook events | | Never arrives, no bounce | Silent filtering at the recipient | Test with another mailbox provider |

Frequently asked questions

Why did my password reset go to spam?
Common causes are missing authentication on your domain, a new or low-reputation sending identity, promotional wording or heavy imagery in a plain account email, or a recipient who previously marked similar mail as spam.
Can a provider guarantee inbox placement?
No. Placement is decided by the receiving mailbox provider using signals nobody else controls. A provider can give you the tools and a clean setup, not a guarantee.

Set up a verified domain

Create a workspace, verify a domain, and make your first API call.

Related