Deliverability
Email deliverability for developers
A practical map of what happens between your API call and the inbox — authentication, reputation, bounces, and webhooks — without ESP marketing fluff.
The pipeline
Your application
↓
Notify API (x-api-key)
↓
Queue + DKIM signing
↓
SMTP delivery to Gmail / Outlook / …
↓
Delivery / bounce / complaint events
↓
Logs + webhooks → your appAuthentication building blocks
- SPF — which servers may send for your domain. Explained for developers
- DKIM — cryptographic signature on the message.
- DMARC — policy for what receivers do when SPF/DKIM fail.
Setup: Domain verification · Cloudflare DNS · Route53
Bounces, complaints, suppressions
Hard bounces and spam complaints hurt reputation. Stop sending to those addresses. Notify tracks suppressions; use webhooks on Pro+ to react in your app.
Best for
Engineers wiring transactional email who need DNS and bounce basics.
Not for
Marketers optimizing newsletter open rates or cold outreach.
Frequently asked questions
What is email deliverability?
Whether recipients actually get your mail in the inbox — driven by authentication (SPF/DKIM/DMARC), reputation, content, and bounce/complaint handling.
Do I need SPF, DKIM, and DMARC for transactional email?
Yes for serious production sending. Notify requires domain verification (SPF/DKIM) before custom from addresses go to production.
Is Notify a deliverability specialist like Postmark?
Postmark markets deliverability as a premium brand. Notify focuses on minimal send + observe and solid domain auth. Choose Postmark if deliverability brand is the buying criterion.
What about bounces and suppressions?
Hard bounces and complaints should stop future sends to that address. Notify maintains a suppression list — see docs.