The complete guide to email deliverability

24 June 2026 · DMARC Engine · 14 min read

Email deliverability is the discipline of getting the messages you send to land in the inbox, not the spam folder, and not silently dropped before they ever arrive. It is often confused with "delivery": a mailbox provider can accept a message at the SMTP layer (delivery succeeds) and then quietly file it in Junk or discard it entirely (deliverability fails). For any organisation that relies on email (transactional receipts, password resets, invoices, newsletters, sales outreach), the gap between those two outcomes is the difference between a working business process and an invisible one.

This is a cornerstone guide. It covers the full picture: the authentication layer that everything else rests on, how sender reputation is actually built and lost, the 2024-25 bulk-sender requirements from Gmail, Yahoo and Microsoft, one-click unsubscribe, list hygiene, IP and domain warmup, and exactly where DMARC fits. If you read one document to understand deliverability end to end, this is intended to be it.

What "deliverability" actually means

Deliverability is the probability that a message you send reaches the recipient's inbox in a usable, visible state. It is decided by the receiving mailbox provider (Google, Microsoft, Yahoo, Apple, Proofpoint, Mimecast and the rest) using a blend of signals they mostly do not publish. Those signals fall into a few broad buckets:

• Identity and authentication. Can the receiver verify who sent this message and that it was not tampered with in transit? This is SPF, DKIM and DMARC.
• Reputation. What is the track record of the sending IP address and, increasingly more important, the sending domain? Have recipients engaged positively, ignored, or complained?
• Content and engagement. Does the message look like something a human wants, and do humans actually open, read and reply to it?
• Compliance. Does the sender honour unsubscribes, keep complaint rates low and follow the published rules for bulk senders?

No single factor controls placement. But authentication is the gate: fail it and the other factors barely matter, because many providers will reject or junk you before reputation is even considered.

Authentication: the foundation everything rests on

Three protocols establish who is allowed to send mail for your domain and let receivers detect forgeries. Get these right first; nothing else in deliverability is reliable without them.

SPF: Sender Policy Framework (RFC 7208)

SPF is a DNS TXT record that lists the IP addresses and hosts authorised to send mail using your domain in the SMTP MAIL FROM (the "envelope sender" or Return-Path). A receiver looks up the record, checks the connecting IP against it, and gets a pass or fail.

A typical record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 -all

Two details trip people up constantly:

• The 10 DNS-lookup limit. SPF evaluation must not require more than 10 DNS lookups (the include, a, mx, ptr, exists and redirect mechanisms all count). Exceed it and the result is permerror, which most receivers treat as a fail. Chaining several include: statements for Google, Microsoft, a CRM, a help-desk and a marketing tool blows past 10 quickly. The fix is to flatten the record (resolve those includes down to the underlying IP ranges) and keep it maintained as providers change their ranges. Our SPF checker counts your lookups and flags a permerror before the receivers do.
• ~all vs -all. The "all" mechanism at the end sets the policy for everything not matched. -all (hard fail) tells receivers to reject unauthorised sources; ~all (soft fail) says "probably not authorised, but accept and mark." End state should be -all, but only once you are certain every legitimate source is listed.

SPF has a well-known weakness: it breaks on forwarding. When a message is forwarded, the connecting IP changes but the original MAIL FROM does not, so SPF fails at the new hop. This is precisely why you do not rely on SPF alone.

DKIM: DomainKeys Identified Mail (RFC 6376)

DKIM attaches a cryptographic signature to the message. The sender signs selected headers and the body with a private key; the receiver fetches the matching public key from DNS and verifies it. A valid signature proves two things: the message genuinely came from a domain that holds the private key, and the signed content was not altered in transit.

The public key lives at a selector subdomain:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Practical points that affect deliverability:

• Selectors enable rotation. You can publish multiple selectors and rotate keys without downtime: bring up the new key, switch signing to it, then retire the old selector after in-flight mail clears. Keys should be rotated on a schedule, and 1024-bit RSA is now considered weak; use 2048-bit.
• Canonicalisation (c14n) matters. DKIM normalises content before signing using a canonicalisation algorithm: simple is strict and brittle (a single whitespace change downstream breaks the signature), relaxed tolerates common, harmless reformatting. relaxed/relaxed is the sensible default for most senders because mailing lists and gateways often tweak whitespace.
• Crucially, DKIM survives forwarding when the signed content is left intact, which is exactly the gap SPF leaves open.

Verify your signing and key strength with the DKIM checker, and generate correctly-sized keys with the DKIM record generator.

DMARC: the policy and reporting layer (RFC 7489)

DMARC ties SPF and DKIM to the domain a human actually sees: the From: header. It does two jobs.

First, alignment. DMARC requires that an SPF or DKIM pass be aligned with the From: domain: the authenticated domain has to match (or be an organisational-domain match for relaxed alignment). This closes the loophole where a spammer passes SPF for their own throwaway domain while forging your brand in the visible From:. A message passes DMARC if either SPF passes and aligns, or DKIM passes and aligns.

Second, policy and reporting. You publish a DMARC record telling receivers what to do with mail that fails:

v=DMARC1; p=none; rua=mailto:reports@example.com; adkim=s; aspf=s

The policy p= escalates through three stages:

• p=none: monitor only. Receivers take no action but send you aggregate (RUA) reports. This is where you start, so you can see who is sending as you before you enforce.
• p=quarantine: failing mail goes to spam. A safe interim step, often ramped with the pct= tag.
• p=reject: failing mail is refused outright. This is full protection and the goal state.

DMARC's reporting is what makes the whole journey safe: the aggregate XML reports show you every source sending under your domain, whether each passes SPF and DKIM, and whether it aligns. You use that data to authorise the legitimate senders you forgot about (the billing system, the HR tool, the field-office relay) before you turn on enforcement and accidentally block your own mail. See the enforcement journey for the staged approach, and check your current record with the DMARC checker.

Reaching p=reject does more than stop spoofing. It is now a hard prerequisite for BIMI: displaying your verified logo in the inbox requires enforced DMARC and, for the major mailbox providers, a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) and a logo in SVG Tiny PS format.

Sender reputation: how trust is earned and lost

Once you can be identified, providers track how you behave. Reputation is scored on two axes that have shifted over time.

IP reputation is the history of a sending IP address. It still matters, especially on dedicated IPs, but shared IPs mean your neighbours' behaviour affects you, and IP reputation resets when you move.

Domain reputation has become the dominant signal. Because authentication ties mail to your domain, providers can follow your reputation wherever you send from. This is mostly good news: it means you carry a portable, hard-earned reputation rather than starting over every time you change ESP or IP. It also means careless sending damages an asset you cannot easily abandon.

The inputs that move reputation up or down:

• Engagement. Opens, clicks, replies, "move to inbox," and saving messages are positive. Deletes-without-reading and prolonged ignoring are negative. Engagement is arguably the single biggest lever in modern deliverability.
• Complaints. Hitting "this is spam" is a direct, heavily-weighted negative signal. Keeping the complaint rate low is non-negotiable under the new bulk-sender rules (more below).
• Spam-trap hits. Sending to a recycled or pristine spam-trap address signals poor list hygiene and can tank reputation fast.
• Bounce rate. A high rate of hard bounces (non-existent mailboxes) signals you are mailing a stale or purchased list.
• Volume consistency. Sudden spikes (going from 500 to 500,000 messages overnight) look like a compromised account or a spam run, even if the mail is legitimate.

The 2024-25 bulk-sender rules

In February 2024, Google and Yahoo introduced aligned requirements for "bulk senders", broadly those sending roughly 5,000 or more messages a day to their users. Microsoft followed with its own equivalent requirements for high-volume senders into Outlook.com / Hotmail consumer domains, phased in through 2025. These rules effectively turned long-standing best practice into mandatory policy. The headline requirements:

• Authenticate with SPF and DKIM. Both must be set up. This is no longer optional for bulk senders.
• Publish a DMARC policy. At minimum p=none is required to be in compliance, but none only satisfies the letter of the rule and provides no protection. The intent, and the safe destination, is enforcement.
• Enforce alignment. The visible From: domain must align with the authenticated domain (SPF and/or DKIM), which is exactly what DMARC measures.
• One-click unsubscribe (RFC 8058). Marketing and promotional mail must include a functional List-Unsubscribe header supporting one-click removal, and the request must be honoured within a short window (two days). The header pairs List-Unsubscribe with List-Unsubscribe-Post: List-Unsubscribe=One-Click.
• Keep complaint rates low. Google publishes a clear threshold: keep the user-reported spam rate below 0.3%, and ideally well under 0.1%. Sustained rates above this lead to throttling and junking.
• Send wanted mail to real addresses. No purchased lists, no sending to people who did not opt in.

If you send any meaningful volume to consumer mailboxes, treat these as the baseline. The practical upshot is that authentication plus a working unsubscribe plus a clean list is now the entry ticket, not a competitive advantage.

One-click unsubscribe done right

A correct one-click header looks like this:

List-Unsubscribe: <https://example.com/u/abc123>, <mailto:unsub@example.com?subject=unsub>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The mailbox provider can then POST to the URL to unsubscribe the user without them leaving the inbox. Two failure modes to avoid: the link must not require login or extra confirmation steps for the one-click flow, and the suppression must actually take effect. Continuing to mail someone who unsubscribed is both a compliance breach and a near-guaranteed spam complaint.

List hygiene: protecting the asset

A clean list is the cheapest, highest-leverage deliverability investment you can make. The principles:

• Confirmed opt-in. Ideally double opt-in for marketing: the subscriber confirms via a link before you mail them. This eliminates typo'd and fake addresses and proves consent.
• Validate at the point of capture. Reject obvious typos and disposable domains in the signup form, before a bad address ever enters the list.
• Suppress hard bounces immediately. A hard bounce means the mailbox does not exist. Never mail it again. Repeated sends to dead addresses are a strong stale-list signal.
• Re-engage or remove the inactive. Subscribers who have not opened in 6-12 months drag down engagement metrics. Run a win-back campaign; if they stay silent, sunset them. A smaller engaged list outperforms a large dormant one on placement.
• Avoid role and spam-trap addresses. Steer clear of info@, sales@, postmaster@ style addresses in marketing, and never buy or scrape lists. Purchased lists are riddled with spam traps that exist specifically to catch you.

Warmup: building reputation deliberately

A brand-new sending IP or domain has no reputation, and providers are suspicious of unknown senders that suddenly push high volume. Warmup is the practice of ramping volume gradually so providers can build a positive history.

The mechanics:

• Start small and grow steadily. Begin with a modest daily volume and increase it over several weeks, roughly doubling at intervals while watching for throttling or bounces.
• Lead with your best, most-engaged recipients. Early in warmup, send only to people most likely to open and click. Strong early engagement teaches providers you are a wanted sender.
• Warm the domain, not just the IP. Because domain reputation now dominates, a new domain needs warming even on an established IP. If you launch a new subdomain for marketing mail (a good practice, see below), warm it.
• Keep volume and cadence consistent. Erratic sending undoes warmup. Predictability is itself a positive signal.

Subdomain strategy

Separate your mail streams by subdomain so a problem in one cannot poison another. A common, robust split:

• Transactional mail (receipts, resets) from mail.example.com or similar.
• Marketing and newsletters from news.example.com.
• Keep the root domain's reputation pristine.

This isolation means a bad marketing send cannot harm your password-reset deliverability, and vice versa. Note that DMARC policy is inherited by subdomains unless you override it with the sp= tag, so plan your policy across the whole tree.

Content and infrastructure hygiene

Smaller factors that still tip borderline messages into spam:

• Valid reverse DNS (PTR) and FCrDNS. Your sending IP should have a PTR record that resolves back to a hostname that forward-resolves to the same IP. Check it with the PTR record checker.
• TLS in transit. Send and receive over TLS. Adding MTA-STS (RFC 8461) tells sending servers to require TLS and refuse to downgrade, protecting mail in transit and signalling a mature setup.
• Clean HTML and a healthy text-to-image ratio. Image-only emails, broken HTML, link shorteners and mismatched display/destination URLs all raise spam scores.
• A real, monitored From address and reply path. "noreply@" that black-holes replies suppresses a positive engagement signal (replies) and frustrates recipients.
• Check blocklists. If a sending IP or domain lands on a major blocklist, deliverability collapses. Monitor with a blacklist checker and have a remediation path.

Where DMARC fits in the bigger picture

It is worth being precise about DMARC's role, because it is frequently over- and under-sold. DMARC does not, by itself, get you into the inbox. It is not a content filter or an engagement booster. What it does is three things that are foundational to everything else:

1. It stops exact-domain spoofing. At p=reject, criminals cannot send phishing that appears to come from your exact domain. That protects your recipients and, over time, your domain's reputation, because the abusive mail that would otherwise erode it never gets sent in your name.
2. It gives you visibility. RUA reports are the only place you see the complete inventory of who sends under your domain. That data is how you fix SPF/DKIM gaps and reach the bulk-sender bar safely.
3. It unlocks the next layer. Enforced DMARC is the prerequisite for BIMI and the inbox logo, which improves recognition and trust, a genuine, if indirect, engagement benefit.

In short: authentication (SPF + DKIM + DMARC) is the price of entry; reputation, engagement and hygiene decide placement above that floor. You cannot win on reputation while failing authentication, which is why this guide starts there.

Next steps

If you want a pragmatic order of operations:

1. Audit what you have. Run your domain through the DMARC checker and SPF checker to see your current records, lookup count and alignment.
2. Fix authentication. Get SPF under the 10-lookup limit (flatten if needed), enable 2048-bit DKIM with relaxed/relaxed canonicalisation, and publish DMARC at p=none with a rua address.
3. Read the reports, then enforce. Use hosted DMARC to collect and parse RUA data, authorise every legitimate sender, then ramp through quarantine to reject following the enforcement journey.
4. Meet the bulk-sender rules. Add one-click unsubscribe, keep complaints under 0.3%, and clean your list.
5. Protect and extend. Add MTA-STS for TLS enforcement and, once at p=reject, pursue BIMI for the inbox logo.

DMARC Engine is built to carry you through that whole sequence: flattening SPF, managing DKIM keys with rotation reminders and overlapping-selector support (not automatic rotation), parsing DMARC reports into a plain-language sender inventory, and guiding the staged ramp to p=reject without an email outage. Get the foundation right and the rest of deliverability becomes a matter of sending wanted mail to people who asked for it.