The Developer's Email Deliverability Checklist

Deliverability problems are easier to prevent than to fix. A domain with damaged reputation can take weeks to recover. This checklist covers everything a developer needs to verify before going to production with email sending — and what to monitor once live.

DNS and authentication

• ☐ SPF record added for your sending subdomain. Include your ESP's sending infrastructure. Use ~all (softfail) while warming, switch to -all (hard fail) once stable.
• ☐ DKIM record added. Your ESP provides the CNAME or TXT record. Verify with dig TXT selector._domainkey.yourdomain.com
• ☐ DMARC record added for the root domain. Start with p=none to monitor, graduate to p=quarantine then p=reject. Add an rua address to receive aggregate reports.
• ☐ Root domain SPF set to -all (no servers authorised to send from root domain)
• ☐ Root domain DMARC set to p=reject — prevents spoofing of your main domain
• ☐ MX records present on your sending subdomain — required by some providers to verify the domain is real

Subdomain architecture

• ☐ Never send from your root domain. Use a subdomain (e.g. mail.yourdomain.com) so root domain reputation is protected.
• ☐ Separate subdomains for transactional and marketing email. Reputation is isolated per subdomain — marketing complaints don't affect transactional delivery.
• ☐ All subdomains have independent DKIM keys. Do not reuse the same key across subdomains.

See the full guide: Email subdomain strategy

Domain warming

• ☐ New domains must be warmed before sending at full volume. Start at 200/day and double weekly.
• ☐ Monitor bounce rate throughout warming — keep below 2%.
• ☐ Monitor complaint rate throughout warming — keep below 0.08%.
• ☐ Send only to engaged contacts during warming. Save cold list segments until reputation is established.
• ☐ Do not spike volume. Sudden volume increases from an otherwise low-volume domain trigger filtering even on warm domains.

See the full schedule: Domain warming guide

API integration

• ☐ API key stored in environment variables. Never in source code or client-side JavaScript.
• ☐ Sandbox key used for development and CI. Switch to production key only after domain verification.
• ☐ Bearer token format correct: Authorization: Bearer YOUR_API_KEY
• ☐ Retry logic implemented for 429 (rate limited) and 5xx (server error) responses. Use exponential backoff with the Retry-After header.
• ☐ 422 suppression responses handled. When the API returns 422 for a suppressed address, update your own records — do not retry.

See the full integration guide: API integration guide

Webhook setup

• ☐ Webhook endpoint registered for all delivery events.
• ☐ Signature verification implemented. Always verify the HMAC-SHA256 signature before processing. Reject unverified requests with 401.
• ☐ Hard bounce handler suppresses immediately. On bounced.hard, update your database and stop sending to that address.
• ☐ Complaint handler suppresses immediately. On complained, suppress and investigate the send that triggered the complaint.
• ☐ Unsubscribe handler updates subscription status. On unsubscribed, mark the contact in your system.
• ☐ Webhook responds 200 immediately. Process events asynchronously — do not do slow DB operations before acknowledging.
• ☐ Idempotency check on event ID. Webhooks can be delivered more than once — check event.id before processing.

See the full guide: Email webhooks guide

List quality

• ☐ Double opt-in enabled for all web sign-up forms.
• ☐ Email format validated at the point of capture — server-side, not just client-side.
• ☐ Suppression list synced before any bulk import. Do not re-import suppressed addresses.
• ☐ Imported lists validated before first send. Lists older than 12 months should be re-permissioned or validated through an email verification service.

Monitoring

• ☐ Google Postmaster Tools registered for your sending domain. Gives domain reputation (High/Medium/Low/Bad) and spam rate data for Gmail.
• ☐ Microsoft SNDS registered for your sending IP. Gives complaint data for Outlook/Hotmail.
• ☐ MXToolbox blacklist check scheduled weekly during warm-up, monthly at steady state.
• ☐ Bounce rate alert set — trigger at 2% hard bounce rate per campaign.
• ☐ Complaint rate alert set — trigger at 0.08% complaint rate per campaign.
• ☐ Authentication monitoring enabled — NexusProMail checks DKIM/SPF/DMARC continuously and alerts on failures.

Pre-production checklist

Before switching from sandbox to production, confirm:

1. All DNS records verified with dig or MXToolbox
2. DMARC reports flowing to your monitoring address
3. Sending subdomain verified in NexusProMail dashboard
4. Webhook endpoint live, signature verification working, test event received
5. Hard bounce and complaint suppression logic tested
6. Retry logic tested with a simulated 429 response
7. Domain warming schedule started — day 1 send volume ≤ 200

For a full walkthrough of the NexusProMail API integration, see the API integration guide. For subdomain architecture, see the subdomain strategy guide. For domain warming, see the domain warming guide.