Email deliverability basics

What “deliverability” actually means

Deliverability is the likelihood that a message you send lands in the recipient’s inbox rather than the spam folder — or never arrives at all. It is distinct from mere delivery: a receiving server can accept a message (no bounce) and still route it straight to spam. Broadly, every message you send ends up in one of three places:

• Inbox — accepted and placed where the recipient will see it.
• Spam — accepted but filtered into the junk folder. The message was delivered; it just won’t be read.
• Bounce — rejected outright. A hard bounce is permanent (the address doesn’t exist); a soft bounce is temporary (a full mailbox, a transient block).

One thing to internalize up front: deliverability is probabilistic, not deterministic. Every large mailbox provider makes its own filtering decision using signals it doesn’t publish, and those decisions shift over time and per-recipient. There is no configuration that guarantees the inbox. The work is about stacking the odds — and then measuring what actually happened.

Pillar 1: Authentication

Authentication proves a message is genuinely authorized to come from the domain it claims. It is table stakes — mail that can’t authenticate is treated as suspicious by default, and the largest providers now effectively require it for bulk senders. The three checks are SPF (which servers may send for your domain), DKIM (a cryptographic signature over the message), and DMARC (a policy that ties a passing SPF or DKIM result to the visible From: domain via alignment).

Authentication doesn’t by itself get you into the inbox — a perfectly authenticated message can still be filtered on reputation or content — but its absence is a reliable way to stay out. For the full mechanics of how each check works and how to read the results, see SPF, DKIM & DMARC explained and the worked DMARC by example.

Pillar 2: Sender reputation

Once a receiver knows who sent a message, it asks whether that sender has a history of sending mail people want. Reputation is tracked along two axes:

• IP reputation — the sending IP address’s track record: complaint rates, bounce rates, spam-trap hits, sending volume and consistency.
• Domain reputation — the reputation attached to your sending domain (and the DKIM d= domain). This increasingly matters more than IP reputation because it follows you even if the underlying IPs change.

Reputation is built slowly and lost quickly. A sudden spike in volume, a jump in complaints (recipients hitting “mark as spam”), or hitting spam traps can all degrade it, and there is no button to reset it — it recovers only through sustained good sending behavior.

Pillar 3: List hygiene & engagement

Who you send to, and whether they want it, is a first-class deliverability signal. Providers watch how recipients interact with your mail — opens, replies, moving a message out of spam, or conversely deleting without reading and marking as junk. Engagement is one of the strongest inbox-placement signals a large provider has, precisely because it’s hard to fake.

Practical hygiene: only send to addresses that opted in, remove hard-bounced addresses promptly, honor unsubscribes immediately, and prune chronically unengaged recipients. Sending to stale lists inflates bounces and complaints and can land you in spam traps — recycled or purpose-built addresses that exist only to catch senders with poor hygiene.

Pillar 4: Content & formatting signals

Content matters less than folklore suggests — there is no secret list of “spam words” that alone gets you filtered — but sloppy construction still hurts. Reasonable signals to get right:

• Send a well-formed message with a matching text/plain and text/html multipart body rather than HTML alone.
• Keep a sensible text-to-image ratio; a single giant image with no text is a classic low-quality pattern.
• Use links on a domain with its own good reputation, and avoid public URL shorteners that hide the destination.
• Make the From: name and address stable and recognizable, and include a working unsubscribe mechanism for bulk mail.

Pillar 5: Sending infrastructure

The plumbing your mail leaves through carries its own signals:

• rDNS / PTR — your sending IP should have a valid reverse-DNS (PTR) record that resolves back to a hostname you control. Missing or generic rDNS is a common reason mail gets penalized.
• Dedicated vs shared IP — on a shared IP your reputation is pooled with other senders; on a dedicated IP it’s entirely yours, which is only an advantage once you send enough consistent volume to establish and maintain it.
• Warmup — a new IP or domain has no reputation, so ramp volume gradually rather than blasting from cold. Providers distrust a brand-new sender that suddenly emits large volume.

Feedback loops & postmaster tools

You don’t have to fly blind. Several mailbox providers offer feedback loops (FBLs), which report back when their users mark your mail as spam so you can suppress those recipients, and postmaster tools that surface your domain’s reputation, spam rate and authentication pass rates. Combined with DMARC aggregate reports (the rua= XML summaries), these are your feedback channels for spotting a reputation problem — or a forgotten sending source — before it becomes a deliverability crisis.

How to test it

All of the above is theory until you look at a real message. The most direct check is to send your app’s outbound mail to a real inbox you own and read what actually arrived — specifically the received headers and the Authentication-Results the receiving server recorded:

Authentication-Results: mx.perenmail.com;
  spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=example.com;
  dkim=pass header.d=example.com header.s=mail2026;
  dmarc=pass (p=REJECT) header.from=example.com

That single header tells you whether SPF, DKIM and DMARC passed and aligned for this specific message — the authentication pillar verified against reality rather than against your DNS records in isolation. This is where a private, persistent testing inbox helps: point a signup, OTP or password-reset message at a Perenmail address and the raw source & header view surfaces synthesized SPF, DKIM and DMARC auth results alongside the full RFC822 message, so you can confirm your outbound authenticates before you worry about the probabilistic pillars. Raw source, headers and attachments are part of Personal+.

Testing confirms authentication and formatting — the parts you fully control. Reputation, engagement and per-provider filtering you can only influence and monitor over time, which is why deliverability is an ongoing practice rather than a one-time fix.