Your Email Deliverability Checklist: An Engineer's Guide

Email deliverability is a beast. You've built a robust system, crafted compelling messages, and yet, your emails are landing in spam folders or, worse, disappearing into the ether. For engineers, this isn't just frustrating; it's a critical system failure. Unlike a server outage with clear logs, email deliverability is a complex dance with recipient mail servers, involving reputation, authentication, and content.

This article provides a practical checklist for senders, rooted in the technical realities of email infrastructure. We'll cut through the marketing fluff and focus on the actionable steps you can take to ensure your emails reach their intended recipients.

1. Nail Your DNS Records: SPF, DKIM, and DMARC

These three acronyms are the foundation of email authentication. Without them, your emails are essentially anonymous, making them prime targets for spam filters.

MX Records (Mail Exchanger)

While primarily for receiving email, ensuring your sending domain has correct MX records is good hygiene. Some mail servers might perform a reverse lookup on your sending domain.

SPF (Sender Policy Framework)

SPF allows you to specify which IP addresses are authorized to send email on behalf of your domain. This is a TXT record.

What to check: * Presence: Do you have an SPF record for your sending domain? * Correct IPs: Does it include all your sending IPs (your own servers, ESPs, transactional email services)? * Mechanism: Use v=spf1 followed by ip4, a, mx, include mechanisms. * Qualifier: ~all (softfail) is generally safer to start with than -all (hardfail) to avoid blocking legitimate mail while you're still auditing. ~all tells receiving servers that emails from unauthorized IPs might be legitimate, but -all says they definitely are not. Move to -all once you are confident. * Lookup Limit: Don't exceed 10 DNS lookups in your SPF record, including those from include mechanisms. This is a common pitfall.

Example: Checking your SPF record with dig

dig +short TXT yourdomain.com

You should see an output similar to v=spf1 include:_spf.google.com include:spf.sendgrid.net ~all. If you see multiple SPF records, that's an issue; merge them into one.

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to your outgoing emails, allowing recipient servers to verify that the email hasn't been tampered with in transit and truly originated from your domain.

What to check: * Presence: Do you have a DKIM record (usually a CNAME or TXT record for a specific selector)? * Correct Key: Is the public key in your DNS record correct and matched by the private key your sending server uses to sign emails? * Selector: Each DKIM record uses a "selector" (e.g., s1, mailgun). Ensure your sending system uses the correct selector. * Signing: Is your Mail Transfer Agent (MTA) actually signing your emails with DKIM? Inspect raw email headers for DKIM-Signature: fields.

Example: Checking a DKIM record with dig (replace selector and yourdomain.com)

dig +short TXT selector._domainkey.yourdomain.com

You should see the public key string. If you get NXDOMAIN, your record isn't configured correctly.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds on SPF and DKIM, allowing you to tell receiving servers what to do with emails that fail authentication, and providing reports on your email traffic.

What to check: * Presence: Do you have a DMARC record (a TXT record at _dmarc.yourdomain.com)? * Policy (p): Start with p=none to collect reports and understand your traffic without impacting deliverability. Gradually move to p=quarantine (send to spam) and then p=reject (block entirely) as you gain confidence. * Reporting (rua, ruf): Set up rua (aggregate reports) to an email address you monitor. These XML reports provide invaluable insights into who is sending email on behalf of your domain.

Example: Checking your DMARC record with dig

dig +short TXT _dmarc.yourdomain.com

A common output might be v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; aspf=r; adkim=r.

2. Optimize Your SMTP Server Configuration and Behavior

Beyond DNS, how your email server interacts with others is crucial.

Reverse DNS (PTR Record)

Your sending IP address must have a PTR record that resolves to your sending domain (or a subdomain thereof). Many recipient servers will outright reject emails from IPs without a matching PTR record, or with a generic ISP-assigned PTR. This is a common requirement for legitimate senders.

TLS/SSL Encryption (STARTTLS)

Always use STARTTLS for encrypting your SMTP sessions. While not strictly a deliverability factor for getting through, it's a security best practice that builds trust and prevents snooping. Most receiving servers prefer or require it.

Example: Basic SMTP interaction with telnet (replace mail.recipient.com with a real mail server)

telnet mail.recipient.com 25
# You'll get a 220 greeting.
EHLO yourdomain.com
# Look for "250-STARTTLS" in the response to confirm support.
MAIL FROM:<sender@yourdomain.com>
RCPT TO:<recipient@recipient.com>
DATA
Subject: Test Email

This is a test.
.
QUIT

This interaction demonstrates the basic flow and allows you to check for STARTTLS support and appropriate SMTP responses. A 250 OK is good for MAIL FROM and RCPT TO.

HELO/EHLO Greeting

Your server's initial greeting (HELO or EHLO) should use a fully qualified domain name (FQDN) that matches your PTR record. Generic names like localhost are red flags.

SMTP Response Codes

Understand and properly handle SMTP response codes: * 2xx (Success): The mail was accepted. * **4