Email Deliverability Glossary

SPF — Sender Policy Framework

RFC 7208. DNS-based mechanism that authorizes which IP addresses may send email on behalf of a domain. Evaluated at SMTP connection time against the Envelope Sender (MAIL FROM) domain — not the visible From header a recipient sees. Result can be pass, fail, softfail, fail, or permerror. SPF alone does not protect the visible From header; that requires DMARC alignment. Complex include chains are constrained by a hard 10-lookup limit — see SPF Flattening.

DKIM — DomainKeys Identified Mail

RFC 6376. Cryptographic signature added to the message header by the sending MTA. The receiving MTA retrieves the public key from DNS (at _domainkey.yourdomain.com) and verifies the signature against the message. Unlike SPF, DKIM survives email forwarding because it signs the message itself rather than authorizing a sending IP. Required alongside SPF for DMARC to provide forwarding-resilient authentication.

DMARC — Domain-based Message Authentication, Reporting & Conformance

RFC 7489. Policy layer built on top of SPF and DKIM. Allows domain owners to publish a policy declaring what receivers should do with messages that fail authentication. DMARC requires identifier alignment — the authenticated domain must match the visible From header. Reporting via rua (aggregate) and ruf (forensic) gives senders visibility into who is sending on their behalf.

ARC — Authenticated Received Chain

RFC 8617. Protocol that preserves authentication results across email forwarding hops. When a message is forwarded, SPFtypically breaks because the forwarding server's IP is not in the original sender's record. ARC allows the forwarding server to cryptographically sign the original authentication results, so downstream receivers can trust them even after the forward. The modern alternative to SRS for forwarding-resilient DMARC compliance.

BIMI — Brand Indicators for Message Identification

Standard that displays a brand logo next to authenticated messages in supporting mailbox providers (Gmail, Yahoo, Apple Mail). Requires DMARC at p=quarantine or p=reject with full alignment, plus a Verified Mark Certificate (VMC) from an approved certificate authority for most providers. Published as a DNS TXT record at default._bimi.yourdomain.com.

MTA-STS — Mail Transfer Agent Strict Transport Security

RFC 8461. Policy mechanism that allows domains to declare they support TLS for inbound SMTP and that sending MTAs must refuse to deliver over unencrypted connections. Prevents downgrade attacks where an attacker tricks a sending MTA into delivering over plaintext. Published via an HTTPS policy file and a DNS TXT record at _mta-sts.yourdomain.com.

DMARC Alignment

The requirement, enforced by DMARC, that the domain authenticated by SPF or DKIM matches the RFC 5322 From header domain. SPF alignment checks whether the Envelope Sender domain matches From. DKIM alignment checks whether the d= tag in the DKIM signature matches From. Alignment can be strict (exact domain match) or relaxed (organizational domain match). A DMARC check passes when at least one of SPF or DKIM passes with alignment.

Identifier Alignment

See DMARC Alignment. The specific requirement that the domain visible in the From header aligns with the domain authenticated via SPF or DKIM. Without alignment, a message can pass SPF or DKIM while still presenting a spoofed From address to the recipient.

Envelope Sender (MAIL FROM)

The domain used in the SMTP MAIL FROM command during message transfer. Also called the Return-Path or bounce address (5321.From). This is the domain SPF evaluates — not the visible From header the recipient sees. When MAIL FROM is empty (as in bounce messages and DSNs), SPF falls back to evaluating the HELO/EHLO hostname instead.

HELO / EHLO

The hostname an MTA announces at the start of an SMTP session. EHLO is the modern extended version; HELO the legacy form. When MAIL FROM is empty (bounce messages, DSNs), RFC 7208 requires SPF to be evaluated against the HELO/EHLO hostname. Many senders publish SPF for their primary domain but neglect to publish a record for their MTA hostname, leaving HELO-based checks unauthenticated.

SPF Flattening

The practice of resolving all nested include: mechanisms in an SPF record down to their constituent IP ranges and publishing those directly as ip4: / ip6: entries. Necessary when an SPF record approaches the hard 10-lookup limit. Each include: that references another domain with its own includes consumes from the budget recursively. Flattening eliminates recursion and void lookups, at the cost of needing maintenance whenever a vendor changes their IP ranges.

Void Lookup

An SPF DNS query that resolves successfully but returns no usable records (NODATA or NXDOMAIN). RFC 7208 limits void lookups to 2; exceeding this triggers permerror. Stale include: mechanisms from decommissioned ESPs or retired SaaS vendors are the most common source of void lookups that silently consume budget without providing authorization.

permerror / softfail / fail

Three SPF result codes indicating the message did not pass:

• fail (-all): The sending IP is explicitly not authorized. DMARC treats this as an authentication failure.
• softfail (~all): The sending IP is not authorized but the domain owner requests lenient handling. Receivers may accept or flag the message.
• permerror: SPF evaluation could not complete — caused by exceeding the 10-lookup limit, a void lookup over-budget, or a DNS syntax error. DMARC treats permerror identically to fail. It is not a soft warning.

rua — Aggregate Reports

The rua= tag in a DMARC record specifies where receivers should send daily XML aggregate reports. These reports summarize every message processed claiming your domain, broken down by source IP, authentication result (SPF / DKIM / DMARC pass or fail), and receiver disposition. Essential for monitoring who is sending on your behalf, spotting permerror events, and tracking alignment failures before they affect delivery. Compare with ruf (forensic reports).

ruf — Forensic Reports

The ruf= tag in a DMARC record specifies where receivers send copies of individual failing messages (or redacted headers) in near real-time. Provides granular debugging context that aggregate reports cannot: the actual message headers, the failing mechanisms, and the specific result codes. Not universally supported by all receivers; many senders omit ruf= for privacy reasons since reports may contain message content.

DMARC Policy

The p= tag in a DMARC record declares how receivers should handle messages that fail DMARC:

• none: Monitor only. No action on failing messages. Receive rua reports to assess authentication coverage before escalating.
• quarantine: Failing messages should be treated as suspicious — typically routed to the spam/junk folder.
• reject: Failing messages should be rejected at the SMTP layer. The strongest enforcement level; prevents spoofed mail from reaching recipients at all.

Standard practice: start at p=none, review aggregate reports until all legitimate mail passes, then escalate to quarantine and finally reject.

MTA — Mail Transfer Agent

Software responsible for transferring email between servers using SMTP. The sending MTA connects to the receiving MTA, announces its HELO/EHLO hostname, delivers the message, and handles bounces and DSNs. Common MTAs: Postfix, Exim, Sendmail, Microsoft Exchange. The MTA hostname must have a forward-confirmed PTR record as a baseline deliverability requirement. Throttling and greylisting are policies applied by the receiving MTA.

PTR Record / Reverse DNS

A DNS record that maps an IP address back to a hostname. Receiving MTAs verify that the connecting IP has a PTR record, and that the PTR hostname resolves forward back to the same IP (forward-confirmed reverse DNS, or FCrDNS). Missing or mismatched PTR records signal a misconfigured sender — a common IP reputation red flag. Required for dedicated sending infrastructure; most cloud and ESP environments handle PTR records automatically.

Dedicated IP vs. Shared IP

Two models for outbound email sending infrastructure:

• Dedicated IP: A single sender owns the IP address. IP reputationis isolated to that sender's behavior. Requires IP warming before sending at volume.
• Shared IP: Multiple senders share the same IP. Reputation is pooled — poor behavior by one sender can affect others on the same IP. Typical for low-volume senders who have not yet warmed a dedicated IP.

IP Warming

The practice of gradually increasing email send volume from a new dedicated IP over days or weeks. Mailbox providers build IP reputation from observed sending patterns and have no history for a cold IP. Sending large volumes immediately triggers throttling, bulking, or outright rejection. Warming schedules typically start with a few hundred messages per day to the most engaged subscribers, scaling up over 4–8 weeks.

Feedback Loop (FBL)

A service offered by mailbox providers that forwards spam complaints directly to senders. When a recipient clicks “This is spam,” the mailbox provider sends a complaint notification to the sender's registered FBL address. Used to maintain suppression lists and track complaint rates. Gmail does not offer a traditional FBL — it surfaces complaint rates via Google Postmaster Tools instead. Yahoo, Comcast, and others maintain standard FBL programs.

Greylisting

A receiving MTA technique that temporarily rejects messages from unknown senders with a 4xx (temporary failure) SMTP code. Legitimate MTAs automatically retry after a delay; spam bots typically do not. On retry, the message is usually accepted. Can cause delivery delays of minutes to hours for first-contact senders. Legitimate senders with proper MTA retry logic are unaffected in the long run.

Throttling

Rate limiting applied by receiving MTAs to inbound connections or messages from a given IP or domain. Expressed as deferred 4xx SMTP responses. Common triggers: new senders during IP warming, weak IP reputation, or sudden volume spikes. A sending MTA should honor throttle signals by reducing connection rate and messages-per-connection rather than forcing delivery through retries.

IP Reputation

A mailbox provider's assessment of a sending IP address based on observed behavior: complaint rates, spam trap hits, hard bounce rates, engagement signals, blocklist status, and PTR record validity. IP reputation is tied to the address — switching to a new IP resets reputation history and requires warming. Compare with domain reputation, which persists across IP changes.

Domain Reputation

A mailbox provider's assessment of a sending domain (the From domain). Informed by DMARC alignment, DKIM signing consistency, complaint rates, and engagement signals. Gmail weights domain reputation as its primary deliverability signal over IP reputation. Domain reputation transfers across IP changes — a domain with poor reputation will underperform on new IPs.

Sender Score

A third-party IP reputation score (0–100) published by Validity (formerly Return Path). Historically referenced as a proxy for inbox placement likelihood. A score below 70 has traditionally correlated with delivery problems. Sender Score and similar tools (Talos Intelligence, Barracuda Reputation) are indicators, not sources of truth — mailbox providers build their own internal reputation systems independently of any third-party score. Use alongside IP reputation and domain reputation signals rather than in isolation.

Blocklist / Denylist

A DNS-based list (DNSBL or RBL) of IP addresses or domains associated with spam, malware, or abuse. Receiving MTAs query blocklists during SMTP connection to determine whether to accept or reject. Major blocklists include Spamhaus (XBL, SBL, DBL), SURBL, and Barracuda. Listings typically result from spam trap hits, high complaint rates, or abuse reports. Removal processes vary by blocklist operator and can take hours to weeks.

Spam Trap / Honeypot

Email addresses maintained by mailbox providers and anti-spam organizations to identify senders with poor list hygiene:

• Pristine traps: Addresses that have never been used by a real person, seeded in locations only scrapers find. Hitting one signals address harvesting.
• Recycled traps: Addresses that were real but abandoned, then repurposed after a dormancy period. Hitting one signals sending to an old, unmaintained list.

Both types contribute to blocklist listings and negative IP reputation.

Complaint Rate

The percentage of delivered messages that recipients mark as spam. Gmail's bulk sender guidelines set a threshold of below 0.10%, with 0.30% being the level at which serious delivery impact occurs. Complaint rates are tracked via Feedback Loops and Google Postmaster Tools. Sustained high complaint rates trigger bulking, throttling, and eventual blocklisting. Complaint rate is one of the strongest signals mailbox providers use to evaluate sender trust.

Hard Bounce

A permanent delivery failure, indicated by an SMTP 5xx status code. Common causes: non-existent address (550 user unknown), domain does not exist, or the recipient MTA has permanently blocked the sender. Hard bounced addresses must be added to the suppression list immediately and never mailed again. Continuing to mail them signals poor list hygiene and degrades IP reputation.

Soft Bounce

A temporary delivery failure, indicated by an SMTP 4xx status code. Common causes: recipient mailbox full, receiving MTA temporarily unavailable, or connection throttled. Sending MTAs automatically retry soft bounces over a configurable window (typically 24–72 hours). If retries exhaust without success, the message is abandoned. Repeated soft bounces to the same address across multiple campaigns may indicate the address is effectively inactive and should be suppressed.

DSN — Delivery Status Notification

A machine-readable bounce message returned by an MTA when delivery fails permanently or temporarily. DSNs contain structured status codes (RFC 3463) that identify the failure type: 5.1.1 (address not found), 5.7.1 (policy rejection), 4.2.2 (mailbox full). Parsing DSN codes correctly allows senders to distinguish hard bounces from soft bounces and route addresses to suppression accordingly. When MAIL FROM is empty, the DSN is sent to the HELO/EHLO hostname.

Inbox Placement Rate

The percentage of delivered messages that land in the inbox as opposed to the spam/junk folder or other folders. Distinct from delivery rate — a message can be accepted by the receiving MTA (delivered) while landing in spam (bulked). Measured by seed-list testing tools (GlockApps, Validity Everest) that place test addresses across mailbox providers and report folder destination. Strong IP reputation, domain reputation, and engagement signals drive inbox placement.

Bulking / Foldering

When a receiving mailbox provider accepts a message at the SMTP layer but routes it to the spam or junk folder rather than the inbox. The message was technically “delivered” but missed the inbox. Bulking is typically driven by weak IP reputation, poor domain reputation, high complaint rates, low engagement history, or content / link reputation issues. Bulk placement is not surfaced in bounce or DSN data — it requires inbox placement rate monitoring to detect.

Double Opt-In

A subscription confirmation process where a new subscriber must click a verification link in a welcome email before being added to the active list. Verifies the address is valid and that the actual inbox owner submitted it. Double opt-in reduces hard bounces, spam trap hits, and complaint rates by eliminating typos, harvested addresses, and people who did not knowingly subscribe. Industry best practice for list hygiene, especially for consumer-facing programs.

List Hygiene

The practice of maintaining a clean, current subscriber list by removing invalid addresses, disengaged subscribers, and high-risk addresses. Core hygiene activities: suppressing hard bounces, removing complaint filers, purging long-inactive subscribers, and validating new addresses at point of collection. Poor list hygiene is the root cause of most deliverability problems — elevated bounce rates, spam trap hits, and rising complaint rates are all symptoms of an unmaintained list.

Suppression List

A list of addresses that must not receive future mailings, regardless of their presence in the active subscriber database. Includes: hard bounces, complaint filers, unsubscribers, and manually flagged addresses. Suppression of unsubscribe requests is a legal requirement under CAN-SPAM, CASL, and GDPR. Maintaining an accurate suppression list prevents re-mailing addresses that will generate complaints or bounces and is a core list hygiene practice.

Re-engagement

A campaign or process targeting subscribers who have not opened or clicked in a defined period (typically 90–180+ days). Aims to either win back engagement or confirm the subscriber wants to continue receiving mail. Extended inactivity negatively affects domain reputation at engagement-weighted providers like Gmail. Subscribers who do not re-engage should be removed from the active list to protect inbox placement rate. Sending re-engagement campaigns to a fully disengaged segment without suppressing non-responders compounds the problem.

SRS — Sender Rewriting Scheme

A technique for rewriting the Envelope Sender (MAIL FROM) when forwarding email, so SPFcan still pass at the final destination. Without SRS, the forwarding server delivers using its own IP — not listed in the original sender's SPF record — causing SPF to fail. SRS rewrites MAIL FROM to be scoped to the forwarding domain, which does authorize the forwarding server's IP. ARC is the preferred modern alternative for handling forwarded mail at scale, preserving authentication results cryptographically rather than rewriting the envelope.