Email Deliverability in 10 Minutes

Transactional mail is triggered by a user's action: password reset, receipt, security alert, or account notification. Marketing mail is promotional or editorial and must be easy to unsubscribe from. They have different urgency, consent, volume, and complaint patterns. Put them on separate subdomains, sending streams, and ideally separate IP pools once volume justifies dedicated infrastructure.

# One practical identity split
[email protected]   # transactional
[email protected]  # marketing

Return-Path: [email protected]
DKIM-Signature: ... d=notify.example.com; s=tx2026;

List-Unsubscribe: <https://example.com/unsubscribe/...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

SMTP carries an envelope sender and envelope recipients before it carries the message headers. The envelope sender, shown later as Return-Path, receives bounces and is the identity SPF evaluates. The header From address is what a person sees and what DMARC protects. These addresses may differ, but their domains need deliberate alignment.

S: 220 mx.receiver.test ESMTP
C: EHLO mail.notify.example.com
C: MAIL FROM:<[email protected]>
C: RCPT TO:<[email protected]>
C: DATA
C: From: Example Receipts <[email protected]>
C: To: Alex <[email protected]>
C: Subject: Your receipt

Envelope MAIL FROM → SPF and bounces
Header From        → visible identity and DMARC alignment

When a message bounces, preserve the SMTP reply, queue ID, recipient, sending stream, and provider message ID. A screenshot saying “email failed” throws away the only useful evidence.

SPF is a DNS TXT policy on the envelope sender's domain. It says which hosts may send using that domain. Publish exactly one SPF record per domain, include every legitimate sender, stay below the ten DNS-lookup limit, and end with a deliberate policy. SPF does not validate the visible From address by itself.

# DNS TXT at bounces.notify.example.com
v=spf1 include:spf.mail-provider.example -all

Received-SPF: softfail (domain of transitioning
[email protected] does not designate 192.0.2.44
as permitted sender) client-ip=192.0.2.44;

DKIM adds a cryptographic signature covering selected headers and the body. The signature names a domain with d and a selector with s. The receiver fetches the public key at selector dot underscore domainkey dot signing domain. Use at least 2048-bit keys when supported, rotate selectors, and keep the old key published while old mail can still be verified.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=notify.example.com; s=tx2026;
 h=from:to:subject:date:message-id; bh=...; b=...

Authentication-Results: mx.receiver.test;
 dkim=fail (DKIM signature verification failed)
 header.d=notify.example.com header.s=tx2026;

DMARC passes when either SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Alignment compares those domains with the visible header From domain. Relaxed alignment permits subdomains under the same organizational domain; strict alignment requires an exact match. An SPF pass for a provider's unrelated bounce domain does not help your DMARC result.

From: [email protected]
Return-Path: [email protected]   # SPF pass, not aligned
DKIM-Signature: d=notify.example.com; ...   # DKIM pass, aligned relaxed

# Start by collecting reports; enforce after every sender is known.
_dmarc.example.com TXT
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

# Later: p=quarantine, then p=reject

550 5.7.26 This mail is unauthenticated, which poses a security risk
to the sender and users, and has been blocked. The sender must
authenticate with at least one of SPF or DKIM.

A receiving server sees the connecting IP and the hostname announced in EHLO or HELO. The IP should reverse-resolve through PTR to a real mail hostname, and that hostname should forward-resolve back to the same IP. Set PTR through the owner of the IP, usually your hosting or email provider. Ordinary DNS hosting cannot create reverse DNS for an address you do not control.

192.0.2.44 PTR mail.notify.example.com.
mail.notify.example.com A 192.0.2.44
EHLO mail.notify.example.com

550 5.7.1 Client host rejected: cannot find your reverse hostname

# Verify both directions
dig -x 192.0.2.44 +short
mail.notify.example.com.
dig mail.notify.example.com A +short
192.0.2.44

For that rejection, first confirm the outbound IP from the earliest external Received header. Ask the IP provider to set its PTR, create the matching A record, configure the mail server's HELO to that hostname, and reconnect. A PTR pointing to a generic cloud name is technically resolvable but still a poor identity.

Authentication answers who sent the mail. Reputation asks whether recipients want mail from that domain and IP. Complaint rate, hard bounces, spam traps, engagement, volume spikes, and message consistency all matter. A brand-new dedicated IP has no useful reputation; warm it with wanted mail and predictable daily volume. At low volume, a reputable shared pool is often safer than your own cold IP.

# Watch trends by stream and mailbox provider
accepted rate      99.4%
temporary deferral  2.1%
hard bounce         0.6%
complaint            0.08%

421 4.7.0 Temporary System Problem. Try again later.
451 4.7.1 Please try again later

For a temporary deferral, keep the original reply, slow that destination's sending rate, retry with exponential backoff and jitter, and look for a recent volume or complaint change. Do not retry every minute from several servers; that turns throttling into abusive behavior. Reputation recovery is mostly fewer unwanted messages sent consistently.

A hard bounce says the address is permanently undeliverable and should be suppressed immediately. A soft bounce is temporary and may be retried with a limit. A complaint says the recipient marked the message as spam; suppress that recipient across the relevant marketing stream immediately. Parse provider events into reason, enhanced status code, recipient, campaign, and permanent or transient class.

550 5.1.1 The email account that you tried to reach does not exist.
552 5.2.2 Mailbox full
421 4.4.2 Connection timed out

5.1.1 → hard bounce → suppress address now
5.2.2 → policy-dependent retry, then suppress after limit
4.4.2 → retry with backoff; preserve attempt history
complaint event → suppress immediately; audit source and campaign

Use confirmed opt-in when address quality matters, record source and consent time, validate obvious syntax errors at entry, and send the promised kind of mail. Remove hard bounces, complaints, and long-term unengaged recipients according to a documented policy. Never buy a list. It contains stale addresses, traps, and people who did not ask to hear from you.

# Minimum subscription audit record
address: [email protected]
source: pricing-page-form
consented_at: 2026-07-25T10:42:13Z
confirmed_at: 2026-07-25T10:44:02Z
policy_version: marketing-v3

# Every marketing message
visible unsubscribe link
one-click unsubscribe headers
working preference endpoint
suppression applied before queueing

Do not delete disengaged people merely to make the open rate chart prettier, and do not keep mailing them forever. Define a sunset flow based on your sending cadence. Also treat opens cautiously because privacy proxies inflate them; clicks, replies, purchases, and explicit preferences are stronger signals.

For a delivered message, download the original raw source. Read Received headers from the bottom upward to reconstruct the route. Find Authentication-Results added by the receiver, then compare header From, Return-Path, DKIM d and s, Message-ID, Date, and unsubscribe headers. For a rejected message, start with the SMTP reply because there may be no final message headers.

# Header triage
Authentication-Results: spf=pass; dkim=pass; dmarc=pass
From: visible domain used for DMARC
Return-Path: envelope domain used for SPF and bounces
DKIM-Signature: d= signing domain; s= selector
Received: route, timestamps, connecting identities
Message-ID: stable correlation key

# Fix order
1. Capture raw SMTP reply or raw received message
2. Identify stream, provider message ID, recipient, and timestamp
3. Verify PTR ↔ A and HELO for the outbound IP
4. Verify one SPF record for the Return-Path domain
5. Verify DKIM selector DNS and post-signing modifications
6. Verify SPF or DKIM alignment with header From
7. Check bounce, complaint, volume, and reputation trends
8. Send a new test; old messages do not re-authenticate

# Meaning of common results
550 5.7.26 unauthenticated → repair SPF/DKIM and alignment
SPF softfail → actual IP not authorized for envelope domain
DKIM signature failed → key mismatch or message changed
550 5.1.1 → suppress nonexistent recipient
421 / 451 → defer and retry with controlled backoff

My order is identity first, reputation second, content last. If the server says SPF softfail, changing the subject line is superstition. If authentication passes but one mailbox provider throttles a campaign, inspect audience quality, complaints, and volume there. Deliverability is an operational feedback loop, not a DNS setup task you finish once.