← Back to Blog

Email Deliverability Checklist: DNS, Authentication, and Reputation

Email · June 11, 2026 · 9 min read

A practical checklist for troubleshooting email deliverability — DNS records, SPF/DKIM/DMARC authentication, blacklist monitoring, and SMTP reputation.

Technical cover image for Email Deliverability Checklist: DNS, Authentication, and Reputation

Why Your Emails Land in Spam

You've configured Postfix or Exim, queued a batch of transactional emails, and they never reach the inbox. Or worse — they vanish entirely. Email deliverability isn't about your MTA being "up." It's about whether receiving servers trust your mail enough to deliver it. Three pillars determine that trust: DNS authentication, IP/domain reputation, and mailbox provider compliance.

1. DNS Authentication: The Baseline

Without SPF, DKIM, and DMARC, your mail looks like a forgery attempt to Gmail, Microsoft, and Yahoo. These three protocols form the authentication triad that every sending domain must have in 2026.

SPF (Sender Policy Framework)

SPF tells the world which IPs are allowed to send mail for your domain. A missing or broken SPF record is the single most common cause of soft bounces and spam folder placement.

Check your SPF with the OpsCheck Email Authentication tool. It parses your record and shows whether it's valid, whether it exceeds the 10-lookup limit, and whether ~all or -all is set.

# Check your SPF record from CLI
dig +short TXT example.com | grep 'v=spf1'

# A well-formed SPF record looks like this:
v=spf1 ip4:192.0.2.1 include:_spf.google.com include:mailgun.org ~all

Common SPF mistakes: hard-failing -all before you've listed every sending source, exceeding 10 DNS lookups (each include: counts), and forgetting your ESP's SPF include. If your sending volume is high and your SPF record bloated, use the OpsCheck SPF Flattener to resolve all includes into raw IP4/IP6 ranges and stay under the 10-lookup limit.

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs outgoing messages so receiving servers can verify the message wasn't tampered with in transit. A missing or invalid DKIM signature is flagged by Gmail's Postmaster Tools as a top rejection reason.

# Check DKIM DNS record (default selector)
dig +short default._domainkey.example.com TXT

# Test DKIM signing from a specific email
# Send a test message then inspect headers:
grep -i 'dkim-signature' email_headers.txt

The OpsCheck Email Authentication tool tests your DKIM selector and verifies whether the public key in your DNS matches your signing configuration. If your DKIM key is shorter than 1024 bits, rotate it — several providers now reject keys weaker than 2048 bits.

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

DMARC ties SPF and DKIM together with a policy that tells receivers what to do when authentication fails. Without DMARC, each receiving server makes its own call — and that call is usually "junk folder."

# Check DMARC record
dig +short _dmarc.example.com TXT

# Progressive DMARC rollout:
# Phase 1: Monitor only (p=none, collect reports)
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com

# Phase 2: Quarantine failures (p=quarantine)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

# Phase 3: Reject (p=reject, 100%)
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Use the Email Authentication tool to verify your DMARC record, check if aggregate reports (rua) are configured, and confirm your policy is set correctly. Do not jump straight to p=reject — start at p=none, monitor for two weeks, then go to p=quarantine before committing to reject.

2. Reputation: Are You on a Blacklist?

Even with perfect authentication, your mail gets blocked if your IP or domain appears on a DNS-based blocklist (DNSBL). Spamhaus, Barracuda, SpamCop, and others maintain real-time lists that MTAs query before accepting mail.

# Quick blacklist check with dig (Spamhaus ZEN)
dig +short 2.0.0.127.zen.spamhaus.org

# Returns 127.0.0.x if listed — each code means a different list

# Full check across 100+ blacklists with OpsCheck
# Use the Blacklist Checker tool below

Run your sending IP through the OpsCheck Blacklist Checker. It queries 100+ DNSBLs simultaneously and tells you exactly which lists have you flagged. A single listing on Spamhaus SBL or Barracuda can drop delivery to zero for major providers.

If you're listed: identify the cause (spam complaint, compromised account, open relay), fix it, then request delisting through each RBL's web form. Spamhaus delisting is automatic once the spam stops for 24 hours. Barracuda requires manual removal. Keep checking with the blacklist checker weekly.

SMTP Reputation Testing

Beyond blacklists, mailbox providers score your sending behavior. Use the OpsCheck SMTP Tester to connect to your mail server and verify: banner greeting correctness, STARTTLS availability, EHLO response, and whether your server accepts mail for your domain. The tool tests the full SMTP handshake and flags misconfigurations that hurt reputation scores.

# Manual SMTP handshake test
openssl s_client -starttls smtp -connect mail.example.com:587 -crlf
EHLO test.example.com
MAIL FROM:<test@example.com>
RCPT TO:<recipient@gmail.com>
QUIT

3. Real-World Scenario: Postfix + Mailgun Relay, Delivered to Spam

A hosting company had Postfix configured to relay through Mailgun for all outbound transactional mail (password resets, invoices, welcome emails). Authentication was set up but mail kept landing in Gmail's spam folder.

Diagnosis Steps:

  1. Ran Email Authentication check: SPF passed (include:mailgun.org present), DKIM valid, DMARC at p=none. Authentication was fine — not the problem.
  2. Checked sending IP against blacklists: Clean across all 100+ lists. Not a blocklist issue.
  3. Used the SMTP Tester: EHLO banner showed mail.example.com but the reverse DNS (PTR) for the sending IP resolved to static-192-0-2-1.isp.net. Gmail's spam filters ding the mismatch between EHLO hostname and PTR record.
  4. Missing rDNS: The sending IP had no PTR record matching the domain. Set up a proper PTR record with the hosting provider pointing back to mail.example.com.
  5. Warming up: New sending IP with zero reputation history. Throttled volume to 50 emails/hour for the first week, doubling every 3 days.

After fixing the PTR record and warming the IP over two weeks, Gmail delivery went from spam to primary inbox. The SMTP Tester confirmed the EHLO/PTR alignment was clean.

4. Deliverability Checklist: Pre-Send Verification

Before Sending Any Campaign or Transactional Batch:

  • SPF: Record exists, includes all sending services, no more than 9 lookups (reserve 1 for the existence check itself), ends with ~all or -all. Use the SPF Flattener if you're over the limit.
  • DKIM: 2048-bit key minimum, selector published in DNS, signing enabled at your ESP/MTA level. Verify with Email Authentication.
  • DMARC: Policy published (even p=none counts), reports configured at rua, alignment mode set (adkim=r; aspf=r).
  • Reverse DNS: Your sending IP's PTR record matches the hostname in your EHLO banner. Check with: dig -x YOUR_IP
  • Blacklists: Run your domain and IP through the Blacklist Checker. Zero hits across the major RBLs.
  • SMTP Handshake: Use the SMTP Tester to confirm: valid banner, STARTTLS offered, no open relay, correct response codes.
  • MX Record: Your domain's MX record points to a mail server that accepts mail for your domain. dig +short MX example.com
  • Custom Return-Path: Use a subdomain (e.g., bounce.example.com) with its own SPF/DKIM/DMARC for bounce tracking, separate from your main domain's reputation.

5. Monitoring and Ongoing Maintenance

Deliverability isn't set-and-forget. Reputation decays if you don't monitor it.

# Weekly health check script
#!/bin/bash
DOMAIN="example.com"
IP="192.0.2.1"

echo "=== SPF ==="
dig +short TXT $DOMAIN | grep v=spf1

echo "=== DKIM ==="
dig +short default._domainkey.$DOMAIN TXT

echo "=== DMARC ==="
dig +short _dmarc.$DOMAIN TXT

echo "=== MX ==="
dig +short MX $DOMAIN

echo "=== PTR ==="
dig +short -x $IP

echo "=== Spamhaus Check ==="
dig +short $(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}').zen.spamhaus.org

Run the Email Authentication tool monthly, the Blacklist Checker weekly, and the SMTP Tester after any MTA configuration change. A five-minute check prevents days of undelivered mail.

If you're starting from scratch with a new domain or IP, warm it up: 50 messages/day for week one, 200/day for week two, 500/day for week three, then scale to normal volume. Sending 10,000 emails from a cold IP on day one triggers spam filters instantly.

Bottom Line

Email deliverability breaks down into three simple checks: authentication (SPF, DKIM, DMARC — all three or nothing), reputation (blacklist status and SMTP handshake compliance), and monitoring (weekly automated checks, not manual spot-checks when users complain). The OpsCheck tools cover all three. Run them before every campaign, after every MTA change, and on a recurring schedule.