Email Infrastructure Glossary — Curated Reference for Operators

Domain-based Message Authentication, Reporting, and Conformance. DMARC is the policy layer that builds on SPF and DKIM, adding domain alignment checks and policy enforcement. Covers RFC 7489, alignment modes (relaxed/strict), policy progression p=none → p=quarantine → p=reject, aggregate vs forensic reports, and the operational decision points that determine whether DMARC actually protects your domain or accidentally drops legitimate mail.

The gradual process of increasing email sending volume from a new dedicated IP address to establish a positive reputation with mailbox providers. Covers the full ramp curve (week-by-week volume targets), engagement-based segmentation strategy, ISP-specific warmup behaviors at Microsoft/Google/Yahoo, common warmup failures, and the difference between cold-start warmup and reputation-recovery warmup after a listing event.

A composite score assigned by mailbox providers to a sending IP address and/or domain based on historical behavior. Covers the inputs each major provider uses (engagement signals, complaint rates, authentication results, list quality), how to read Microsoft SNDS color codes, how Google Postmaster Tools represents domain vs IP reputation separately, and the operational difference between "reputation" and "deliverability" — they're correlated but not identical.

Sender Policy Framework (RFC 7208) — the DNS-based mechanism that lets a domain owner authorize specific IPs to send mail on its behalf. Covers the 10 DNS lookup limit math with ESP-by-ESP cost map, the void lookup limit nobody mentions, the flattening vs subdomains vs macros decision matrix, alignment with DMARC including strict vs relaxed edge cases, and 6 production failure modes with diagnostic patterns.

DomainKeys Identified Mail (RFC 6376) — cryptographic signature attached to outbound messages that lets receivers verify the sending domain and that content wasn't modified in transit. Covers the DKIM-Signature anatomy tag-by-tag, RSA-2048 vs Ed25519 with empirical receiver support matrix (8 major receivers), 7-step safe rotation sequence, ESP signing pattern table (10 ESPs — who aligns by default, who needs CNAME setup), Microsoft 365 CNAME-vs-TXT distinction, and 8 production failure modes with diagnostic patterns.

Brand Indicators for Message Identification — the standard that puts your verified brand logo in supported inbox slots (Gmail, Yahoo, Apple Mail, Fastmail, La Poste). Inside this entry: 3-tier strategy (self-asserted free / CMC $650-1,100 / VMC $749-1,688) with verdict per provider, 6-row mailbox provider compatibility matrix, 6 prerequisites including DMARC at enforcement (≥30 days p=quarantine or p=reject), real BIMI DNS record syntax (v=BIMI1; l=; a=), SVG Tiny PS spec with required vs forbidden elements, 5-CA pricing comparison (DigiCert/Entrust/Sectigo/GlobalSign/SSL.com), top 6 failure reasons from URIports 2025 analysis (53.6% fail rate), engagement uplift numbers (+90% confidence, +4-6% open rate, +80% CTR, +44% brand recall).

SMTP service extension for opportunistic TLS upgrade (RFC 3207, February 2002). The mechanism that brought encryption to SMTP without breaking backward compatibility — used by ~95% of inbox-bound mail per Google Transparency Report. What this entry covers: complete RFC timeline 1981→2018 (RFC 821→2487→3207→8314), real STARTTLS handshake colorized step-by-step (EHLO before/after TLS), opportunistic vs mandatory TLS decision matrix (smtpd_tls_security_level=may vs encrypt), STRIPTLS downgrade attack mechanics with documented real-world incidents (Cisco IOS, Sandvine, ISP-level), 4-port comparison table (25/465/587/2525) with verdict per use case, full Postfix configuration syntax (main.cf + master.cf + tls_policy), openssl s_client + swaks testing commands, and the MTA-STS+DANE+TLS-RPT mitigation chain that closes RFC 3207's structural gap. Closes the transport security cluster.

SMTP MTA Strict Transport Security (RFC 8461) — the policy mechanism that forces outbound TLS for mail to a domain via an HTTPS-served policy file. Covers the dual DNS+HTTPS architecture, three modes (none/testing/enforce) with delivery semantics, 2026 adoption data (<1% Top 1M but 39.9% UK gov), MTA-STS vs DANE decision matrix, 7-step testing→enforce rollout sequence, hosted vs self-hosted deployment patterns, Microsoft CNAME-on-MX gotcha, and 8 production failure modes from URIports' 2026 survey.

SMTP TLS Reporting (RFC 8460) — the daily reporting mechanism that tells you which sending MTAs successfully or unsuccessfully delivered to your domain under MTA-STS or DANE policies. Covers the JSON report anatomy field-by-field, all 11 RFC 8460 result-types decoded with operational fixes, sender support matrix (Google #1, Microsoft #2 with rua= flaw, Comcast #3, Mail.ru #4, Mimecast #5), rua= endpoint patterns (mailto vs HTTPS vs multi), DMARC RUA architectural comparison, and 4 mailbox configuration considerations.

DNS-Based Authentication of Named Entities (RFC 7672 for SMTP, RFC 6698 base) — binds TLS certificates to MX hostnames via DNSSEC-signed TLSA records, eliminating CA trust and resisting downgrade and MITM attacks. Covers TLSA record anatomy field-by-field (Usage/Selector/Matching Type), the canonical 3 1 1 SMTP combination explained, Microsoft Inbound DANE GA October 2024 + the July 2026 *.mx.microsoft DNSSEC migration roadmap, certificate rotation timing (T0/T0+2×TTL/T0+4×TTL), DANE vs MTA-STS 10-dimensional decision matrix, 6 production failure modes from TLS-RPT data, and 2026 adoption reality (only 30 of 5.5M domains in DMARCguard's scan).

Authenticated Received Chain — IETF Experimental protocol (RFC 8617, July 2019) that preserves SPF/DKIM/DMARC authentication results across forwarding intermediaries (mailing lists, account forwarders, security gateways) where original authentication would otherwise break. Inside this entry: 4 forwarding scenarios that break direct auth, the three-header triplet (AAR + AMS + AS) explained per role, real ARC headers in annotated code with i=1/i=2 chain progression, cv=none/pass/fail validation semantics, ARC chain across forwarding hop visualization, 14-row implementation matrix (Gmail/Microsoft/Yahoo/Fastmail receivers + OpenARC/authentication_milter/Halon/MailerQ/Sympa/Mailman senders + Postfix/PowerMTA/KumoMTA), Microsoft 365 Trusted ARC Sealers configuration, IETF Experimental status controversy, and the honest decision matrix on when intermediaries need ARC sealing vs when senders don't.

Gmail's domain-level reputation portal showing IP reputation, domain reputation, complaint rate, and authentication breakdown. Coming entry will cover the reputation buckets (Bad/Low/Medium/High), the difference between IP and domain reputation in practice, the volume thresholds for data visibility, and how Postmaster v2 (released 2024) changed the operational visibility model.

Microsoft's free per-message feedback loop. When a recipient at Outlook.com, Hotmail, Live or MSN clicks the junk button, JMRP forwards the original message to a reporting address you nominate — the only Microsoft pathway from aggregate complaint rate to message-level source attribution. Covers the end-to-end flow (button-click → ARF report at your inbox), the five-step enrolment through the SNDS portal, the recipient-address redaction problem and the per-recipient identifier workaround, the operational pipeline (immediate suppression, campaign attribution, volume threshold alerting), the comparison with other FBLs (Yahoo CFL returns full address, Gmail has no FBL, Apple has no FBL), the common failure modes (no confirmation email, no reports arriving, dropped feed after the May 2026 SNDS migration), and the four ARF headers that matter most operationally (Source-IP, Original-Mail-From, Original-Rcpt-To, Arrival-Date).

The non-profit operating the most consequential email blocklists protecting Apple iCloud, Microsoft, Yahoo, Proofpoint, and Cloudmark (NOT Gmail, which uses internal reputation). Covers the full 8-zone family with grid cards (SBL/XBL/PBL/DBL/CSS/ZEN/DROP/BCL+ROKSO), the canonical return code reference INCLUDING the 127.255.255.x error range nobody covers, the per-zone delisting workflow with the escalating-penalty system (first removal instant, second human review, third permanent block), the Spamhaus Project (non-profit, Andorra) vs Spamhaus Technology (commercial) structural distinction, the 2026 DQS migration deprecating public mirrors, the eDROP→DROP merger of April 2024, and the post-2023 ROKSO public deprecation.

Smart Network Data Services — Microsoft's free first-party reputation dashboard for any IP that sends mail to Outlook.com, Hotmail, Live, MSN. Covers the five reported columns (IP Status traffic light, complaint rate, trap hits, filter result, authentication failure rate), the enrolment sequence via role-address verification, the paired JMRP per-message feedback loop and how the two combine for source attribution, the May 2026 migration to a REST API with updated calculation methodology, the operational runbook when SNDS turns Red (pause → audit → fix → wait 7–14 days → delist), and the four classes of Microsoft delivery problems SNDS does NOT cover (SmartScreen, tenant-side rejections, domain reputation, subnet-level filtering).

Mail Privacy Protection — Apple's iOS 15 (Sep 2021) feature that routes remote image loads through Apple proxy servers and pre-fetches tracking pixels before recipients open messages, inflating open rates industry-wide by ~50%. Covers the pre-fetch flow (delivery → proxy fetch → cache → human read with no new request), the four downstream effects on what senders can measure (open rate unreliable, timestamp unreliable, geolocation masked, device generalised — clicks/bounces/complaints unaffected), the 2026 numbers (49-54% Apple Mail share, ~95% MPP-enabled, ~50% of all opens are machine pre-fetches), the conditions that gate pre-fetch (Wi-Fi, battery, app in background, Inbox placement), what still works (CTR, CTOR, replies, conversions, bounces, complaints), four operational adaptations (treat MPP-flagged opens as separate column, move north star to clicks, extend inactivity windows to 180+ days, disclose methodology), the cold-email impact (follow-up sequence misfires), and five common myths debunked.

Directory-Based Edge Blocking — Microsoft Exchange Online Protection's directory check that rejects mail to addresses not present in the recipient tenant's Azure AD with a 550 5.4.1 Recipient address rejected: Access denied NDR. The most common cause of 5.4.1 rejections and the most frequently misdiagnosed (senders waste hours auditing SPF/DKIM/DMARC/SNDS when nothing on the sender side matters). Covers the 6-layer EOP perimeter pipeline (DBEB sits at layer 2, before content filtering), when DBEB activates (Authoritative domain type only; Internal Relay turns it off), the 3-step configuration with race condition warning during cut-over, decode table separating DBEB from 5.7.x policy rejects, four hybrid Exchange configurations with their DBEB implications, the mail contact workaround for external addresses, Mail-Enabled Public Folder complications, sender-side 5-step diagnosis runbook, and what DBEB does NOT do (it is not anti-spam or anti-phishing).

A Feedback Loop (FBL) is the programmatic agreement between mailbox providers and senders that delivers complaint reports — typically in Abuse Reporting Format (ARF, RFC 5965) — whenever recipients mark mail as spam. Covers the terminology variants (JMRP/CFL/FBL/Universal FBL), full ARF anatomy with the 7 operational headers (Feedback-Type, Source-IP, Original-Mail-From, Original-Rcpt-To, Arrival-Date, Reported-Domain, Authentication-Results), the 2026 provider matrix (Microsoft JMRP per-IP redacted, Yahoo CFL per-domain DKIM-keyed full-address, Gmail Postmaster aggregate-only, Apple no FBL, Comcast/Cox/OVH/Mail.ru/25+ via Validity Universal), why Yahoo CFL is unique (DKIM-domain registration), the 6-step ARF processing pipeline with sub-5-minute suppression target, complaint thresholds (<0.10% target, 0.30% enforcement at Gmail/Yahoo/Microsoft), and the worst operational pattern (enrolment without suppression).

DNS-based Block List (modern term) / Real-time Blackhole List (historical term). Coming entry will cover the query mechanism (reversed IP + zone hostname), response code interpretation, the IP-based vs domain-based vs URL-based distinctions, the handful of DNSBLs that actually matter (Spamhaus, Barracuda, SpamCop, SORBS) versus the dozens that mostly don't.

Mail Transfer Agent — the SMTP-speaking server software that routes email between systems. Complete umbrella treatment covering: MTA vs MUA vs MDA distinction, the architectural spectrum (monolithic Exim/Sendmail → modular Postfix → async Lua-driven KumoMTA), the 7 major implementations (Postfix, Exim, Sendmail, PowerMTA, KumoMTA, MailerQ, Halon) with deep comparison matrix, real adoption data from Shodan Feb 2025 (2.57M Postfix vs 2.56M Exim), Sendmail decline 80%→4% market share, 5-tier volume thresholds, declarative vs programmable config philosophies, and Kubernetes/mailcow deployment patterns for 2026.

Commercial high-volume Mail Transfer Agent from Port25 (acquired by SparkPost in 2018, now owned by Bird since 2021). Covers the architectural role in the email stack (engine, not platform), the ownership timeline and what each transition meant operationally, real performance numbers (1-3M msgs/hour typical, 7-9M+ peak), declarative configuration philosophy with a worked virtual MTA example, the 2026 licensing reality ($5,500-8,000+/year volume-based, dev/test licensed separately), and the 4-way decision matrix vs Postfix, MailerQ, and KumoMTA — including the operator question of 2026: stay or migrate?

First open-source high-performance MTA designed from the ground up for high-volume commercial senders. Apache 2.0, Rust core (kumod) + Lua policy, founded 2023 by Wez Furlong (ex-Momentum/Ecelerity Chief Architect). Topics in this entry: origin story (Message Systems lineage), architecture (Rust async + Lua config-as-code), 6 lifecycle hooks (init/get_queue_config/get_egress_path_config/smtp_server_message_received/http_message_generated/should_enqueue_log_record), 6 policy helpers (Sources/Listener_Domains/Queues/DKIM_Signer/Shaping/Log_Hooks), real Lua policy example, KumoMTA vs PowerMTA decision matrix, 5 production case studies (AWeber, PureSend, Taguchi, AhaSend, Laposta), and the 6-step PowerMTA→KumoMTA migration sequence.

The most widely deployed open-source MTA in the world (~2.57M Shodan instances Feb 2025), default on macOS, NetBSD, RHEL/CentOS, and Ubuntu. Created 1997-1998 by Wietse Venema at IBM Watson as a security-focused Sendmail replacement. What you'll find inside: master/child daemon architecture (~50 specialized processes), 4-queue lifecycle (maildrop → incoming → active → deferred), main.cf vs master.cf configuration philosophy with -o override syntax, realistic throughput numbers (hundreds/sec, ~50-100K msgs/hr per server tuned), 4 deployment patterns (complete server, app relay, gateway/filtering, split-MTA), 10-parameter high-volume tuning table from official TUNING_README, and the operational decision framework for choosing Postfix vs PowerMTA vs KumoMTA at every volume tier.

The foundational protocol for email transmission across the internet (RFC 5321). This entry covers: 44-year historical timeline (RFC 821→2821→5321→6409→8314), full SMTP transaction in annotated code (HELO/EHLO/STARTTLS/AUTH/MAIL FROM/RCPT TO/DATA/QUIT with client/server colorized), the envelope-vs-headers distinction that breaks DMARC, complete commands reference table, the 4-port reality decoded (25 server-only / 465 implicit TLS per RFC 8314 / 587 STARTTLS / 2525 unofficial), 9 ESMTP extensions reference, response code categories (2yz/3yz/4yz/5yz) plus Enhanced Status Codes RFC 3463, the STRIPTLS attack with DANE/MTA-STS mitigation chain, and operational testing with telnet/openssl. Foundational anchor connecting all other entries.

Permanent delivery failure (5xx SMTP response). Coming entry will cover the spec-defined 5xx codes most commonly seen (550, 551, 553, 554), how to distinguish "address doesn't exist" from "policy rejection" by reading enhanced status codes (RFC 3463), why 5xx codes from forwarders shouldn't be treated like 5xx from authoritative MX, and the hard bounce processing operationally required to stay under ISP thresholds.

Temporary delivery deferral (4xx SMTP response). Coming entry will cover the common 4xx codes (421, 450, 451, 452), what they typically mean from each major receiver, how soft bounces should be retried (cadence, max attempts, escalation to hard bounce after N retries), and the operational pattern for handling rate limit (4.7.0) responses from Gmail/Microsoft.

The 3-digit codes returned by receiving servers during the SMTP transaction. Coming entry will cover the RFC 5321 / RFC 3463 reference tables, the practical mapping from code to operational decision (retry / suppress / investigate), the receiver-specific extensions to the standard codes (Microsoft's 5.7.501, Gmail's 421-4.7.28), and how to parse enhanced status codes from log streams.

US federal law governing commercial email (15 U.S.C. § 7701). Coming entry will cover the substantive requirements (truthful headers, no deceptive subject lines, valid postal address, unsubscribe within 10 business days), the FTC enforcement record, the 2024 ANPR proposed amendments, the interaction between CAN-SPAM and state laws (California's CCPA), and the practical compliance checklist for transactional vs marketing email.

General Data Protection Regulation — EU law governing personal data processing including email lists. Coming entry will cover the consent standard for marketing (opt-in, demonstrable, granular), the lawful bases beyond consent that apply to transactional/legitimate-interest mail, data subject access rights, the cross-border transfer mechanisms (SCCs post-Schrems II), the relationship to ePrivacy Directive, and the actual enforcement record on email-related complaints.

RFC 2369 / RFC 8058 mechanism for one-click unsubscribe. Coming entry will cover the dual-format requirement (mailto + HTTPS POST), Gmail and Yahoo's 2024 bulk sender requirements making this mandatory, the difference between Gmail's "List-Unsubscribe-Post: List-Unsubscribe=One-Click" and Apple Mail's UI implementation, and the suppression timing requirements.

The percentage of accepted messages that actually land in the recipient's primary inbox versus spam folder, promotions tab, or other categorization. Coming entry will cover the difference between deliverability (acceptance rate) and inbox placement (visibility rate), how seedlist testing measures it (Litmus, GlockApps, Mailtrap), the global average (~84% per current 2026 reports), and why a high deliverability score doesn't guarantee inbox placement.

The mechanism by which receiving MTAs limit accepted message volume per sender. Coming entry will cover the per-IP, per-domain, and per-content-pattern throttling layers, the difference between connection-level and session-level limits, the typical 4xx response codes (421-4.7.28 from Gmail, 421-4.7.0 from Microsoft, etc.), how to detect throttling versus blocking, and the backoff strategy that respects rate limits without hurting reputation further.

An email address used by anti-spam organizations to identify senders with poor list hygiene. Coming entry will cover the three types (pristine — never-real addresses; recycled — formerly real, abandoned; typo — common misspellings of real domains), how each type indicates a different operational failure (scraping/buying vs hygiene gaps vs validation gaps), the SCBL spamtrap weighting math (5x for ≤5 hits, squared for >5), and the operational practices that minimize trap exposure.

The pattern of distributing spam volume across many IPs and domains to fly under per-IP volume thresholds. Coming entry will cover the historical context (named after the wide-distributing footprint of a snowshoe), the detection signals that trigger Spamhaus CSS listings (volume distribution patterns, domain age, registration patterns), why legitimate senders sometimes accidentally trigger snowshoe detection during architecture changes, and the remediation when this happens.