← RFC Reference

The Complete Email Deliverability Guide

Email Concepts Encyclopedia
ELI5: Deliverability is not the same as delivery. Delivery means the receiving server accepted your email. Deliverability means it landed in the inbox, not the spam folder. Think of it like mailing a package: delivery is getting it to the building; deliverability is getting it to the right person’s desk instead of the dumpster out back.

Everything that determines whether your email reaches the inbox — authentication, reputation, content, list hygiene, warming, and monitoring — in one place.

The Deliverability Equation

Email deliverability is the result of four factors working together:

  1. Authentication — Proving you are who you say you are
  2. Reputation — Your historical track record as a sender
  3. Content — What your message contains and how it is structured
  4. List quality — Whether your recipients actually want your email

Each factor is necessary but not sufficient on its own. Perfect authentication cannot save a sender with terrible reputation. Excellent content will not help if you are sending to a list full of spam traps. This guide covers all four pillars and how they interact.

Pillar 1: Authentication

Authentication is the foundation. Without it, nothing else matters. You need three protocols configured correctly, and they must work together.

SPF

SPF publishes which servers are authorized to send mail for your domain. Set it up as a DNS TXT record:

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com -all"

Key rules: stay under 10 DNS lookups, use -all (hard fail) once you are confident in your record, and audit regularly to remove services you no longer use.

DKIM

DKIM adds a cryptographic signature to every message. The receiving server verifies it against a public key published in your DNS. DKIM proves the message was sent by your domain and was not modified in transit.

mtg._domainkey.example.com. IN CNAME mtg._domainkey.mailertogo.com.

Ensure your DKIM signing domain (d=) matches your From: header domain for DMARC alignment. Use at least 2048-bit RSA keys.

DMARC

DMARC ties SPF and DKIM together with a policy. Start with monitoring, then enforce:

; Phase 1: Monitor (collect data, do not enforce)
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; Phase 2: Quarantine (filter failures to spam)
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Phase 3: Reject (block failures completely)
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Read your DMARC aggregate reports before moving from p=none to p=reject. The reports will show you which legitimate services are sending mail as your domain and whether they are properly authenticated. Do not skip this step.

The authentication checklist

Pillar 2: Reputation

Sender reputation is the accumulated trust score that mailbox providers assign to your IP addresses and domains. It is built over time and can be destroyed quickly.

Building reputation

Protecting reputation

Pillar 3: Content

Content matters, but less than you might think. Reputation and authentication are more important. That said, poor content can still land a trusted sender in spam.

Content best practices

The unsubscribe imperative

Since 2024, Gmail and Yahoo require bulk senders to implement RFC 8058 one-click unsubscribe. This means including both headers:

List-Unsubscribe: <https://example.com/unsub?id=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header enables the mailbox provider to show an unsubscribe button in the UI that works with a single click, without requiring the recipient to visit a web page. This is now mandatory for bulk senders.

Pillar 4: List Quality

Your list is your most important deliverability asset. Every other optimization is undermined by a bad list.

Building a clean list

Maintaining list hygiene

Subdomain Strategy

Separating your mail streams across subdomains is one of the most effective deliverability strategies. Here is a common setup:

Subdomain Purpose Why
mail.example.com Transactional email Password resets, receipts, notifications. Must reach the inbox. Isolated from marketing reputation.
promo.example.com Marketing / bulk email Newsletters, promotions. Higher complaint risk. Damage stays contained.
example.com Corporate / person-to-person Employee email. Should not carry any automated sending reputation.

Each subdomain gets its own SPF, DKIM, and DMARC records. Each builds its own reputation independently. If your marketing subdomain takes a reputation hit, your transactional mail continues to flow.

Monitoring and Metrics

You cannot improve what you do not measure. Track these metrics:

Metric Healthy Range Action Threshold
Delivery rate >97% <95% — investigate bounces
Bounce rate (hard) <0.5% >2% — list quality problem
Spam complaint rate <0.05% >0.1% — warning; >0.3% — critical
Open rate (marketing) 15–25% <10% — engagement or deliverability problem
Unsubscribe rate <0.5% >1% — content or frequency problem

Use these monitoring tools:

Troubleshooting Delivery Problems

Messages going to spam at Gmail

  1. Check Google Postmaster Tools for domain reputation. If it is Low or Bad, you have a reputation problem.
  2. Verify authentication: SPF, DKIM, and DMARC should all pass. Check the Authentication-Results header in a test message.
  3. Check your spam complaint rate in Postmaster Tools. Above 0.3% is the likely cause.
  4. Review your list: are you sending to unengaged recipients? Prune inactive addresses.
  5. Check for blocklist listings on your sending IPs and domains.

Messages deferred (4xx responses)

  1. Check the specific error message. Common causes: rate limiting (you are sending too fast), greylisting (retry will work), or reputation-based throttling.
  2. If rate-limited, slow down. Spread your sending over a longer period.
  3. If you are warming a new IP, you may be ramping up too quickly. Reduce volume.
  4. Check Postmaster Tools and SNDS for reputation indicators.

Messages rejected (5xx responses)

  1. Read the rejection message carefully. It usually tells you why.
  2. 550 5.1.1 — Recipient does not exist. Remove from your list.
  3. 550 5.7.1 — Policy rejection. Often blocklist or authentication failure. Check the extended message for details.
  4. 552 5.3.4 — Message too large. Reduce attachment size.
  5. 554 5.7.1 — Content or reputation rejection. Check blocklists, authentication, and content.

Sudden drop in delivery rates

  1. Check blocklists immediately. A new listing is the most common cause of sudden drops.
  2. Check for authentication changes. Did a DNS record change? Did DKIM keys rotate incorrectly?
  3. Check for infrastructure changes. New IP address? DNS provider change? TLS certificate expiry?
  4. Review recent sends. Did you send to a new, unvalidated list segment? Import a list from a partner?

The Deliverability Checklist

A complete checklist for deliverability readiness:

Key Takeaways

Further Reading

Related RFCs