Resources / Glossary

The email deliverability glossary.

158 terms you'll meet when email gets serious, defined in plain language by people who operate this infrastructure daily, and cross-linked to the deep references.

Deliverability basics

Delivery vs placement (delivered rate vs inbox placement): "Delivered" means the receiving server accepted the message at the SMTP transaction; "placement" is where that accepted message actually lands once the provider decides. A high delivered rate says nothing about whether mail reached the inbox, the Promotions tab, or the spam folder.; See also: Inbox placement
Email deliverability: The practice of getting email accepted and placed in the inbox rather than rejected or spam-foldered. It is a function of sender reputation, authentication, infrastructure, list quality, and content. It is distinct from "delivery," which only means the receiving server accepted the message.; See also: Overview, Delivery vs placement
Engagement-based filtering (behavioral filtering, engagement filtering): Placement logic that weighs how recipients interact with your mail (opens, clicks, replies, deletes-without-reading, marking as spam) alongside technical signals. Industry guidance describes engagement as the single most influential factor in modern inbox-placement decisions, which is why mailing unengaged recipients erodes placement for everyone.; See also: Sender reputation, List hygiene
Envelope vs header (From / Return-Path) (envelope-from vs From, 5321.MailFrom vs 5322.From): The SMTP envelope (MAIL FROM / Return-Path) controls routing and where bounces go, while the message header From: is what the recipient sees. These can differ, and the gap between them is exactly what DMARC alignment evaluates. SPF authenticates the envelope MAIL FROM domain; DKIM and DMARC tie the visible From: to an authenticated identity.; See also: Return-Path (bounce address), DMARC alignment (relaxed / strict)
ESP (Email Service Provider) (Email Service Provider): A service that sends email on behalf of customers, handling injection, authentication, sending IPs, and event tracking. The ESP's reputation practices and the discipline of its other customers can affect your outcomes, especially on shared infrastructure.; See also: Shared IP pool, SMTP relay
Inbox placement (inbox placement rate): Where an accepted message is actually filed: inbox, a tab such as Promotions, or spam. Mailbox providers decide placement using reputation and engagement signals, so "delivered" does not mean "seen."; See also: Engagement-based filtering, Seed testing
List hygiene (list cleaning): The ongoing removal of invalid, dead, and unengaged addresses from your lists, plus prompt processing of bounces and complaints. It is the highest-leverage deliverability habit because it directly controls bounce rate, complaint rate, and spam-trap exposure.; See also: Spam trap, Sunset policy, M3aawg Sending Best Practices
Mailbox provider (MBP) (MBP, ISP, receiver): The operator of the recipient's mailbox, such as Gmail, Yahoo, Microsoft Outlook, or Apple iCloud. The MBP runs the receiving servers and the filters that decide acceptance and placement, and it is the party whose published requirements senders must meet.; See also: Provider Rule Tracker
Marketing / bulk email (bulk messaging, promotional email): Messages sent to advertise or build the relationship between a brand and its audience, as opposed to transactional mail. Bulk marketing generates more complaints and spam-trap risk, which is why providers apply their strictest bulk-sender rules to it and why operators isolate it from transactional streams.; See also: Stream separation, Gmail
MSA (Mail Submission Agent) (Mail Submission Agent, submission server): The server that accepts mail from a mail client or application for the first time, typically on the submission port with authentication, before handing it to an MTA for relay. RFC 5321/6409 separate submission from relay so that policy and authentication can be applied at the point of origin.; See also: MTA (Mail Transfer Agent), MUA (Mail User Agent)
MTA (Mail Transfer Agent) (Mail Transfer Agent): Software that transfers email between servers over SMTP. Sending MTAs queue, retry, and deliver outbound mail to recipients' MX hosts; receiving MTAs accept or reject it. Examples include Postfix, Exim, and KumoMTA.; See also: SMTP, MX record
MUA (Mail User Agent) (Mail User Agent, email client): The email client a person uses to read and compose mail, such as Apple Mail, Outlook, or a webmail interface. The MUA renders messages and is where features like one-click unsubscribe surface to the recipient.; See also: MSA (Mail Submission Agent)
MX record (mail exchanger record): A DNS record that names the mail servers responsible for receiving email for a domain, each with a preference value that orders them. Sending MTAs look up the recipient domain's MX records to find where to deliver.; See also: MTA (Mail Transfer Agent), SMTP
Operational email: Service and system mail that keeps a business running: alerts, status updates, invoices, and reminders. Like transactional mail, it is expected and must arrive reliably, so it benefits from the same authentication and stream discipline.; See also: Transactional email
Postmaster tools (Google Postmaster Tools, SNDS): Provider dashboards that expose your reputation, authentication, and spam-rate data as that provider sees it. Examples include Google Postmaster Tools and Microsoft SNDS. Gmail explicitly requires senders to monitor their Postmaster Tools spam rate to stay under threshold.; See also: Complaint rate, Gmail
Return-Path (bounce address) (bounce address, envelope-from, MAIL FROM): The envelope sender address (SMTP MAIL FROM) where delivery failures and bounce notifications are returned. It is the domain SPF checks for DMARC, and it is often a subdomain distinct from the visible From: address so bounces can be processed automatically.; See also: Envelope vs header (From / Return-Path), SPF (Sender Policy Framework)
Seed testing (seed list testing, inbox placement testing): Sending to a controlled panel of test addresses across multiple providers to estimate inbox placement before and during a campaign. Seed panels are a sample, not the truth: they indicate placement trends but do not measure your real audience's experience.; See also: Inbox placement, Postmaster tools
Transactional email (transactional messaging): Mail triggered by a user action or account relationship: password resets, receipts, one-time passcodes, and notifications. M3AAWG defines it as confirming a transaction or providing individual account status. It is expected, wanted, and time-sensitive, so reliable delivery is the priority.; See also: Operational email, Stream separation

Authentication

ARC (Authenticated Received Chain) (Authenticated Received Chain): An experimental standard (RFC 8617) that preserves an authenticated record of a message's authentication state across intermediaries such as mailing lists and forwarders, which otherwise break SPF and DKIM. Receivers may use a valid ARC chain to override a DMARC failure, but ARC is not a trust framework and remains far from universally deployed.; See also: Arc, ARC header set (AAR / AMS / AS), DMARC
ARC header set (AAR / AMS / AS) (AAR, AMS, ARC-Seal, ARC set): Each ARC-participating hop adds three headers sharing an instance number (i=): ARC-Authentication-Results (AAR) records the authentication seen on arrival, ARC-Message-Signature (AMS) signs the message like DKIM, and ARC-Seal (AS) signs the chain itself. Instance values run from 1 to 50; a chain that breaks (cv=fail) cannot be continued.; See also: ARC (Authenticated Received Chain)
Authentication-Results header (Auth-Results, A-R header): A header (RFC 8601) added by the receiving system that records the outcome of SPF, DKIM, DMARC, and other checks for a message, e.g. spf=pass, dkim=pass, dmarc=pass. It is how receivers communicate authentication verdicts internally and to downstream filters, and a primary diagnostic when troubleshooting alignment.; See also: DMARC, ARC header set (AAR / AMS / AS)
BIMI (Brand Indicators for Message Identification) (Brand Indicators for Message Identification): A standard that displays a brand-controlled logo next to authenticated mail in supporting clients, published as a DNS TXT record at default._bimi.<domain>. It requires DMARC at enforcement (p=quarantine or p=reject); p=none is insufficient. BIMI authenticates nothing on its own, relying entirely on DMARC.; See also: Bimi, VMC / CMC (Verified & Common Mark Certificates), DMARC policy (p=)
DKIM (DomainKeys Identified Mail) (DomainKeys Identified Mail): A cryptographic signature (RFC 6376) added to messages and verifiable via a public key published in DNS, proving the signed parts were not altered and that the signing domain (d=) takes responsibility. A DKIM pass does not prove the From: domain is the author; alignment with From: is what makes it count for DMARC.; See also: Dkim, DKIM selector, DKIM canonicalization
DKIM canonicalization (simple/relaxed canonicalization, c= tag): The c= tag's normalization rules applied to the header and body before signing and verifying, with two algorithms each: simple (no changes) and relaxed (tolerates whitespace and header-case changes). relaxed/relaxed is common because intermediate servers often make minor whitespace edits that would otherwise break a simple signature.; See also: DKIM (DomainKeys Identified Mail), DKIM l= tag (body length)
DKIM key rotation (DKIM key rollover): Periodically replacing a DKIM key pair, publishing the new public key under a fresh selector and retiring the old one. Using a new selector for each key (rather than overwriting) lets in-flight mail still verify and avoids confusing key-rotation failures with forgeries. Gmail and Yahoo require at least a 1024-bit key and recommend 2048-bit.; See also: DKIM selector, DKIM (DomainKeys Identified Mail)
DKIM l= tag (body length) (body length count): An optional DKIM tag that limits how many octets of the body are covered by the signature. RFC 6376 cautions against it: anything appended past the signed length still verifies, which lets an attacker add content to a validly signed message. Most senders should omit l= entirely.; See also: DKIM (DomainKeys Identified Mail), DKIM canonicalization
DKIM selector (s= tag, _domainkey): The label (s= tag) that picks which public key to use, queried in DNS as <selector>._domainkey.<domain>. Selectors let a domain run multiple concurrent keys, which is what makes clean key rotation possible. RFC 6376 advises against reusing a selector for a new key.; See also: DKIM (DomainKeys Identified Mail), DKIM key rotation
DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy and reporting layer (RFC 9989, which obsoletes RFC 7489) built on SPF and DKIM. A DMARC pass requires an SPF or DKIM pass plus identifier alignment with the visible From: domain. It lets domain owners state how receivers should treat failures and request reports, but it does not itself confer deliverability.; See also: Dmarc 2026, DMARC policy (p=), DMARC alignment (relaxed / strict)
DMARC aggregate & failure reports (rua / ruf) (rua, ruf, aggregate reports, failure reports): rua= names URIs that receive aggregate XML reports (RFC 9990) summarizing authentication and disposition, sent at least once every 24 hours; ruf= names URIs for per-message failure reports (RFC 9991) in ARF format. Many providers limit or disable ruf for privacy reasons, so rua is the practical workhorse for diagnosing alignment.; See also: DMARC, ARF (Abuse Reporting Format), Dmarc 2026
DMARC alignment (relaxed / strict) (identifier alignment, adkim, aspf): The requirement that the authenticated domain (SPF MAIL FROM or DKIM d=) match the visible From: domain. Relaxed alignment (the default) accepts the same organizational domain; strict alignment requires an exact match. Alignment is what gives authentication meaning, and unaligned mail increasingly goes to spam.; See also: DMARC, Envelope vs header (From / Return-Path)
DMARC policy (p=) (p=none, p=quarantine, p=reject): The p= tag tells receivers how to treat mail that fails DMARC: none (monitor only), quarantine (treat as suspicious), or reject (refuse). Bulk-sender programs at Gmail, Yahoo, and Microsoft require at least p=none. RFC 9989 also forbids receivers from rejecting solely because of p=reject, treating such mail as quarantine in the absence of other signals.; See also: DMARC, DMARC subdomain & non-existent policy (sp= / np=), Dmarc 2026
DMARC subdomain & non-existent policy (sp= / np=) (sp= tag, np= tag): sp= sets the policy for existing subdomains of the organizational domain (inheriting p= if absent), and np= (added in RFC 9989) sets the policy for non-existent subdomains. np= is useful for shutting down lookalike subdomains that were never meant to send mail.; See also: DMARC policy (p=), DMARC Tree Walk
DMARC testing mode (t=) (t= tag, pct= replacement): The t= tag introduced in RFC 9989 lets a domain owner request that receivers not actually apply the stated policy yet, supporting a graduated rollout. It replaces the pct= tag from the obsolete RFC 7489, which no longer exists in the current standard.; See also: DMARC policy (p=), DMARC
DMARC Tree Walk (DNS Tree Walk, organizational domain discovery): The method RFC 9989 uses to find the organizational domain by walking up the DNS hierarchy with a series of queries, replacing RFC 7489's reliance on the Public Suffix List. The walk is capped at 8 DNS queries per Author Domain to prevent denial-of-service.; See also: DMARC, PSD DMARC
Email authentication (sender authentication): The set of standards (SPF, DKIM, DMARC, and increasingly ARC and BIMI) that let receivers verify a message genuinely comes from its claimed sender. Since 2024, having SPF, DKIM, and DMARC in place is a hard requirement for bulk senders at Gmail, Yahoo, and Microsoft.; See also: Email Authentication Overview, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC
PSD DMARC (psd= tag, Public Suffix Domain DMARC): Public Suffix Domain DMARC lets the operator of a public suffix (such as a country-code or brand TLD) publish DMARC policy for the domains beneath it, declared with the psd= tag. RFC 9989 formalizes participation by Public Suffix Operators, helping protect non-existent or unconfigured registrable domains.; See also: DMARC Tree Walk, DMARC
SPF (Sender Policy Framework) (Sender Policy Framework): A DNS TXT record (RFC 7208) listing which servers may send mail using your domain in the envelope MAIL FROM or HELO identity. Receivers check the connecting server's IP against the record. For DMARC, only the MAIL FROM result is used, and it must also align with the visible From: domain.; See also: Spf, SPF qualifiers (+ - ~ ?), SPF 10-lookup limit
SPF 10-lookup limit (10 DNS lookup limit, SPF flattening): RFC 7208 requires SPF evaluation to use no more than 10 DNS-querying terms (include, a, mx, ptr, exists, and redirect); exceeding this returns permerror. Implementations should also cap void lookups at two and allow at least 20 seconds. Bloated records with many includes are a frequent cause of SPF failure.; See also: SPF (Sender Policy Framework), SPF permerror / softfail
SPF permerror / softfail (permerror, softfail, temperror): Two SPF results that trip up senders. Permerror means the record could not be interpreted (often from exceeding the 10-lookup limit or having two SPF records), and DMARC treats it as not passing. SoftFail (~all) is a weak "probably not authorized" statement that receivers may accept but weigh negatively.; See also: SPF 10-lookup limit, SPF qualifiers (+ - ~ ?)
SPF qualifiers (+ - ~ ?) (all mechanism, -all, ~all): Prefixes on SPF mechanisms that set the result when they match: + (Pass, the default), - (Fail), ~ (SoftFail, probably not authorized), and ? (Neutral, no assertion). The common closing terms -all (hard fail) and ~all (soft fail) decide how receivers treat unlisted servers.; See also: SPF (Sender Policy Framework), SPF permerror / softfail
VMC / CMC (Verified & Common Mark Certificates) (Verified Mark Certificate, Common Mark Certificate): Certificates that attest a brand's right to a BIMI logo. A Verified Mark Certificate (VMC) is based on a registered trademark; a Common Mark Certificate (CMC) covers logos that are not trademarked. Most major mailbox providers require a VMC or CMC to actually display a BIMI logo; self-asserted records have limited support.; See also: BIMI (Brand Indicators for Message Identification)

Reputation

ASN reputation (network reputation, Autonomous System reputation): Reputation associated with an Autonomous System Number, the network block an IP belongs to. Blocklists and filters can escalate from a single IP to an entire network or ASN when abuse is widespread, so the conduct of your network neighbors can affect you.; See also: IP reputation, Spamhaus SBL
Bounce rate: The share of sends rejected by receivers. High bounce rates signal poor list quality and damage sender reputation; M3AAWG notes that large volumes of permanent failures can subtract from an IP's reputation score. Prompt suppression of hard bounces keeps the rate down.; See also: Hard bounce, Soft bounce, List hygiene
Complaint rate (spam rate, spam complaint rate): The share of delivered mail that recipients mark as spam. Gmail's published guidance is to keep the Postmaster Tools spam rate below 0.10% and never reach 0.30%; Yahoo asks senders to stay below 0.3%. Sustained rates near these ceilings damage placement for everything you send.; See also: Postmaster tools, Feedback loop (FBL), Gmail
Dedicated IP: A sending IP used by a single sender, so its reputation reflects only that sender's behavior. It is best for steady, meaningful volume; below a consistent threshold of mail, a dedicated IP can struggle to build and hold reputation.; See also: Shared IP pool, IP warming (warmup)
Domain reputation: Reputation tied to the sending domain and the domains in your links, carried via DKIM. It follows you across IPs, which is why changing IPs cannot fix a domain or content problem, and why DKIM lets a good reputation move with you to new infrastructure.; See also: Ip Vs Domain Reputation, Sender reputation
IP reputation: Reputation tied to a sending IP address. New IPs have none, which is why warming exists; damaged IPs face throttling or blocks until rehabilitated. With IPv6 proliferation, providers increasingly weigh domain and content reputation over IP alone.; See also: Ip Vs Domain Reputation, IP warming (warmup), Dedicated IP
IP warming (warmup) (warmup, ramp-up, domain warming): Gradually increasing volume on a new sending IP (or domain) so providers can build trust, starting with your most engaged recipients and letting prior results gate each increase. Ramping too fast triggers throttling and spam-foldering. There is no single universal schedule; the right pace is demand-gated by engagement and provider response.; See also: M3aawg Sending Best Practices, IP reputation, Rate limiting / throttling
Pristine spam trap (pure trap, classic spam trap): An address that never belonged to a real user and was created purely to detect spam. Hitting one is a strong indicator of harvesting, address-space probing, or purchased lists, and it is the type most blocklists rely on. Confirmed opt-in essentially prevents these.; See also: Spam trap, Seeded spam trap
Recycled spam trap (dead address trap, recycled trap): A once-valid address that a provider retired and later reactivated as a trap after a period of inactivity (M3AAWG suggests a minimum of 12 months). Hitting these indicates poor bounce processing or mailing addresses that have gone cold, so engagement-based sunsetting is the main defense.; See also: Spam trap, Sunset policy
Seeded spam trap (seeded trap): An address deliberately scattered in places like web-page source code so that scrapers harvest it. Receiving mail at a seeded trap indicates the sender is scraping addresses or buying lists from someone who does.; See also: Spam trap, Pristine spam trap
Sender permanence (sending consistency): Maintaining a consistent sending identity, volume, and infrastructure over time so providers see stability rather than the IP-hopping typical of spammers. Bursty, erratic volume degrades even a well-established reputation, while occasional zero-volume days are tolerated if they do not extend too long.; See also: IP warming (warmup), Sender reputation
Sender reputation (reputation): The trust mailbox providers assign to a sender, built from complaint rates, bounce rates, spam-trap hits, authentication, engagement, and history. It attaches to both IPs and domains. As Spamhaus puts it, reputation predicts how recipients will react based on how they reacted before, and it is far easier to damage than to repair.; See also: Overview, IP reputation, Domain reputation
Shared IP pool (shared IP): Sending IPs used by multiple senders, where reputation is collective. The quality of the pool and the discipline of its operator determine everyone's outcomes; a single bad actor can dilute the group, while a well-run pool can carry low-volume senders who could not sustain a dedicated IP.; See also: Dedicated IP, ESP (Email Service Provider)
Snowshoeing (snowshoe spam): Spreading low-volume sending thinly across many IPs and domains to dilute reputation signals and dodge blocks, named for how a snowshoe spreads weight. It is a recognized abuse pattern, so legitimate senders using far more IPs than their volume warrants can look like snowshoers.; See also: Spamhaus CSS, IP pool
Spam trap (spamtrap, honeypot): An address that exists to catch senders with poor list practices; it never opts in or sends mail. Hitting traps signals purchased, harvested, or stale lists and can trigger blocklisting. The trap is a symptom, not the disease: the fix is better consent and hygiene, not hunting for and suppressing the trap.; See also: Pristine spam trap, Recycled spam trap, Typo spam trap, Spamhaus Blocklists
Typo spam trap (typo domain trap): A trap at a common-misspelling domain such as gmial.com or homail.com, used to catch addresses collected without validation. Because these can also receive legitimate mistyped mail, operators often weight them less than pristine traps. Address validation at the point of collection and double opt-in prevent most of them.; See also: Spam trap, Double opt-in (confirmed opt-in)

Blocklists

Allowlist (whitelist) (whitelist, safe sender list): A list of senders explicitly trusted to bypass some filtering. At the mailbox-provider level, broad sender allowlisting has largely disappeared — Spamhaus notes it is unaware of any ISP that offers it — so senders cannot buy their way past filters and must earn reputation. Allowlisting still exists inside receiver-side tools (e.g., local whitelists for wanted bulk mail).; See also: Blocklist (blacklist), Sender reputation
Blocklist (blacklist) (blacklist, denylist): A published list of IPs or domains accused of sending abuse, consulted by receivers to refuse or tag mail. Reach varies enormously: a listing on a widely used list like Spamhaus has major impact, while obscure lists can often be ignored.; See also: DNSBL / RBL, Spamhaus ZEN, Listing / delisting
DNSBL / RBL (RBL, DNS blocklist, Real-time Blackhole List): A DNS-based blocklist (also called a Real-time Blackhole List) that receivers query over DNS to check whether a connecting IP or a domain is listed. The reply encodes the listing; receivers then choose to reject the mail or accept and tag it for further filtering.; See also: Blocklist (blacklist), URIBL / SURBL, Spamhaus Blocklists
Listing / delisting (listing, removal request): Being added to a blocklist (listing) and the process of getting removed (delisting). Removal generally requires fixing the underlying problem first and then requesting removal with evidence; reputable operators like Spamhaus never charge a fee, and any paid "removal" offer is a scam.; See also: Blocklist (blacklist), Spamhaus Blocklists
Spamhaus CSS (CSS, Combined Spam Sources): Combined Spam Sources, an automatically produced subset of the SBL zone that targets low-reputation senders, snowshoe operations, and compromised hosts not already caught by the PBL or XBL. It is fully automated, in contrast with the manually researched SBL proper.; See also: Spamhaus Blocklists, Spamhaus SBL, Snowshoeing
Spamhaus DBL (DBL, Domain Blocklist): The Spamhaus Domain Blocklist, a domain-based list of domains showing signs of spam or malicious activity, used during the SMTP transaction (HELO, MAIL FROM) and in content inspection of headers, body URLs, and contact addresses. It catches actors who send from clean IPs but use abusive domains, and it is queried separately from the IP-based ZEN list.; See also: Spamhaus Blocklists, URIBL / SURBL
Spamhaus PBL (PBL, Policy Blocklist): The Spamhaus Policy Blocklist, a list of end-user IP ranges (largely residential/dynamic space) that should never send mail directly to a recipient's MX; such mail should go through an authenticated submission server instead. Listed IPs are not necessarily "bad" — they simply should not be delivering directly, and the PBL must be applied only to the connecting IP.; See also: Spamhaus Blocklists, Spamhaus ZEN, MSA (Mail Submission Agent)
Spamhaus SBL (SBL, sbl.spamhaus.org): The Spamhaus Blocklist, an IP-based list of addresses and ranges identified by Spamhaus's research team as sources of spam, snowshoe operations, or malicious hosting. It is manually curated and used both at the initial connection and in content filtering.; See also: Spamhaus Blocklists, Spamhaus ZEN, Spamhaus CSS
Spamhaus XBL (XBL, Exploits Blocklist): The Spamhaus Exploits Blocklist, an automated list of individual IPs showing signs of compromise, such as malware infections, proxies, or credential abuse. Listings expire automatically once the malicious behavior stops.; See also: Spamhaus Blocklists, Spamhaus ZEN
Spamhaus ZEN (ZEN, zen.spamhaus.org): A combined IP blocklist that bundles SBL, CSS, XBL, and PBL into one query for speed and simplicity, returning distinct codes per dataset. If you query ZEN there is usually no need to query those IP lists separately; the domain-based DBL is not included and must be queried on its own.; See also: Spamhaus Blocklists, Spamhaus SBL, Spamhaus DBL
URIBL / SURBL (URIBL, SURBL, URI blocklist): Domain/URI blocklists that list the domains and links appearing inside spam message bodies, not the sending IPs. They complement IP blocklists by catching campaigns that send from clean IPs but reuse abusive link domains. Both are designed to feed a spam score rather than to issue a hard block on their own.; See also: Uri Blocklists Surbl Uribl, Spamhaus DBL, DNSBL / RBL

SMTP & transport

Enhanced status codes (X.Y.Z) (DSN status codes, X.Y.Z codes): Finer-grained status codes (RFC 3463) of the form class.subject.detail that accompany basic reply codes, e.g. 5.1.1 (bad mailbox) or 4.2.2 (mailbox full). The class (2/4/5) mirrors success, transient, or permanent failure, while subject and detail pinpoint the cause.; See also: Enhanced Status Codes, SMTP reply codes (2xx / 4xx / 5xx), DSN (Delivery Status Notification)
ESMTP (Extended SMTP, EHLO): Extended SMTP, the modern form of the protocol negotiated when a client opens a session with EHLO instead of HELO. The server then advertises extensions it supports, such as STARTTLS, SIZE, PIPELINING, and 8BITMIME.; See also: SMTP, STARTTLS, HELO / EHLO
Greylisting (greylist): A receiver tactic (described in RFC 6647) of temporarily rejecting first contact from an unfamiliar sender with a 4xx code; well-behaved MTAs retry and pass, while crude spamware often does not. It mainly saves filtering resources and buys time for blocklists to react, at the cost of delaying first messages, so it is best paired with reputation data.; See also: Greylisting Tarpitting Rate Controls, Tarpitting, SMTP reply codes (2xx / 4xx / 5xx)
HELO / EHLO (HELO, EHLO, SMTP greeting): The SMTP greeting commands by which a connecting client identifies itself with a hostname; EHLO is the extended form that triggers ESMTP capability negotiation, and HELO is the legacy fallback. Receivers expect the announced hostname to be consistent with forward and reverse DNS.; See also: ESMTP, Reverse DNS (PTR record), FCrDNS (Forward-Confirmed reverse DNS)
Pipelining (SMTP pipelining): An ESMTP extension that lets a client send several commands in a batch without waiting for each individual reply, reducing round trips and speeding up delivery. Servers that do not advertise PIPELINING expect strict command-by-command exchange.; See also: ESMTP, SMTP
Rate limiting / throttling (throttling, deferral): Receivers slowing a sender down with temporary deferrals when volume or reputation exceeds their comfort. It is a server-side policy (connections or messages per IP over a window), not a single standard, and respecting per-provider tolerances avoids most of it. Senders apply their own throttling outbound to stay within those tolerances.; See also: Greylisting Tarpitting Rate Controls, Soft bounce, IP warming (warmup)
SMTP (Simple Mail Transfer Protocol): The Simple Mail Transfer Protocol (RFC 5321), the text-based protocol used to transfer email between clients and servers and between servers. A session runs commands such as EHLO, MAIL FROM, RCPT TO, and DATA, with the server answering each with a numeric reply code.; See also: Reading Smtp Replies, ESMTP, SMTP reply codes (2xx / 4xx / 5xx)
SMTP reply codes (2xx / 4xx / 5xx) (reply codes, response codes, 2yz/4yz/5yz): Three-digit responses whose first digit signals the outcome: 2xx means accepted, 4xx is a transient failure the client should retry (a soft bounce), and 5xx is a permanent failure the client should not repeat (a hard bounce). The reply after the final data dot determines who owns delivery responsibility next.; See also: Reading Smtp Replies, Enhanced status codes (X.Y.Z), Soft bounce, Hard bounce
SMTP retry / queue (requeue, deferred retry): After a transient 4xx failure, a sending MTA re-queues the message and tries again later. RFC 5321 recommends a retry interval of at least 30 minutes and a give-up time of roughly 4–5 days, though MTAs vary widely. Spamware typically does not retry, which is the basis for greylisting.; See also: Soft bounce, Greylisting, SMTP reply codes (2xx / 4xx / 5xx)
STARTTLS: An ESMTP command that upgrades a plaintext SMTP connection to an encrypted TLS session. It is opportunistic by default, meaning it protects against passive eavesdropping but can be stripped by an active attacker unless reinforced by MTA-STS or DANE.; See also: TLS, Opportunistic vs enforced TLS, MTA-STS
Tarpitting (tarpit, greet delay): Deliberately slowing down an SMTP session — for example by delaying the greeting or inserting pauses between multi-line replies — to impose cost on high-volume or non-compliant senders. There is no standards-track RFC for tarpitting; it is an implementation-level defensive technique.; See also: Greylisting Tarpitting Rate Controls, Greylisting, Rate limiting / throttling

Transport security

DANE / TLSA (DANE, TLSA record): DNS-Based Authentication of Named Entities for SMTP (RFC 7672) uses DNSSEC-signed TLSA records to bind a mail server to its certificate, forcing authenticated TLS and preventing downgrade. Unlike MTA-STS, DANE depends on DNSSEC rather than the web PKI.; See also: MTA-STS, DNSSEC, Opportunistic vs enforced TLS
DNSSEC (DNS Security Extensions): DNS Security Extensions, which add cryptographic signatures to DNS records so resolvers can verify they were not tampered with in transit. DNSSEC is the foundation DANE relies on, and it strengthens the integrity of the DNS records that email authentication depends on.; See also: DANE / TLSA
FCrDNS (Forward-Confirmed reverse DNS) (forward-confirmed reverse DNS, full circle DNS): Forward-Confirmed reverse DNS, the check that an IP's PTR hostname also has a forward (A/AAAA) record resolving back to that same IP. Passing FCrDNS is a baseline expectation of legitimate mail servers and is part of Gmail's PTR requirement.; See also: Reverse DNS (PTR record), HELO / EHLO
MTA-STS (SMTP MTA Strict Transport Security): SMTP MTA Strict Transport Security (RFC 8461), a standard letting a domain publish a policy (via HTTPS and a DNS record) that requires senders to use validated TLS for inbound mail, protecting against downgrade and interception attacks. It relies on the web PKI rather than DNSSEC.; See also: Opportunistic vs enforced TLS, TLS-RPT, DANE / TLSA
Opportunistic vs enforced TLS (forced TLS, required TLS): Opportunistic TLS uses encryption if the other side offers STARTTLS but falls back to plaintext otherwise, leaving it vulnerable to a downgrade attack. Enforced TLS requires encryption and refuses to deliver without it; MTA-STS and DANE are the mechanisms that turn opportunistic TLS into enforced TLS.; See also: STARTTLS, MTA-STS, DANE / TLSA
Reverse DNS (PTR record) (PTR record, rDNS): The DNS record mapping a sending IP back to a hostname. Receivers expect it to exist and to be meaningful rather than generic or dynamic-looking; Gmail requires a valid PTR whose hostname resolves back to the sending IP. Missing or generic PTR records are a spam signal.; See also: FCrDNS (Forward-Confirmed reverse DNS), HELO / EHLO, Gmail
TLS (Transport Layer Security): Transport Layer Security, the encryption that protects an SMTP connection in transit. Gmail has required TLS for inbound mail since December 2023. TLS protects the channel between two hops; it does not encrypt the stored message or guarantee end-to-end confidentiality.; See also: STARTTLS, Opportunistic vs enforced TLS
TLS-RPT (SMTP TLS Reporting, TLSRPT): SMTP TLS Reporting (RFC 8460), a companion to MTA-STS and DANE in which receivers send senders aggregate reports of TLS negotiation successes and failures. It lets operators detect interception, misconfiguration, or downgrade attempts they would otherwise never see.; See also: MTA-STS, DANE / TLSA

Bounces & feedback

ARF (Abuse Reporting Format) (Abuse Reporting Format): The Abuse Reporting Format (RFC 5965), a standard MIME structure (multipart/report with a message/feedback-report part) used to convey spam complaints and other abuse reports. It is the format feedback loops and DMARC failure reports use to tell senders which messages were reported.; See also: Feedback loop (FBL), DMARC aggregate & failure reports (rua / ruf)
Auto-Submitted / loop prevention (null return-path, MAIL FROM:<>, loop prevention): The Auto-Submitted header (RFC 3834) marks automatically generated mail (auto-replied, auto-generated) so that responders do not reply to it, preventing mail loops. Bounces and feedback reports use a null Return-Path (MAIL FROM:<>) for the same reason — so a failure of the report cannot itself generate another report.; See also: Return-Path (bounce address), DSN (Delivery Status Notification)
DSN (Delivery Status Notification) (Delivery Status Notification, bounce message): A Delivery Status Notification, the structured machine-readable bounce message a mail system generates to report whether a message was delivered, delayed, or failed, carrying an enhanced status code. It is the formal mechanism behind the bounce emails senders process.; See also: Bounces And Dsn, NDR (Non-Delivery Report), Enhanced status codes (X.Y.Z)
Feedback loop (FBL) (FBL, complaint feedback loop, CFL): A mechanism where a mailbox provider sends senders copies of messages that its users reported as spam, in ARF format, so the complainers can be suppressed immediately. Enrollment and availability vary by provider: Yahoo's is keyed on the DKIM domain via Sender Hub, Google offers Postmaster Tools instead of a per-message FBL, and Apple offers none.; See also: ARF (Abuse Reporting Format), Complaint rate, Suppression list
Hard bounce (permanent failure, 5xx bounce): A permanent delivery failure (a 5xx reply), such as a non-existent mailbox or domain. Hard-bounced addresses must be suppressed immediately and never retried; repeatedly mailing them looks like abuse and damages reputation.; See also: Soft bounce, SMTP reply codes (2xx / 4xx / 5xx), Suppression list
List-Unsubscribe (List-Unsubscribe header): A header (RFC 2369) that gives recipients a direct way to unsubscribe, containing one or more URIs (an HTTPS URL and/or a mailto:). Mailbox providers surface it as a built-in unsubscribe control, and honoring it quickly protects your complaint rate.; See also: One-click unsubscribe (RFC 8058), List-Unsubscribe-Post, Unsubscribe
List-Unsubscribe-Post (List-Unsubscribe=One-Click): The header that, together with List-Unsubscribe, signals one-click support; its only valid value is exactly List-Unsubscribe=One-Click. Receivers POST that value to the HTTPS unsubscribe URI when the user clicks, and both headers must be covered by the message's DKIM signature.; See also: One-click unsubscribe (RFC 8058), List-Unsubscribe
NDR (Non-Delivery Report) (Non-Delivery Report, non-delivery notification): A Non-Delivery Report, the human-readable notification returned to the sender when a message cannot be delivered. In practice it is the everyday term for the bounce email a person sees, conveying the same failure the DSN encodes for machines.; See also: DSN (Delivery Status Notification), Hard bounce
One-click unsubscribe (RFC 8058) (RFC 8058, one-click List-Unsubscribe): A standard (RFC 8058) that lets a recipient unsubscribe with a single click handled by an HTTPS POST, with no login or confirmation step. It requires a List-Unsubscribe HTTPS URI, a List-Unsubscribe-Post header, and a DKIM signature covering both. Gmail and Yahoo require it for bulk marketing mail; Yahoo asks that requests be honored within 2 days.; See also: List-Unsubscribe, List-Unsubscribe-Post, Yahoo
Soft bounce (transient failure, 4xx bounce, deferral): A temporary delivery failure (a 4xx reply), such as a full mailbox, a busy server, or rate limiting. Retried sensibly these often deliver; M3AAWG suggests removing an address only after it bounces consecutively over multiple campaigns, not on a single soft bounce.; See also: Hard bounce, SMTP reply codes (2xx / 4xx / 5xx), SMTP retry / queue

Consent (permission): Permission to send a recipient mail, and the legal and reputational basis for sending it. Consent is not transferable, which is why purchased, rented, harvested, or appended lists are prohibited by M3AAWG and risky everywhere. Several laws place the burden of proving consent on the sender.; See also: Consent records, Opt-in, Suppression And Consent
DNC (Do-Not-Contact) (Do-Not-Contact): A suppression scope covering specific recipients who must never be mailed again, typically from unsubscribes, complaints, or direct requests. Properly implemented, DNC is enforced at the sending gate itself, so no upstream system can override it.; See also: Suppression list, DNP (Do-Not-Prospect)
DNP (Do-Not-Prospect) (Do-Not-Prospect): A suppression scope covering entire recipient domains or organizations that must not be prospected, often for legal, contractual, or relationship reasons. Enforced at the gate, it blocks outreach to anyone at the covered domain.; See also: Suppression list, DNC (Do-Not-Contact)
Double opt-in (confirmed opt-in) (confirmed opt-in, COI, DOI): The practice of sending a confirmation message after sign-up and only adding the address once the recipient confirms. M3AAWG and deliverability sources call confirmed opt-in the gold standard because it blocks typos, forged addresses, and most spam traps from ever entering the list.; See also: Opt-in, Typo spam trap, Suppression And Consent
Opt-in (single opt-in, permission): Consent given by an affirmative action before receiving mail, such as ticking an unchecked box or submitting a form. It is the baseline expectation of legitimate sending and of most non-US laws; pre-checked boxes do not count and are illegal in some jurisdictions.; See also: Double opt-in (confirmed opt-in), Consent, Suppression And Consent
Opt-out: A model in which mail is sent without prior consent and recipients must ask to stop. US CAN-SPAM permits this for commercial email, but deliverability sources consider opt-out acquisition the riskiest method, almost guaranteeing complaints, spam-trap hits, and blocklisting.; See also: Opt-in, CAN-SPAM, Unsubscribe
Role account (role address): A non-personal mailbox tied to a function rather than an individual, such as postmaster@, abuse@, info@, sales@, or admin@. These are frequently harvested and some double as live spam traps, so deliverability guidance is to keep them off marketing lists.; See also: Spam trap, List hygiene
Sunset policy (sunsetting, re-engagement policy): A rule for stopping mail to recipients who have been unengaged for a defined period, then suppressing them if a re-permission attempt fails. Spamhaus describes starting around a year of inactivity and iterating shorter; it is the main defense against recycled spam traps and engagement decay.; See also: Recycled spam trap, List hygiene, Engagement-based filtering
Suppression list (suppression): The list of addresses you must not mail: unsubscribes, hard bounces, and complainers. Maintaining it is not optional — it is both legal obligation and deliverability hygiene. Enforced at the sending infrastructure, it ensures no upstream application can accidentally re-mail a suppressed recipient.; See also: Suppression And Consent, DNC (Do-Not-Contact), Unsubscribe
Unsubscribe (opt-out request): The recipient's act of opting out of future mail, and the mechanism that enables it. Best practice and law require it to be easy, free, and login-free, and to be honored promptly; an unsubscribe should add the recipient to the suppression list immediately.; See also: List-Unsubscribe, One-click unsubscribe (RFC 8058), Suppression list

Spam filtering

Bayesian filtering (naive Bayes filtering, statistical filtering): A statistical spam-detection method, popularized by Paul Graham in 2002, that learns token (word and feature) probabilities from a sender's own corpus of spam and ham and combines them to estimate how spammy a message is. It requires training on both classes and works best per-user; thresholds are deployment-specific, not universal.; See also: Bayesian Spam Filtering, False positive / ham, Content filtering
Content filtering (content analysis): Receiver-side analysis of a message's headers, body, HTML, and links to judge spamminess, as opposed to connection- or reputation-based checks. Modern engines blend content scoring with authentication results, reputation, and collaborative signals rather than relying on content alone.; See also: Overview, Bayesian filtering, SpamAssassin
Corpus / TREC evaluation (spam corpus, TREC Spam Track, Ling-Spam): A corpus is a labeled collection of spam and ham used to train or evaluate a filter; the TREC Spam Track is the standard methodology that feeds messages chronologically and measures error rates such as the area above the ROC curve. Results depend heavily on the corpus, and live network lookups make some public corpora non-reproducible.; See also: Spam Corpora And Evaluation, False positive / ham
DCC (Distributed Checksum Clearinghouses) (Distributed Checksum Clearinghouses, Distributed Checksum Clearinghouse): A collaborative system where clients report fuzzy checksums of messages and servers total how many recipients saw each one. DCC measures bulkiness, not spamminess — only the recipient can say whether bulk mail is wanted — so it generally needs a local whitelist of solicited bulk sources to be used for rejection.; See also: Dcc Pyzor Razor, Fuzzy / locality-sensitive hashing, Pyzor
False positive / ham (ham, false positive): Ham is legitimate, wanted mail; a false positive is ham wrongly classified as spam. Filter designers treat false positives as far costlier than missed spam — Graham called missing legitimate mail an order of magnitude worse — which is why good filters bias toward protecting ham.; See also: False Positives Ham Protection, Bayesian filtering
Fuzzy / locality-sensitive hashing (near-duplicate detection, LSH, shingling): Hashing designed so that similar messages produce similar or matching digests, letting filters recognize a bulk campaign even when each copy is personalized or slightly altered. Unlike a cryptographic hash, which any single-character change defeats, fuzzy hashing tolerates the small variations typical of templated mail.; See also: Fuzzy Hashing Near Duplicate, Shingles, DCC (Distributed Checksum Clearinghouses)
Hashbusting: A spammer tactic of inserting small random variations into messages to defeat exact-match and fingerprint-based filters. Fuzzy and shingle-based hashing exist precisely to survive hashbusting, which is why bulk campaigns are still detectable despite per-message noise.; See also: Fuzzy / locality-sensitive hashing, DCC (Distributed Checksum Clearinghouses)
Naive Bayes (naive Bayesian classifier): The probabilistic model underlying classic Bayesian spam filters, which combines per-feature spam probabilities while assuming features are independent and the prior is even. Despite the simplifying assumptions, it performs well on token-based spam, though research shows it needs safety nets when blocked mail is deleted outright.; See also: Bayesian filtering, Corpus / TREC evaluation
Pyzor: A collaborative, networked spam-detection system that generates a short digest of each message and queries a server for how many times it has been reported as spam or whitelisted as not-spam. It supports both reporting and a not-spam whitelist operation, and anyone can run their own GPL-licensed servers.; See also: Dcc Pyzor Razor, DCC (Distributed Checksum Clearinghouses), Razor (Vipul's Razor / Razor2)
Razor (Vipul's Razor / Razor2) (Vipul's Razor, Razor2): A distributed, collaborative spam-detection network based on user submissions that computes signatures designed to spot mutating spam content and returns a 0–100 confidence value per message part. The open-source client is legacy (last updated 2013) though the network persists; SpamAssassin integrates it as the Razor2 plugin.; See also: Dcc Pyzor Razor, SpamAssassin, Pyzor
Rspamd: A high-performance, event-driven mail filtering framework (C core plus Lua scripting) that sits between the MTA and the internet. It runs authentication, content, fuzzy, RBL, statistical, and neural checks in parallel, accumulates symbol scores, and recommends an action: pass, add headers, greylist, or reject.; See also: Rspamd Architecture, Score threshold, SpamAssassin
Score threshold (spam threshold, required score): The cumulative score at which a scoring filter takes action, such as tagging or rejecting. SpamAssassin's default is 5.0, but thresholds are deployment-specific and tuned to local mail; no universal value applies, and engines like Rspamd use multiple action thresholds rather than one.; See also: SpamAssassin, Rspamd, Overview
Shingles (shingling, trigrams): Overlapping word sequences (Rspamd uses trigrams) used in text fuzzy hashing: each shingle is hashed with multiple functions and the similarity score reflects how many shingles match. This lets a filter detect messages that are similar but not identical, which is the signature of a templated bulk campaign.; See also: Fuzzy / locality-sensitive hashing, Rspamd
SpamAssassin (Apache SpamAssassin, SA): An open-source, extensible mail filter (Apache, written in Perl) that runs many tests — header, body, Bayesian, authentication, network, and collaborative checks — and sums their scores. By default a message scoring 5.0 or higher is tagged as spam, though real deployments tune this and the Bayes subsystem needs at least 200 spam and 200 ham to score.; See also: Spamassassin Architecture, Score threshold, Rspamd

Infrastructure & sending

CNAME (CNAME record, alias record): A DNS record that aliases one hostname to another, commonly used to delegate a sending or tracking subdomain to a provider while keeping it under your own domain. CNAME delegation is the preferred way to brand sending infrastructure (e.g. email.yourbrand.com) so reputation accrues to you.; See also: Sending domain / subdomain, Tracking domain
Dedicated infrastructure (dedicated sending infrastructure): Sending resources — IPs, domains, queues, and configuration — reserved for a single sender or stream rather than shared. It gives full control over reputation and volume and prevents other senders' mistakes from affecting you, in exchange for needing enough consistent volume to sustain it.; See also: Dedicated IP, Multi-tenant isolation
Email API (sending API): A programmatic interface for sending and managing mail from your own software: injecting messages, provisioning domains, and consuming delivery events. It is how applications integrate sending without speaking raw SMTP, typically paired with webhooks for real-time event feedback.; See also: Webhook, SMTP relay
IP pool (sending pool): A group of sending IPs managed together for a stream or customer, letting operators separate traffic by type or reputation. Pools enable stream separation and per-stream remediation, but using more IPs than your volume justifies can resemble snowshoeing.; See also: Stream separation, Dedicated IP, Snowshoeing
Multi-tenant isolation (tenant isolation): Keeping multiple customers' or streams' mail separated within shared infrastructure so that one tenant's reputation, complaints, or bounces do not bleed into another's. Isolation can be by IP pool, subdomain, DKIM identity, and queue, and it is what makes a well-run shared platform safe for everyone on it.; See also: IP pool, Shared IP pool, Stream separation
Sending domain / subdomain (subdomain delegation, sending subdomain): The domain (often a dedicated subdomain) used in your From: and authentication for a given mail stream. Using distinct subdomains — for example for transactional versus marketing — lets each stream build its own reputation without contaminating the others or your primary corporate domain.; See also: Stream separation, Domain reputation
SMTP relay (mail relay, relay service): A service that accepts your mail and delivers it onward to recipients. Quality varies enormously, and the relay's reputation practices and IP hygiene effectively become yours, so the choice of relay directly affects deliverability.; See also: MTA (Mail Transfer Agent), Email API, ESP (Email Service Provider)
Stream separation (stream isolation, subdomain strategy): Sending different categories of mail — transactional, marketing, operational — over separate IPs, subdomains, or pools so their reputations stay independent. Because marketing generates more complaints and trap hits, separating it protects high-stakes transactional delivery, a practice endorsed by M3AAWG and major ESPs.; See also: Sending domain / subdomain, IP pool, Transactional email
Tracking domain (click-tracking domain): The domain used in links and open-tracking pixels so that clicks and opens can be measured and rewritten links can be branded. A custom (CNAME-delegated) tracking domain aligned with your sending domain looks more trustworthy than a shared one, and its reputation feeds domain-based filtering.; See also: CNAME, Sending domain / subdomain, URIBL / SURBL
Webhook (event webhook, HTTP callback): An HTTP callback that pushes events — deliveries, bounces, deferrals, complaints, suppression hits — to your systems in near real time. It is the standard way sending infrastructure feeds CRMs, dashboards, and automated suppression workflows.; See also: Email API, Feedback loop (FBL)

Compliance & law

Australia Spam Act 2003 (Spam Act 2003, ACMA Spam Act): Australia's commercial-email law, enforced by ACMA. It requires consent (express or inferred), accurate sender identification kept valid for at least 30 days, and an unsubscribe honored within 5 working days. It prohibits address harvesting and puts the burden of proving consent on the sender. This is not legal advice.; See also: Australia Spam Act, Consent records, Opt-in
CAN-SPAM (CAN-SPAM Act): The US commercial-email law (15 U.S.C. § 7701 et seq.), enforced by the FTC. It is an opt-out regime — no prior consent is required — but it mandates accurate headers and subject lines, a physical postal address, and a working opt-out honored within 10 business days, with the mechanism functional for at least 30 days. It covers B2B mail and carries penalties up to $53,088 per violating email. This is not legal advice.; See also: Us Can Spam, Opt-out, Consent records
CASL (Canada's Anti-Spam Legislation): Canada's Anti-Spam Legislation, enforced by the CRTC. It requires express opt-in consent by default (with limited implied-consent exceptions such as an existing business relationship), sender identification, and an unsubscribe honored within 10 business days that stays functional for at least 60 days. Penalties reach CAD $1 million per violation for individuals and CAD $10 million for businesses. This is not legal advice.; See also: Canada Casl, Opt-in, Consent records
Consent records (proof of consent, consent log): Evidence of how and when a recipient consented — typically the date and time, the source or form, and the IP address of the submission. Several laws (CASL, the Australian Spam Act, Türkiye's İYS) place the burden of proving consent on the sender, so durable records support a due-diligence defense and reputation investigations.; See also: Consent, Double opt-in (confirmed opt-in), Suppression And Consent
Data residency (data localization): Where personal data is physically stored and processed, which can be constrained by law or contract (for example, keeping EU residents' data within the EU). It affects choice of sending infrastructure and is a frequent requirement in regulated industries and cross-border marketing. This is not legal advice.; See also: DPA (Data Processing Agreement), GDPR
DPA (Data Processing Agreement) (Data Processing Agreement, data protection agreement): A contract that governs how a processor (such as an ESP or sending platform) handles personal data on behalf of a controller (the sender), required under GDPR Article 28 and analogous regimes. For email, it sets the terms for processing recipient data and is often where breach-notification and mandated-email procedures are agreed. This is not legal advice.; See also: GDPR, Data residency
ePrivacy Directive (ePrivacy, Directive 2002/58/EC): EU Directive 2002/58/EC, whose Article 13 generally requires prior opt-in consent for electronic marketing to individuals and which is transposed (with variations) by each member state. It sits alongside GDPR; together they form the EU framework for email marketing consent. This is not legal advice.; See also: Eu Gdpr Eprivacy, GDPR, Opt-in
ETK / İYS (Law No. 6563, IYS, İleti Yönetim Sistemi): Türkiye's Law No. 6563 on the Regulation of Electronic Commerce: opt-in consent for commercial electronic messages to consumers (opt-out for merchants and traders), sender identification, and an opt-out honored within 3 business days. Consents must be registered in the central İYS (Message Management System) platform or they are deemed invalid. This is not legal advice.; See also: Turkey Kvkk Etk, KVKK, Consent records
GDPR (General Data Protection Regulation): The EU General Data Protection Regulation (2016/679), which governs processing of personal data including email addresses used for marketing. It grants a right to object to direct marketing (Article 21), requires a lawful basis, and provides fines up to €20 million or 4% of global annual turnover under Article 83. It works alongside the ePrivacy Directive for email marketing. This is not legal advice.; See also: Eu Gdpr Eprivacy, ePrivacy Directive, Data residency
KVKK (Kişisel Verilerin Korunması Kanunu, Law No. 6698): Türkiye's Law No. 6698 on the Protection of Personal Data, the data-protection layer that applies to processing email addresses for marketing, enforced by the KVKK Board. It typically requires a lawful basis such as consent and operates alongside the ETK commercial-messaging rules. This is not legal advice.; See also: Turkey Kvkk Etk, ETK / İYS, Consent
PECR (Privacy and Electronic Communications Regulations): The UK Privacy and Electronic Communications Regulations, enforced by the ICO and read alongside UK GDPR. Marketing email to individuals needs consent, with a soft opt-in exception for a company's own existing customers; corporate-body recipients may be emailed without prior consent, though opt-outs must be honored. This is not legal advice.; See also: Uk Pecr, Soft opt-in, GDPR
Soft opt-in (soft opt in): A UK PECR exception that lets a business email its own existing customers about similar products without explicit consent, provided it offered an opt-out at data collection and offers one in every message. It applies only to your own prior customers, not to prospects or bought-in lists. This is not legal advice.; See also: PECR, Opt-in

Standards & RFCs

IANA (Internet Assigned Numbers Authority): The Internet Assigned Numbers Authority, which maintains the registries that protocols depend on — including the SMTP enhanced status code registry and feedback report types. When a standard defines codes or parameters, IANA is where the authoritative, extensible list lives.; See also: Enhanced status codes (X.Y.Z), IETF
IETF (Internet Engineering Task Force): The Internet Engineering Task Force, the open standards body that develops and publishes the protocols behind email and the wider internet as RFCs. Working groups within the IETF produced and continue to maintain SMTP, DKIM, DMARC, ARC, and the transport-security standards.; See also: RFC, IANA
M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group): The Messaging, Malware and Mobile Anti-Abuse Working Group, an industry body whose Best Common Practices documents are a primary reference for consent, list hygiene, bounce handling, stream separation, and IP warming. Its guidance is widely cited by mailbox providers and ESPs.; See also: M3aawg Sending Best Practices, Double opt-in (confirmed opt-in), Stream separation
RFC (Request for Comments): A Request for Comments, the document series published by the RFC Editor that defines internet standards and practices, including the email protocols. Email's core specifications — SMTP, the message format, SPF, DKIM, DMARC, and more — are all RFCs, each with a stable number and canonical URL.; See also: IETF, RFC 5321 (SMTP), RFC 6376 (DKIM)
RFC 5321 (SMTP) (RFC5321, SMTP RFC): The Simple Mail Transfer Protocol specification, which defines the SMTP command/response model, reply-code classes (2xx/4xx/5xx), delivery responsibility after the data dot, and retry behavior. It is the foundation for how mail moves between servers.; See also: SMTP, SMTP reply codes (2xx / 4xx / 5xx), Reading Smtp Replies
RFC 5322 (Internet Message Format) (RFC5322, Internet Message Format): The Internet Message Format specification, which defines the structure of an email message: header fields (including From:, To:, Subject:, Date:), the body, and address and date syntax. Provider requirements to send RFC 5322-compliant messages refer to this standard.; See also: Envelope vs header (From / Return-Path), RFC 5321 (SMTP)
RFC 5965 (ARF) (RFC5965, ARF RFC): The Abuse Reporting Format specification, defining the multipart/report structure with a message/feedback-report part used to convey spam complaints and abuse reports. It is the format that feedback loops and DMARC failure reports use to tell senders which messages were reported.; See also: ARF (Abuse Reporting Format), Feedback loop (FBL)
RFC 6376 (DKIM) (RFC6376, DKIM RFC): The DomainKeys Identified Mail signature standard (an Internet Standard, STD 76), defining the DKIM-Signature header, its tags (d=, s=, c=, l=, and others), canonicalization, and the DNS public-key record format. It is the authoritative source for what a DKIM pass does and does not prove.; See also: DKIM (DomainKeys Identified Mail), Dkim
RFC 6647 (greylisting) (RFC6647, greylisting RFC): The Email Greylisting applicability statement, which describes greylisting as degrading service for unknown senders (typically a temporary 4xx) and recommends a tuple of IP, MAIL FROM, and first RCPT TO with a retry window from one minute to 24 hours. It frames greylisting as one layer in an array of anti-abuse techniques, not a standalone solution.; See also: Greylisting, Greylisting Tarpitting Rate Controls
RFC 7208 (SPF) (RFC7208, SPF RFC): The Sender Policy Framework specification, defining the SPF record syntax, mechanisms and qualifiers, the seven evaluation results, and the 10 DNS-lookup limit. It is the authority behind permerror, softfail, and the rules for include and redirect.; See also: SPF (Sender Policy Framework), SPF 10-lookup limit, Spf
RFC 8058 (one-click unsubscribe) (RFC8058): The specification for signaling one-click unsubscribe functionality in list email, defining the List-Unsubscribe-Post header with its sole value List-Unsubscribe=One-Click and the HTTPS POST behavior. It underpins the one-click unsubscribe that Gmail and Yahoo require for bulk marketing mail.; See also: One-click unsubscribe (RFC 8058), List-Unsubscribe-Post
RFC 8460 (TLS-RPT) (RFC8460, TLSRPT RFC, TLS-RPT RFC): The SMTP TLS Reporting specification, defining how receivers send senders aggregate reports of TLS negotiation outcomes so operators can detect interception, downgrade, or misconfiguration. It is the reporting companion to MTA-STS and DANE.; See also: TLS-RPT, RFC 8461 (MTA-STS)
RFC 8461 (MTA-STS) (RFC8461, MTA-STS RFC): The SMTP MTA Strict Transport Security specification, letting a domain publish a policy that requires senders to use validated TLS for inbound mail, defending against downgrade and interception attacks using the web PKI.; See also: MTA-STS, RFC 8460 (TLS-RPT)
RFC 8617 (ARC) (RFC8617, ARC RFC): The Authenticated Received Chain specification (Experimental), defining the AAR, AMS, and ARC-Seal headers, instance numbering from 1 to 50, and chain validation status. It lets intermediaries preserve authentication results so DMARC failures from forwarding can be reassessed.; See also: ARC (Authenticated Received Chain), ARC header set (AAR / AMS / AS), Arc
RFC 9989 (DMARC) (RFC9989, DMARC RFC, DMARCbis): The current DMARC core specification (May 2026), which obsoletes RFC 7489. It introduces the DNS Tree Walk for finding the organizational domain, adds the np= and t= tags, removes pct=, and forbids rejecting solely on p=reject. Aggregate and failure reporting are split into the companion RFCs 9990 and 9991.; See also: DMARC, DMARC Tree Walk, Dmarc 2026

Want this handled instead of memorized?

Domains, rough volume, current providers, and what hurts. You will get a straight answer on fit, and a real number, in one conversation.

Talk to our team