Glossary

The most complete glossary for email deliverability on the internet. Covers beginner to advanced terminology used by ESPs, mailbox providers, spam filters, security vendors, and deliverability engineers—including Bot Finder and bot detection. 75+ full entries (with detailed explanation, why it matters, technical details, example, related terms, category, edge cases, SEO notes) plus 45+ additional concise terms for 120+ concepts. See also Bot Finder and bot detection setup.

A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z

| A | B | C | D | E | F | G | H | | I | J | K | L | M | N | O | P | | Q | R | S | T | U | V | W | X | | Y | Z |

A

Alignment

Short Definition: DMARC and BIMI require that the domain in the From header matches (aligns with) the domain used in SPF/DKIM.

Detailed Explanation: In DMARC, alignment can be “strict” (exact match) or “relaxed” (organizational domain match). For example, mail.example.com aligns relaxed with example.com but not strict. DKIM alignment checks the d= tag in the signature against the From domain.

Why It Matters: Misalignment causes DMARC to fail even when SPF and DKIM pass, leading to rejections or quarantine. Proper alignment is required for BIMI and strong policy enforcement.

Technical Details: RFC 7489 (DMARC), RFC 8601 (BIMI). Headers: From, Return-Path; DKIM d= tag.

Example: Sending from newsletter@mail.brand.com with DKIM d=brand.com gives relaxed alignment for brand.com; with d=mail.brand.com you get strict alignment for the subdomain.

Related Terms: DMARC, SPF, DKIM, BIMI, Policy enforcement, Subdomain delegation

Category: Authentication

Edge Cases: Forwarding can break alignment when the forwarder rewrites Return-Path or adds headers. Mailing lists and some gateways may break strict alignment.

SEO Notes: DMARC alignment: strict vs relaxed domain match for SPF/DKIM. Required for BIMI and inbox placement.

ARC (Authenticated Received Chain)

Short Definition: A protocol that preserves authentication results across forwarding and middleboxes so downstream receivers can trust earlier SPF/DKIM/DMARC results.

Detailed Explanation: When an email is forwarded or processed by an intermediary, original authentication may fail (e.g., new Return-Path). ARC adds a chain of seals (AR-Seal) and message signatures (AR-Message) so the last hop can verify the chain and decide to trust the original auth.

Why It Matters: Forwarding, mailing lists, and corporate gateways often break SPF/DKIM. ARC lets mailbox providers and filters retain trust in the original sender and reduce false failures.

Technical Details: RFC 8617. Headers: ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal. Chain is validated in order; one broken link can invalidate the chain.

Example: User forwards from Gmail to Yahoo; Yahoo sees failed SPF (Gmail’s IP) but valid ARC chain from Gmail attesting to original auth—Yahoo may accept based on ARC.

Related Terms: DMARC, DKIM, Forwarding, Policy enforcement

Category: Authentication

Edge Cases: Long chains (many hops) increase validation cost; some providers cap chain length. Malicious actors could attempt to forge ARC seals if validation is weak.

SEO Notes: ARC preserves email authentication across forwards and middleboxes. RFC 8617. Improves deliverability for forwarded mail.

Apple Mail Privacy Protection (MPP)

Short Definition: Apple’s feature that preloads images and links in emails in the background, generating opens and sometimes clicks before the user views the message.

Detailed Explanation: When MPP is enabled (default for many Apple Mail users), Apple’s proxy servers fetch remote content (images, links) when the email is received. This triggers open pixels and can trigger link prefetches, which appear as opens/clicks in analytics but are not human engagement.

Why It Matters: MPP inflates open rates and can create “false” clicks. Deliverability and engagement metrics that don’t filter these events are misleading. Bot Finder and bot detection help separate MPP traffic from real engagement.

Technical Details: Requests come from Apple IP ranges; user-agent and timing patterns differ from real Mail.app opens. Image proxying and link prefetching; some links may be rewritten or scanned.

Example: A marketer sees 60% open rate; after filtering MPP/bot traffic via BotDetect, true human opens might be 25%.

Related Terms: Open tracking, Prefetching, Bot Finder, Image proxying, Link wrapping

Category: Analytics · Bot Detection

Edge Cases: MPP behavior can change with iOS/macOS updates. Combined with corporate proxies or security scanners, traffic can be hard to attribute. Time-to-click and IP clustering help distinguish.

SEO Notes: Apple MPP preloads images and links, inflating opens and clicks. Filter bot traffic for accurate email engagement metrics.

Authentication

Short Definition: The set of mechanisms (SPF, DKIM, DMARC, BIMI, ARC) that prove an email is from the claimed sender and has not been altered.

Detailed Explanation: Authentication uses DNS records and cryptographic signatures so receiving systems can verify the sending domain and message integrity. It is the foundation of modern deliverability; most major providers require at least SPF and DKIM, and many recommend DMARC.

Why It Matters: Unauthenticated or poorly configured auth leads to spam folding, spoofing abuse, and lower inbox placement. Strong authentication improves reputation and is required for BIMI and many B2B receivers.

Technical Details: DNS (TXT records for SPF, DKIM selector records), SMTP (EHLO, MAIL FROM), message headers (From, Reply-To, DKIM-Signature, etc.).

Example: A brand publishes SPF, DKIM, and DMARC; Gmail and Microsoft validate all three and place mail in inbox; a phisher spoofing the same domain fails DMARC and is rejected or quarantined.

Related Terms: SPF, DKIM, DMARC, BIMI, Alignment, DNS propagation

Category: Authentication

Edge Cases: Third-party senders (ESP, CRM) require correct SPF includes and DKIM delegation. Forwarding and mailing lists can break auth without ARC.

SEO Notes: Email authentication: SPF, DKIM, DMARC. Prove sender identity and improve deliverability and trust.

Automated link scanner

Short Definition: Software that automatically follows links in emails to check for malware, phishing, or policy violations before delivering to the user.

Detailed Explanation: Corporate gateways (Proofpoint, Mimecast, Barracuda, Microsoft Safe Links, etc.) and some consumer providers rewrite links or fetch them in a sandbox. The request appears as a “click” in the sender’s analytics but is not a human action.

Why It Matters: Link scanners inflate click rates and can trigger tracking pixels. Senders who don’t filter these events overestimate engagement and may misattribute conversions. Bot detection separates scanner traffic from real clicks.

Technical Details: Often use headless browsers or HTTP clients; IPs belong to vendor ranges; user-agent and timing (e.g., click within seconds of delivery) are typical signals.

Example: Proofpoint fetches every link in an email 2 minutes after delivery; the sender sees a “click” from a Proofpoint IP; BotDetect flags it as bot/scanner.

Category: Bot Detection · Security

Edge Cases: Some scanners run only on certain link types or domains. Rate of scanning can vary by vendor and policy. False positives can occur when real users share the same corporate network as the scanner.

SEO Notes: Automated link scanners (Proofpoint, Mimecast, Safe Links) trigger non-human clicks. Filter for accurate email analytics.

B

Barracuda filtering

Short Definition: Barracuda Networks’ email security gateways filter spam, malware, and phishing and may rewrite links or prefetch them, generating non-human click events.

Detailed Explanation: Barracuda appliances sit at the edge of corporate networks and scan incoming mail. They may follow links for security checks and rewrite URLs, which triggers tracking pixels and click redirects. Those requests appear as opens/clicks in sender analytics.

Why It Matters: Like other gateways, Barracuda can inflate engagement metrics. Bot detection helps identify and filter Barracuda-originated traffic for accurate reporting.

Technical Details: Requests from Barracuda IP ranges; link rewriting and prefetch behavior vary by product and policy. Often used in B2B environments.

Example: Corporate user receives email; Barracuda prefetches all links; sender sees several “clicks” from same IP within seconds; BotDetect classifies as bot.

Category: Security · Bot Detection

Edge Cases: Configuration varies by organization. Some deployments only scan attachments or specific link types.

SEO Notes: Barracuda email gateways filter and scan mail; can generate bot opens/clicks. Filter for accurate metrics.

Bayesian filtering

Short Definition: A statistical spam filter that classifies messages by learning from tokens (words, phrases) and their probability of appearing in spam vs. ham.

Detailed Explanation: The filter builds a model from labeled training data: token frequencies in spam and in legitimate mail. For each incoming message it computes a combined probability and compares to a threshold. It adapts as users mark messages spam/not spam.

Why It Matters: Bayesian filters are highly effective at catching content-based spam and adapt to new campaigns. Senders must avoid spammy language and maintain consistent, legitimate content to avoid triggering the model.

Technical Details: Typically applied to subject and body text; some implementations use headers or metadata. Requires sufficient training data; can be fooled by tokenization tricks (e.g., obfuscation).

Example: A campaign with “FREE,” “Act now,” and “Click here” in subject and body scores high spam probability; rewriting to neutral, specific copy lowers the score.

Related Terms: Content filtering, Heuristic filtering, SpamAssassin, Anti-Spam

Category: Anti-Spam

Edge Cases: Legitimate marketing language can overlap with spam tokens; false positives occur. Multilingual and HTML-heavy content may be tokenized differently across implementations.

SEO Notes: Bayesian spam filter uses word probability to classify spam. Avoid spammy tokens for better deliverability.

BIMI (Brand Indicators for Message Identification)

Short Definition: A DNS-based standard that allows verified senders to display a logo in supporting mailbox providers’ inboxes, contingent on DMARC policy and VMC.

Detailed Explanation: BIMI uses a TXT record at default._bimi.<domain> pointing to the logo URL and optionally a Verified Mark Certificate (VMC). Receivers that support BIMI (e.g., Gmail, Yahoo) display the logo when DMARC passes and policy is enforced.

Why It Matters: Brand visibility in the inbox increases recognition and trust; it also requires strong authentication (DMARC at reject or quarantine) and often a VMC, which drives adoption of best practices.

Technical Details: RFC 8601. DNS: default._bimi.<domain>. Requires DMARC policy of at least quarantine; many providers require VMC from approved certification authorities.

Example: A brand with DMARC p=reject and a valid VMC publishes BIMI; Gmail shows the brand logo next to the message in the inbox.

Related Terms: DMARC, Alignment, VMC, Authentication

Category: Authentication

Edge Cases: Not all providers support BIMI; VMC is expensive and not all brands qualify. Logo format and size are specified by the standard.

SEO Notes: BIMI shows brand logo in inbox for DMARC-verified senders. Requires DMARC and often VMC.

Blocklist

Short Definition: A list of IP addresses or domains considered untrustworthy; mail from listed entities may be rejected, throttled, or deprioritized by receivers.

Detailed Explanation: Blocklists are maintained by third parties (e.g., Spamhaus, SORBS) or privately by mailbox providers. Listings can be automatic (e.g., spam traps, honeypots) or manual (abuse reports). Delisting usually requires remediation and a request process.

Why It Matters: Being on a blocklist severely harms deliverability; some providers use multiple lists. Monitoring list status and avoiding behaviors that cause listing (e.g., spam traps, low engagement) is critical.

Technical Details: DNSBL (DNS-based blocklist) lookups; RBL (Real-time Blackhole List). Receivers query list zones with sender IP or domain; positive result triggers policy.

Example: An IP is listed on Spamhaus for sending to a spam trap; Gmail rejects or bulks mail from that IP until the sender is delisted.

Related Terms: Reputation, IP reputation, Spam trap, Greylisting, Delist

Category: Anti-Spam · Reputation

Edge Cases: False positives occur (e.g., shared IP, compromised server). Some lists are more aggressive than others; B2B and corporate gateways may use different lists.

SEO Notes: Email blocklists list bad IPs/domains. Get delisted to restore deliverability. Monitor Spamhaus, SORBS.

Bounce processing

Short Definition: The handling of non-delivery reports (hard bounces, soft bounces) by the sender or ESP to update lists, suppress bad addresses, and comply with receiver expectations.

Detailed Explanation: When a message bounces, the receiving MTA may send a DSN (Delivery Status Notification). Senders parse bounce type (hard = permanent, soft = temporary), update suppression lists, and may retry soft bounces with backoff. Continuous sending to hard bounces harms reputation.

Why It Matters: High bounce rates signal poor list hygiene and can trigger blocks or throttling. Proper bounce processing reduces waste and protects reputation.

Technical Details: RFC 3461–3464 (DSN). SMTP response codes (5xx = permanent, 4xx = temporary); Content-Type multipart/report; enhancement codes (e.g., 5.1.1 user unknown).

Example: An ESP receives a 5.1.1 DSN; it marks the address as hard bounce and suppresses it from future sends; the next campaign excludes that address.

Related Terms: Hard bounce, Soft bounce, Suppression list, MTA, Feedback loop

Category: Infrastructure · Deliverability

Edge Cases: Some bounces are misclassified (e.g., greylisting 4xx vs. real 5xx). Gray mail and full mailboxes may generate different DSNs. Feedback loops complement bounces for abuse reporting.

SEO Notes: Process hard and soft bounces; suppress bad addresses to protect sender reputation and deliverability.

Bot Finder

Short Definition: A click on an email link that is generated by automated software (e.g., security scanner, Apple MPP, crawler) rather than a human subscriber.

Detailed Explanation: Bot clicks come from link prefetchers, malware/phishing scanners, privacy proxies, and other automated systems. They are indistinguishable from human clicks in raw analytics without additional signals (IP, user-agent, timing, behavioral patterns).

Why It Matters: Unfiltered bot clicks inflate click-through rates and can distort A/B tests, conversion attribution, and engagement-based filtering. Bot Finder helps identify and filter bot clicks for accurate metrics.

Technical Details: Signals include IP (vendor ranges), user-agent, time-to-click (very fast after delivery), lack of subsequent conversion, and clustering. Machine learning or rule-based scoring classifies events as bot vs. human.

Example: 40% of “clicks” in a campaign come from Proofpoint and Apple MPP; after bot filtering, true human CTR is 2.1%.

Category: Bot Detection · Analytics

Edge Cases: Some corporate users click immediately after a scanner prefetches; deduplication and time-to-click help. Mobile and VPN can complicate IP-based rules.

SEO Notes: Bot clicks are non-human link clicks (scanners, MPP). Filter for true email engagement and CTR.

Bot filtering

Short Definition: The process of excluding or flagging automated (bot) open and click events from engagement metrics and reports so that analytics reflect real subscriber behavior.

Detailed Explanation: Bot filtering uses signals such as IP, user-agent, timing, and behavioral patterns to score each event and classify it as bot, suspicious, or human. Filtered data is then used for reporting, segmentation, and deliverability decisions.

Why It Matters: Without bot filtering, open and click rates are inflated and engagement-based reputation (e.g., Gmail) can be skewed. Accurate metrics improve send decisions and troubleshooting.

Technical Details: Implemented in analytics pipelines (e.g., InboxEagle BotDetect/Lens); outputs include verdict (BOT/SUSPICIOUS/HUMAN) and confidence. Can be applied in real time or in batch.

Example: InboxEagle ingests SES events, runs BotDetect, and surfaces “human” opens and clicks in the dashboard; bot and suspicious events are excluded from rate calculations.

Category: Bot Detection · Analytics

Edge Cases: Aggressive filtering may remove some real engagement; conservative filtering leaves noise. Tuning by campaign or segment can improve accuracy.

SEO Notes: Bot filtering removes automated opens/clicks from email metrics. Improves accuracy of engagement and deliverability decisions.

Bot detection

Short Definition: The process of identifying whether an email open or click event was generated by a human or by automated software (e.g., scanners, privacy proxies, crawlers).

Detailed Explanation: Bot detection uses signals such as IP address, user-agent, time-to-click, request patterns, and sometimes behavioral or device fingerprinting. Results are used to filter analytics, segment “human” engagement, and improve deliverability decisions. InboxEagle’s Bot Finder provides bot detection for Amazon SES data.

Why It Matters: Without bot detection, open and click rates are inflated and engagement-based reputation can be skewed. Accurate human metrics improve list segmentation and sending strategy.

Technical Details: Rule-based or ML classification; output is typically verdict (BOT/SUSPICIOUS/HUMAN) and confidence. Applied in pipeline before reporting.

Example: InboxEagle ingests SES events, runs BotDetect, and attaches a verdict to each event; dashboard and exports show human-only or bot-filtered metrics.

Category: Bot Detection

Edge Cases: New scanner or proxy types may not be in the model initially. Cross-device and VPN usage can complicate IP-based rules.

SEO Notes: Bot detection identifies non-human email opens and clicks. Use for accurate engagement and deliverability. InboxEagle Bot Finder.

Bounce rate

Short Definition: The percentage of sent emails that result in a bounce (hard or soft) as reported by the receiving system.

Detailed Explanation: Bounce rate is computed as bounces / sent (or similar). High bounce rate indicates bad list hygiene, invalid addresses, or receiver-side issues. ESPs and mailbox providers use it as a reputation signal.

Why It Matters: Sustained high bounce rates can trigger throttling, blocks, or listing. Keeping bounce rate low (e.g., under 2%) is a best practice for deliverability.

Technical Details: Measured via DSN (bounce messages) or SMTP responses. Hard bounces should be suppressed immediately; soft bounces may be retried with backoff.

Example: A campaign to 100k recipients generates 1.5k hard bounces; bounce rate 1.5%; those addresses are suppressed for future sends.

Related Terms: Bounce processing, Hard bounce, Soft bounce, Suppression list

Category: Deliverability · Infrastructure

Edge Cases: Greylisting and temporary failures can inflate soft bounces. Some receivers don’t send DSNs, so measured bounce rate may be understated.

SEO Notes: Email bounce rate: % of messages that bounce. Keep low and suppress hard bounces for good deliverability.

C

Complaint rate

Short Definition: The percentage of delivered emails that recipients report as spam (e.g., via “Report spam” in the mailbox provider UI).

Detailed Explanation: Complaint rate = complaints / delivered (or similar). Mailbox providers track it per sender and use it as a strong reputation signal. High complaint rate leads to throttling, spam folding, or blocking.

Why It Matters: Keeping complaint rate low (e.g., under 0.1%) is critical for deliverability. Processing feedback loops and suppressing complainers helps protect reputation.

Technical Details: Measured via FBL (ARF) reports and provider-side aggregation. Gmail Postmaster Tools and others surface complaint or spam rate in sender dashboards.

Example: Sender has 0.05% complaint rate; reputation stays high. After a bad campaign, rate spikes to 0.3%; next campaigns are throttled until rate recovers.

Related Terms: Feedback loop, Reputation, Suppression list, Domain reputation

Category: Reputation · Deliverability

Edge Cases: Complaints are voluntary; not all users report. Some providers use “not interested” or “unsubscribe” as softer signals. B2B vs. consumer complaint behavior differs.

SEO Notes: Email complaint rate: % of mail marked as spam. Keep low; use FBLs and suppress lists.

Content filtering

Short Definition: Spam and security filtering based on the content of the email (subject, body, attachments) rather than solely on reputation or authentication.

Detailed Explanation: Content filters scan text and attachments for patterns associated with spam, phishing, or malware. They may use keyword lists, Bayesian models, heuristics, and ML. Content filtering runs alongside reputation and authentication checks.

Why It Matters: Even with strong auth and reputation, spammy or phishing-like content can trigger filtering. Clean, relevant, and non-deceptive content supports inbox placement.

Technical Details: Applied to MIME parts (text/plain, text/html); attachment scanning (type, extension, sandbox). Headers (Subject, From display name) are often included.

Example: A marketing email with “Winner!!! Claim your prize” and a shortened link in the body is flagged by content filter and sent to spam.

Category: Anti-Spam

Edge Cases: Legitimate marketing and transactional content can trigger false positives. Localization and encoding affect tokenization. Image-based spam bypasses text filters unless OCR or URL analysis is used.

SEO Notes: Content filtering scans email text and attachments for spam/phishing. Improve copy and links for better placement.

Click tracking

Short Definition: The practice of replacing links in emails with tracking URLs that redirect to the final destination and record a click event for analytics.

Detailed Explanation: Each link is rewritten to point to a tracking domain (e.g., click.example.com/xxx). When the user (or a bot) clicks, the redirect server logs the event and then sends the user to the real URL. This enables per-link and per-recipient click metrics.

Why It Matters: Click tracking powers CTR, engagement reporting, and conversion attribution. It is also a source of bot clicks when security scanners and prefetchers follow the same links.

Technical Details: HTTP 302/301 redirects; tracking domain must be configured (DNS, SSL). Query params or path encode campaign/recipient/link IDs. Link wrapping is the implementation pattern.

Example: Original link https://store.com/sale becomes https://track.esp.com/c/abc123; click is logged, then user is redirected to store.com/sale.

Related Terms: Link wrapping, Open tracking, Bot Finder, Pixel tracking

Category: Analytics

Edge Cases: Some clients block redirects or strip tracking params. Corporate proxies may prefetch all links, inflating clicks. Privacy regulations may limit tracking scope.

SEO Notes: Click tracking uses redirect URLs to log email link clicks. Combine with bot filtering for accurate CTR.

Corporate email gateway

Short Definition: An intermediary system (e.g., Proofpoint, Mimecast, Barracuda) that filters, scans, and often rewrites email before delivering it to the end user’s mailbox.

Detailed Explanation: Corporate gateways sit between the internet and the organization’s mail server. They perform spam filtering, antivirus scanning, link rewriting (Safe Links), attachment sandboxing, and DLP. They may also fetch links and images, generating bot-like opens and clicks.

Why It Matters: Gateway behavior affects both deliverability (e.g., strict filtering) and analytics (scanner-generated opens/clicks). Senders must account for gateways when interpreting metrics and troubleshooting delivery.

Technical Details: Typically deployed as an MTA or proxy; may change headers, rewrite URLs, and add ARC or other headers. Receiving IP and reputation are often the gateway’s, not the original sender’s.

Example: An email passes Gmail but is blocked by a corporate Proofpoint policy; the sender sees “delivered” at Gmail level but the end user never receives it. Proofpoint also prefetches links, creating bot clicks.

Category: Infrastructure · Bot Detection

Edge Cases: Policies vary by organization; same content may pass one gateway and fail another. B2B senders see a mix of direct and gateway-mediated delivery.

SEO Notes: Corporate email gateways (Proofpoint, Mimecast) filter and scan mail; they also generate bot opens/clicks. Account for them in analytics.

Deliverability

Short Definition: The measure of whether emails reach the intended folder (inbox, promotions) versus spam, bounce, or block, and the practice of improving that outcome.

Detailed Explanation: Deliverability encompasses authentication, reputation, content, list hygiene, and infrastructure. It is monitored per domain, IP, and provider. InboxEagle provides deliverability dashboards by brand and sending domain, including placement and Google Postmaster data.

Why It Matters: Poor deliverability means messages never reach users or land in spam, reducing revenue and trust. Improving deliverability is the core goal of email marketing operations and postmaster teams.

Technical Details: No single metric; combines inbox placement, bounce rate, complaint rate, authentication status, and reputation. Measured via seed testing, provider APIs (e.g., Postmaster), and bounce/FBL processing.

Example: A sender improves SPF/DKIM/DMARC, cleans the list, and reduces complaints; inbox placement improves from 60% to 88% across Gmail, Yahoo, and Microsoft.

Category: Deliverability

Edge Cases: Deliverability varies by provider, segment, and time. B2B gateways add another layer. Engagement (opens/clicks) affects Gmail placement.

SEO Notes: Email deliverability: getting mail to the inbox. Auth, reputation, content, and list hygiene. InboxEagle monitors it.

D

DKIM (DomainKeys Identified Mail)

Short Definition: An email authentication method that uses a digital signature in the message header to verify that the message was sent by an authorized server and has not been modified.

Detailed Explanation: The sending MTA signs the message (or selected headers/body) with a private key; the signature is added in the DKIM-Signature header. The receiving system fetches the public key from DNS (selector._domainkey.) and verifies the signature. Alignment links the signing domain to the From domain for DMARC.

Why It Matters: DKIM provides integrity and domain authentication. It is required by most major receivers and is a component of DMARC. Broken or missing DKIM often leads to spam folding or rejection.

Technical Details: RFC 6376. Header: DKIM-Signature (v=1; a=; d=; s=; h=; b=). DNS: <selector>._domainkey.<domain> TXT with public key. Signing algorithm (e.g., rsa-sha256).

Example: Mail from newsletter@brand.com is signed with selector s1, domain brand.com; receiver fetches s1._domainkey.brand.com, verifies signature, and passes DKIM for brand.com.

Related Terms: SPF, DMARC, Alignment, Key rotation, DKIM replay attack

Category: Authentication

Edge Cases: Forwarding and mailing lists can break DKIM if they modify the message. Multiple signatures (e.g., ESP + sender) are allowed; DMARC evaluates alignment. Key rotation must be coordinated with DNS.

SEO Notes: DKIM signs email with a domain key for authentication and integrity. Essential for DMARC and deliverability.

DKIM replay attack

Short Definition: An attack where a valid DKIM-signed message is replayed (resent) to other recipients or at a later time to abuse the original signature.

Detailed Explanation: Because DKIM does not bind the signature to the recipient or a nonce, a captured signed message could be replayed. Receivers may mitigate by checking other signals (e.g., SMTP recipient, timestamp, ARC chain) or by treating replay as suspicious.

Why It Matters: Replay can be used for phishing or to leverage a legitimate domain’s reputation. Senders and receivers should be aware of the limitation; DMARC and other mechanisms add some protection.

Technical Details: DKIM only attests to domain and integrity at sign time. No standard mechanism in DKIM for replay prevention; ARC and DMARC policy can help when the replay path differs.

Example: Attacker intercepts a signed marketing email and resends it to a different list; DKIM still verifies; DMARC or recipient-based checks may flag or reject.

Related Terms: DKIM, DMARC, Phishing detection, Spoofing

Category: Security · Authentication

Edge Cases: Mailing list forwards and “resend” features can look like replay. Some providers use heuristics (e.g., same message to many new recipients) to detect abuse.

SEO Notes: DKIM replay: resending a signed message to abuse the signature. Receivers use DMARC and other checks to mitigate.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Short Definition: A DNS-based policy and reporting framework that tells receivers what to do when SPF/DKIM fail or don’t align, and how to send back aggregate and forensic reports.

Detailed Explanation: Domain owners publish a DMARC TXT record at _dmarc. with policy (none, quarantine, reject), alignment requirements, and report URIs. Receivers evaluate SPF and DKIM against the From domain; if policy fails, they apply the requested action and may send XML reports to the domain owner.

Why It Matters: DMARC reduces spoofing and phishing using your domain and improves trust. Policy enforcement (quarantine/reject) is required for BIMI and is a strong reputation signal.

Technical Details: RFC 7489. DNS: _dmarc.<domain> TXT. Tags: p= (policy), rua= (aggregate reports), ruf= (forensic), adkim/saspf= (alignment), pct= (percentage). Reports are XML (aggregate) or email (forensic).

Example: Domain sets p=reject, adkim=s; receiver sees SPF pass but DKIM fail (no alignment); message is rejected. Owner receives daily aggregate report showing pass/fail counts.

Related Terms: SPF, DKIM, Alignment, Policy enforcement, BIMI

Category: Authentication

Edge Cases: Third-party senders need to be in SPF and sign with aligned domain. Forwarding can break alignment; ARC helps. Gradual rollout (pct=) is common.

SEO Notes: DMARC: DNS policy for failed SPF/DKIM. Use quarantine or reject to stop spoofing and improve deliverability.

DNS propagation

Short Definition: The time it takes for new or updated DNS records to propagate globally so that resolvers worldwide return the new values.

Detailed Explanation: When you add or change a DNS record (e.g., SPF, DKIM, DMARC), authoritative servers update immediately, but recursive resolvers and caches may still serve old data until TTL expires. Propagation can take minutes to 48+ hours depending on TTL and topology.

Why It Matters: After changing authentication records, mail may fail until propagation completes. Testing too soon can give false negatives; planning rollouts and using low TTL before changes can reduce risk.

Technical Details: TTL (Time To Live) in seconds on DNS records controls cache duration. Global propagation depends on each resolver’s cache. Tools (e.g., DNS checker) query from multiple locations.

Example: You add a new DKIM selector; some receivers see it within minutes, others still see NXDOMAIN for an hour; after 24 hours all see the new record.

Related Terms: SPF, DKIM, DMARC, Subdomain delegation

Category: Infrastructure · Authentication

Edge Cases: Some networks use very long caches or stale data. DNSSEC can add validation delay. Geographic and provider differences cause uneven propagation.

SEO Notes: DNS propagation: delay before new SPF/DKIM/DMARC records are seen globally. Plan auth changes around TTL.

Domain age signals

Short Definition: The use of domain registration age or history as a factor in spam and reputation scoring by filters and mailbox providers.

Detailed Explanation: Newly registered domains (e.g., days or weeks old) may be treated with more suspicion than domains that have been active for years. Age can be combined with other signals (volume, authentication, content) to reduce risk from throwaway or phishing domains.

Why It Matters: Senders using new domains should expect a ramp-up period and may need stronger authentication and engagement to build trust. Established domains have an advantage.

Technical Details: WHOIS or RDAP for registration date; some providers use internal history. No standard; used heuristically.

Example: A phishing campaign uses a domain registered 3 days ago; filter downweights or blocks. A legitimate brand uses a 10-year-old domain; filter treats it as established.

Related Terms: Domain reputation, Warmup, Phishing detection

Category: Reputation · Security

Edge Cases: Domains can change ownership; age alone is not sufficient. Subdomains may inherit or not inherit parent age signals.

SEO Notes: Domain age can affect email reputation. New domains may need warmup and strong auth.

Domain impersonation

Short Definition: The practice of sending email that appears to be from a trusted brand or entity (e.g., similar-looking domain or display name) to deceive recipients.

Detailed Explanation: Impersonation can use lookalike domains (e.g., paypa1.com), homographs, or spoofed display names. Receivers use authentication (DMARC, SPF, DKIM), domain reputation, and content analysis to detect and block impersonation.

Why It Matters: Impersonation harms brands and users. Strong DMARC policy (reject) and BIMI help protect your domain and make it harder for impersonators to abuse your brand.

Technical Details: DMARC fails for unauthorized use of your domain. Display-name spoofing is not fully solved by DMARC (From header can show fake name). BIMI plus VMC shows verified logo.

Example: Attacker sends from support@paypa1-security.com with display name “PayPal Security”; user may be fooled; DMARC does not apply to the attacker’s domain; content and URL filters may catch it.

Related Terms: Spoofing, Phishing detection, DMARC, BIMI

Category: Security

Edge Cases: Internationalized domain names (IDN) can look identical to ASCII. Display name spoofing remains a problem. Brand monitoring and takedown complement technical controls.

SEO Notes: Domain impersonation: fake sender to deceive users. DMARC and BIMI protect your domain.

Domain reputation

Short Definition: The reputation score or tier assigned to a sending domain by mailbox providers and filters, based on historical engagement, complaints, bounces, and authentication.

Detailed Explanation: Receivers track domains (often the visible From domain or the organizational domain) and assign reputation from signals such as spam complaints, bounces, engagement (opens/clicks), list hygiene, and authentication. High reputation improves inbox placement; low reputation leads to spam or blocks.

Why It Matters: Domain reputation often matters as much as or more than IP reputation for large providers like Gmail. Protecting and improving domain reputation is central to deliverability.

Technical Details: Proprietary algorithms per provider (e.g., Gmail Postmaster Tools shows domain reputation). Signals include authentication, volume, complaint rate, bounce rate, and engagement. Google Postmaster Tools and InboxEagle help monitor it.

Example: A new subdomain used for marketing has no history; Gmail may treat it cautiously until engagement and low complaint rates build reputation.

Category: Reputation

Edge Cases: Subdomains can have different reputation than parent. Brand new domains start neutral or negative. Reputation can be segment-specific (e.g., B2B vs. consumer).

SEO Notes: Domain reputation: mailbox providers score your sending domain. Improve with auth, engagement, and low complaints.

E

Feedback loop (FBL)

Short Definition: A mechanism by which mailbox providers notify senders when users mark their mail as spam, so senders can suppress complainers and improve practices.

Detailed Explanation: FBLs are typically automated: when a user clicks “spam,” the provider sends a message (often ARF format) to the sender’s registered FBL address. The sender parses it and adds the recipient to a suppression list or reduces sending to that segment.

Why It Matters: High complaint rates severely harm reputation. Processing FBLs and suppressing complainers is a best practice and often required by ESPs and receivers.

Technical Details: ARF (Abuse Reporting Format), RFC 5965. FBL registration is per domain (e.g., via provider’s postmaster page). Message contains original headers and recipient; sender must identify the user and suppress.

Example: Gmail sends an FBL to abuse@sender.com when a user marks a message as spam; the sender adds that recipient to a “do not mail” list and excludes them from future campaigns.

Related Terms: Complaint rate, Suppression list, Reputation, Bounce processing

Category: Infrastructure · Reputation

Edge Cases: Not all providers offer FBLs; some require whitelisting. Multiple complaints from same user may generate multiple FBL messages. Parsing and matching to internal IDs can be complex.

SEO Notes: Feedback loops let providers notify senders of spam complaints. Process FBLs and suppress complainers for better reputation.

Forwarding

Short Definition: Delivering an email to a different address than the original recipient (e.g., user forwards from Gmail to Yahoo, or uses an alias).

Detailed Explanation: When mail is forwarded, the next hop may see a different envelope sender (Return-Path) or modified headers. SPF can fail (forwarder’s IP), and DKIM may still pass. ARC was designed to preserve authentication across forwards.

Why It Matters: Forwarding can break SPF and sometimes DKIM, causing authentication failures. Receivers that support ARC can retain trust in the original sender.

Technical Details: SMTP forwarding changes MAIL FROM; SRS (Sender Rewriting Scheme) preserves original sender in Return-Path. DKIM is unchanged unless the forwarder modifies the body or signed headers.

Example: User forwards from Gmail to Yahoo; Yahoo sees SPF fail (Gmail’s IP) but ARC chain from Gmail; Yahoo accepts based on ARC.

Related Terms: ARC, SPF, DKIM, Alignment

Category: Infrastructure · Authentication

Edge Cases: Multiple hops compound the problem. Mailing lists often break both SPF and DKIM. Some forwarders strip or modify content.

SEO Notes: Email forwarding can break SPF. ARC preserves authentication across forwards.

F

False click

Short Definition: A click event recorded in email analytics that is not a genuine human click (e.g., from a scanner, prefetcher, or bot).

Detailed Explanation: False clicks are generated by Apple MPP, corporate link scanners, security sandboxes, crawlers, and other automated systems that follow tracking links. They inflate CTR and can mislead optimization and conversion attribution.

Why It Matters: Treating false clicks as real engagement overstates performance and can trigger incorrect segmentation or send decisions. Filtering via Bot Finder or similar improves accuracy.

Technical Details: Detected by IP (vendor ranges), user-agent, time-to-click (e.g., within seconds of delivery), and behavioral clustering. Machine learning or rule-based classifiers assign bot/suspicious/human verdicts.

Example: A campaign shows 8% CTR; 6% of clicks are from known scanner IPs and MPP; filtered human CTR is 2%.

Related Terms: Bot Finder, Sandbox click, Prefetching, Human click verification

Category: Bot Detection · Analytics

Edge Cases: Some real users are behind the same IP as a scanner (e.g., corporate). Time-to-click and conversion follow-through help separate human from bot.

SEO Notes: False clicks are non-human link clicks in email. Filter them for accurate CTR and conversion metrics.

G

Gmail Postmaster Tools

Short Definition: Google’s free service that provides senders with domain and IP reputation, spam rate, authentication results, and delivery errors for mail sent to Gmail.

Detailed Explanation: Senders verify domain ownership and add DNS records; Google then surfaces dashboards for reputation (High/Medium/Low/Bad), user-reported spam rate, domain and IP authentication, encryption (TLS), and delivery errors. Data is aggregated and delayed (e.g., daily).

Why It Matters: Gmail is a major receiver; Postmaster data helps diagnose placement issues and track the impact of authentication and sending practices. InboxEagle can connect to Postmaster to surface this data in your deliverability dashboard.

Technical Details: Verification via DNS (TXT or CNAME) or HTML file. API and UI show time-series and breakdowns. Reputation is per domain; IP reputation is also shown where applicable.

Example: A sender sees “Low” domain reputation and elevated spam rate; they improve list hygiene and authentication; over weeks reputation moves to “High” and inbox placement improves.

Related Terms: Domain reputation, IP reputation, Spam rate, Authentication

Category: Reputation · Deliverability

Edge Cases: Data is aggregated and not real-time. Some senders use multiple domains; each must be verified. International and consumer vs. workspace data may differ.

SEO Notes: Gmail Postmaster Tools: free Google service for domain/IP reputation and spam rate. Use for Gmail deliverability.

Greylisting

Short Definition: A technique where a receiver temporarily rejects mail (4xx) with a “try again later” response, expecting legitimate MTAs to retry and thus filtering out many spam bots that don’t retry.

Detailed Explanation: The receiver stores the triplet (sender IP, envelope from, recipient) and rejects the first attempt. On retry (typically minutes later), the receiver accepts. Many spam sources do not retry; legitimate MTAs do, so greylisting reduces spam with minimal false positives.

Why It Matters: Senders must implement retry logic with appropriate backoff; otherwise greylisting causes delayed or failed delivery. ESPs and MTAs generally retry, so greylisting mainly affects first-time delivery delay.

Technical Details: SMTP 4xx (e.g., 451) on first attempt; 2xx on retry. Retry window varies (minutes to hours). Some receivers use greylisting only for unknown senders.

Example: A new IP sends to a greylisting server; first attempt gets 451; MTA retries after 5 minutes; second attempt is accepted.

Related Terms: Retry logic, MTA, Soft bounce, Queueing

Category: Anti-Spam · Infrastructure

Edge Cases: Greylisting can delay time-sensitive mail. Some implementations whitelist after first successful delivery. Not all receivers use greylisting.

SEO Notes: Greylisting: temporary reject to filter bots. Senders need retry logic for reliable delivery.

Hard bounce

Short Definition: A permanent delivery failure (e.g., recipient address does not exist, domain does not exist) that should result in the address being removed from the list.

Detailed Explanation: Hard bounces are indicated by SMTP 5xx responses or DSN with permanent failure codes (e.g., 5.1.1 user unknown). The address is invalid and should be suppressed immediately to protect reputation and avoid wasting sends.

Why It Matters: Repeatedly sending to hard bounces signals poor list hygiene and can trigger blocks or reputation damage. Bounce processing must identify and suppress hard bounces.

Technical Details: RFC 3463 enhancement codes: 5.1.1 (bad destination mailbox), 5.1.2 (mailbox disabled), 5.2.1 (mailbox full can be soft in some systems). DSN with Action=failed.

Example: Send to old@deleted-domain.com; receive 5.1.1 DSN; add to suppression list; never send again.

Related Terms: Soft bounce, Bounce processing, Suppression list, Bounce rate

Category: Infrastructure · Deliverability

Edge Cases: Some receivers use 4xx for temporary failures that look like hard bounces. Greylisting sends 4xx; retry later. Misconfigured DSN can misclassify.

SEO Notes: Hard bounce: permanent delivery failure. Suppress address to protect reputation.

H

Heuristic filtering

Short Definition: Spam filtering based on rules and weighted signals (e.g., keywords, header patterns, structure) rather than pure statistical or ML models.

Detailed Explanation: Heuristic filters use a set of rules that assign positive or negative scores to features (e.g., “FREE” in subject, suspicious URL pattern, missing Reply-To). The total score is compared to a threshold. Rules are often hand-tuned and updated in response to new spam trends.

Why It Matters: Heuristic filters are transparent and fast; senders can often infer why a message was flagged (e.g., certain words, link patterns) and adjust content accordingly.

Technical Details: Implemented in filters like SpamAssassin (rules in config); each rule has a score. Combined score above threshold = spam. Rules can target headers, body, MIME structure.

Example: Rule “SUBJECT_FREE” +2, “HTML_LINK_CLICK_HERE” +1.5; message with both scores 3.5, threshold 5; adding more triggers pushes it over.

Category: Anti-Spam

Edge Cases: Legitimate marketing can trigger heuristic rules. Rule sets vary by vendor; one provider’s pass can be another’s fail. Evasion (obfuscation) can reduce heuristic scores but may trigger other filters.

SEO Notes: Heuristic spam filter uses rule-based scoring. Avoid spammy patterns to pass. SpamAssassin uses heuristics.

Human click verification

Short Definition: The process or technology used to confirm that a click (or open) was initiated by a human rather than a bot, scanner, or proxy.

Detailed Explanation: Human verification uses signals such as time-to-click, IP reputation, user-agent, behavioral patterns, and sometimes conversion follow-through. BotDetect scores each event and labels it BOT, SUSPICIOUS, or HUMAN.

Why It Matters: Verified human engagement is the right basis for CTR, conversion attribution, and engagement-based filtering. Unverified metrics lead to wrong decisions.

Technical Details: Implemented in analytics or deliverability pipelines. Combines time-to-click analysis, user-agent fingerprinting, IP allow/block lists, and optional ML.

Example: Event has 2-minute time-to-click, known consumer IP, browser user-agent; classified HUMAN. Event has 3-second time-to-click, Proofpoint IP; classified BOT.

Category: Bot Detection · Analytics

Edge Cases: Power users may click very fast; some humans share IP with scanners. Verification is probabilistic, not absolute.

SEO Notes: Human click verification separates real clicks from bots. Use for accurate CTR and conversion. InboxEagle Bot Finder.

I

Image proxying

Short Definition: The practice of a mailbox provider or privacy service fetching images in emails through their own servers and serving them to the user, often to hide the user’s IP and load images in a controlled way.

Detailed Explanation: When an email contains an image (e.g., tracking pixel), the client or provider may request the image via a proxy URL. The request comes from the provider’s IP, not the user’s, and may occur when the message is received (e.g., Apple MPP) or when the user opens. This affects open tracking and privacy.

Why It Matters: Image proxying triggers “opens” that are not necessarily user-initiated and can come from bots or prefetchers. Open rates are inflated; bot filtering helps separate real opens from proxy/prefetch traffic.

Technical Details: HTTP request to image URL from proxy IP; user-agent may identify the proxy (e.g., Apple). Tracking pixels are 1x1 images; load = “open” in sender analytics.

Example: Apple MPP loads all images when the message is received; the sender’s pixel fires and logs an “open” before the user has seen the email.

Category: Analytics · Bot Detection

Edge Cases: Some proxies strip or modify images; some clients block images by default. Multiple proxies (e.g., corporate + Apple) can cause multiple “opens” per recipient.

SEO Notes: Image proxying: providers load email images via proxy. Inflates open tracking; use bot detection for real opens.

Inbox placement

Short Definition: The folder or tab where an email lands (inbox, promotions, social, spam, or block) at a given mailbox provider.

Detailed Explanation: Inbox placement is the outcome of filtering and reputation: the same message may go to inbox for one provider and spam for another. Placement is often measured by seed testing or provider-reported metrics (e.g., Gmail Postmaster). InboxEagle helps monitor placement by brand and domain.

Why It Matters: Placement directly affects visibility and engagement. Improving placement (via authentication, reputation, content) is the goal of deliverability work.

Technical Details: No single protocol; measured via panel/seed tests or provider APIs. Gmail has Primary, Promotions, Social; others use inbox vs. junk vs. block.

Example: After fixing DMARC and reducing complaint rate, a sender’s Gmail placement shifts from 70% Promotions / 20% Spam to 85% Primary / 15% Promotions.

Related Terms: Deliverability, Domain reputation, Spam folder, Seed testing

Category: Deliverability

Edge Cases: Placement can vary by user (engagement, filters). B2B and consumer receivers behave differently. B2B gateways may block before inbox.

SEO Notes: Inbox placement: where your email lands (inbox vs. spam). Improve with auth, reputation, and content.

IP reputation

Short Definition: The reputation score or tier assigned to a sending IP address by mailbox providers and blocklists, based on sending history, complaints, bounces, and list quality.

Detailed Explanation: Receivers track sending IPs and assign reputation from signals such as volume, complaint rate, bounce rate, authentication, and blocklist status. Shared IPs pool reputation with other senders; dedicated IPs isolate your reputation but require warmup.

Why It Matters: Poor IP reputation leads to throttling, spam folding, or blocking. Building and protecting IP reputation is essential, especially on dedicated IPs.

Technical Details: Proprietary per provider. Gmail Postmaster Tools and Microsoft SNDS show IP reputation where available. Blocklists (e.g., Spamhaus) also affect IP reputation.

Example: A new dedicated IP starts with neutral reputation; after a gradual warmup and low complaints, reputation rises and inbox placement improves.

Related Terms: Domain reputation, Warmup, Blocklist, Dedicated IP

Category: Reputation

Edge Cases: Shared IPs can be hurt by one bad sender. NAT and pools may share reputation across many internal IPs. IPv6 reputation may be separate from IPv4.

SEO Notes: IP reputation: mailbox providers score your sending IP. Warm up dedicated IPs and avoid blocklists.

Lens (inboxeagle/lens)

Short Definition: The multi-tenant headless worker service (Lens) that consumes SES events from AWS SQS per tenant, runs bot-detection analysis, and delivers results via webhook, SNS, or S3—powering Bot Finder in InboxEagle.

Detailed Explanation: Lens is the backend pipeline for Bot Finder. SES sends events to SNS → SQS (per tenant); an ingest worker normalizes and stores them in MongoDB; an analysis worker runs a 5-layer scoring model (deterministic, behavioral, confidence, historical, cross-tenant) and classifies each event as bot (≥60), suspicious (30–59), or human (<30); a delivery worker sends results via the tenant’s configured webhook, SNS, or S3. Sync workers maintain IP ranges (AWS/GCP/Azure/Apple Relay), AbuseIPDB blocklist, DNSBL results, spam-trap risk, stats rollups, and intelligence rollups that feed back into scoring.

Why It Matters: Bot Finder in the InboxEagle app depends on Lens for all bot detection. Operators and engineers should use the Lens README (in the trueengage/lens repository, README.md) for the full architecture, scoring rules table, worker modules, and deployment.

Technical Details: Package @inboxeagle/lens. Pipeline: Ingest → Analysis → Delivery; plus Resource Sync, IP Sync, AbuseIPDB Sync, DNSBL Sync, Spam Trap Monitor, Stats Rollup, Hourly Stats, Intelligence Rollup, Maintenance. Analysis v8: three-tier classification (fixed thresholds 60/30), bot types (honeypot, privacy_proxy, security_scanner, automated_behavior, spam_trap), 7 rule categories (privacy_proxy, security_scanner, timing, ip_intelligence, user_agent, trap_detection, cross_tenant). MongoDB for state; per-tenant circuit breaker and DLQ for delivery.

Example: Tenant connects Bot Finder via InboxEagle; SES events flow to tenant SQS; Lens ingest consumes them, analysis scores each event, delivery POSTs to tenant webhook; Bot Finder dashboard shows bot/suspicious/human counts and recent events.

Category: Bot Detection · Infrastructure

Edge Cases: Run IP sync and AbuseIPDB sync before analysis for full rule coverage. Per-tenant disabledRuleCategories can turn off categories. Timing suppression avoids double-counting when privacy_proxy or security_scanner rules fire.

SEO Notes: Lens is the backend bot-detection pipeline for InboxEagle Bot Finder. See Lens README and BotDetect reference for full details.

Key rotation

Short Definition: The practice of periodically changing DKIM signing keys (and updating DNS) to limit the impact of key compromise and align with security best practices.

Detailed Explanation: DKIM private keys are stored on the MTA or signing service; if compromised, an attacker could sign mail as the domain. Rotating to a new key pair and publishing the new public key in DNS (often with a new selector) limits the window of abuse. Old selector can be kept for a transition period.

Why It Matters: Rotation reduces risk from key theft and satisfies compliance requirements. It must be coordinated with DNS propagation so that receivers can verify signatures during and after the change.

Technical Details: Generate new key pair; publish new selector._domainkey. TXT; start signing with new key; optionally keep old selector for overlap; remove old selector when traffic has shifted.

Example: Domain uses selector s1; add s2 with new key; deploy signer to use s2; after 48 hours remove s1 from DNS.

Related Terms: DKIM, DNS propagation, Authentication

Category: Authentication · Security

Edge Cases: Too-short overlap can cause verification failures for in-flight mail. Some receivers cache keys; TTL affects how quickly they see the new key.

SEO Notes: DKIM key rotation: change signing keys periodically. Update DNS and signer in sync.

L

Link wrapping

Short Definition: The technique of replacing original URLs in an email with tracking redirect URLs that log the click and then send the user to the final destination.

Detailed Explanation: Each link is rewritten to point to a tracking server (e.g., click.esp.com/xxx). When the link is requested (by human or bot), the server records the event and issues an HTTP redirect to the real URL. This enables click analytics and per-link reporting.

Why It Matters: Link wrapping is the basis of click tracking. It is also the point where bot clicks (scanners, prefetchers) are generated; filtering those requests is necessary for accurate CTR.

Technical Details: Typically 302 redirect; tracking domain must resolve and support HTTPS. Original URL encoded in path or query. Link wrapping is synonymous with click-tracking URL rewriting.

Example: Link https://example.com/product is wrapped as https://track.sender.com/c/abc?u=...; click is logged, then 302 to example.com/product.

Category: Analytics · Infrastructure

Edge Cases: Some clients or proxies don’t follow redirects. Corporate link scanners fetch wrapped links and generate bot clicks. Privacy tools may strip or alter redirects.

SEO Notes: Link wrapping: replace links with tracking redirects for click measurement. Filter bot clicks for accurate CTR.

List hygiene

Short Definition: The practice of keeping the email list clean by removing bounces, complainers, inactive addresses, and invalid or risky entries to protect reputation and deliverability.

Detailed Explanation: List hygiene includes processing bounces (hard and soft), FBL complaints, and unsubscribes; removing role addresses and traps where appropriate; and periodically re-engaging or pruning inactive subscribers. Clean lists have lower bounce and complaint rates.

Why It Matters: Poor list hygiene is a leading cause of blocks and reputation damage. Spam traps and high bounce rate often result from neglected lists.

Technical Details: Suppression lists (do not mail); bounce and FBL parsing; engagement scoring; sunset policies. Implemented in ESP or CRM.

Example: Monthly: suppress hard bounces and FBL complainers; remove addresses with no open in 12 months or run re-engagement campaign; validate new signups with double opt-in.

Related Terms: Suppression list, Bounce processing, Spam trap, Double opt-in

Category: Deliverability · Email Marketing

Edge Cases: Over-aggressive pruning can shrink list; balance with re-engagement. Different segments may need different rules.

SEO Notes: List hygiene: remove bounces and complainers, prune inactives. Essential for deliverability.

M

MTA (Mail Transfer Agent)

Short Definition: Software or service that sends and receives email by speaking SMTP; it queues messages, retries, and hands off to the next hop or final delivery agent.

Detailed Explanation: An MTA accepts mail from users or other MTAs, applies policy (relay, filter), and delivers to the next MTA or to a mailbox (MDA). Examples include Postfix, SendGrid, Amazon SES. MTAs implement queueing, retry logic, and bounce handling.

Why It Matters: MTA configuration (e.g., retries, TLS, rate limits) affects deliverability. Understanding MTA behavior helps troubleshoot bounces and delays.

Technical Details: SMTP (RFC 5321); queue directories or cloud queues; DSN for bounces. MTA-STS and TLS ensure encryption in transit.

Example: A marketer sends via an ESP; the ESP’s MTA queues the message, resolves MX of recipient domain, connects with TLS, and delivers; on 4xx it retries per backoff schedule.

Related Terms: SMTP, Queueing, Retry logic, Bounce processing, MTA-STS

Category: Infrastructure

Edge Cases: Greylisting requires MTA retry. Rate limiting may trigger 4xx; backoff must be appropriate. Multiple MTAs in a path (e.g., gateway) complicate debugging.

SEO Notes: MTA: Mail Transfer Agent sends/receives email via SMTP. Handles queue, retry, and bounces.

MTA-STS (Mail Transfer Agent Strict Transport Security)

Short Definition: A standard that allows domain owners to declare that MTAs must use TLS when delivering mail to their servers, and to specify MX hostnames that support TLS.

Detailed Explanation: Domain owners publish a policy (via HTTPS at mta-sts./.well-known/mta-sts.txt) and a DNS TXT record pointing to it. Sending MTAs fetch the policy and only connect to the domain’s MX over TLS, aborting if TLS fails or if the MX is not in the policy.

Why It Matters: MTA-STS prevents downgrade attacks and ensures encryption in transit. Some receivers use it as a positive signal; adoption is growing.

Technical Details: RFC 8461. HTTPS: mta-sts./.well-known/mta-sts.txt. DNS: _mta-sts. TXT “v=STSv1; id=…”. Policy lists MX hosts and mode (enforce/testing).

Example: Sender connects to receiver’s MX; sender has MTA-STS policy for receiver; connection must use TLS and match policy MX; otherwise sender does not deliver.

Related Terms: TLS, SMTP, MX record, Infrastructure

Category: Infrastructure · Security

Edge Cases: Policy fetch failure can block mail if mode is enforce. Certificate validity and hostname matching are required. Testing mode allows monitoring without enforcing.

SEO Notes: MTA-STS: require TLS for email delivery. Publish policy to prevent downgrade attacks.

Mimecast link rewriting

Short Definition: Mimecast’s security feature that rewrites URLs in incoming email to route clicks through Mimecast’s infrastructure for threat checking before redirecting the user.

Detailed Explanation: Like Microsoft Safe Links and Proofpoint, Mimecast rewrites links so that when the user clicks, the request goes to Mimecast first. Mimecast may check the destination for malware or phishing and then redirect. The initial request is logged by the sender as a “click” but is not a direct human click to the final URL.

Why It Matters: Mimecast-generated requests inflate click metrics. Bot detection can identify and filter them so that CTR and conversion reports reflect real engagement.

Technical Details: Links rewritten at delivery; click goes to Mimecast domain; redirect after check. Requests from Mimecast IP ranges; identifiable by URL pattern and timing.

Example: Corporate user receives email; Mimecast rewrites track.sender.com to mimecast proxy URL; user clicks; Mimecast fetches (sender sees click), checks destination, redirects user.

Category: Security · Bot Detection

Edge Cases: Policy may vary by organization. Some links may not be rewritten (e.g., whitelisted domains).

SEO Notes: Mimecast rewrites email links for security. Produces non-human clicks; filter for accurate metrics.

Microsoft Safe Links

Short Definition: A Microsoft 365 feature that rewrites URLs in emails to point through Microsoft’s proxy; when the user clicks, Microsoft checks the target URL for threats before redirecting.

Detailed Explanation: Safe Links replaces links in incoming mail with URLs that point to Microsoft’s service. On click, Microsoft evaluates the destination (e.g., malware, phishing) and may block or allow. The click request comes from Microsoft’s infrastructure, so it appears as a “click” in the sender’s analytics but is not necessarily a human click.

Why It Matters: Safe Links generates bot-like clicks and can inflate CTR. It also protects users from malicious links. Senders should filter Safe Links traffic when measuring engagement.

Technical Details: Link rewriting at delivery time; click goes to Microsoft; redirect to final URL after check. Requests from Microsoft IP ranges; identifiable by URL pattern or user-agent in some flows.

Example: User receives email with track.sender.com link; Safe Links rewrites to safeurl.microsoft.com/…; user clicks; Microsoft fetches (sender sees click), checks destination, redirects user.

Category: Security · Bot Detection

Edge Cases: Different Microsoft products (O365, Defender) may apply Safe Links differently. Time-to-click and IP can help distinguish from human clicks.

SEO Notes: Microsoft Safe Links rewrites links for security. Produces non-human clicks; filter for accurate email CTR.

O

Open tracking

Short Definition: The practice of embedding a tracking pixel (typically a 1x1 image) in emails so that when the image is loaded, the sender records an “open” event for that recipient.

Detailed Explanation: The tracking server hosts a unique image URL per recipient/campaign. When the client (or a proxy) loads the image, the HTTP request is logged as an open. Opens are not reliable as a proxy for “read” because many clients block images, and privacy features (e.g., Apple MPP) preload images.

Why It Matters: Open rate is a common metric but is inflated by bots and prefetchers. Bot filtering separates real opens from automated loads for accurate engagement metrics.

Technical Details: <img src="https://track.domain.com/o/xxx" />; server logs request; may set cookie. Image often 1x1 transparent GIF. Load can come from user or proxy (e.g., Apple).

Example: Recipient opens email; client requests pixel; sender logs open. With MPP, Apple requests pixel when message is received, before user opens—counted as open but not human.

Category: Analytics

Edge Cases: Image blocking prevents opens. Multiple loads (e.g., re-open, forward) can overcount. Prefetch and proxy create bot opens.

SEO Notes: Open tracking uses a pixel to log email opens. Filter bot and prefetch traffic for accurate open rates.

Pixel tracking

Short Definition: The use of a small, typically invisible image (tracking pixel) loaded when the recipient views an email, to record an “open” event.

Detailed Explanation: A 1x1 pixel image is embedded with a unique URL per recipient or campaign. When the email client or a proxy (e.g., Apple MPP) loads the image, the HTTP request is logged as an open. Image proxying and prefetch mean that not every load is a human open.

Why It Matters: Pixel tracking is the basis of open rate. Because of Apple Mail Privacy Protection and other proxies, open rate is inflated without bot filtering.

Technical Details: <img src="https://track.domain.com/pixel/xxx" width="1" height="1" />. Server logs GET request. Often transparent GIF. Load can come from user’s client or from a proxy.

Example: Marketer embeds pixel; 50% of “opens” are from Apple proxy IPs within 2 minutes of delivery; after filtering, true open rate is 22%.

Category: Analytics

Edge Cases: Image blocking prevents pixel load. Multiple loads (re-open, forward) can overcount. Proxies create bot opens.

SEO Notes: Pixel tracking: 1x1 image logs email opens. Filter proxy and bot loads for real open rate.

P

Phishing detection

Short Definition: Systems and rules that identify emails designed to trick recipients into revealing credentials or taking harmful actions, often by impersonating trusted entities.

Detailed Explanation: Phishing detection uses content analysis (urgent language, credential harvesters), link reputation (known phishing URLs), authentication (failed DMARC, spoofed From), and behavioral signals. Mailbox providers and gateways run multiple layers to protect users.

Why It Matters: Phishing harms users and brands. Senders with weak authentication (e.g., no DMARC reject) are more likely to be spoofed; strong DMARC and BIMI help protect your domain and improve trust.

Technical Details: URL reputation feeds, sandboxing, ML models on content and headers. DMARC and SPF/DKIM alignment block unauthorized use of your domain. BIMI and VMC add brand verification.

Example: A phisher sends mail claiming to be from a bank; DMARC fails (no valid DKIM/SPF for that domain); message is quarantined or rejected. Link to fake login is detected by URL reputation and blocked.

Related Terms: Spoofing, DMARC, Domain impersonation, URL reputation

Category: Security · Anti-Spam

Edge Cases: Legitimate marketing (e.g., “Confirm your account”) can trigger heuristic phishing filters. New phishing domains and techniques require constant updates to detection.

SEO Notes: Phishing detection identifies fake emails and malicious links. Strong DMARC and authentication reduce spoofing.

Policy enforcement

Short Definition: The act of applying a domain’s DMARC policy (none, quarantine, reject) when authentication fails or does not align, so that receivers reject or quarantine non-compliant mail.

Detailed Explanation: When a receiver evaluates DMARC and the result is “fail” (e.g., no aligned SPF/DKIM), it applies the policy from the DMARC record: p=none (monitor only), p=quarantine (e.g., send to spam), or p=reject (reject at SMTP). Enforcement reduces spoofing and phishing using the domain.

Why It Matters: Without enforcement (p=none), phishers can still use your domain. Moving to p=quarantine or p=reject protects your brand and is required for BIMI. Gradual rollout (pct=) is recommended.

Technical Details: RFC 7489. Receiver fetches _dmarc., evaluates alignment, applies p= policy. pct= limits the fraction of failing messages that get the policy; rest get p=none behavior until full enforcement.

Example: Domain sets p=reject, pct=100; any message failing DMARC alignment is rejected at SMTP; spoofed messages never reach the inbox.

Related Terms: DMARC, Alignment, BIMI, Quarantine

Category: Authentication

Edge Cases: Third-party senders must be in SPF and sign with aligned domain or they will fail. Forwarding can break alignment; ARC helps. Testing with pct=10 allows monitoring before full enforcement.

SEO Notes: DMARC policy enforcement: reject or quarantine mail that fails authentication. Stops spoofing and enables BIMI.

Prefetching

Short Definition: The loading of links or images in an email before the user explicitly opens or clicks, often by a privacy service or security scanner, which triggers tracking events.

Detailed Explanation: Apple MPP, some security scanners, and other systems fetch links and images when the message is received or when the user opens the message, before the user has clicked. These requests are logged as “clicks” or “opens” by the sender but are not user-initiated.

Why It Matters: Prefetching inflates open and click metrics. Bot Finder and time-to-click analysis help identify and filter prefetch traffic so that engagement metrics reflect real behavior.

Technical Details: HTTP GET to tracking or destination URL from proxy/scanner IP; often within seconds of delivery. User-agent and IP identify the prefetcher. No subsequent conversion (e.g., purchase) typically associated.

Example: Apple MPP prefetches all links 2 minutes after delivery; sender sees 50 “clicks” from Apple IPs; none are from users clicking; BotDetect flags them as bot.

Category: Bot Detection · Analytics

Edge Cases: Some prefetchers only hit certain link types. Delayed prefetch (hours later) can look like real clicks; conversion and session data help distinguish.

SEO Notes: Prefetching: automatic loading of email links/images. Inflates clicks and opens; filter for accurate metrics.

Proofpoint click scanning

Short Definition: Proofpoint’s security feature that follows links in emails (often at delivery time) to check for malware or phishing, generating non-human click and sometimes open events in sender analytics.

Detailed Explanation: Proofpoint email gateways may prefetch or rewrite links. When they follow a link to scan the destination, the request hits the sender’s tracking server and is logged as a click. These events cluster by IP (Proofpoint) and time (shortly after delivery).

Why It Matters: Proofpoint is widely deployed in enterprises. Senders see inflated CTR and open rates from Proofpoint traffic. Bot Finder and similar tools filter these events for accurate engagement metrics.

Technical Details: Requests from Proofpoint IP ranges; often within minutes of delivery. Link rewriting may change URL to Proofpoint proxy. Identifiable for filtering.

Example: B2B campaign delivered to 10k; 2k are behind Proofpoint; Proofpoint prefetches all links; sender sees 2k “clicks” from a few Proofpoint IPs; BotDetect flags as bot.

Category: Security · Bot Detection

Edge Cases: Configuration varies; some organizations only scan certain link types. Time-to-click and IP clustering help distinguish from human clicks.

SEO Notes: Proofpoint scans email links; produces bot clicks. Filter for accurate email CTR. InboxEagle Bot Finder.

Q

Quarantine

Short Definition: Holding email in a separate folder (e.g., “Junk,” “Spam,” or “Quarantine”) instead of delivering to inbox or rejecting, often when DMARC or other checks fail.

Detailed Explanation: Receivers may quarantine when DMARC policy is p=quarantine or when content or reputation triggers a “suspicious” classification. Users can often review quarantined mail and release false positives. For senders, quarantine means the message did not reach the primary inbox.

Why It Matters: Quarantine is better than reject for debugging (users or admins may see the message) but still means poor placement. Moving to inbox requires fixing authentication or reputation.

Technical Details: DMARC p=quarantine; content/reputation filters. Implementation is provider-specific. Some gateways allow admins to whitelist senders.

Example: Domain has DMARC p=quarantine; spoofed message fails alignment; receiver puts it in spam folder instead of rejecting.

Related Terms: DMARC, Policy enforcement, Spam folder, Inbox placement

Category: Deliverability · Authentication

Edge Cases: User may never check quarantine. Some systems use “bulk” or “promotions” as a form of soft quarantine. Corporate quarantine policies vary.

SEO Notes: Email quarantine: mail held in spam/junk when auth fails or content is suspicious. Fix auth and reputation.

R

Reputation filtering

Short Definition: The use of sender reputation (domain, IP, or both) as a primary or major factor in deciding whether to accept, throttle, or reject email.

Detailed Explanation: Receivers maintain reputation scores for domains and IPs. Mail from high-reputation senders is more likely to be accepted and placed in the inbox; mail from low-reputation senders may be throttled, bulked, or blocked. Reputation is built from authentication, complaints, bounces, engagement, and volume over time.

Why It Matters: Reputation is one of the strongest signals for deliverability. Building and maintaining good reputation (via list hygiene, authentication, engagement) is essential for inbox placement.

Technical Details: Proprietary algorithms; Gmail Postmaster Tools and Microsoft SNDS expose some reputation data. Signals include complaint rate, bounce rate, authentication, and engagement (opens/clicks). InboxEagle helps monitor reputation and placement.

Example: A sender with consistently low complaint rate and strong authentication has high domain reputation; Gmail places most mail in Primary. A new IP with no history has neutral reputation and may be throttled until behavior is established.

Category: Reputation

Edge Cases: Reputation can be segment-specific (e.g., B2B vs. consumer). Sudden volume or content change can trigger reputation drop. Blocklists override reputation at some receivers.

SEO Notes: Reputation filtering uses sender reputation to accept or block email. Build reputation for better deliverability.

Retry logic

Short Definition: The MTA behavior of resending a message after a temporary failure (4xx) with increasing delay (backoff) until success or permanent failure.

Detailed Explanation: When the receiving MTA returns 4xx (e.g., 451 greylisting, 421 rate limit), the sending MTA does not give up immediately. It queues the message and retries after a delay (e.g., 5 min, 15 min, 1 hour). This is required to cope with greylisting and temporary overload.

Why It Matters: Without retry logic, greylisting and other temporary failures would cause unnecessary bounces. Proper backoff avoids hammering the receiver and respects rate limits.

Technical Details: Queue state machine; retry schedule (e.g., exponential backoff); max retries or TTL; DSN on final failure. RFC 5321 recommends retry.

Example: First attempt gets 451; MTA retries in 5 min; second attempt gets 250 OK; message delivered.

Related Terms: Greylisting, Queueing, MTA, Soft bounce

Category: Infrastructure

Edge Cases: Too-aggressive retry can trigger rate limiting. Too many retries can delay delivery. Permanent vs. temporary classification can be wrong.

SEO Notes: Retry logic: MTA retries after 4xx. Needed for greylisting and temporary failures.

Rate limiting

Short Definition: A receiver or MTA limiting the number of messages or connections accepted from a sender per time window (e.g., per minute per IP).

Detailed Explanation: Rate limits protect receivers from overload and abuse. When a sender exceeds the limit, the receiver may return 4xx (try again later) or drop the connection. Limits can be per IP, per domain, or per authenticated identity. New or low-reputation senders often face stricter limits.

Why It Matters: Exceeding rate limits causes deferred delivery or bounces. Warmup and gradual volume increase help stay within limits. Throttling is a form of rate limiting.

Technical Details: SMTP 421 or 450; connection limits; message-per-minute caps. Implementation is receiver-specific. Gmail Postmaster and delivery errors can indicate rate-limit issues.

Example: New IP sends 50k in 10 minutes; receiver allows 5k/hour from unknown IPs; excess gets 421; sender must slow down and retry.

Related Terms: Throttling, Warmup, Retry logic, MTA

Category: Infrastructure · Deliverability

Edge Cases: Limits may be burst vs. sustained. Authenticated or whitelisted senders may have higher limits. Limits can change with reputation.

SEO Notes: Email rate limiting: receiver caps send rate. Warm up and stay within limits for delivery.

Queueing

Short Definition: The MTA practice of storing messages in a queue when they cannot be delivered immediately, then attempting delivery later (with retries).

Detailed Explanation: When the next hop is unavailable, returns 4xx, or the sender is rate-limited, the MTA queues the message. A queue manager periodically retries delivery according to retry logic. Messages may be queued for seconds to days depending on policy and final failure handling.

Why It Matters: Queueing enables reliable delivery despite temporary failures (e.g., greylisting, receiver busy). Poor queue design can cause delays or lost mail.

Technical Details: On-disk or in-memory queue; retry schedule; max age or hop count; DSN on permanent failure. RFC 5321 describes deferred delivery.

Example: Message arrives at MTA; next hop returns 451; MTA queues message; 10 minutes later retry succeeds; message delivered.

Related Terms: Retry logic, MTA, Greylisting, Bounce processing

Category: Infrastructure

Edge Cases: Long queues can delay time-sensitive mail. Queue buildup can indicate reputation or configuration issues. Dead-letter queues hold permanently failed messages.

SEO Notes: Email queueing: MTA stores and retries mail. Essential for handling 4xx and greylisting.

S

SPF (Sender Policy Framework)

Short Definition: A DNS-based method that allows a domain to publish which IP addresses (or other hosts) are authorized to send mail for that domain.

Detailed Explanation: The domain publishes an SPF TXT record that lists mechanisms (e.g., ip4:, include:, a:, mx:). Receivers check the envelope sender (Return-Path) domain and compare the connecting IP to the SPF record. Pass means the IP is authorized; fail means it is not.

Why It Matters: SPF is one of the foundational authentication methods and is required by DMARC (along with DKIM). Missing or incorrect SPF leads to authentication failure and worse placement or rejection.

Technical Details: RFC 7208. DNS: TXT at the domain (or subdomain). Syntax: v=spf1 mechanisms. Common: include: for ESPs, ip4:/ip6: for dedicated IPs. Lookup limit (10 DNS lookups) must not be exceeded.

Example: Domain example.com has “v=spf1 include:_spf.google.com ~all”; mail sent via Google’s IPs passes SPF for example.com.

Related Terms: DKIM, DMARC, Alignment, Subdomain delegation

Category: Authentication

Edge Cases: Forwarding changes Return-Path and can break SPF unless the forwarder uses SRS or the receiver uses ARC. Multiple includes and macros can hit the 10-lookup limit.

SEO Notes: SPF: DNS record listing authorized sending IPs. Essential for email authentication and DMARC.

SMTP (Simple Mail Transfer Protocol)

Short Definition: The standard protocol used for sending and relaying email between servers (MTAs) and for client-to-server submission.

Detailed Explanation: SMTP runs over TCP (port 25 for server-to-server, 587 or 465 for submission). The sender connects, issues EHLO, MAIL FROM, RCPT TO, DATA, and the receiver responds with status codes (2xx success, 4xx temporary failure, 5xx permanent failure). TLS (STARTTLS) encrypts the connection. MTA-STS can require TLS for delivery.

Why It Matters: SMTP is the foundation of email delivery. Understanding it helps troubleshoot bounces, greylisting, and authentication. Proper use of TLS and authentication improves deliverability and security.

Technical Details: RFC 5321 (SMTP), RFC 3207 (STARTTLS). Commands: EHLO, MAIL FROM, RCPT TO, DATA, RSET, QUIT. Response codes 2xx, 4xx, 5xx. SPF checks MAIL FROM domain.

Example: Sender MTA connects to receiver MX on port 25; STARTTLS; MAIL FROM:bounce@brand.com; RCPT TO:user@gmail.com; DATA (message); 250 OK.

Related Terms: MTA, TLS, MTA-STS, SPF, Bounce processing

Category: Infrastructure

Edge Cases: Port 25 may be blocked by some ISPs; submission ports 587/465 are used for client send. Authentication (SMTP AUTH) is for submission, not relay. Rate limits apply per connection or IP.

SEO Notes: SMTP: protocol for sending email between servers. Use TLS and auth for secure delivery.

Sandbox click

Short Definition: A click event generated when a security product or sandbox loads a link in an isolated environment to check for malware or phishing, not by a human user.

Detailed Explanation: Corporate gateways and some cloud security services execute links in a sandbox (headless browser or HTTP client). The request is logged by the sender as a click but is not from a real user. Sandbox clicks often have characteristic IPs, user-agents, and timing.

Why It Matters: Sandbox clicks inflate CTR. Bot detection identifies sandbox traffic so that engagement and conversion metrics reflect real behavior.

Technical Details: Request from vendor IP; user-agent may indicate automation; often within seconds of delivery; no cookies or session consistent with human flow.

Example: Proofpoint sandbox loads all links 2 minutes after delivery; sender sees 50 clicks from one Proofpoint IP; all classified as bot.

Category: Bot Detection · Security

Edge Cases: Some sandboxes run only on certain link types. Delayed sandbox runs can look more like human clicks; conversion data helps.

SEO Notes: Sandbox click: security sandbox loads link; not a human click. Filter for accurate CTR.

Security scanner

Short Definition: Software that automatically fetches links or attachments in email to check for malware, phishing, or policy violations before or after delivery to the user.

Detailed Explanation: Corporate and cloud email security products (Proofpoint, Mimecast, Barracuda, Microsoft Defender, etc.) scan links and sometimes images. The HTTP requests they generate are recorded as opens and clicks by the sender but are not from the recipient. Bot Finder helps flag and filter this traffic.

Why It Matters: Scanner traffic can dominate click and open metrics in B2B sends. Filtering it is essential for accurate engagement and conversion attribution.

Technical Details: Requests from known vendor IP ranges; user-agent and timing patterns. Often all links in a message are requested in a short window. No downstream conversion typically.

Example: Campaign to 5k B2B recipients; 40% behind scanners; scanners prefetch links; 2k “clicks” from scanner IPs; human CTR after filtering is 1.8%.

Category: Security · Bot Detection

Edge Cases: New scanner vendors or regions may not be in filter lists. Some scanners run only on first open or on specific link patterns.

SEO Notes: Security scanners fetch email links; create bot opens/clicks. Filter for accurate email metrics. InboxEagle Bot Finder.

Soft bounce

Short Definition: A temporary delivery failure (e.g., mailbox full, server busy) that may succeed on a later retry, as opposed to a permanent hard bounce.

Detailed Explanation: Soft bounces are indicated by SMTP 4xx or DSN with temporary failure. The MTA should retry with retry logic. If retries are exhausted, the address may be suppressed or flagged for review. Some “soft” conditions (e.g., mailbox full for weeks) are treated as hard in practice.

Why It Matters: Distinguishing soft from hard bounces ensures valid addresses are not suppressed too soon while invalid ones are. High soft bounce rate can still harm reputation if it indicates list or receiver issues.

Technical Details: SMTP 4xx (e.g., 421, 450, 451); DSN Action=delayed. Enhancement codes 4.2.1 (mailbox full), 4.7.1 (greylisting). Retry with backoff.

Example: First attempt gets 451 (greylisting); MTA retries in 10 min; second attempt succeeds. Or: 452 mailbox full; retry for 3 days; then suppress.

Related Terms: Hard bounce, Bounce processing, Retry logic, Greylisting

Category: Infrastructure · Deliverability

Edge Cases: Some receivers use 4xx for policy (e.g., rate limit) that may not resolve quickly. Misconfigured DSN can misclassify.

SEO Notes: Soft bounce: temporary failure; retry. Don’t suppress too soon; use retry logic.

Spam rate

Short Definition: The percentage of delivered emails that recipients report as spam (user-reported spam rate), often surfaced in provider tools like Gmail Postmaster Tools.

Detailed Explanation: Spam rate = complaints (or spam reports) / delivered. It is a key reputation signal for mailbox providers. High spam rate leads to throttling, bulk folding, or blocking. Target is typically well below 0.1%.

Why It Matters: Spam rate is one of the strongest negative signals. Reducing it (better content, list hygiene, feedback loop processing) is essential for inbox placement.

Technical Details: Measured by providers from user “Report spam” actions. Gmail Postmaster shows spam rate in UI. FBL reports give per-message complaint data for processing.

Example: Sender has 0.02% spam rate; reputation stays high. After a poorly targeted campaign, rate rises to 0.2%; next sends are throttled until rate recovers.

Category: Reputation · Deliverability

Edge Cases: Spam rate can be segment-specific. Some providers use “not interested” or similar as a softer signal. B2B complaint behavior differs from consumer.

SEO Notes: Email spam rate: % reported as spam. Keep very low for good deliverability. Use FBLs.

SpamAssassin

Short Definition: An open-source, rule-based and heuristic spam filter that scores messages and is used by many MTAs and hosting providers.

Detailed Explanation: SpamAssassin uses a large set of rules (headers, body, URIs) that add or subtract points. The total score is compared to a threshold (e.g., 5.0 = spam). Rules can be customized. It can also use Bayesian filtering and other plugins.

Why It Matters: Many receivers use SpamAssassin or similar logic. Understanding that content and structure are scored helps senders avoid trigger patterns and test with tools like spamtester.

Technical Details: Perl-based; rules in config; score per rule; header X-Spam-Score added. Can integrate with DKIM/SPF. Bayesian and other modules optional.

Example: Message gets +2 for “FREE” in subject, +1.5 for “click here” in body, -1 for valid DKIM; total 2.5; below 5.0 so not spam. Add more spammy patterns and score crosses threshold.

Category: Anti-Spam

Edge Cases: Rule sets vary by deployment. Custom rules can reduce false positives. Evasion (obfuscation) may trigger other rules.

SEO Notes: SpamAssassin: open-source spam filter using rules and score. Avoid spammy content to pass.

Spam folder

Short Definition: The folder (e.g., Junk, Spam) where mailbox providers place messages that fail authentication, reputation, or content checks instead of the primary inbox.

Detailed Explanation: When a message is classified as spam or suspicious, it is typically delivered to the spam folder rather than rejected. Users can review and move messages; senders see this as poor inbox placement. Improving authentication and reputation moves mail to inbox.

Why It Matters: Placement in spam folder means low visibility and engagement. Monitoring inbox placement and fixing causes (auth, complaints, content) improves deliverability.

Technical Details: Provider-specific; no standard. Often tied to DMARC quarantine, blocklists, content score, and complaint rate. Gmail Postmaster and InboxEagle help track placement.

Example: Sender has weak DMARC; spoofed messages and some legitimate mail land in Gmail Spam; after strengthening DMARC and list hygiene, more mail lands in Primary.

Category: Deliverability

Edge Cases: User habits (e.g., “Not spam”) affect future placement. Promotions tab is different from spam but still secondary. B2B gateways may block before any folder.

SEO Notes: Spam folder: where filtered mail lands. Improve auth and reputation for inbox placement.

Spam trap

Short Definition: An email address that is not used by a real user but is maintained by a blocklist operator or mailbox provider to catch senders who mail to invalid or harvested addresses.

Detailed Explanation: Spam traps can be “pure” (never used, only found by scraping) or “recycled” (formerly valid, now abandoned). Sending to them signals poor list hygiene or list acquisition practices. Trap hits often result in listing or reputation damage.

Why It Matters: Trap hits are a strong negative signal. Avoiding traps requires strict list hygiene, double opt-in, and never buying or scraping lists. Monitoring blocklists and reputation helps detect trap issues.

Technical Details: Traps are secret; senders discover them indirectly (listing, reputation drop). Recycled traps appear in old lists; pure traps appear when addresses are harvested. No way to “remove” a trap from your list except to stop mailing and clean data.

Example: A sender buys a list; it contains a recycled spam trap; after sending, the sender is listed on Spamhaus and sees a sharp reputation drop.

Related Terms: Blocklist, List hygiene, Reputation, Double opt-in

Category: Anti-Spam · Reputation

Edge Cases: Some traps are domain-level (e.g., role addresses that never opted in). Re-engagement campaigns can hit recycled traps. Delisting requires remediation and time.

SEO Notes: Spam traps catch bad list practices. Use double opt-in and never buy lists to avoid traps.

T

TLS (Transport Layer Security)

Short Definition: The cryptographic protocol used to encrypt SMTP connections between MTAs (and between client and server) so that email in transit cannot be read or modified by third parties.

Detailed Explanation: When an MTA connects to another MTA, they can negotiate TLS (STARTTLS). Once encrypted, the message content and SMTP commands are protected. TLS is recommended for all hops; MTA-STS allows domain owners to require TLS for delivery to their MX.

Why It Matters: Encryption protects privacy and integrity. Some receivers treat TLS as a positive signal. Lack of TLS (or failed verification) can result in rejection when MTA-STS is in enforce mode.

Technical Details: SMTP STARTTLS (RFC 3207). TLS 1.2 or 1.3. Certificate must match MX hostname. MTA-STS (RFC 8461) enforces TLS for receiving domains.

Example: Sender’s MTA connects to receiver’s MX; EHLO, STARTTLS, TLS handshake; subsequent SMTP traffic is encrypted.

Related Terms: MTA-STS, SMTP, Encryption

Category: Infrastructure · Security

Edge Cases: Older MTAs may not support TLS or may use weak ciphers. Certificate errors (expired, wrong hostname) can cause fallback to plaintext or failure. MTA-STS testing mode allows monitoring without enforcing.

SEO Notes: TLS encrypts email in transit. Use STARTTLS and MTA-STS for secure delivery.

Time-to-click analysis

Short Definition: The practice of measuring the time between email delivery (or open) and a click event to help distinguish human clicks from automated ones (e.g., scanners that click within seconds).

Detailed Explanation: Humans typically click minutes or hours after receiving or opening; security scanners and prefetchers often request links within seconds. By analyzing the distribution of time-to-click, senders can set thresholds (e.g., clicks within 5 seconds = likely bot) and filter or downweight those events.

Why It Matters: Time-to-click is a strong signal for bot detection. It improves accuracy of CTR and conversion metrics when combined with IP and user-agent filtering.

Technical Details: Timestamp of delivery/open vs. timestamp of click request. Thresholds are configurable (e.g., 10 seconds, 1 minute). May be combined with other signals in a scoring model.

Example: 80% of “clicks” from known scanner IPs occur within 10 seconds of delivery; human clicks have a median of 15 minutes; filter applies bot label to sub-10-second clicks from those IPs.

Related Terms: Bot Finder, Prefetching, Human click verification, Bot filtering

Category: Bot Detection · Analytics

Edge Cases: Some real users click immediately (e.g., “Confirm subscription”). Segment-specific thresholds (e.g., transactional vs. marketing) can improve accuracy.

SEO Notes: Time-to-click: time between delivery and click. Short time-to-click often indicates bot; use for bot detection.

Throttling

Short Definition: The receiver limiting the rate or volume of mail accepted from a sender (e.g., by delaying or rejecting excess messages) based on reputation or policy.

Detailed Explanation: When a receiver throttles, it may return 4xx (try again later) or queue and slow acceptance. Throttling protects the receiver from overload and is often applied to senders with neutral or low reputation. Warmup and good reputation reduce throttling.

Why It Matters: Throttling causes delayed delivery or temporary bounces. Senders need to respect rate limiting and build reputation to avoid sustained throttling.

Technical Details: Per-IP or per-domain limits; may be dynamic based on reputation. SMTP 4xx or deferred acceptance. Gmail Postmaster and delivery errors can indicate throttling.

Example: New IP sends 100k in first hour; receiver throttles after 10k; remaining mail is delayed or gets 421; sender reduces rate and warms up; throttling eases.

Related Terms: Rate limiting, Warmup, IP reputation, Queueing

Category: Infrastructure · Deliverability

Edge Cases: Throttling can be burst-based or sustained. Some receivers throttle by recipient domain or time of day. Retry logic must back off.

SEO Notes: Email throttling: receiver limits send rate. Warm up and build reputation to avoid it.

U

URL reputation

Short Definition: A score or classification assigned to URLs (links) by security and filtering systems based on whether they have been associated with malware, phishing, or abuse.

Detailed Explanation: When an email contains links, receivers or gateways may check each URL against reputation databases (e.g., Google Safe Browsing, Microsoft SmartScreen). Links to known-bad or suspicious URLs can cause the message to be filtered or the link to be blocked or rewritten.

Why It Matters: Sending email with bad or newly registered URLs can trigger content filtering or phishing detection. Use reputable domains and avoid shorteners or redirect chains that hide destination.

Technical Details: Real-time or cached lookup by URL or domain; blocklists and ML models. Microsoft Safe Links and similar rewrite links and check on click.

Example: Phishing email contains link to fake-login.tk; URL reputation is bad; message is quarantined or link is blocked.

Category: Security · Anti-Spam

Edge Cases: New URLs have no history; false positives occur. Legitimate marketing links may share domains with bad actors. Reputation can change quickly.

SEO Notes: URL reputation: links scored for malware/phishing. Use clean domains to avoid filtering.

User-agent fingerprinting

Short Definition: Using the HTTP User-Agent header (and related request characteristics) of an open or click event to infer whether the request came from a real browser or from automation (e.g., scanner, proxy).

Detailed Explanation: When a tracking pixel or link is requested, the User-Agent identifies the client. Real users typically have browser UAs (Chrome, Safari, etc.); security scanners and prefetchers often use distinct UAs (e.g., “Proofpoint”, “AppleMail”, generic HTTP client). Fingerprinting helps bot detection classify events.

Why It Matters: User-agent is a fast, low-cost signal for filtering bot traffic. Combined with IP and time-to-click, it improves accuracy of human vs. bot classification.

Technical Details: HTTP User-Agent header; sometimes combined with Accept, Accept-Language, or other headers. Known-bot patterns in a list or rule set. BotDetect uses UA among other signals.

Example: Request with User-Agent “Proofpoint URL Defense” is classified as bot; request with “Mozilla/5.0 (Windows; …) Chrome/…” is classified as human (subject to other checks).

Category: Bot Detection · Analytics

Edge Cases: Some bots use browser-like UAs. Mobile and embedded clients may have unusual UAs. UA can be spoofed (less common for scanners).

SEO Notes: User-agent fingerprinting identifies bot vs. browser in email tracking. Use for bot detection.

V

VMC (Verified Mark Certificate)

Short Definition: A certificate issued by an approved certification authority that attests to a brand’s right to use a logo for BIMI display in supporting mailbox providers.

Detailed Explanation: BIMI allows senders to specify a logo URL in DNS; some receivers (e.g., Gmail) require that the logo be backed by a VMC. The VMC is issued after the CA verifies the brand’s trademark and identity. The certificate is referenced in the BIMI DNS record.

Why It Matters: VMC is required for BIMI in Gmail and possibly others. It adds cost and process but enables the verified logo in the inbox, improving recognition and trust.

Technical Details: X.509 certificate; issued by approved CAs (e.g., DigiCert, Entrust). Referenced in BIMI record. DMARC must be at p=quarantine or p=reject for BIMI to apply.

Example: Brand obtains VMC from DigiCert; publishes BIMI record with logo URL and VMC; Gmail shows logo next to messages that pass DMARC.

Related Terms: BIMI, DMARC, Authentication

Category: Authentication

Edge Cases: Not all brands qualify (trademark required). Cost and renewal. Not all receivers require VMC yet.

SEO Notes: VMC: Verified Mark Certificate for BIMI logo display. Required by Gmail for BIMI.

Warmup

Short Definition: The gradual increase in sending volume and reputation from a new IP or domain so that receivers learn to trust the sender and do not throttle or block.

Detailed Explanation: New IPs and domains start with no or neutral reputation. Sending full volume immediately can trigger rate limits and spam filters. Warmup involves starting with low volume and high-engagement segments, then scaling up over days or weeks while monitoring reputation and placement.

Why It Matters: Skipping warmup often leads to blocks and long-term reputation damage. Proper warmup builds positive reputation and improves long-term deliverability.

Technical Details: No standard; typically 2–4 weeks. Volume curves vary by provider and ESP. Dedicated IP warmup is common; shared IPs may not require sender-specific warmup. InboxEagle and Postmaster tools help monitor during warmup.

Example: New dedicated IP: day 1–7 send 1k–5k/day to engaged segment; day 8–14 increase to 20k/day; day 15+ scale to full volume while watching reputation.

Related Terms: IP reputation, Domain reputation, Rate limiting, Throttling

Category: Deliverability · Reputation

Edge Cases: Cold IPs on shared pools can warm up quickly due to pool reputation. Very large senders may use multiple IPs and warm them in parallel. Sudden volume drop after warmup can also hurt reputation.

SEO Notes: Email warmup: gradually increase volume on new IP/domain to build reputation and avoid blocks.

Glossary

Table of contents

Alphabet navigation

A

Alignment

ARC (Authenticated Received Chain)

Apple Mail Privacy Protection (MPP)

Authentication

Automated link scanner

B

Barracuda filtering

Bayesian filtering

BIMI (Brand Indicators for Message Identification)

Blocklist

Bounce processing

Bot Finder

Bot filtering

Bot detection

Bounce rate

C

Complaint rate

Content filtering

Click tracking

Corporate email gateway

Deliverability

D

DKIM (DomainKeys Identified Mail)

DKIM replay attack

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DNS propagation

Domain age signals

Domain impersonation

Domain reputation

E

Feedback loop (FBL)

Forwarding

F

False click

G

Gmail Postmaster Tools

Greylisting

Hard bounce

H

Heuristic filtering

Human click verification

I

Image proxying

Inbox placement

IP reputation

Lens (inboxeagle/lens)

Key rotation

L

Link wrapping

List hygiene

M

MTA (Mail Transfer Agent)

MTA-STS (Mail Transfer Agent Strict Transport Security)

Mimecast link rewriting

Microsoft Safe Links

O

Open tracking

Pixel tracking

P

Phishing detection

Policy enforcement

Prefetching

Proofpoint click scanning

Q

Quarantine

R

Reputation filtering

Retry logic

Rate limiting

Queueing

S

SPF (Sender Policy Framework)

SMTP (Simple Mail Transfer Protocol)

Sandbox click

Security scanner

Soft bounce