Email deliverability in 2026 — the standards, the warmup, the feedback loop.

§1 · Definition

What email deliverability actually is.

Deliverability is the rate at which your sent messages reach the recipient's primary inbox — distinct from delivery (the message was accepted by the recipient mail server) and from send (you handed it to the sending pipeline). A message can be sent successfully, delivered to the recipient mail server, and end up in the spam folder — that's a delivery success and a deliverability failure. The numbers people care about — open rate, click rate, conversion — depend on deliverability, not delivery.

Mailbox providers — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, the major regional providers — each run a multi-stage scoring pipeline against every incoming message. The stages are roughly the same across providers, with weight differences:

1. Connection-time checks. Reverse DNS, HELO/EHLO sanity, TLS support, IP listing on RBLs (Spamhaus, SpamCop, etc).
2. Authentication checks. SPF pass/fail (RFC 7208), DKIM signature validation (RFC 6376), DMARC alignment (RFC 7489). All three must pass cleanly for the most lenient downstream scoring.
3. Content scoring. Spam-keyword density, link reputation, image-to-text ratio, whether the From-name matches the From-address.
4. Reputation lookup. The provider's internal record of your sending IP and From-domain — historical bounce rate, complaint rate, engagement on prior sends.
5. Engagement signal. Did the recipient (or recipients in their cohort) open or click similar messages from you previously? Recent engagement is the strongest single positive signal.
6. Disposition. Inbox, Promotions tab (Gmail), spam folder, or reject. The disposition feeds back into reputation.

The five sections below address stages 2 (authentication) and 4 (reputation). Stage 1 is mostly the sending relay's job; stages 3 and 5 are content + audience decisions outside the scope of a deliverability guide. Stage 6 is the output. For a typical commercial sender, getting stages 2 and 4 right takes you from 60–80% inboxing to 95%+.

This guide is written for self-hosted operators because you're the one tuning the dials. On SaaS the platform abstracts most of this; on self-hosted you own the SPF record, the DKIM keypair, the DMARC policy, the IP warmup schedule. The good news: the standards are public and stable. The bad news: there are no shortcuts.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) is a public list of IP addresses authorised to send email on behalf of your domain. You publish it as a single TXT record on your sending domain. When a mailbox provider receives a message claiming to be from @yourcompany.com, it looks up the SPF record at yourcompany.com and asks: did this message come from one of the listed IPs? If yes, SPF passes. If no, SPF fails.

The syntax

v=spf1 include:amazonses.com ~all

Reads as: "SPF version 1, authorize anything Amazon SES authorizes, soft-fail anything else." The ~all at the end is the catch-all clause. ~all = soft-fail (mark suspicious but accept), -all = hard-fail (reject), ?all = neutral (no opinion). Use ~all until DMARC is healthy, then tighten to -all.

Multiple senders (e.g. Google Workspace for outbound + SES for marketing + Mailgun for transactional) chain with multiple include: mechanisms:

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

The 10-DNS-lookup limit. RFC 7208 §4.6.4 caps SPF resolution at 10 DNS lookups total. Each include: counts as one. A common failure: chaining 5+ vendors and tripping the limit, after which SPF resolves to permerror and is treated as fail. Audit with dig TXT yourcompany.com + an SPF flattener if you're near the limit.

SPF in AcelleMail

AcelleMail's SendingDomain model exposes getSpf() at app/Model/SendingDomain.php:154, which reads the global spf_record setting and renders the TXT record value. The verifySpf(string $ipOrHostname) method at line 363 wraps the Mika56\SPFCheck library — it queries the live DNS at runtime and asserts RESULT_PASS. The verification surface in the admin UI shows green when the record is present and authorizes the sending IP, red otherwise.

Practical tip: SPF only authenticates the envelope sender (the SMTP-level MAIL FROM), not the visible From-header. That distinction is what DMARC alignment fixes — see §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) attaches a cryptographic signature to every outgoing message. The receiving server fetches your public key from a TXT record in DNS, verifies the signature against specific message headers and the body, and accepts the message as authentic if the math works. SPF says "this IP is allowed to send for us"; DKIM says "this exact message body and From-header haven't been tampered with since we signed it."

The mechanism

1. You generate an RSA keypair (1024-bit minimum, 2048-bit recommended for new setups).
2. The public key goes into DNS as a TXT record at {selector}._domainkey.{yourdomain}. The selector is an arbitrary string (e.g. k1, mail, 20251208) you pick to allow rotating keys without breaking inflight messages.
3. The private key stays on your sending server. The MTA (or sending relay) signs each outgoing message with it, adding a DKIM-Signature header.
4. The recipient mail server reads the d= (domain) and s= (selector) values from the signature header, looks up {s}._domainkey.{d}, fetches the public key, and verifies.

DKIM in AcelleMail

SendingDomain::generateDkimKeys() at app/Model/SendingDomain.php:221 generates a 1024-bit RSA keypair via PHP's OpenSSL bindings, stores the private half on dkim_private, and stores the public half on dkim_public. The selector is read from dkim_selector on the model, falling back to the global dkim_selector setting. The DNS record value renders via $this->getDomain()->getDkimDnsRecord() (line 270) and is shown to the operator with a copy button next to "the value to publish."

The key generation pattern (from generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verification: $this->getDomain()->verifyDkim() queries DNS at {selector}._domainkey.{domain} and compares the published public key against the locally stored value. The full verify() method on the model orchestrates identity + DKIM + SPF + DMARC checks in one call (line 300).

Vendor-managed DKIM

If you're sending through Amazon SES, SendGrid, Mailgun, or any other vendor that signs on its end, you publish the vendor's selector + public key instead of generating your own. AcelleMail's driver-level SignsDkimOnServer capability (see app/SendingServers/Capabilities/SignsDkimOnServer.php) flags drivers that handle DKIM remotely; the UI then shows the vendor's CNAME records to publish instead of generating local keypair. SES uses three CNAMEs that delegate _domainkey to amazonses.com — set them once and SES rotates the underlying key for you.

§4 · DMARC

DMARC — alignment, policy, and reporting.

DMARC (RFC 7489) sits on top of SPF and DKIM. It does three things SPF and DKIM individually don't:

1. Alignment. Requires that the SPF-validated envelope domain or the DKIM-signing domain matches the visible From-header domain. Without alignment, SPF and DKIM can pass for a different domain than the one the recipient sees — the gap that phishing exploits.
2. Policy. Tells receiving servers what to do when alignment fails: none (do nothing, just report), quarantine (deliver to spam), reject (refuse the message at SMTP).
3. Reporting. Aggregate reports (RUA — daily XML reports of all sends from your domain) and forensic reports (RUF — per-failure individual reports) sent to addresses you specify. Reports give you visibility into who's sending mail claiming to be you.

The syntax

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Reads as: "DMARC version 1, quarantine messages that fail alignment, send aggregate reports to dmarc@yourcompany.com, apply policy to 100% of failing messages, require strict alignment for both SPF and DKIM."

The standard rollout

1. Day 0: publish p=none with rua= pointing at a monitored mailbox. Accept reports for 7–14 days. This is observe-only — no message is rejected.
2. Day 14: review reports. Identify legitimate senders (your own SES, your CRM's sending IPs, transactional providers) and bring them all into SPF + DKIM alignment.
3. Day 30: tighten to p=quarantine; pct=10. Misaligned mail goes to spam for 10% of recipients. Watch reports for two weeks.
4. Day 45: escalate to pct=50, then pct=100 over 2–4 weeks.
5. Day 60–90: tighten to p=reject. Now misaligned mail bounces at SMTP — phishers using your domain see hard rejects.

Don't skip the rollout. Going straight from no DMARC to p=reject is the most common cause of self-inflicted deliverability disasters: a forgotten transactional sender (your CRM, your support tool, your billing system) starts hard-bouncing the moment p=reject propagates.

Mailbox provider mandates

As of February 2024, Gmail and Yahoo require DMARC for any sender that emails > 5,000 messages per day to their domains, plus aligned SPF or DKIM, plus one-click List-Unsubscribe (RFC 8058). Microsoft 365 has aligned with the same standard at the time of writing. The bar for "commercial sending" has moved permanently — DMARC is no longer optional for any list above ~1,000 contacts. Set it up early, even if your list is still small.

§5 · BIMI

BIMI — the brand-logo bonus.

BIMI (Brand Indicators for Message Identification) displays your brand logo next to your messages in the recipient's inbox. Gmail, Yahoo, Apple Mail, and Fastmail support it as of 2025. It's a deliverability-adjacent feature — not authentication itself — but it requires DMARC at p=quarantine or p=reject as a prerequisite, which is why it lives in this guide.

Setup steps (after DMARC is at quarantine or stricter):

1. Create an SVG version of your logo following the BIMI SVG Tiny PS spec — square, no text outside the mark, simple paths.
2. Host the SVG at a publicly-accessible HTTPS URL.
3. Optionally obtain a Verified Mark Certificate (VMC) from a CA — required by Gmail to display the badge with a blue check, ~$1,500/year. Common Mark Certificates (CMC) are a cheaper alternative for unregistered brands.
4. Publish the BIMI record: default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

BIMI's deliverability impact is indirect but measurable: brand logos in the inbox lift open rates 5–20% in published case studies (Yahoo Mail's pilot data, Mailchimp's BIMI report). It's also a strong forcing function — you can't enable BIMI without first hardening DMARC, so teams use it as the carrot for an authentication clean-up.

§6 · Reputation

Reputation — what mailbox providers actually score.

Authentication is binary — a record either resolves and aligns or it doesn't. Reputation is continuous: a score from 0 to 100 maintained by each mailbox provider, against your sending IP and your From-domain independently. The two scores combine into the routing decision (inbox vs Promotions vs spam vs reject).

The signals

Where to read your reputation score

• Google Postmaster Tools (postmaster.google.com) — IP and domain reputation per Gmail's view, plus authentication compliance, encryption rate, spam rate. Free.
• Microsoft SNDS (postmaster.live.com/snds/) — Outlook.com's IP-level data, sender reputation classifications. Free, requires registration.
• Yahoo Sender Hub — newer, signups via Yahoo Postmaster page. Aggregate stats per domain.
• Provider dashboards — Amazon SES Reputation Dashboard surfaces bounce + complaint rates with thresholds. SparkPost, Mailgun, SendGrid all have similar.

Check at least one weekly. The leading indicators (spam rate trend, IP reputation drop) appear days before downstream effects (open rate dropping) — by the time you notice a campaign underperforming, the reputation issue is already two weeks old.

§7 · IP warmup

IP warmup — the 6-week schedule.

A fresh sending IP starts at zero reputation. Mailbox providers throttle high volumes from new IPs by design — it's the primary defence against snowshoe spammers spinning up cloud instances and blasting. Warmup is the practice of gradually increasing send volume over 4–6 weeks while staying inside per-day and per-hour throttle limits, building reputation organically.

You only do this once per IP. Most teams never do it because Amazon SES, SendGrid, and Mailgun's shared IPs come pre-warmed. The cases where warmup matters: dedicated IP on SES (typically > 1M sends/month justifies one), self-hosted Postal MTA on a fresh cloud instance, migration from one ESP to another with a domain change.

The schedule

Schedule based on the SparkPost / Postmark / SES published warmup recommendations consolidated to a single week-by-week table. Ramp slower than this if you see complaint rate trending upward; ramp faster only if you have provider-confirmed reputation green-light at every step.

Warmup tracking in AcelleMail

AcelleMail's SendingServer model has first-class warmup state. warmup_enabled, warmup_strategy_id, and warmup_started_at live on the sending_servers table; isWarmupEnabled() at app/Model/SendingServer.php:333 gates send-time decisions. The companion SendingServerWarmupLog table records every send during the warmup window with date, status, and a serialized meta payload — see app/Model/SendingServerWarmupLog.php.

The pattern: assign a WarmupStrategy (a row defining the per-day volume curve) to a sending server, flip warmup_enabled = true, set warmup_started_at = now(). The send pipeline's SendingServerWarmupUsage tracks today's count and refuses to dispatch beyond the strategy's daily ceiling. When the strategy's day-N ceiling exceeds your full daily volume, the server graduates and warmup mode auto-disables.

The DynamicRateTracker and InMemoryRateTracker classes (app/Library/) handle per-minute / per-hour rate limiting at the SMTP layer — even outside warmup, AcelleMail enforces the relay's published rate caps so a queue surge doesn't trip provider-side throttling.

§8 · Bounces + complaints

Bounces, complaints, and the feedback loop.

Hard vs soft bounces

A hard bounce is a permanent failure — typically a 5xx SMTP code: the address doesn't exist, the domain doesn't resolve, the recipient's mailbox is permanently disabled. AcelleMail's BounceLog model defines the constants HARD and SOFT at app/Model/BounceLog.php:33; a hard bounce immediately suppresses the address. A soft bounce is transient — a 4xx code: mailbox full, server temporarily unavailable, message too large. Soft bounces retry on a backoff schedule; addresses that soft-bounce repeatedly across sends are eventually demoted to hard.

The classification map for AWS SES bounce notifications (the source AcelleMail's BounceLog.php:32 documentation cites): bounce types include Permanent (hard) with sub-types General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (soft) with sub-types General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; plus Undetermined (treat as soft, retry).

Complaints

A complaint is a recipient hitting "report as spam" in their email client. Complaints arrive via Feedback Loops (FBLs) — a per-provider notification channel where ISPs forward you the abuse-reported messages. AcelleMail's FeedbackLoopHandler at app/Model/FeedbackLoopHandler.php processes inbound FBL messages over IMAP/POP and parses the Abuse Reporting Format (ARF, RFC 5965) headers to extract the original message ID and the feedback type.

ARF feedback types that AcelleMail handles (per FeedbackLoopHandler::FEEDBACK_TYPES at line 35):

• abuse — recipient explicitly marked as spam. Suppress immediately.
• fraud — recipient marked as phishing. Suppress + log to security review.
• virus — recipient's antivirus flagged a payload. Suppress + audit content.
• other — generic complaint. Suppress.
• not-spam — explicit "this isn't spam" report (rare). Excluded from suppression — see EXCLUDED_FEEDBACK_TYPES.

Major mailbox providers participating in FBLs: AOL, Yahoo, Microsoft (via JMRP), Comcast, BlueTie. Gmail does not run a public FBL — they deliver "marked as spam" feedback through the Postmaster Tools dashboard and through aggregate DMARC reports.

Suppression rules

1. Hard bounce → suppress permanently. Never re-attempt; address is dead.
2. Complaint → suppress permanently. Recipient has actively asked to stop. Re-sending is illegal in most jurisdictions and torches reputation.
3. Soft bounce ×3 in 30 days → demote to hard, suppress. Persistent soft bounces are mailbox-full or persistent connectivity issues — treat as dead.
4. Unsubscribe → suppress for marketing, not for transactional. Order receipts and password resets continue; campaigns stop.
5. Spam-trap hit → escalate to investigation. Pull the entire acquisition source for that subscriber. List was likely contaminated with purchased or scraped addresses.

§9 · List hygiene

List hygiene — the discipline that keeps reputation high.

Authentication is one-time setup. Reputation is operational discipline. The seven habits that move the dial:

1. Double opt-in for all marketing signups. A confirmation click before the address joins the active list. Eliminates typos, role addresses (info@, sales@), and harvested addresses. Adds 10–20% friction to signup; subtracts 50–80% of the bounce/complaint risk.
2. One-click unsubscribe (RFC 8058). List-Unsubscribe header pointing at a one-click URL. Required by Gmail and Yahoo for senders > 5K/day to their domains since February 2024. Make unsub easier than complaint — recipients who'd hit "spam" hit "unsubscribe" instead.
3. Re-engagement before suppression. Subscribers who haven't opened in 90 days get a "we want to keep being relevant" campaign. Open → keep. No open → move to a sunset queue. No open after 180 days → suppress.
4. Bounce auto-suppression. Process the bounce webhook within minutes; remove from the active sending list before the next campaign. AcelleMail's BounceLog::record() and vbrandsync-style bounce-webhook handlers do this automatically.
5. Don't import purchased lists. Ever. Purchased lists are seeded with spam traps. One trap hit and your domain is on Spamhaus for 30+ days. The math never works — purchased lists are a permanent reputation sink.
6. Segment by engagement. Send campaigns to the engaged 50% twice as often, the cold 50% half as often. Drives up overall open rate, drives down complaint rate, and gives mailbox providers a strong "this sender is relevant" signal.
7. Cap automation cadence. A welcome series + abandoned-cart + post-purchase + birthday + re-engagement can produce 8 messages in a single week. Cap total automation messages at one per 48 hours per recipient, with hard exceptions for transactional (receipts, password resets).

§10 · Acelle tooling

AcelleMail's deliverability tooling — what the source ships.

Pulled directly from /Users/luan/apps/acelle/app/. Every entry is a real model, capability interface, or library class — not marketing.

§11 · Troubleshooting

Common deliverability problems and fixes.

§12 · FAQ

Email deliverability FAQ.

Cluster head

Where to go next.

Authenticated domains. Tracked bounces. Inbox-grade reputation.

AcelleMail ships SPF/DKIM/DMARC verification, ARF feedback-loop processing, IP warmup state machine, and per-server rate limiting in the box. Every claim in this guide maps to a class in app/Model/ or app/Library/ in the source tree.