Deliverability, explained by people who operate it.

Guides

• Email Deliverability Best Practices Playbook One deep, skimmable playbook for legitimate bulk and transactional senders, synthesized from the standards bodies (M3AAWG, IETF), the mailbox providers (Gmail, Yahoo, Microsoft, Apple, Orange, GMX), the major blocklist (Spamhaus), and the leading ESP documentation. Every section is a checklist that links out to our deep pages, and we use only the thresholds providers actually publish - no invented warmup curves, no universal score myths.
• Email Headers and the SMTP Envelope, Explained A message has two layers most people conflate: the SMTP envelope that moves it, and the RFC 5322 header block a person reads. This guide walks through both, every header that matters for deliverability and authentication, and how to read a full raw header set top-down to find a message's origin.
• Email Forwarding and Redirection, Explained Forwarding is where authentication goes to die: SPF breaks the moment the relaying IP changes, and list software breaks DKIM by editing the message. This guide explains exactly what breaks and why, the mechanisms involved - Sieve redirect, aliases, SRS, ARC - and how to build a forwarding product that does the least harm.
• How to Report Email Abuse: Spam & Phishing A practical, standards-based guide to reporting email abuse. How to tell what counts as abuse, trace the real source from the headers, find the responsible network's abuse contact, and route the report to the place that can act on it - the sending provider, your mailbox provider's "report spam" button, APWG and government phishing channels, or a blocklist.

Authentication

• Email Authentication: SPF, DKIM, DMARC, ARC, BIMI SPF, DKIM, and DMARC are not interchangeable, and none of them on their own tells a receiver a message is safe. This is the map: what each layer checks, what a pass actually proves, and how alignment, ARC, and BIMI sit on top.
• DMARC in 2026 (RFC 9989, 9990, 9991) The RFC most "DMARC explained" articles still cite is obsolete. In May 2026 DMARC was re-issued as three Standards-Track RFCs. Here is everything that changed - tags, the Tree Walk, reporting, and the new p=reject guidance - in plain language, with records you can copy.
• SPF Deep Dive (RFC 7208) SPF authorizes which hosts may use your domain in the SMTP envelope. This is the full RFC 7208 picture: record format, every mechanism and qualifier, the hard 10-lookup limit that breaks records, the result codes, and the mistakes that quietly cause permerror.
• DKIM Deep Dive (RFC 6376) DKIM signs a message so a domain can take cryptographic responsibility for it. This is the full RFC 6376 picture: selectors, the signature and key tags, simple vs relaxed canonicalization, the l= body-length trap, key rotation, and the crypto updates from RFC 8301 and RFC 8463.
• ARC: Authenticated Received Chain (RFC 8617) ARC preserves a message's authentication result across the intermediaries that break SPF and DKIM. This is the RFC 8617 picture: the three header fields, how a chain is built and validated, the chain-validation states, and the honest limits - ARC is advisory, not a pass.
• BIMI: Logos, DMARC, and Mark Certificates BIMI puts a brand logo next to authenticated mail, but it authenticates nothing itself - it rides on enforced DMARC. This covers the prerequisites, the SVG Tiny PS logo, VMC and CMC mark certificates, the DNS record, and the honest provider-support reality.

Sender requirements

• Gmail, Yahoo, Microsoft & Apple Sender Rules A side-by-side tracker of what Gmail, Yahoo, Microsoft Outlook.com, and Apple iCloud actually require of senders - with the exact thresholds, the effective dates, and an honest note on where each provider stays silent.
• Gmail Sender Guidelines & Bulk Sender Rules What Google actually requires to deliver to personal Gmail accounts - every sender authenticates, bulk senders (5,000+/day) clear a higher bar, and the spam-complaint rate is the number that decides your fate. Quoted directly from Google's published guidelines.
• Yahoo & AOL Sender Requirements Yahoo's requirements - which also cover AOL and other Yahoo-hosted brands - rolled out alongside Gmail's in early 2024. Yahoo authenticates the same way but deliberately publishes no volume threshold and runs its own Complaint Feedback Loop through Sender Hub.
• Microsoft Outlook.com Sender Requirements Microsoft brought Outlook.com into line with Gmail and Yahoo in May 2025 - SPF, DKIM, and aligned DMARC for senders of 5,000+ messages a day. The published post is internally contradictory about whether non-compliant mail is junked or rejected; here is exactly what it says.
• Apple iCloud Mail Sender Guidance Apple's iCloud Mail guidance is the quiet one - no volume threshold, no spam-rate number, no feedback loop, and no allow list. It is a list of hard requirements whose failure means rejection, and an honest map of what Apple chooses not to tell you.
• Orange & Wanadoo Sender Requirements Orange runs the mailboxes behind orange.fr and wanadoo.fr and now requires SPF, DKIM and DMARC to all pass on every message. This page covers Orange's published delivery guidelines, its rules for senders above 1,000 messages a day, the per-connection and size limits, and the complete Orange error-code table with fixes.
• GMX & WEB.DE Sender Requirements GMX and WEB.DE are both run by United Internet on one mail platform. Their postmaster guidance makes a valid, aligned DKIM signature mandatory - SPF and DMARC are recommended, but DKIM is the floor - and layers consent, M3AAWG/CSA standards, and RFC 8058 unsubscribe on top for bulk senders.
• Comcast / Xfinity Sender Requirements Comcast publishes a detailed but legacy postmaster site for comcast.net senders - rDNS rules, SenderScore-keyed rate limits, documented BL/RL block codes, and a feedback loop. The headline for 2026 is bigger than any single rule: Comcast is moving comcast.net mailboxes to Yahoo Mail, so Yahoo's requirements increasingly govern this audience.
• Fastmail Sender Requirements Fastmail is a paid, privacy-respecting mailbox provider with a small published sender surface. There is no bulk threshold, no spam-rate number, and no feedback loop. What it documents is classic hygiene - FCrDNS, a matching HELO, SPF/DKIM/DMARC - and an explicit stance that authentication only shifts a spam score rather than triggering rejection.
• Proton Mail Sender Requirements Proton Mail is an end-to-end-encrypted, Switzerland-based provider with a deliberately small sender-facing surface. It publishes no bulk threshold, no spam-rate number, and no feedback loop. What it does document is a machine-learning anti-spam and anti-abuse posture, clear abuse channels, and standard SPF/DKIM/DMARC guidance for custom domains - and its privacy model means senders get no open or click visibility.

SMTP errors & bounces

• Reading SMTP Replies (RFC 5321) An SMTP server answers every command with a three-digit reply code. The first digit tells you whether it succeeded, failed temporarily, or failed permanently. This page reads those codes the way RFC 5321 defines them, with the full numeric table and real transcripts.
• Enhanced Status Codes (RFC 3463, 5248, 7372) Enhanced status codes are the X.Y.Z numbers that ride alongside a basic SMTP reply and say precisely what went wrong. This page explains the class.subject.detail structure from RFC 3463, the IANA registry defined by RFC 5248, the authentication codes added by RFC 7372, and the specific codes worth recognizing.
• Bounces and DSN Parsing (RFC 3464, 3461) A bounce is a machine-readable Delivery Status Notification, not a prose apology. This page reads the DSN format from RFC 3464, the SMTP request extension from RFC 3461, how to classify hard vs soft from the Action and Status fields, and where provider 421 4.7.x codes fit.

Suppression & consent

• Suppression and Consent (RFC 6449, 8058) A suppression list is the memory of every "do not send" signal you have received - bounces, complaints, unsubscribes, and manual entries. This page covers the standards that produce those signals - List-Unsubscribe (RFC 2369, 8058), ARF feedback reports (RFC 5965, 6650), feedback-loop operations (RFC 6449) - plus consent models, sunset policy, and why honoring every signal protects reputation.

Transport security

• Encryption in Transit: STARTTLS, MTA-STS, DANE SMTP started as a cleartext protocol, and the TLS that secures it today is opportunistic and unauthenticated by default. This page explains STARTTLS, the downgrade and stripping attacks it cannot stop on its own, and how MTA-STS and DANE turn best-effort encryption into enforced, authenticated delivery.
• MTA-STS (RFC 8461): policy, records, and modes MTA-STS lets a domain demand authenticated TLS for inbound mail using DNS plus an HTTPS-served policy, without DNSSEC. This page covers the _mta-sts TXT record, the well-known policy file, the three modes, max_age caching, and exactly how a sending MTA validates and applies a policy - all per RFC 8461.
• TLS-RPT (RFC 8460): SMTP TLS reporting explained TLS-RPT is the feedback channel for SMTP transport security. Senders mail you a daily JSON summary of how many TLS sessions succeeded or failed against your domain and why. This page covers the _smtp._tls TXT record, the report schema, every failure result-type, and how to use reports to roll out MTA-STS and DANE safely - per RFC 8460.
• DANE for Email (RFC 7672): TLSA and DNSSEC DANE uses DNSSEC-signed TLSA records to tell senders exactly which certificate or key your MX must present, making SMTP TLS downgrade-resistant. This page covers the TLSA record format, the hard DNSSEC dependency, the certificate usages to publish, and a DANE vs MTA-STS comparison so you know when each applies - per RFC 7672, 6698, and 7671.

Reputation & blocklists

• Sender Reputation - What It Actually Is Reputation is not a single score you own - it is each receiver's prediction, built from your sending history, of how their users will react to your next message. This page explains what feeds that prediction, why it lives on both your IP and your domain, and why it is far easier to damage than to rebuild.
• IP vs Domain Reputation: What Counts Now Receivers score the sending IP and the sending domain as two different identities. This page draws the line precisely - what lives where, how shared and dedicated IPs differ, why domain reputation is overtaking IP reputation, and exactly what does and does not survive when you change IPs.
• Spamhaus Blocklists: SBL, XBL, PBL, DBL, ZEN A precise field guide to the Spamhaus blocklists - what each of SBL, CSS, XBL, PBL, DBL and the combined ZEN lists, the DROP/ASN-DROP and AuthBL datasets, the 127.0.0.x return codes, the RFC 5782 query mechanics and usage rules, and how listings and (always-free) delistings actually work.
• DNSBL Directory - Blocklists and How to Use Them DNS-based blocklists (DNSBLs) are the closest thing email has to a shared reputation signal. This page explains the standard query model from RFC 5782, the operational practices of RFC 6471, and gives a neutral, verified directory of the major lists - what each one lists, how to read its return codes, and how to get delisted - with strong guidance on using them as a score rather than a hard block.
• URI Blocklists - SURBL and URIBL URI blocklists judge the domains linked inside your message, not the IP you sent from. This page explains how SURBL and URIBL work, why a spotless sending IP gets filtered on one bad link, and how shorteners and tracking domains pull you onto someone else's reputation.
• Deliverability frameworks and industry guidance Deliverability best practice is not owned by any single authority - it is a remarkably consistent consensus across standards bodies, blocklist operators, mailbox providers, and the ESPs. This page is the annotated map of who publishes what, which document is best for which question, and why they all say the same six things. For the actionable playbook those documents add up to, see our sending best-practices guide.

Spam filtering & anti-abuse methods

• How receiver-side spam filtering actually works A spam filter is not one test with one threshold. It is a layered pipeline - connection and reputation checks, authentication, statistical content analysis, collaborative checksum networks, and rules engines - whose signals combine into a single decision. This page walks the whole chain so you can see where a legitimate message can go wrong.
• How Bayesian Spam Filtering Works Statistical filters do not match keywords - they learn token probabilities from a receiver's own ham and spam, then combine the most telling tokens with Bayes' rule. This is the history, the math, and the operational caveats, ending with what it means for a legitimate sender.
• Fuzzy Hashing and Near-Duplicate Detection A single changed character defeats an exact hash, so bulk-mail detection needs hashing that tolerates variation. This explains the difference between exact and fuzzy hashing, how DCC and Rspamd implement near-duplicate detection, and why "bulk" is not the same as "spam."
• DCC, Pyzor, and Razor: Checksum Spam Networks DCC, Pyzor, and Vipul's Razor let many receivers pool what they see, so a message sent in bulk is recognized as bulk even when each copy is personalized. Here is how each one works, how they differ, what they catch and miss, and the whitelist rule every legitimate bulk sender depends on.
• How SpamAssassin Works: Rules and Scoring SpamAssassin classifies mail by running many rules, each contributing a positive or negative score, and tagging messages whose total crosses a configurable threshold. Here is the scoring model, the plugin architecture, the network tests, the Bayes subsystem, and how training really works.
• How Rspamd Works: Architecture and Scoring Rspamd is an event-driven filtering framework that sits between the MTA and the internet, runs dozens of modules in parallel, sums named symbols into a score, and maps that score to an action. Here is the pipeline, the scoring and action model, fuzzy storage, and why it is fast.
• Greylisting, Tarpitting, and Rate Controls Before any content is scored, receivers can slow or defer suspicious connections. Greylisting (standardized in RFC 6647) returns a temporary failure that legitimate senders retry and most spamware abandons. Here is the mechanism, the RFC's recommended implementation, the failure modes, and where tarpitting and rate limiting fit.
• False Positives: When Good Mail Gets Flagged A false positive - a legitimate message filed as spam - is treated by every serious filter as the worst error, yet it is the one senders can do the most to prevent. This is how false positives arise across the filtering stack and the concrete, sourced practices that keep wanted mail on the right side.
• How Spam Filters Are Tested and Scored Filter accuracy claims mean nothing without a methodology. This explains how spam filters are evaluated - the TREC Spam Track's one-at-a-time model, the 1-ROCA% and lam% metrics, the feedback regimes - and the public corpora researchers use, with the caveats that make any single number unreliable.

Legal compliance

• Email marketing laws by country (2026) Anti-spam laws look alike until you sort them by consent. The US (and, for B2B, Turkey) let you mail first and honor opt-outs; Canada, the UK, the EU, and Australia want permission before the first message. This page lines all six up on consent, sender identity, unsubscribe timeframe, who enforces, and the penalties we could verify.
• CAN-SPAM Act: what US email law requires CAN-SPAM is an opt-out law: you may email someone who never asked, as long as the message is honest, names you, carries a physical address, and offers an unsubscribe you honor within 10 business days. There is no B2B exemption, and each non-compliant email is a separate violation.
• CASL: Canada's anti-spam law for senders CASL is an express opt-in law with a narrow, time-limited implied-consent exception. Every commercial electronic message must identify you and carry a working unsubscribe honored within 10 business days, and the burden of proving consent is on the sender. Penalties reach CAD $1M for individuals and CAD $10M for businesses per violation.
• UK PECR and UK GDPR for email marketing UK email marketing runs on two laws at once - PECR for the consent rules and UK GDPR for the data underneath. Marketing to individuals is opt-in (with a narrow soft opt-in for existing customers), while corporate bodies can be emailed without prior consent. We describe the ICO's enforcement powers qualitatively because the specific PECR penalty ceiling is not confirmed from a primary source.
• EU email marketing: GDPR and ePrivacy In the EU, marketing email is governed by the ePrivacy Directive (the consent rule) layered over the GDPR (the data rule). ePrivacy Article 13 generally requires prior opt-in for individuals; GDPR supplies the lawful basis, the right to object, and the accountability that turns consent into something you must be able to prove. Because the directive is transposed by each member state, the specifics vary by country.
• Australia's Spam Act 2003 for senders Australia's Spam Act 2003 is an opt-in law built on three rules - consent, identify, unsubscribe. Consent is express or (narrowly) inferred, the burden of proving it sits on the sender, and an unsubscribe must work and be honored within 5 working days. ACMA enforces; we describe its role without a penalty figure because the current amounts were not confirmed from a primary source.
• Turkey's ETK, KVKK and IYS for email Turkey requires prior consent (onay) to send commercial electronic messages to consumers, allows B2B sends to merchants and traders without consent, and routes consent and opt-outs through a central government registry, the IYS. Unsubscribe must be honored within 3 business days. The ETK obligations below come from the official law text; the KVKK data-protection layer is flagged where we could not verify it.

Postmaster tools

• Postmaster & Reputation Tools Overview A postmaster tool is the only place a mailbox provider tells you, in its own numbers, how it sees your mail. This page explains what the four big providers expose - reputation, spam rate, authentication, feedback loops - how they differ, and the questions none of them answer.
• Google Postmaster Tools, Explained Google Postmaster Tools is Gmail's window into how it sees your mail. This page walks the eight dashboards - what each measures, the exact reputation tiers, the spam-rate definition, and the traps in reading them - using only what Google's own documentation states.
• Microsoft SNDS & JMRP for Outlook.com Microsoft's postmaster surface for consumer Outlook.com is two services - SNDS for per-IP sending data and JMRP for complaint feedback. This page covers what each verifiably provides, how access works, and is honest about the specifics that live behind login and cannot be stated as fact.
• Yahoo Sender Hub & Complaint Feedback Loop Yahoo Sender Hub is the domain-based portal for Yahoo and AOL sender services - chiefly the DKIM-keyed Complaint Feedback Loop and an aggregated Insights view. This page covers what it offers and how to enroll, then closes with Apple iCloud's deliberately minimal postmaster surface.

About this library

• How we source these references Every page in this library is built from primary sources, verified, and dated. Here is exactly how we do it, and the lines we will not cross.