Email deliverability has a specialised vocabulary that spans email authentication protocols, ISP-specific concepts, MTA terminology, and engagement metrics. This glossary provides complete definitions for every key term used in email deliverability and email infrastructure — from A-record to VMTA — with enough technical depth to understand the concept fully and enough context to understand why it matters for inbox placement. Terms are grouped thematically rather than alphabetically to help readers understand how related concepts connect.
Authentication Terms: SPF, DKIM, DMARC, BIMI, ARC
SPF (Sender Policy Framework): An email authentication protocol that allows domain owners to specify which mail servers are authorised to send email on behalf of their domain. SPF is published as a TXT record in DNS containing a list of authorised sending IPs and mechanisms (include:, a:, mx:, ip4:, ip6:). When a receiving server receives email, it queries the MAIL FROM domain's SPF record and evaluates whether the sending IP is authorised. SPF can produce results of pass, fail, softfail, neutral, none, permerror, or temperror. SPF does not survive email forwarding — a forwarded message fails SPF because the forwarding server's IP is not in the original sender's SPF record.
DKIM (DomainKeys Identified Mail): A cryptographic email authentication protocol that adds a digital signature to outbound email. The signature is generated using a private key stored on the sending server and can be verified by any receiving server using the corresponding public key published in DNS (at selector._domainkey.domain.com). DKIM signs a specified set of headers and the email body, allowing the receiving server to verify that the signed content has not been modified in transit and that the signer controls the signing domain. DKIM signatures survive forwarding as long as the signed content is not modified. DKIM key length should be 2048 bits minimum; 1024-bit keys are deprecated by major ISPs. The d= parameter identifies the signing domain; the s= parameter identifies the selector used to find the public key in DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance): An email authentication protocol that builds on SPF and DKIM to provide domain-level protection against spoofing. DMARC is published as a TXT record at _dmarc.domain.com and specifies: (1) a policy (p=none: monitor only; p=quarantine: route failing messages to spam; p=reject: block failing messages), (2) a percentage to apply the policy to (pct=100 applies to all messages), (3) reporting addresses for aggregate reports (rua=) and forensic reports (ruf=). DMARC alignment requires that the From: header domain aligns with either the SPF-authenticated MAIL FROM domain or the DKIM d= signing domain. Advancing from p=none to p=reject provides the strongest brand protection and improves inbox placement by 6-8 percentage points at Gmail.
BIMI (Brand Indicators for Message Identification): An email standard that allows brands to display a verified logo in supported inboxes when their email passes DMARC authentication at enforcement level (p=quarantine or p=reject). BIMI requires a TXT record published at default._bimi.domain.com pointing to an SVG Tiny P/S compliant logo file. Gmail requires a VMC (Verified Mark Certificate) or CMC (Common Mark Certificate) for logo display. Yahoo Mail supports BIMI with or without a certificate. BIMI provides brand recognition and trust signals in the inbox list view, with measurable open rate lift (reported at 10-15% by early adopters).
VMC (Verified Mark Certificate): A digital certificate that cryptographically links a brand's logo to its sending domain for BIMI purposes. VMC requires a registered trademark for the logo in a supported jurisdiction. VMC is required for the Gmail verified checkmark (the blue checkmark badge that appears alongside the BIMI logo). Issued by DigiCert or Entrust (the two authorised certificate authorities for VMC as of 2026). Annual cost approximately $1,500-2,000.
CMC (Common Mark Certificate): A BIMI certificate type introduced in 2023 that does not require a registered trademark. CMC requires proof of 12+ months of consistent logo use in public-facing materials. CMC enables Gmail BIMI logo display (but not the verified checkmark, which requires VMC). CMC has made BIMI accessible to organisations without trademark registration. Annual cost approximately $800-1,500.
ARC (Authenticated Received Chain): An email authentication standard (RFC 8617) that allows email intermediaries (mailing lists, forwarding services, email gateways) to preserve the authentication state of a message through forwarding. ARC adds three headers per forwarding hop: ARC-Seal (seals the ARC chain), ARC-Authentication-Results (records the authentication state at receipt), and ARC-Message-Signature (signs the message as received). ARC allows receiving servers to honour the original sender's DMARC authentication even when forwarding has broken the direct SPF/DKIM chain.
DKIM Selector: A string (e.g., "mail", "mail2026") that identifies which DKIM public key in DNS to use to verify a specific DKIM signature. The selector appears in the s= tag of the DKIM-Signature header and is used to construct the DNS lookup: selector._domainkey.domain.com. Multiple selectors allow different signing keys to coexist for the same domain (e.g., different keys for different ESPs, or during key rotation when old and new keys are both valid).
DKIM Key Rotation: The process of replacing an existing DKIM signing key with a new one. Best practice is to rotate DKIM keys annually or after any key compromise. The rotation process: generate new key pair; publish new public key in DNS under a new selector; configure the signing system to use the new selector; verify the new key is signing correctly; retire the old selector after confirming all mail signed with the old key has been delivered.
FCrDNS (Forward-Confirmed Reverse DNS): Also called rDNS or PTR/FCrDNS. The verification that a sending IP's PTR record (reverse DNS) resolves to a hostname, and that hostname's A record resolves back to the same IP. FCrDNS is required by major ISPs including Microsoft 365 for SMTP connection acceptance. Missing or broken FCrDNS causes connection-level rejection at strict ISPs. FCrDNS is configured by the IP hosting provider (not the domain owner) via the PTR record.
PTR Record: A DNS record type that maps an IP address to a hostname. PTR records exist in the reverse DNS zone (in-addr.arpa for IPv4, ip6.arpa for IPv6). For email, each sending IP must have a PTR record set by the hosting provider. The PTR record must match the hostname used in EHLO and must resolve back to the same IP (FCrDNS). PTR records are controlled by the IP owner (hosting provider), not by the domain owner.
MTA-STS (Mail Transfer Agent Strict Transport Security): A mechanism allowing email senders and receivers to declare their ability to receive TLS-encrypted connections and to specify whether receiving servers should refuse to deliver messages over unencrypted connections. Published via HTTPS at mta-sts.domain.com and a DNS TXT record at _mta-sts.domain.com. Prevents downgrade attacks where an attacker intercepts SMTP traffic and forces plaintext delivery.
TLS-RPT (SMTP TLS Reporting): A mechanism for receiving reports about email delivery failures related to SMTP TLS when MTA-STS is deployed. Published as a DNS TXT record at _smtp._tls.domain.com specifying a reporting endpoint. Provides visibility into TLS negotiation failures for email destined to the domain.
DANE (DNS-Based Authentication of Named Entities): A protocol for publishing TLS certificate information in DNS (TLSA records) to allow mail servers to verify the identity of destination mail servers during SMTP delivery. DANE provides stronger authentication than MTA-STS for environments where DNSSEC is deployed.
Reputation and Filtering Terms
Domain Reputation: A sender's trustworthiness score as maintained by ISPs for a specific sending domain. Gmail Postmaster Tools publishes domain reputation as: Bad, Low, Medium, or High. Domain reputation is primarily influenced by spam complaint rate, engagement rates, authentication correctness, and sending consistency. Unlike IP reputation, domain reputation follows the sender's domain rather than their sending IPs — making it portable across IP and ESP changes when DKIM signing uses the sender's own domain.
IP Reputation: A sender's trustworthiness score as maintained by ISPs for a specific sending IP address. IP reputation is influenced by complaint rates, spam trap hits, blacklist listings, and sending volume patterns from that specific IP. Microsoft SNDS provides IP reputation monitoring for Outlook.com and Microsoft 365. IP reputation is IP-specific — changing IPs resets IP reputation, while domain reputation persists.
Sender Score: A numerical score (0-100) produced by Validity (formerly Return Path) representing an IP address's reputation based on behaviour across its global email network. A score of 80+ indicates good reputation; 70-79 is average; below 70 indicates reputation problems. SenderScore.org provides free score lookup. Sender Score is one of many reputation signals; it is not used directly by all ISPs but correlates with overall deliverability health.
Spam Trap: An email address that is used to identify senders with poor list hygiene or malicious intent. There are two types: pristine spam traps (addresses that have never been used for legitimate purposes and are distributed through channels specifically to identify scrapers and list purchasers) and recycled spam traps (formerly valid email addresses that were abandoned and repurposed by ISPs or anti-spam organisations as traps after a period of time). Sending to any spam trap address is a strong negative reputation signal that can cause blacklist listings.
Blocklist (Blacklist): A list of IP addresses or domain names associated with spam or malicious activity, maintained by organisations including Spamhaus, Barracuda, SORBS, and others. ISPs and corporate email gateways use blocklists as inputs to their spam filtering decisions. A listing on Spamhaus SBL (Spamhaus Block List) causes delivery rejection at many major ISPs. Legitimate senders can request delisting after addressing the cause of the listing.
Postmaster Tools: Google's domain reputation monitoring dashboard for email senders. Postmaster Tools (at postmaster.google.com) provides: domain reputation (High/Medium/Low/Bad), spam rate per domain, delivery errors, authentication success rates, and encryption statistics. Requires domain ownership verification. Essential monitoring tool for any programme sending to Gmail addresses. Updated daily with 24-48 hour data lag.
SNDS (Smart Network Data Services): Microsoft's IP reputation monitoring portal. SNDS provides complaint rate data and spam trap hit data for registered sending IPs, displayed as Green (good), Yellow (caution), or Red (bad) status. SNDS enrollment is required to receive this reputation feedback; unenrolled IPs receive no Microsoft-specific reputation data. Available at postmaster.live.com.
FBL (Feedback Loop): A mechanism through which ISPs send complaint reports to senders when their users mark messages as spam. Yahoo FBL, Microsoft JMRP (Junk Mail Reporting Program), and other ISP FBLs send ARF-format complaint reports to registered senders. FBL enrollment enables complaint-based suppression — removing complainers from future sends before they accumulate into reputation damage. Gmail does not provide individual-level FBL reports; its complaint data is available only through Postmaster Tools aggregate statistics.
Bounce and Delivery Status Terms
Hard Bounce: A permanent email delivery failure caused by a non-existent, invalid, or blocked email address. The SMTP response code for a hard bounce is 5xx (permanent failure). Hard-bounced addresses must be immediately added to the suppression list — continuing to send to addresses that hard bounce generates reputation damage with no possibility of successful delivery. Common hard bounce codes: 550 5.1.1 (user unknown), 550 5.1.2 (domain not found), 550 5.7.1 (sender not authorised).
Soft Bounce: A temporary email delivery failure that may resolve on retry. The SMTP response code for a soft bounce is 4xx (temporary failure). Common causes: recipient's mailbox full (452 4.2.2), destination server temporarily unavailable (421), or throttling by the receiving server (421 4.7.0). MTAs automatically retry soft bounces according to their retry schedule. Addresses that soft bounce repeatedly (typically 3-5 consecutive attempts) over a period of days should be treated as hard bounces and suppressed.
Deferral: A soft bounce where the receiving server has temporarily rejected the message, typically due to rate limiting or reputation concerns. The sending MTA holds the message in queue and retries according to the retry schedule. A high deferral rate (above 20%) at a specific ISP indicates rate limiting or reputation problems with that ISP that require investigation.
DSN (Delivery Status Notification): A standardised message format that MTAs use to report delivery status — successful delivery, deferral, or permanent failure — back to the original sender. DSN messages are sent to the MAIL FROM (Return-Path) address. Bounce processors monitor the MAIL FROM address's mailbox for DSN messages to classify and suppress bounced addresses.
ARF (Abuse Reporting Format): The standard format used for FBL complaint reports. ARF messages contain the original email that was marked as spam (with recipient details anonymised by most ISPs) and metadata about the complaint. Senders enrolled in ISP FBLs receive ARF-format complaints and must process them to suppress complainers from future sends.
ISP and Postmaster Terminology
EOP (Exchange Online Protection): Microsoft's cloud-based email filtering service that protects Microsoft 365 (formerly Office 365) email. EOP evaluates incoming email for spam, phishing, and malware before delivering to Microsoft 365 mailboxes. EOP is the primary anti-spam layer for the majority of corporate email worldwide. EOP uses IP reputation (via SNDS), DMARC/DKIM/SPF authentication, content scoring, and machine learning signals for filtering decisions.
MAGY: The acronym for the four major consumer email providers whose bulk sender requirements commercial senders must comply with: Microsoft, Apple, Google (Gmail), and Yahoo. The MAGY bulk sender requirements (announced in 2024-2025) require SPF, DKIM, DMARC, FCrDNS, TLS, one-click unsubscribe, and spam rate management for bulk commercial senders.
JMRP (Junk Mail Reporting Program): Microsoft's feedback loop program that provides complaint reports to registered senders when Outlook.com and Microsoft 365 users mark messages as junk. JMRP enrollment requires registering sending IPs at the Microsoft Postmaster Portal. JMRP complaints arrive as ARF-format messages to the registered report recipient address.
Promotions Tab: Gmail's filtered inbox category for promotional marketing emails. Emails routed to the Promotions tab are considered delivered — they are not in spam — but may have lower open rates than inbox-primary delivery because many Gmail users check Promotions less frequently. Gmail uses engagement signals, content analysis, and sender reputation to determine whether marketing email lands in Primary or Promotions. Deliverability professionals generally treat Promotions tab delivery as a success (not spam) but acknowledge the engagement rate difference.
Infrastructure and MTA Terms
MTA (Mail Transfer Agent): Software that transfers email messages between servers using SMTP. Commercial MTAs include PowerMTA and Postfix; open-source alternatives include Postal and Exim. The MTA is responsible for SMTP connection management, queue management, bounce processing, DKIM signing integration, and delivery retry logic.
VMTA (Virtual MTA): A logical sending configuration within PowerMTA that defines a specific combination of sending IP, EHLO hostname, DKIM signing configuration, and per-domain delivery parameters. VMTAs enable multi-client sending from a single PowerMTA instance with complete reputation isolation between clients — each client's VMTA uses its own IP pool and domain, so one client's reputation event does not affect other clients' VMTAs.
Domain Block (PowerMTA): A PowerMTA configuration section that defines per-destination-domain SMTP connection parameters — maximum concurrent connections (max-smtp-out), retry interval, message-rate limits, and queue management for that specific destination domain. Domain blocks allow different connection limits for Gmail (20 concurrent), Microsoft (12 concurrent), and Yahoo (15 concurrent) from a single PowerMTA instance.
Queue Management: The set of operations that control how messages in an MTA's delivery queue are processed: flushing queued messages to force immediate retry, holding queued messages to pause delivery for a specific destination, purging (deleting) queued messages, and monitoring queue depth as an operational health indicator.
Accounting Log: PowerMTA's per-event delivery log that records every delivery attempt, SMTP response, and queue state change in structured format. The accounting log is the primary diagnostic tool for PowerMTA installations — it provides per-message, per-ISP delivery data that enables rapid identification of delivery problems by destination domain, SMTP response code, or sending IP.
SMTP (Simple Mail Transfer Protocol): The application protocol used to transfer email between servers. SMTP defines the connection handshake (EHLO), sender/recipient declaration (MAIL FROM, RCPT TO), message data transfer (DATA), and connection termination (QUIT). SMTP response codes are three-digit numbers: 2xx (success), 4xx (temporary failure/retry), 5xx (permanent failure/bounce).
EHLO (Extended Hello): The SMTP command sent by the connecting mail server to identify itself to the receiving server. The EHLO hostname is a key technical element: it must be a valid fully-qualified domain name, must match the PTR record of the sending IP, and must resolve in forward DNS. An EHLO hostname that does not match the PTR record triggers FCrDNS failures at strict ISPs.
Return-Path: The email address to which bounce notifications (DSN messages) are sent. Also called the MAIL FROM address or envelope sender. The Return-Path domain is evaluated in SPF authentication. The Return-Path is separate from the From: header address (which is shown to recipients) — many email programmes use a dedicated bounce-processing subdomain as the Return-Path (e.g., bounces.brand.com) separate from the human-readable From: address (noreply@brand.com).
Engagement and Analytics Terms
Inbox Placement Rate: The percentage of delivered emails that land in the recipient's primary inbox (or Promotions tab in Gmail's case) rather than the spam folder. Measured through seed testing — sending the campaign to a set of seed addresses across ISPs and checking where each seed address receives the message. Industry average inbox placement is approximately 83-85%; top-quartile programmes achieve 95%+.
Open Rate: The percentage of delivered emails that generate an open event (tracking pixel load). Open rate has been significantly inflated since Apple Mail Privacy Protection (2021) pre-loads tracking pixels, and further inflated since Gmail Gemini AI (2025) auto-opens emails for summary generation. As of 2026, open rate is an unreliable engagement metric — click rate, reply rate, and conversion rate are more reliable indicators of genuine engagement.
Click Rate (Click-Through Rate): The percentage of delivered emails where a recipient clicked at least one link. Click events require human action — neither Apple MPP nor Gmail Gemini generates false click events. Click rate is the most reliable engagement metric available in the Apple MPP and Gemini era.
Spam Complaint Rate: The percentage of delivered messages that recipients mark as spam. Gmail Postmaster Tools provides spam rate as a daily percentage for the sending domain. The MAGY bulk sender requirement is to keep Gmail spam rate below 0.10%; Google recommends staying below 0.05% for optimal inbox placement.
IP Warming: The process of gradually increasing sending volume from a new IP address over several weeks to build positive reputation with ISPs before sending at full production volume. New IPs start with no reputation history — ISPs apply more aggressive spam filtering to unknown IPs. Warmup sends to the most engaged subscribers at increasing volumes allows ISPs to observe positive engagement signals that build reputation incrementally.
Compliance and Regulatory Terms
CAN-SPAM: The US Controlling the Assault of Non-Solicited Pornography And Marketing Act (2003). CAN-SPAM applies to commercial email and requires: accurate From and Subject information, identification of commercial content, a valid physical mailing address, and a functional opt-out mechanism that must be processed within 10 business days. CAN-SPAM does not require prior consent (unlike GDPR) — it is an opt-out law, not an opt-in law.
GDPR (General Data Protection Regulation): The EU regulation governing personal data processing, effective May 2018. For email marketing, GDPR requires a valid lawful basis for sending email to EU residents — typically explicit consent for marketing communications. GDPR also governs the storage, processing, and transfer of email addresses as personal data, requiring data protection measures, data subject rights (including right to erasure), and data processing agreements with ESPs.
CASL (Canada's Anti-Spam Legislation): Canada's anti-spam law, the strictest major commercial email regulation globally. CASL requires express or implied consent before sending commercial email to Canadian recipients. Express consent requires an explicit opt-in action. Implied consent exists for limited circumstances (existing business relationships). CASL violation penalties can reach CAD $10 million per violation for organisations.
One-Click Unsubscribe: The MAGY bulk sender requirement (based on RFC 8058) that commercial senders include List-Unsubscribe and List-Unsubscribe-Post headers enabling recipients to unsubscribe through their email client's interface without visiting a separate webpage. The unsubscribe endpoint must accept POST requests and process the removal within 2 business days.
Double Opt-In: A subscription confirmation process that requires new subscribers to take two actions: the initial sign-up (entering their email address) and a confirmation action (clicking a link in a confirmation email sent to the provided address). Double opt-in verifies that the email address is valid and that the person with access to the inbox consented to the subscription. Double opt-in lists have lower bounce rates, lower complaint rates, and higher engagement rates than single opt-in lists.
Technical Protocol Terms
RFC 5321: The IETF standard defining the Simple Mail Transfer Protocol (SMTP). RFC 5321 specifies the protocol used for mail transfer between servers, including the EHLO handshake, MAIL FROM and RCPT TO commands, DATA transmission, and SMTP response codes.
RFC 5322: The IETF standard defining the format of Internet Message Format — the structure of email messages, including the required headers (From, Date, Message-ID), optional headers (Reply-To, CC, BCC), and the body format. RFC 5322 compliance is a requirement for email delivery at major ISPs.
RFC 7208: The IETF standard defining SPF (Sender Policy Framework), including the DNS record format, mechanism evaluation rules, the 10-lookup limit, and result definitions (pass, fail, softfail, neutral, none, permerror, temperror).
RFC 6376: The IETF standard defining DKIM (DomainKeys Identified Mail), including the signature format, canonicalisation algorithms (simple and relaxed), header and body signing requirements, and key publication in DNS.
RFC 7489: The IETF standard defining DMARC (Domain-based Message Authentication, Reporting and Conformance), including the policy record format, alignment requirements, aggregate and forensic reporting specifications, and failure handling policies.
RFC 8617: The IETF standard defining ARC (Authenticated Received Chain), including the three ARC header types, sealing procedure, and chain validation.
RFC 8058: The IETF standard defining one-click unsubscribe (List-Unsubscribe-Post header), specifying the POST-based unsubscribe mechanism required by Gmail's bulk sender requirements for the one-click unsubscribe feature.
DNSSEC (DNS Security Extensions): A set of DNS protocol extensions that add cryptographic signatures to DNS records, allowing resolvers to verify that DNS responses have not been tampered with in transit. DNSSEC protects email authentication records (SPF, DKIM, DMARC, BIMI) from DNS spoofing attacks where an attacker manipulates DNS responses to redirect email authentication lookups. DNSSEC is published and managed through the domain registrar and hosting provider; implementation requires both zone signing and resolver validation support.
TLS (Transport Layer Security): The cryptographic protocol that encrypts SMTP connections between mail servers, preventing interception of email content in transit. TLS 1.2 and 1.3 are the required versions; TLS 1.0 and 1.1 are deprecated and disabled by major ISPs. MAGY sender requirements mandate TLS encryption for all outbound SMTP connections from bulk senders.
MX Record: A DNS record type that specifies the mail servers responsible for receiving email for a domain. MX records contain a priority value and a mail server hostname. When an MTA sends email to recipient@domain.com, it queries the MX records for domain.com to find the destination mail server. For sending-only domains (domains used for sending but not receiving), MX records should still be configured for bounce processing and DMARC report receipt.
This glossary covers the core vocabulary of email deliverability — the terms used throughout this site and throughout the broader email industry. Understanding these terms precisely enables more effective communication with ESPs, ISPs, and other email professionals, and more accurate diagnosis of deliverability problems when they occur. Bookmark this glossary as a reference for any term encountered in audit reports, postmaster documentation, or deliverability discussions — and use the related guides throughout this site to go deeper on any concept that the definition here introduced.