Email Deliverability Glossary

Every term that shows up when you debug why campaigns land in spam — authentication, reputation, filtering, and bot traffic — defined for store owners and email marketers, with why each one costs or earns you revenue. 110 entries, cross-linked to the InboxEagle docs.

A

Alignment

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

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 individually, meaning your emails can still land in spam or be rejected. If your Shopify store sends through Klaviyo, the signing domain must align with your From address — misalignment is a common setup mistake. Proper alignment is also required for BIMI.

Technical details: RFC 7489 (DMARC). BIMI is specified in the IETF draft draft-blank-ietf-bimi, not an RFC. Headers: From, Return-Path; DKIM d= tag.

Example: A Shopify brand sends from newsletter@mail.yourbrand.com with DKIM signed as d=yourbrand.com; this gives relaxed DMARC alignment and passes. If their ESP signs with a mismatched domain, DMARC fails and campaigns start landing in spam.

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

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.

Apple Mail Privacy Protection

MPP. Apple’s feature that fetches the images in an email through Apple’s proxy servers on receipt, generating an open before the subscriber has looked at the message, or without them ever looking at it.

When MPP is enabled, which it is by default for most Apple Mail users, Apple’s proxy servers fetch the remote images when the message arrives. That fires your open tracking pixel, so the open is recorded whether or not anyone reads the email. MPP does not prefetch links, so clicks are not inflated by it; bot clicks come from security scanners and link scanning, which are separate mechanisms.

Why it matters: MPP makes open rates unreliable for e-commerce brands. If you use open rates to trigger flows in Klaviyo, measure campaign success, or suppress unengaged subscribers, MPP means your data is likely inflated 2–3x for Apple Mail users. Clicks are the metric that survives MPP intact, which is why engagement segments built on clicks hold up where open-based ones quietly stop meaning anything. Bot Finder separates MPP-triggered events from real human engagement so your metrics and automations reflect actual subscriber behavior.

Technical details: Image proxying only. Requests come from Apple IP ranges, and user-agent and timing patterns differ from a real Mail.app open. Images are cached, so subsequent genuine opens may not re-request the pixel at all.

Example: A Shopify store sees 60% open rate in Klaviyo; after filtering MPP and bot traffic via InboxEagle Bot Finder, true human opens are 22% — revealing the real performance of their campaigns and enabling more accurate flow triggers.

Related terms: Open tracking, Prefetching, Bot click, Image proxying, Link wrapping

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.

ARC

Authenticated Received Chain. A protocol that preserves authentication results across forwarding and middleboxes so downstream receivers can trust earlier SPF/DKIM/DMARC results.

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 and mailing lists often break SPF/DKIM authentication, which can cause legitimate emails to land in spam at the destination. ARC helps preserve your sender’s good reputation through those hops — reducing false spam classification for forwarded mail.

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: A customer forwards your promotional email from their Gmail account to a Yahoo account; Yahoo sees failed SPF but a valid ARC chain from Gmail confirming the original authentication — Yahoo accepts the message instead of sending it to spam.

Related terms: DMARC, DKIM, Forwarding, Policy enforcement

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.

Authentication

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

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. Since the Google and Yahoo rules of February 2024 and Microsoft’s of May 2025, SPF and DKIM are required of everyone and a DMARC record is required of bulk senders; DMARC is no longer a recommendation you can defer.

Why it matters: Missing or misconfigured authentication leads to emails landing in spam, your domain being spoofed by phishers, and lower inbox placement. For store owners, most ESPs (Klaviyo, Omnisend) handle DKIM for you — but SPF and DMARC usually require manual DNS setup, which many brands skip.

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

Example: A Shopify brand sets up SPF (including their Klaviyo ESP), activates DKIM via their sending domain settings, and publishes DMARC at p=quarantine; Gmail and Yahoo validate all three and place emails in the inbox consistently — while phishers spoofing their domain get rejected.

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

Authentication

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

Automated link scanner

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

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 your click rates and can trigger Klaviyo flows for subscribers who never actually clicked. If you use click events to trigger abandoned cart or post-purchase automations, scanner-generated clicks cause those flows to fire for the wrong people. Bot Finder filters scanner traffic so your automations trigger on real engagement.

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: A B2B promotional email is delivered to a corporate recipient behind Proofpoint; Proofpoint fetches every link 2 minutes after delivery; InboxEagle Bot Finder flags these as scanner clicks, keeping your Klaviyo click metrics clean.

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.

B

Barracuda filtering

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

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: Barracuda, like other corporate security gateways, inflates your click metrics with scanner-generated events. If you send to any B2B subscribers (work emails), Barracuda traffic can skew your reported CTR and trigger automations incorrectly. Bot Finder identifies Barracuda traffic so you measure real engagement.

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

Example: A DTC brand’s email reaches a corporate buyer whose company uses Barracuda; Barracuda prefetches all links within seconds of delivery; InboxEagle Bot Finder classifies these as bot clicks, preventing them from skewing campaign stats.

Security Bot Detection

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

Bayesian filtering

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

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 learn from past spam to detect new spam — meaning your subject lines and copy choices directly affect whether you land in the inbox. Promotional language like “FREE,” “Act now,” “Click here,” or excessive exclamation marks trains the filter against you. Clean, specific, value-driven copy is the fix.

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 Shopify brand’s flash sale email uses “FREE GIFT — Act Now!!!” in the subject; Bayesian filters score it as likely spam and route it to the junk folder; rewriting to “Your exclusive gift with orders over $75” dramatically improves inbox placement.

Related terms: Content filtering, Heuristic filtering, SpamAssassin

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.

BIMI

Brand Indicators for Message Identification. A DNS-based standard that allows verified senders to display a logo in supporting mailbox providers’ inboxes, contingent on DMARC policy and VMC.

BIMI uses a TXT record at default._bimi.<domain> pointing to the logo URL and to a certificate. Receivers that support BIMI display the logo when DMARC passes and policy is enforced. Gmail and Yahoo accept a VMC or a CMC; Apple Mail requires a VMC.

Why it matters: BIMI displays your brand logo next to your emails in Gmail and Apple Mail — increasing recognition and open rates for promotional campaigns. For e-commerce brands, a visible logo in the inbox builds the trust that drives clicks. Achieving BIMI also forces you to implement strong DMARC enforcement, which protects your domain from phishing.

Technical details: Specified in the IETF draft draft-blank-ietf-bimi; BIMI is not an RFC. DNS: default._bimi.<domain> TXT. Requires a DMARC policy of at least quarantine, plus a VMC or CMC from an approved certification authority.

Example: A Shopify brand sets DMARC to p=reject, obtains a Verified Mark Certificate (VMC), and publishes a BIMI DNS record; Gmail and Apple Mail now show their logo next to every email — increasing brand recognition and open rates.

Related terms: DMARC, Alignment, VMC, CMC, Policy enforcement, Authentication

Authentication

Edge cases: Not all providers support BIMI. A CMC removes the trademark barrier but not at Apple Mail, which is where most consumer opens are. The logo must be SVG Tiny Portable/Secure; ordinary SVG exports are rejected.

Blocklist

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

Blocklists are maintained by third parties (e.g., Spamhaus, SpamCop, Barracuda) 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 major blocklist like Spamhaus can cause Gmail, Yahoo, and other providers to reject or bulk all your emails overnight — immediately stopping your abandoned cart flows, post-purchase sequences, and promotional campaigns. InboxEagle monitors your sending IPs against blocklists so you find out before your revenue does.

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: A Shopify store purchases a third-party email list; it contains a Spamhaus spam trap address; after sending, their IP is listed on Spamhaus and Gmail starts rejecting all their emails — halting every automation and campaign until they get delisted.

Related terms: Domain reputation, IP reputation, Spam trap, Greylisting, Delist

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.

Bot click

A click on an email link generated by software rather than a subscriber — a security scanner, a privacy proxy, a crawler, a link prefetcher. Also called a false click.

In raw analytics a bot click is indistinguishable from a human one: same URL, same timestamp format, same entry in the report. Only the surrounding signals separate them — the originating IP, the user-agent, how fast the click followed delivery, and whether anything happened on your store afterwards.

Why it matters: Bot clicks inflate CTR, and every system downstream believes the number. Klaviyo fires abandoned cart, post-purchase, and re-engagement flows at people who never clicked; A/B tests crown the wrong winner; click-based attribution credits revenue to campaigns that did not earn it. Bot Finder separates automated clicks from genuine engagement.

Technical details: Classified on vendor IP ranges, user-agent, time-to-click (often seconds after delivery), absence of any follow-on session, and clustering across recipients. Rule-based or ML scoring assigns a BOT / SUSPICIOUS / HUMAN verdict.

Example: A Black Friday campaign reports 8% CTR in Klaviyo. Six of those eight points came from Proofpoint scanners and Apple MPP proxies; true human CTR is 2% — a different campaign than the dashboard described.

Bot Detection Analytics

Edge cases: A real subscriber on a corporate network shares an IP with the gateway that prefetched the same link seconds earlier — time-to-click and conversion follow-through are what separate them. Mobile networks and VPNs weaken IP-based rules.

Bot detection

Deciding whether an open or click came from a person or from software — a security scanner, a privacy proxy, a crawler. Detection produces the verdict; filtering is what you do with it: keep bot events out of the metrics, segments, and automations that drive revenue.

Every event is scored on signals a human cannot fake consistently: sending IP against known vendor ranges, user-agent, time-to-click, request patterns, and whether the click ever leads to a session on your store. InboxEagle’s Bot Finder runs this on Amazon SES events and hands back cleaned engagement data.

Why it matters: Unfiltered open and click rates are inflated by Apple MPP and corporate link scanners, and every downstream decision inherits the error. Klaviyo flows fire for subscribers who never clicked, A/B tests pick the wrong winner, and re-engagement campaigns suppress people who are still reading. For a Shopify brand, that is revenue lost to a number that was never real.

Technical details: Rule-based or ML scoring; output is a verdict (BOT / SUSPICIOUS / HUMAN) plus confidence, applied in real time or in batch before reporting. Filtering thresholds are tunable per campaign or segment.

Example: A Shopify brand connects Bot Finder to Amazon SES. Bot events from Apple MPP and Proofpoint scanners are flagged and excluded; reported open rate drops from 55% to 24% — and the 24% is the number worth optimising against.

Bot Detection Analytics

Edge cases: Filter too aggressively and you drop real engagement; too conservatively and noise survives. New scanner and proxy types take time to appear in the model, and VPN or shared corporate networks weaken IP-based rules — a real subscriber clicking seconds after their gateway prefetched the same link needs deduplication to be counted correctly.

Bot filtering

Excluding or flagging bot opens and clicks so reports, segments, and automation triggers run on human engagement only. Filtering is the action taken on a detection verdict — see Bot detection for how events are classified and what the verdict costs you when it is wrong.

Bot Detection Analytics

Bounce processing

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.

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 tell Gmail and Yahoo your list is unclean, triggering spam filtering or outright blocks. Most ESPs (Klaviyo, Omnisend) handle hard bounce suppression automatically — but if your bounce rate spikes after a campaign, you need to investigate your list quality before the next send.

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: A Klaviyo campaign returns a 5.1.1 “address not found” bounce for an old subscriber email; Klaviyo automatically marks it as a hard bounce and suppresses it from all future sends, protecting your sender reputation.

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

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.

Bounce rate

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

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 signal list hygiene problems and trigger spam filtering or blocks. For e-commerce brands, sending to old or purchased lists is a common cause. Most ESPs (Klaviyo, Omnisend) automatically suppress hard bounces — but if your bounce rate spikes, you need to investigate and clean your list quickly.

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 Shopify brand sends a re-engagement campaign to their full 200k list including 2-year-old subscribers; 4k hard bounces result in a 2% bounce rate; the following week’s promotional campaigns land in spam at Gmail until reputation recovers.

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

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.

Bulk sender requirements

The authentication, unsubscribe, and complaint-rate rules that Gmail, Yahoo, and Microsoft apply to anyone sending roughly 5,000 or more messages a day to their users.

Google and Yahoo introduced the rules in February 2024 and Microsoft published its own for Outlook, Hotmail, and Live in May 2025. The three sets overlap closely: authenticate with SPF and DKIM, publish a DMARC record, send from a domain with matching forward and reverse DNS, transmit over TLS, offer one-click unsubscribe on marketing mail, and keep user-reported spam rate low.

Why it matters: These are not recommendations you can defer. Gmail began escalating from spam-foldering to outright rejection for non-compliant traffic in November 2025, and Microsoft moved the same way through 2026. If your Shopify store sends daily campaigns and automations through Klaviyo, you are almost certainly over the threshold, and a missing DMARC record or unsubscribe header is the difference between delivery and a bounce.

Technical details: Threshold is approximately 5,000 messages per day to a single provider’s users, counted per sending domain. Requires SPF and DKIM passing with alignment, a DMARC record (p=none is an accepted starting point, with progression to quarantine or reject expected), a valid PTR record, TLS for transmission, List-Unsubscribe and List-Unsubscribe-Post on marketing mail, and spam rate held below the published ceiling.

Example: A Shopify brand sending 18,000 campaign emails a day crosses the threshold at all three providers. They pass SPF and DKIM but have no DMARC record; Gmail starts rejecting a growing share of their sends. Publishing v=DMARC1; p=none; rua=mailto:... restores delivery, and they move to quarantine once their aggregate reports come back clean.

Related terms: SPF, DKIM, DMARC, One-click unsubscribe, Spam rate, PTR record, Authentication

Deliverability Compliance

Edge cases: The threshold is per provider, not total volume, so a list weighted toward Gmail can cross there and nowhere else. Transactional mail is subject to the authentication rules but not the unsubscribe requirement. Crossing the threshold once puts you in scope; providers do not reassess daily.

C

Click tracking

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

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 reporting, Klaviyo flow triggers, and conversion attribution in your email campaigns. However, the same mechanism that tracks real clicks also captures bot clicks from security scanners and Apple MPP — meaning your reported CTR is inflated without bot filtering.

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: A link to your Shopify store’s sale page (https://yourbrand.com/sale) is wrapped by Klaviyo as a tracking URL; every real customer click is logged and reported in Klaviyo analytics, but so are security scanner prefetches — which is why bot filtering matters.

Related terms: Link wrapping, Open tracking, Bot click, Pixel tracking

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.

CMC

Common Mark Certificate. A certificate that verifies a brand’s logo for BIMI display without requiring a registered trademark, using instead evidence of prior public use of the mark.

CMCs arrived in 2024 and 2025 as a lower-barrier alternative to the VMC. Gmail and Yahoo accept either certificate type for logo display. Apple Mail does not accept a CMC; it requires a VMC backed by a registered trademark.

Why it matters: A VMC means trademark registration, which many e-commerce brands have never done and which takes months plus legal fees. A CMC lets those brands display a logo at Gmail and Yahoo without it. The catch is the one that matters most: Apple Mail accounts for a large share of opens for consumer brands, and it will keep showing a default avatar for a CMC-only sender.

Technical details: X.509 certificate issued by an approved certification authority, referenced from the a= tag of the BIMI DNS record exactly as a VMC is. Requires DMARC at quarantine or reject. Typically cheaper than a VMC. Confers no verified checkmark in Gmail, only the logo.

Example: A Shopify brand without a registered trademark obtains a CMC and publishes their BIMI record. Their logo appears next to campaigns in Gmail and Yahoo. Apple Mail subscribers still see initials, so the brand starts trademark registration to upgrade to a VMC later.

Related terms: BIMI, VMC, DMARC, Policy enforcement

Authentication

Edge cases: Provider support differs, so a CMC does not guarantee display everywhere a VMC would. Evidence of prior use must usually cover a defined period before issuance. Upgrading from CMC to VMC means a new certificate and a BIMI record change, not an amendment.

Competitive intelligence

The practice of monitoring competitor brands’ inbox placement rates, sending domain data, and authentication practices to benchmark your own email program.

Email competitive intelligence involves tracking the observed inbox, promotions, and spam placement rates of competitor brands using a panel of seed mailboxes. By comparing your placement rates against a direct competitor at the same providers, you can identify gaps in authentication, sending frequency, or list hygiene that explain performance differences.

Why it matters: If a competitor consistently achieves 89% inbox placement at Gmail while you are at 72%, the root cause is usually discoverable — different DMARC enforcement levels, different complaint rates, or different IP strategies. InboxEagle’s competitive intelligence dashboard shows head-to-head and industry benchmark comparisons.

Technical details: Based on panel/seed observation data; not private ESP data. Placement rates are calculated from the same seed panel used for your own program, so comparisons are on identical measurement basis.

Example: A DTC clothing brand tracks three direct competitors in InboxEagle; two of the three are at p=reject DMARC while the brand is still at p=none; after enforcing DMARC, their Gmail inbox rate rises from 74% to 86% — closing the gap with competitors.

Related terms: Inbox placement, Domain reputation, Seed list, DMARC

Analytics Deliverability

Edge cases: Panel observation captures only what the seed mailboxes see; low-volume senders may have sparse competitive data. Brand tracking requires the competitor’s sending domain to be observed through the panel.

Complaint rate

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

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: The 0.10% target and 0.30% ceiling are not folklore; they are the thresholds published in the Gmail and Yahoo bulk sender requirements, and Microsoft enforces its own complaint thresholds for Outlook, Hotmail, and Live. At or above 0.30% your domain is treated as ineligible for delivery rather than merely throttled. One badly-timed campaign to an unengaged or purchased list can damage your deliverability for weeks, hurting all your automated flows in Klaviyo or Omnisend.

Technical details: Measured via FBL (ARF) reports and provider-side aggregation. Gmail Postmaster Tools and others surface complaint or spam rate in sender dashboards; tagging sends with Feedback-ID breaks the Gmail figure down per campaign instead of per domain.

Example: A store sends a broad re-engagement campaign without segmenting inactive subscribers; complaint rate spikes to 0.35%; abandoned cart and welcome emails land in spam for Gmail users for the next two weeks until reputation recovers.

Related terms: Feedback loop, Domain reputation, Suppression list, Spam rate

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.

Content filtering

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

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 perfect SPF, DKIM, and DMARC, spammy subject lines, aggressive promotional language, or suspicious links can trigger content filters and send your campaigns to spam. For Shopify stores, this is often the difference between a flash sale that reaches the inbox and one that doesn’t.

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 Shopify store’s promotional email uses “You WON!!! Claim your free gift 🎁🎁🎁” in the subject with a bit.ly shortlink in the body; Gmail’s content filter routes it to spam; rewriting to “Your complimentary gift is waiting — expires Sunday” with a clean tracked link improves inbox placement.

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.

Corporate email gateway

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

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: Corporate email gateways affect both deliverability and your engagement metrics. If you sell to business buyers or B2B customers, gateway-generated clicks can dominate your CTR data. InboxEagle Bot Finder identifies gateway traffic so your analytics reflect real buyer behavior, not scanner activity.

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: A brand sends a B2B campaign; Gmail accepts it, but a corporate Proofpoint gateway blocks it before reaching the employee’s inbox — the brand sees “delivered” in their ESP but the buyer never received it. Proofpoint also prefetches all links, creating apparent click events that Bot Finder flags as bots.

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.

Cost optimization

The practice of identifying and suppressing unengaged contacts to reduce per-contact or per-email ESP costs while improving deliverability by sending only to active subscribers.

Most ESPs charge based on contact count or email volume. A significant portion of any mature list — typically 20–50% — consists of contacts who have not genuinely engaged in months or whose “engagement” was generated by bots (Apple Mail Privacy Protection, security scanners). Suppressing these contacts reduces costs without reducing real revenue, since they were not converting anyway. InboxEagle’s cost optimization tool uses Bot Finder-filtered engagement data to make suppression decisions on confirmed human activity rather than raw open rates.

Why it matters: Average cost reduction for programs that have never cleaned their list is 40%. Sending to unengaged contacts also degrades inbox placement over time — mailbox providers treat low engagement as a negative reputation signal. Suppressing non-engagers improves both your budget and your deliverability in parallel.

Technical details: Requires engagement data filtered for bot opens (see Bot Finder). Suppression lists are uploaded to your ESP or synced via Klaviyo. Apple Mail Privacy Protection means open-based suppression alone is unreliable; click signals are more reliable for confirming disengagement.

Example: A Shopify brand with 120k contacts in Klaviyo uses InboxEagle cost optimization to identify 48k contacts with no confirmed human open in 180 days; after suppressing them, their monthly Klaviyo cost drops by 38% and their Gmail inbox rate improves from 79% to 88% due to higher engagement ratios.

List Management Deliverability

Edge cases: Apple Mail users will appear disengaged if only opens are tracked. Consider click-based confirmation before suppressing. Re-engagement campaigns before final suppression can recover some contacts.

D

Dedicated IP

A sending IP used by one sender only, rather than shared with other customers of an ESP. Dedicated IPs give you full control of IP reputation but must be warmed up, and they need consistent volume to stay trusted.

Why it matters: A dedicated IP is usually sold as an upgrade, and for most e-commerce brands it is the wrong one. Below roughly 100,000 messages a month there is not enough consistent volume to hold a reputation, and you lose the cover of a well-run shared pool without gaining anything. Above that, and with steady sending, it stops your deliverability depending on strangers.

Technical details: Requires warmup over weeks, a valid PTR record, and volume consistent enough that gaps do not read as a dormant IP returning. Microsoft SNDS reports per-IP data, which is only accessible to whoever holds the IP allocation.

Example: A brand sending 40,000 emails a month moves to a dedicated IP. Volume is too low and too uneven to establish reputation; placement gets worse than it was on the shared pool, and they move back.

Related terms: IP reputation, Warmup, Throttling, PTR record, Microsoft SNDS, Sending domain

Deliverability Reputation

Edge cases: Seasonal senders with long quiet periods do badly on dedicated IPs. Some providers rate-limit unknown IPs regardless of warmup pace. A dedicated IP does nothing for domain reputation, which is the signal that matters more at Gmail.

Delist

The process of requesting removal from a blocklist after fixing the problem that caused the listing. Most operators require evidence of remediation, and repeat listings take longer to clear.

Related terms: Blocklist, Spam trap, IP reputation

Deliverability

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

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 your abandoned cart reminders, welcome series, and promotional campaigns never reach customers — directly cutting revenue. For e-commerce brands, every improvement in inbox placement translates to more orders seen and more email revenue recovered.

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 Shopify brand fixes their SPF, DKIM, and DMARC setup, cleans inactive subscribers from their list, and reduces spam complaints; inbox placement improves from 60% to 88% across Gmail and Yahoo — recovering significant monthly email revenue.

Deliverability

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

Deliverability monitoring

Continuously tracking where your email actually lands, whether authentication passes, and how mailbox providers rate your sending, rather than inferring it from opens and clicks.

Monitoring combines provider-reported data (Google Postmaster Tools, Yahoo Sender Hub, Microsoft SNDS), seed testing for placement by folder, DMARC aggregate reports for authentication coverage, and blocklist checks.

Why it matters: Campaign reports tell you what happened to the mail that arrived. They say nothing about the mail that did not, because a message in the spam folder is a delivered message. Without monitoring, the first signal of a deliverability problem is usually a revenue drop weeks after the cause. InboxEagle exists to close that gap.

Technical details: Sources are provider dashboards and APIs, seed accounts across the major providers, aggregate DMARC XML at the rua= address, and DNSBL lookups. Provider data is aggregated and delayed, typically by a day, and has volume floors below which nothing is reported.

Example: A Shopify brand’s Gmail domain reputation slips from High to Medium after a large re-engagement send. Monitoring surfaces it within a day, while open rates still look normal, and the brand pauses the remaining batches before reputation drops to Low and placement collapses.

Deliverability Analytics

Edge cases: Provider reputation data needs sustained volume before it appears at all, so new or low-volume domains show nothing. Seed lists approximate real subscribers and can drift from them. Aggregate DMARC reports show authentication, not placement.

DKIM

DomainKeys Identified Mail. 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.

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.<domain>) and verifies the signature. Alignment links the signing domain to the From domain for DMARC.

Why it matters: DKIM is required by Gmail, Yahoo, and most major mailbox providers and is a component of DMARC. Broken or missing DKIM frequently causes emails to land in spam. Your ESP (Klaviyo, Omnisend, Shopify Email) signs emails with DKIM — but you must add the provided public key record to your domain’s DNS to activate it.

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: A brand sets up DKIM in Klaviyo by adding the selector DNS record they provide; emails from newsletter@yourbrand.com now pass DKIM at Gmail and Yahoo, improving inbox placement for all campaigns and flows.

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

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.

DKIM replay attack

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

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: DKIM replay attacks can allow bad actors to reuse legitimate signed emails from your brand to reach inboxes or lend credibility to phishing. Strong DMARC enforcement at p=reject, combined with BIMI, helps protect your brand’s identity and signals to mailbox providers that you take security seriously.

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: An attacker intercepts a signed promotional email from a Shopify brand and resends it to a different list; DKIM still passes since the signature is valid; DMARC reporting helps the brand detect the misuse, and recipient-level checks may eventually flag the replayed messages.

Related terms: DKIM, DMARC, Phishing detection, Spoofing

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.

DMARC

Domain-based Message Authentication, Reporting and Conformance. 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.

Domain owners publish a DMARC TXT record at _dmarc.<domain> 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: Without DMARC, phishers can send emails impersonating your brand, damaging customer trust and hurting your domain reputation with mailbox providers. DMARC at p=quarantine or p=reject is required for BIMI (brand logo in inbox) and is a strong trust signal to Gmail and Yahoo that you are a legitimate sender.

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: A DTC brand sets DMARC to p=quarantine; a phisher attempting to spoof their domain has messages quarantined by Gmail and Yahoo; the brand also receives daily DMARC reports showing authentication pass/fail rates across their Klaviyo and transactional email infrastructure.

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

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.

DMARC aggregate report

An XML report sent daily by mailbox providers to the rua address in a DMARC record, showing authentication pass/fail data for all mail claiming your domain, broken down by sending source and IP.

When a domain has a DMARC record with a rua= URI, participating mailbox providers (Gmail, Yahoo, Outlook, and others) send a daily XML report covering every IP that sent mail claiming your domain during that period. Each row shows the source IP, SPF result, DKIM result, DMARC disposition, and message count. InboxEagle parses these reports automatically and surfaces the data in the DMARC monitoring dashboard.

Why it matters: Without a rua address, you are blind to unauthorized senders — phishers, forgotten marketing tools, or misconfigured services sending on your domain’s behalf. Aggregate reports are the primary data source for discovering unauthorized senders before they damage your domain reputation. Even if you have p=none (no enforcement), you need rua data to understand what is happening and build toward enforcement.

Technical details: RFC 7489 Section 7.2. Format: gzipped XML. Delivered via email to rua address within 24 hours of the reporting period. Reports cover a 24-hour period. Multiple providers send separate reports; InboxEagle consolidates them.

Example: A Shopify brand adds rua=mailto:dmarc@inboxeagle.com to their DMARC record; InboxEagle begins receiving daily reports from Gmail, Yahoo, and Outlook; after one week, the brand discovers three unknown IP addresses sending mail claiming their domain — two are forgotten transactional services, one is a phishing attempt — and takes action.

Related terms: DMARC, Alignment, Unauthorized sender, Policy enforcement

Authentication

Edge cases: Not all providers send DMARC reports; smaller providers may not participate. Reports have a 24-hour inherent delay. Forensic reports (ruf) provide individual message data but are less widely supported.

DNS propagation

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

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 updating your SPF, DKIM, or DMARC DNS records, it can take minutes to 48 hours before all mailbox providers see the change. Testing authentication too soon after a DNS change will give false failures. Plan DNS updates at least 48 hours before a major send, and lower your TTL beforehand to speed up propagation.

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: A Shopify brand updates their DKIM selector before a Black Friday campaign; Gmail sees the new record within 30 minutes, but Yahoo still returns NXDOMAIN for 6 hours; they should have made the change 48 hours earlier to avoid authentication failures during the campaign.

Related terms: SPF, DKIM, DMARC, Subdomain delegation

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.

Domain age signals

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

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: New sending domains (or subdomains) need time to build trust with mailbox providers. If you launch a new Shopify store or rebrand and switch sending domains, expect inbox placement to be lower initially. Combine domain age with strong authentication and a proper warmup strategy to build reputation faster.

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

Example: A new DTC brand launches and starts sending from a freshly registered mail.newbrand.com; Gmail treats the subdomain with caution and routes some emails to Promotions initially; after 4–6 weeks of consistent sending, low complaints, and strong authentication, inbox placement improves.

Related terms: Domain reputation, Warmup, Phishing detection

Reputation Security

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

Domain impersonation

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.

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: Phishers impersonating your brand damage customer trust, increase spam complaints against your domain, and can harm your sender reputation. Setting DMARC to p=reject prevents phishers from spoofing your exact domain in the From address, and BIMI provides a visual trust signal that distinguishes your legitimate emails from fakes.

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: A scammer sends emails with the display name “YourBrand Support” from a lookalike domain; customers are tricked into giving credentials; DMARC can’t stop the lookalike domain but p=reject on your real domain prevents spoofing your actual address. Phishing reports can also hurt your domain’s reputation indirectly.

Related terms: Spoofing, Phishing detection, DMARC, BIMI

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.

Domain reputation

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

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 is often more important than IP reputation for Gmail and Yahoo. For Shopify brands, your sending domain (e.g., mail.yourbrand.com) builds trust with each mailbox provider based on engagement, complaint rate, and authentication. Poor domain reputation means even well-crafted campaigns land in spam.

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 DTC brand moves their promotional sends to a new subdomain promo.yourbrand.com; Gmail treats it with caution initially — Promotions or Spam placement — until positive engagement signals (opens, clicks, low complaints) build reputation over several weeks.

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).

Double opt-in

Requiring a subscriber to confirm their address by clicking a link in a confirmation email before they receive anything else, rather than adding them on form submission alone.

Why it matters: It costs you some list growth and buys you the two things that actually damage sending reputation: typo and malicious signups never join the list, and spam traps planted through forms never get confirmed. For a brand that runs giveaways or has an open newsletter form, that trade is usually worth it.

Technical details: Form submission sends a confirmation message with a tokenised link; the address becomes mailable only once the link is clicked. Confirmation clicks can be triggered by security scanners, so the confirmation link should be single-use and the click should be treated as weak evidence rather than proof of a human.

Example: A Shopify brand switches their newsletter form to double opt-in after a subscription-bombing attack floods it with addresses that never belonged to real visitors. List growth drops by about a fifth; complaint rate and bounce rate both fall, and the unconfirmed addresses never enter the sending list.

List Management Compliance

Edge cases: Confirmation emails land in spam like any other mail, so a brand with poor deliverability loses subscribers who did want to join. Scanner-triggered confirmations can mark an address confirmed that no human ever saw.

E

Encryption

Protection of message contents in transit (opportunistic TLS, enforced by MTA-STS) or at rest at the mailbox provider. Mailbox providers increasingly expect TLS on every connection.

Related terms: TLS, MTA-STS, TLS-RPT, SMTP

Infrastructure Security

Engagement-based filtering

Mailbox providers deciding placement from how a specific recipient has treated your previous mail, not only from how your domain performs in aggregate.

Opens, replies, moves out of spam, deletions without reading, and how long a message sits unopened all feed per-recipient models. This is why the same campaign reaches one subscriber’s inbox and another’s spam folder with identical authentication, content, and sending IP.

Why it matters: It explains the single most common confusion in e-commerce email: nothing about your setup changed, yet placement got worse. What changed is that you kept mailing people who stopped engaging. Sending to a large inactive segment does not just waste sends; it teaches Gmail that your mail is unwanted, and that verdict follows you to engaged subscribers too.

Technical details: Signals are per-recipient and provider-proprietary. Aggregate sender reputation sets a baseline, then recipient history adjusts placement from there. Recency is weighted heavily, so a long gap in sending or a sudden volume spike to dormant addresses both read as risk.

Example: A Shopify brand mails their full 90,000-address list including subscribers who have not opened in two years. Engaged subscribers keep landing in the inbox, but placement for the dormant half collapses and overall spam rate rises, which then starts pulling the engaged segment down too.

Deliverability Reputation

Edge cases: Bot opens and MPP inflate apparent engagement without teaching the provider anything, so a segment that looks active can be dead. Transactional mail is judged more leniently. B2B recipients behind a gateway generate weaker per-recipient signals.

Engagement rate

The share of delivered mail that subscribers open, click, or reply to over a period. Mailbox providers weigh engagement heavily, so falling engagement usually precedes falling inbox placement.

Related terms: Open tracking, Click tracking, Sunset policy, Bot filtering

Analytics

F

False click

Any click recorded in email analytics that no human made — scanner, prefetcher, proxy, or crawler. Synonym for bot click, which covers the signals used to catch them and what they cost you when they slip through.

Bot Detection Analytics

Feedback-ID

A header that lets you tag outgoing mail with your own campaign and stream identifiers so Google Postmaster Tools can break spam rate down by those tags instead of reporting one number for the whole domain.

The header carries up to four colon-separated fields of your choosing, typically something like campaign, segment, customer, and a sender identifier. Postmaster Tools then reports complaint data per identifier.

Why it matters: A domain-level spam rate of 0.18% tells you that you have a problem somewhere. It does not tell you that your abandoned-cart flow is fine and one re-engagement campaign is responsible for nearly all of it. Tagging turns a single alarming number into a list you can act on, and it is the difference between pausing one flow and pausing your whole program.

Technical details: Feedback-ID: a:b:c:SenderId in the message header, maximum 4 fields, the last being a sender-chosen identifier. Gmail-specific. Requires enough volume per identifier before data appears. Most established ESPs set it automatically, though the field layout varies.

Example: A Shopify brand’s Gmail spam rate sits at 0.21%. Their ESP tags each send, and Postmaster Tools shows the browse-abandonment flow at 0.03% while a win-back campaign to two-year-old addresses is at 1.4%. They retire the win-back segment and the domain rate falls back under 0.1% within a week.

Analytics Reputation

Edge cases: Low-volume identifiers are suppressed, so tagging too granularly hides everything. Gmail only; other providers ignore the header. Changing your tagging scheme resets the history you were building.

Feedback loop

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

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: FBLs are how Yahoo and other providers tell you when subscribers mark your email as spam. Processing these reports and suppressing complainers is essential — sustained high complaint rates lead to your emails being filtered at the provider level, killing the deliverability of your entire email program. Most ESPs handle FBL enrollment automatically.

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: A Shopify brand’s Yahoo subscribers mark a re-engagement campaign as spam; Yahoo sends FBL complaint reports to the brand’s ESP; Klaviyo automatically suppresses those contacts from future sends, protecting the brand’s complaint rate and deliverability.

Infrastructure Reputation

Edge cases: Provider coverage is uneven and worth knowing precisely. Yahoo and AOL run a Complaint Feedback Loop, Microsoft runs the Junk Mail Reporting Program alongside SNDS, and Gmail offers no per-message FBL to ordinary senders at all: there you get the aggregate spam rate plus whatever Feedback-ID segmentation you set up yourself. Multiple complaints from one user can generate multiple reports, and matching them back to internal IDs is often the hard part.

Forwarding

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

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: When customers forward your emails, the original authentication can break — potentially causing your brand’s message to land in the recipient’s spam. ARC helps preserve trust through forwarding hops, reducing false spam classification of legitimately forwarded email.

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: A customer forwards your promotional email from their Gmail to a colleague’s Yahoo account; Yahoo sees SPF fail because Gmail’s IPs sent the message, but Gmail included an ARC seal; Yahoo accepts the email based on the ARC chain rather than rejecting it.

Related terms: ARC, SPF, DKIM, Alignment

Infrastructure Authentication

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

G

Google Postmaster Tools

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

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 typically the largest mailbox provider for any e-commerce brand. Postmaster Tools gives you Gmail’s view of your domain reputation, spam rate, and authentication pass rates — the signals Gmail actually uses to decide inbox vs. spam. InboxEagle surfaces this data alongside your other deliverability metrics so you can act on it without switching tools.

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. Spam rate is reported against the 0.10% target and 0.30% ceiling of the bulk sender requirements, and a Feedback-ID header lets you break that rate down per campaign rather than per domain.

Example: A Shopify brand sees “Low” domain reputation in Google Postmaster after a broad re-engagement campaign; they clean their list, strengthen DMARC, and reduce complaint rate; over 6 weeks, Gmail domain reputation rises to “High” and inbox placement for their abandoned cart flows improves significantly.

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

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.

Greylisting

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.

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: Greylisting causes a short delay in email delivery — typically a few minutes — on first contact. For e-commerce brands, this is rarely a problem since major ESPs (Klaviyo, Omnisend) automatically retry. However, time-sensitive emails (order confirmations, abandoned cart triggers) may arrive slightly later than expected due to greylisting.

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 transactional order confirmation email from a new sending IP hits a greylisting server; the first attempt returns a 451 temporary error; Klaviyo’s MTA retries after 5 minutes; the second attempt is accepted and the customer receives their order confirmation slightly delayed.

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

Anti-Spam Infrastructure

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

H

Hard bounce

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.

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: Sending repeatedly to hard-bounced addresses tells Gmail and Yahoo your list is dirty — leading to reputation damage and spam filtering across your whole program. Most ESPs (Klaviyo, Omnisend) auto-suppress hard bounces, but if you import external lists or have old segments, check for bounced addresses before sending.

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: A Shopify brand imports an old customer list from a previous platform; several addresses bounce with 5.1.1 “address not found” errors; Klaviyo suppresses them automatically, but the spike in bounce rate on the first send signals the need to warm up more gradually with a new or re-imported list.

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

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.

Heuristic filtering

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

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 score your emails based on detectable patterns — subject line words, link structures, HTML formatting. For Shopify brands, this means your promotional copy choices and email template design directly affect spam scores. Testing emails with tools like Mail-Tester before major campaigns helps catch high-scoring patterns.

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: A store’s promotional email uses “FREE” in the subject and “Click Here” in the body CTA button; heuristic rules add +2 and +1.5 to the spam score; replacing “FREE” with “Complimentary” and “Click Here” with “Shop the sale” reduces the score and keeps the email below the spam threshold.

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.

Human click verification

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

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

Why it matters: Human-verified click data is the foundation of accurate email ROI for e-commerce brands. When you base Klaviyo segment logic, A/B test results, and flow triggers on verified human clicks rather than scanner traffic, your decisions are grounded in real subscriber behavior — improving campaign performance and automation accuracy.

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

Example: InboxEagle Bot Finder analyses each click event: a click arriving 4 minutes after delivery from a residential IP with a Chrome user-agent is classified HUMAN; a click arriving 3 seconds after delivery from a Proofpoint IP is classified BOT — keeping your Klaviyo click data clean.

Bot Detection Analytics

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

I

Image proxying

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.

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 is the mechanism behind inflated open rates. Apple MPP, Gmail Image Proxy, and corporate security tools all load your tracking pixel through a proxy — triggering an “open” before the subscriber has seen your email. For Shopify brands, this means open-rate-based Klaviyo segments and flow triggers are working off inflated numbers without bot filtering.

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: A Shopify brand sends a new collection email to 50k subscribers; Apple MPP immediately loads images for all Apple Mail recipients, firing the open pixel for each one; the apparent open rate jumps to 61%, but InboxEagle Bot Finder shows only 26% are real human opens.

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.

Inbox placement

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

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: If your abandoned cart flows or promotional campaigns land in the Promotions tab or spam folder instead of the inbox, most customers never see them. Every percentage point of inbox placement improvement is direct revenue. InboxEagle monitors placement per domain and mailbox provider so you can spot and fix issues before they compound.

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 Shopify store’s Gmail placement shifts from 70% Promotions / 20% Spam to 85% Primary / 15% Promotions — dramatically improving open and click rates across all automated flows.

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

Deliverability

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

Inbox placement test

An on-demand test that sends a campaign to a panel of seed mailboxes and reports where it landed — inbox, promotions, or spam — at each mailbox provider, usually within minutes.

Also called seed list testing. The tester sends their email using their normal sending infrastructure to a set of real mailboxes maintained by a deliverability monitoring service (the seed list). The service checks each mailbox and reports placement per provider. Unlike ongoing monitoring (which uses real subscriber data over time), seed testing is triggered on demand and returns results quickly — typically under 5 minutes. InboxEagle’s inbox placement testing tool covers 20+ email providers including Gmail, Outlook, and Yahoo.

Why it matters: Seed testing lets you catch a spam folder problem before your real subscribers encounter it. Running a seed test before a major campaign — a flash sale, a Black Friday promotion, a re-engagement series — gives you the chance to fix authentication or content issues before revenue is on the line.

Technical details: Results depend on the seed panel composition and the sending infrastructure used. Must send from the same IP, domain, and configuration as production sends. Results are point-in-time; ongoing placement may vary from a single test.

Example: Before a Black Friday campaign, a Shopify brand runs an InboxEagle placement test; results show 94% Gmail inbox, 82% Yahoo inbox, and 68% Outlook inbox; the lower Outlook rate prompts them to check IP reputation for Outlook, finding a soft reputation signal they address before sending to their full list.

Related terms: Inbox placement, Seed list, Deliverability, Domain reputation

Deliverability Testing

Edge cases: A clean seed test does not guarantee clean placement for your real list — reputation signals from real subscriber behavior may differ from the seed panel. Test from the exact same sending infrastructure as production sends.

IP reputation

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.

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 by mailbox providers. Stores on shared IPs (as with most ESPs) share reputation with other senders on the same pool. Dedicated IPs isolate your reputation but require a gradual warmup period before sending at full volume.

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 Shopify brand moves to a dedicated sending IP; after a six-week warmup at increasing volumes — starting with their most engaged recent buyers — IP reputation rises from neutral to high and Gmail inbox placement improves from 65% to 91%.

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

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.

J

Junk folder

The provider folder where filtered mail lands — called spam at Gmail and junk at Outlook. Mail delivered to junk still counts as delivered, which is why bounce rate alone never proves inbox placement.

Related terms: Spam folder, Inbox placement, Quarantine

Deliverability

K

Key rotation

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

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: Rotating DKIM keys reduces the risk of key compromise and keeps your authentication secure. For most Shopify brands this is handled by your ESP — but if you manage your own DKIM keys, coordinate key rotation with DNS propagation carefully. A badly timed rotation can break DKIM and cause emails to land in spam during the transition window.

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

Example: A brand rotates their DKIM key: they publish the new selector (s2) in DNS, wait 48 hours for propagation, then update their ESP to sign with s2; after confirming the new key works, they remove the old s1 selector — avoiding any authentication gap during the transition.

Related terms: DKIM, DNS propagation, Authentication

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.

L

Link wrapping

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.

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 enables click tracking in all your Klaviyo campaigns and flows — it’s how open, click, and conversion data is captured. The same mechanism also captures bot scanner clicks, inflating your CTR. Using InboxEagle Bot Finder alongside your ESP’s click tracking gives you both: full tracking capability and accurate human-only engagement data.

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: A Shopify product link (https://yourbrand.com/products/summer-tee) is wrapped by Klaviyo as a tracking URL; every click (human or bot) is logged and attributed; InboxEagle Bot Finder then classifies each click event so your Klaviyo reports reflect real customer clicks.

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.

List hygiene

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

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 the most common cause of deliverability problems for e-commerce brands. Sending to old, purchased, or unengaged lists leads to high bounce rates, spam complaints, and spam trap hits — all of which damage your domain reputation and reduce inbox placement across your entire email program, including automated flows.

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

Example: A Shopify brand runs quarterly list hygiene: suppresses all hard bounces, removes subscribers with no engagement in 12 months (or runs a sunset campaign first), and switches new signups to double opt-in; bounce rate drops from 3.1% to 0.8% and complaint rate improves noticeably.

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

Deliverability Email Marketing

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

List-Unsubscribe

An email header that tells the receiving client how to unsubscribe a recipient, so the client can offer its own unsubscribe control instead of relying on a link buried in your footer.

Two forms exist. The original header carries a mailto: address, an HTTPS URL, or both. The newer form adds List-Unsubscribe-Post, which lets the client unsubscribe with a single POST request and no confirmation page. That pair is what one-click unsubscribe means.

Why it matters: Gmail, Yahoo, and Microsoft require this on marketing mail from bulk senders, and Gmail surfaces it as a native Unsubscribe button next to your sender name. The button is the point: a subscriber who wants out will either use it or hit Report spam, and one of those two outcomes costs you reputation while the other does not.

Technical details: List-Unsubscribe: <https://...>, <mailto:...> per RFC 2369, plus List-Unsubscribe-Post: List-Unsubscribe=One-Click per RFC 8058. The HTTPS endpoint must accept POST without requiring a login or a confirmation step. Requests must be honoured within two days.

Example: A Shopify brand’s Klaviyo campaigns carry both headers. Gmail shows an Unsubscribe button beside the sender name; roughly a third of departing subscribers use it rather than the footer link, and the brand’s complaint rate falls because those people are no longer reaching for Report spam.

Compliance List Management

Edge cases: A mailto: form alone does not satisfy the one-click requirement. An endpoint that answers a POST with a confirmation page rather than processing the request fails it too. Prefetching by security scanners can trigger unsubscribe URLs, which is why the POST form, not a GET link, is the one that counts.

M

Microsoft Safe Links

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.

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: Microsoft Safe Links generates click events on your tracked links for every email delivered to Outlook/Microsoft 365 users — instantly inflating your CTR with scanner activity. For Shopify brands with B2B customers or customers on Microsoft email, Safe Links can be a significant source of false clicks.

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: A Shopify brand sends a campaign to 20k subscribers, many on Microsoft 365; Safe Links scans every link immediately after delivery; the brand sees hundreds of near-instant “clicks” from Microsoft IP ranges; Bot Finder classifies these as bot activity, revealing the true human CTR.

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.

Microsoft SNDS

Smart Network Data Services. Microsoft’s free service that reports how mail from your sending IP addresses is treated at Outlook.com, Hotmail, and Live.

SNDS reports per-IP data: volume, complaint rate, spam-trap hits, and a colour-coded status. Its companion, the Junk Mail Reporting Program (JMRP), is Microsoft’s feedback loop, returning a copy of each message a user marks as junk.

Why it matters: Microsoft is the mailbox provider most e-commerce brands ignore until it blocks them, largely because it publishes far less than Gmail does. SNDS is the only direct view you get, and since Microsoft’s May 2025 sender rules it is the place where an IP problem shows up before your Outlook subscribers quietly stop converting.

Technical details: Access is requested per IP range and verified by email to an address at the IP’s registered owner, which means senders on shared ESP infrastructure usually cannot enrol; the ESP holds the access. Data is IP-based, not domain-based, and is delayed by roughly a day. JMRP enrolment is separate.

Example: A brand on a dedicated IP sees Outlook engagement fall with no change at Gmail. SNDS shows their IP flagged yellow with a complaint rate above Microsoft’s threshold, pointing at a specific segment rather than a domain-wide reputation problem.

Reputation Deliverability

Edge cases: Senders on shared ESP IPs generally cannot access SNDS for those IPs. Data appears only above a daily volume floor. SNDS covers consumer Outlook, not Microsoft 365 business tenants, which filter separately.

Mimecast link rewriting

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

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: If you send to B2B subscribers protected by Mimecast, their security system rewrites and prefetches your tracked links — generating apparent clicks in Klaviyo that are scanner activity, not real customer interest. InboxEagle Bot Finder identifies Mimecast traffic so your click and conversion data reflects real buyer 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: A DTC brand sends a B2B wholesale offer to corporate buyers; Mimecast rewrites their Klaviyo tracking links and prefetches them; the brand sees a spike in “clicks” seconds after delivery; Bot Finder classifies these as Mimecast scanner traffic, leaving only genuine buyer clicks in the stats.

Security Bot Detection

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

MTA

Mail Transfer Agent. 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.

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: For most Shopify brands, the MTA is managed by your ESP (Klaviyo, Omnisend, Mailgun) — you don’t configure it directly. But understanding MTA behavior helps you interpret bounce error codes, diagnose delivery delays, and understand why some emails retry while others are permanently rejected.

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

Example: A Klaviyo campaign sends 100k emails; Klaviyo’s MTA resolves each recipient’s MX record, connects with TLS, and delivers; for Gmail addresses that return a 421 (too many connections), the MTA retries after a few minutes automatically — no action needed from the store owner.

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

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.

MTA-STS

Mail Transfer Agent Strict Transport Security. 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.

Domain owners publish a policy (via HTTPS at mta-sts.<domain>/.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 ensures emails sent to your domain are always encrypted in transit, protecting your customers’ data. For most e-commerce brands, this is configured by your email host or IT team — but awareness matters since some providers reject mail that fails MTA-STS enforcement.

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

Example: A customer’s email server has MTA-STS enabled; when your ESP tries to deliver to that address, it checks the MTA-STS policy, verifies TLS, and delivers securely — or fails delivery if TLS cannot be established, rather than falling back to an unencrypted connection.

Related terms: TLS, TLS-RPT, SMTP, MX record, MTA

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. Publish TLS-RPT alongside the policy, or a broken certificate will silently block inbound mail with no signal to you.

MX record

The DNS record that names the mail servers accepting mail for a domain. Receiving infrastructure is chosen by MX lookup; sending authentication is unrelated to it.

Related terms: MTA, SMTP, DNS propagation

Infrastructure

N

Neutral trap

A recycled or parked address that neither converts nor complains but silently absorbs volume, dragging engagement rates down without an obvious signal.

Related terms: Spam trap, List hygiene, Engagement rate

List Management

O

One-click unsubscribe

The requirement that marketing email from bulk senders can be unsubscribed in a single action from the mail client, with no confirmation page, login, or preference form in between.

Mechanically this is the List-Unsubscribe header pair, specified in RFC 8058. See that entry for the headers, the endpoint behaviour, and the two-day processing obligation.

Compliance List Management

Open tracking

Recording an “open” by embedding a 1x1 tracking pixel in the email: when the image loads, the sender logs the request. Also called pixel tracking — the pixel is the mechanism, open tracking is the practice built on it.

Each recipient or campaign gets a unique image URL. Whatever loads that URL is counted as an open, which is why the number was never a count of people reading your email: image blocking hides real opens, and image proxying and prefetch invent ones that never happened.

Why it matters: Open rate is how Klaviyo, Omnisend, and Mailchimp report engagement, and Apple MPP alone inflates it for every Apple Mail subscriber you have. Segments built on opens, flows triggered by opens, and benchmarks measured in opens all inherit that inflation. Bot Finder separates proxy and scanner opens from human ones so the number means something again.

Technical details: <img src="https://track.domain.com/pixel/xxx" width="1" height="1" />, usually a transparent GIF; the server logs the GET request and may set a cookie. The request can come from the subscriber’s client, from a privacy proxy, or from a security scanner — the log looks the same either way.

Example: A Shopify store’s Klaviyo campaign reports a 52% open rate. Bot Finder shows half those opens fired from Apple proxy IPs within two minutes of delivery, before anyone could have read the email. True human open rate: 22%.

Analytics

Edge cases: Image blocking suppresses the load entirely, so a real read goes unrecorded. Re-opens and forwards load the pixel again and overcount. Proxies and prefetchers load it without a human present.

P

Phishing detection

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

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 emails impersonating your brand damage customer trust and, if widespread, can hurt your domain reputation with mailbox providers as spam reports pile up. Setting DMARC to p=reject prevents phishers from spoofing your exact From domain, and BIMI provides a visible trust signal that helps customers identify genuine emails from your store.

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: Scammers send fake “account security” emails impersonating a Shopify brand; because the brand has DMARC at p=reject, Gmail and Yahoo reject any emails that fail DMARC alignment — protecting customers from the phishing attempt and the brand’s reputation from associated spam complaints.

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

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.

Pixel tracking

The 1x1 image embedded in an email whose load is recorded as an open — the mechanism behind open tracking, where the signal, its blind spots, and what inflates it are covered in full.

Analytics

Policy enforcement

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.

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: A DMARC policy of p=none means you’re monitoring but not protecting — phishers can still impersonate your brand’s domain and reach inboxes. For Shopify brands, moving to p=quarantine and then p=reject is essential for brand protection and a prerequisite for BIMI. Use the pct= parameter to roll out enforcement gradually and catch any authentication gaps.

Technical details: RFC 7489. Receiver fetches _dmarc.<domain>, 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: A DTC brand moves from DMARC p=none to p=quarantine at pct=10 (10% of failing mail quarantined); after reviewing DMARC reports to confirm all legitimate sending is authenticated, they increase to pct=100; then move to p=reject — completely blocking spoofed emails from reaching any inbox.

Related terms: DMARC, Alignment, BIMI, Quarantine

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.

Preference center

A hosted page where subscribers choose what they receive and how often, instead of facing a single choice between all of your email and none of it.

Typical controls are topic or brand selection, frequency, and a pause option. It is reached from a footer link, and it is where an unsubscribe click can land once the mandatory one-click unsubscribe path already exists separately.

Why it matters: A subscriber who is tired of three emails a week does not want to leave, they want fewer emails. Without that option their only lever is unsubscribe, or worse, Report spam. A preference center converts some of those departures into reduced frequency, which keeps the address on the list and keeps complaint rate down.

Technical details: A hosted page keyed to a subscriber identifier, writing back to list or segment membership in the ESP. It must not be presented as the one-click unsubscribe endpoint, which has to unsubscribe on a single POST without an intermediate page.

Example: A Shopify brand sends four campaigns a week. Adding a “one email a week” option to the footer link moves roughly a fifth of would-be unsubscribers onto the reduced cadence, keeping them on the list through the next peak season.

List Management Email Marketing

Edge cases: Using a preference center as the one-click endpoint fails the bulk sender requirement. Subscribers who reduce frequency but never engage still need a sunset policy. Requiring a login to change preferences defeats the purpose.

Prefetching

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.

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 by Apple MPP, Gmail Image Proxy, and corporate security tools is the primary source of inflated open and click rates for e-commerce brands. If you’re using Klaviyo open or click data to trigger flows, build segments, or measure campaign performance, unfiltered prefetch traffic skews everything. Bot Finder separates prefetch events from real subscriber engagement.

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: A Shopify brand’s email is delivered to 30k Apple Mail users; Apple MPP prefetches all images and links within 2 minutes of delivery; the brand sees a spike of 30k apparent opens and thousands of “clicks” instantly; Bot Finder flags all prefetch events as bot activity.

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.

Proofpoint click scanning

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.

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: If your Shopify brand sells to enterprise customers or businesses, a large portion of your click data may be Proofpoint scanner activity — not real buyer interest. Proofpoint-inflated CTR makes B2B email performance look better than it is and can trigger Klaviyo flows for buyers who never clicked.

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

Example: A DTC brand sends a wholesale invitation to 10k B2B prospects; 2k are behind Proofpoint; Proofpoint prefetches all links and the brand sees 2k apparent “clicks” within seconds of delivery from a handful of Proofpoint IPs; Bot Finder flags them all as bots, revealing 340 real human clicks.

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.

PTR record

A DNS record that maps a sending IP address back to a hostname, giving receivers a reverse lookup to check against the forward lookup of that hostname.

When the hostname a PTR returns resolves back to the same IP, the pair is forward-confirmed. Receivers treat a sending IP with no PTR, or with a generic ISP-assigned one, as a strong spam signal.

Why it matters: Valid reverse DNS is a named requirement in the Gmail, Yahoo, and Microsoft bulk sender rules, not a nicety. For most e-commerce brands the ESP owns the sending IPs and handles this, but it becomes yours the moment you move to a dedicated IP or send from your own infrastructure, and a missing PTR there will sink delivery before any content is examined.

Technical details: A PTR record in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone, published by whoever controls the IP allocation, usually the hosting provider or ESP rather than you. Forward-confirmed reverse DNS requires the PTR hostname’s A or AAAA record to resolve back to the original IP.

Example: A brand moves to a dedicated IP with their ESP. The PTR is set to a hostname on the ESP’s domain that resolves back to the same IP, so forward-confirmed reverse DNS passes and Gmail accepts the connection on the first send.

Related terms: Bulk sender requirements, IP reputation, Dedicated IP, MX record, SMTP

Infrastructure Authentication

Edge cases: Only the IP allocation holder can publish a PTR, so you cannot fix this in your own DNS. Generic provider-assigned hostnames satisfy the lookup but still read as low-trust. IPv6 senders need an ip6.arpa PTR as well, and it is more often missing.

Q

Quarantine

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.

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: When DMARC policy quarantines a message, it lands in the spam or junk folder instead of the inbox — effectively invisible to most customers. For Shopify brands, quarantined emails mean lost revenue from promotions and automations. Fix authentication, reputation, and list hygiene to recover inbox placement.

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

Example: A Shopify brand’s DMARC policy is p=quarantine; a phisher spoofing their domain has their message quarantined to the spam folder by Gmail rather than rejected — better than reaching inboxes, but upgrading to p=reject prevents spoofed emails entirely.

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

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.

Queueing

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

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: Your ESP’s message queue is the safety net that ensures emails are eventually delivered even when there are temporary failures. For Shopify brands, this is largely invisible — but it means time-sensitive emails like abandoned cart sequences may arrive a few minutes later than expected if the recipient’s mail server is temporarily busy.

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: Klaviyo sends an abandoned cart email; the recipient’s mail server returns a 451 temporary error; Klaviyo queues the message and retries 10 minutes later; the second attempt succeeds and the subscriber receives the cart reminder — slightly delayed but delivered.

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

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.

R

Rate limiting

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

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: If you send too many emails too fast to a mailbox provider — especially from a new or low-reputation IP — they will rate limit you, deferring delivery or rejecting the excess. For Shopify brands planning large campaigns (like Black Friday sends to 500k+), warming up properly and spreading sends over time avoids rate limit issues.

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: A Shopify brand sends a 100k Black Friday campaign in one burst from a new dedicated IP; Gmail rate-limits them after the first 5k, returning 421 errors for the remainder; Klaviyo retries over the next few hours, but the campaign’s time-sensitivity is lost. A proper warmup would have established sufficient sending rate for the volume.

Related terms: Throttling, Warmup, Retry logic, MTA

Infrastructure Deliverability

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

Reputation filtering

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

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 filtering is how Gmail and Yahoo decide whether to deliver your emails to the inbox or spam — and it’s cumulative. Every campaign you send affects your reputation. For Shopify brands, protecting reputation means keeping complaint rates low, maintaining good list hygiene, and sending to engaged subscribers rather than broad unsegmented blasts.

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 Shopify brand consistently sends to engaged subscribers with sub-0.05% complaint rates and full authentication; Gmail places their campaigns in Primary. When they send a one-off blast to their full unengaged list, complaint rate spikes and Gmail starts filtering subsequent campaigns to spam.

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.

Retry logic

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

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: Retry logic is what your ESP (Klaviyo, Omnisend) uses to handle temporary delivery failures — so greylisting and temporary server errors result in delayed delivery rather than bounces. For store owners, this works automatically in the background; the key is knowing that some transactional emails (order confirmations, shipping notifications) may have a short delay due to retries.

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

Example: A Shopify order confirmation email hits a greylisting server on first attempt and receives a 451 temporary error; Klaviyo’s MTA retries 5 minutes later; the second attempt is accepted and the customer receives their confirmation email — slightly delayed but not lost.

Related terms: Greylisting, Queueing, MTA, Soft bounce

Infrastructure

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

Return-Path

The envelope sender address a receiving server uses for bounces, and the domain SPF is checked against. It is distinct from the From address a subscriber sees.

Also called the envelope sender, bounce address, or MAIL FROM. ESPs normally set it to their own bounce-handling domain, which is why alignment between Return-Path and From matters for DMARC.

Why it matters: This is the source of the most common authentication surprise in e-commerce email: SPF passes, DKIM passes, and DMARC still fails. SPF is validated against the Return-Path domain, so if your ESP’s bounce domain does not align with your From domain, SPF contributes nothing to DMARC and you are relying on DKIM alone.

Technical details: Set in the SMTP MAIL FROM command and written to the Return-Path header on delivery. SPF is evaluated against its domain. DMARC requires either SPF alignment with the From domain or DKIM alignment; ESP-owned bounce domains usually provide the latter only, unless you configure a custom bounce subdomain.

Example: A Shopify brand sends from hello@yourbrand.com while their ESP uses its own bounce domain as Return-Path. SPF passes for the ESP’s domain but is not aligned, so DMARC rests entirely on DKIM. Configuring a custom bounce subdomain such as bounce.yourbrand.com brings SPF into alignment too.

Related terms: SPF, Alignment, DMARC, Bounce processing, Subdomain delegation, Forwarding

Authentication Infrastructure

Edge cases: Forwarding rewrites Return-Path, which is why SPF breaks across forwarders and ARC exists. An empty Return-Path (<>) marks a bounce message itself and must not be replied to. Some gateways rewrite it in ways that break alignment silently.

Risk zone

Yahoo’s classification of a sending program’s complaint rate standing — Normal, Warning, or Enforcement — used in Yahoo Sender Hub to indicate how close the sender is to throttling or blocking.

Yahoo assigns a risk zone to each sending domain based on its complaint rate among Yahoo and AOL users. The three zones are: Normal (complaint rate below 0.10%, program in good standing), Warning (complaint rate at or above 0.10%, action required), and Enforcement (complaint rate approaching or exceeding the enforcement threshold, where Yahoo may throttle, bulk, or block mail). Zone data is available via Yahoo Sender Hub and surfaced in InboxEagle when the integration is connected.

Why it matters: Yahoo’s risk zone is the earliest warning sign before complaint rates affect delivery. For Shopify brands with significant Yahoo or AOL subscriber bases, moving from Normal to Warning typically precedes inbox placement degradation by 24–72 hours. Monitoring zone changes allows you to act before customers stop receiving emails.

Technical details: Data available via Yahoo Sender Hub (sender.yahoo.com). Complaint rate is computed as spam-marked messages divided by delivered messages to Yahoo/AOL. Threshold values: 0.10% = warning threshold; higher thresholds apply to enforcement actions (not publicly disclosed).

Example: A brand’s Yahoo Sender Hub risk zone changes from Normal to Warning on a Monday; InboxEagle fires an alert; the brand pauses sends to unengaged Yahoo/AOL segments and suppresses 12k low-engagement contacts; by Thursday, complaint rate drops below 0.10% and the zone returns to Normal — without any delivery disruption.

Related terms: Yahoo Sender Hub, Complaint rate, Feedback loop

Reputation

Edge cases: Yahoo’s exact enforcement thresholds are not publicly disclosed. The zone can change within 24 hours of a high-complaint campaign. Low-volume senders may see less frequent zone updates due to data thresholds.

S

Sandbox click

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.

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 from security systems like Proofpoint inflate your click-through rates, making campaigns appear more successful than they are. For e-commerce brands using click data for A/B testing, attribution, or Klaviyo flow triggers, sandbox traffic distorts results and leads to poor decisions.

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: A campaign email is delivered to a corporate recipient; Proofpoint’s sandbox loads all 8 tracked links within 90 seconds of delivery; InboxEagle Bot Finder classifies all 8 as bot clicks from a known Proofpoint IP range — keeping click attribution clean.

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.

Security scanner

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

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: Security scanners are a major source of inflated email metrics, especially if you send to business email addresses. For Shopify brands with wholesale, B2B, or DTC customers on corporate email, scanner-generated clicks can dwarf real customer engagement — making your reported CTR meaningless without filtering.

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: A DTC brand runs a wholesale offer campaign to 5k B2B buyers; 40% are behind corporate security scanners; the scanners generate 2k “clicks” within seconds of delivery; after InboxEagle Bot Finder filtering, the true human CTR is 1.8% — still a meaningful result, but very different from the raw 42% reported.

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.

Seed list

A set of real mailboxes across multiple email providers maintained by a deliverability monitoring service, used to test where emails land (inbox, promotions, or spam) before or after sending.

A seed list consists of actual email accounts at providers including Gmail, Outlook, Yahoo, AOL, Apple Mail, and others. When a sender sends their campaign to the seed addresses using the same sending infrastructure as production, the monitoring service checks each mailbox and reports the placement per provider. Results typically return in under 5 minutes. InboxEagle’s seed list covers 20+ providers for comprehensive placement testing.

Why it matters: Seed list testing is the only way to check inbox placement before a campaign reaches real subscribers. For e-commerce brands, running a seed test before Black Friday or a major product launch means catching a spam folder problem when you still have time to fix it — not after 100,000 emails have already landed in spam. It is also useful after any authentication change (new DKIM key, updated DMARC policy) to confirm the change improved placement.

Technical details: Seed mailboxes are real accounts, not simulated environments. Test results are only as accurate as the sending infrastructure used — always send to seeds using the same IP, domain, and configuration set as production. Volume sent to seeds is small (one email per seed address), so it does not affect reputation.

Example: A Shopify brand runs a seed test before their summer sale campaign; InboxEagle reports 91% Gmail inbox, 87% Yahoo inbox, 0% spam across both providers; the test also shows 100% DKIM and DMARC pass at every provider — confirming the campaign is ready to send to the full list.

Deliverability Testing

Edge cases: A passing seed test does not guarantee passing placement for all real subscribers — domain/IP reputation from past sends still matters. Seed results represent a single point in time; ongoing placement data captures trends.

Seed testing

Sending a campaign to a panel of monitored inboxes across providers to see where it lands before or during the real send.

Related terms: Seed list, Inbox placement test, Inbox placement

Deliverability

Sending domain

The domain that appears in the From address and carries your authentication records. Deliverability is judged per sending domain, so a dedicated subdomain (for example mail.yourbrand.com) keeps marketing reputation separate from transactional and corporate mail.

Why it matters: This is the single structural decision that most affects how much a bad campaign can cost you. Send marketing from your root domain and one complaint-heavy send drags down order confirmations, password resets, and the mail your staff send to customers. Send it from a subdomain and the damage stays where it happened.

Technical details: Needs its own SPF record, DKIM selector, and Return-Path alignment. A subdomain inherits the organizational domain’s DMARC policy unless it publishes its own, and it builds reputation separately from the parent, which means it starts from nothing and needs warmup.

Example: A Shopify brand moves Klaviyo campaigns to mail.yourbrand.com while order confirmations keep sending from yourbrand.com. A later re-engagement send damages the marketing subdomain’s reputation; transactional mail keeps landing in the inbox throughout.

Authentication Infrastructure

Edge cases: A brand-new subdomain has no reputation at all, so moving established volume onto one overnight looks like a sudden unknown sender. Splitting too finely spreads volume so thin that no subdomain earns a reputation.

SMTP

Simple Mail Transfer Protocol. The standard protocol used for sending and relaying email between servers (MTAs) and for client-to-server submission.

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 protocol your ESP uses to deliver every email you send. For Shopify brands, SMTP works invisibly in the background via Klaviyo or Omnisend — but understanding it helps when interpreting bounce error codes, diagnosing delivery failures, and understanding why some emails retry while others are permanently rejected.

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: When Klaviyo sends a campaign email for your Shopify store, it uses SMTP to connect to Gmail’s mail servers, negotiates TLS encryption, sends the message, and receives a 250 OK confirmation — all automatically, with bounce codes returned for any addresses that fail.

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

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.

Soft bounce

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

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: Soft bounces represent temporary delivery failures and usually resolve on retry — so most ESPs (Klaviyo, Omnisend) automatically retry soft bounced emails. However, an unusually high soft bounce rate can signal sending volume problems, IP reputation issues, or a bloated list with many inactive addresses worth investigating.

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: A Shopify brand’s cart recovery email soft bounces for a subscriber whose inbox is full (452 error); Klaviyo retries for up to 3 days; if the mailbox stays full, the address is treated as a long-term soft bounce and deprioritised — protecting sender reputation while still attempting delivery.

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

Infrastructure Deliverability

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

Spam folder

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

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: When your welcome series, abandoned cart flows, or flash sale promotions land in spam, customers don’t see them and you lose that revenue. Monitoring placement by mailbox provider — via InboxEagle or Google Postmaster Tools — is the first step to diagnosing and fixing the problem.

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: A Shopify brand’s DMARC is set to p=none with no enforcement; spoofed messages from phishers and some legitimate marketing mail both land in Gmail Spam; after tightening DMARC to p=quarantine and cleaning their list, the majority of emails move to Primary.

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.

Spam rate

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

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 most powerful levers on your deliverability. For Shopify brands, Google Postmaster Tools reports your spam rate at Gmail — the metric Google actually uses to decide inbox vs. spam. Keeping it below 0.10% is the target and 0.30% is the ceiling, both published in the Gmail and Yahoo bulk sender requirements; at or above the ceiling your domain is treated as ineligible for delivery. Microsoft applies its own thresholds to Outlook, Hotmail, and Live, visible through SNDS.

Technical details: Measured by providers from user “Report spam” actions. Gmail Postmaster shows spam rate in UI, and a Feedback-ID header splits that one number out per campaign or flow. FBL reports give per-message complaint data for processing, though Gmail provides no per-message FBL to ordinary senders.

Example: A Shopify brand’s Gmail spam rate stays at 0.02% with well-segmented sends; after sending a broad discount campaign to their entire inactive list, spam rate spikes to 0.22%; the following week’s abandoned cart and promotional emails are throttled by Gmail until the rate recovers over several sends.

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.

Spam trap

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.

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: Hitting a spam trap is one of the fastest ways to destroy your sender reputation and land on a blocklist like Spamhaus. For Shopify brands, the most common cause is importing old customer lists, purchased contacts, or scraped email addresses. Double opt-in and regular list hygiene are the best defences.

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 Shopify brand purchases a list of “potential customers” from a data broker; the list contains a Spamhaus recycled spam trap; after sending a welcome campaign, the brand’s sending IP is listed on Spamhaus and Gmail starts rejecting all their emails — including automated abandoned cart flows.

Related terms: Blocklist, List hygiene, Domain reputation, Double opt-in

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.

SpamAssassin

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

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 smaller mailbox providers and hosting companies use SpamAssassin or similar rule-based scoring. For Shopify brands, this means your promotional copy, HTML structure, and link patterns contribute to a spam score that determines inbox or spam placement. Testing campaigns with tools like Mail-Tester before sending can catch high-scoring patterns.

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: A Shopify brand tests their sale email on Mail-Tester; “FREE” in the subject scores +2, “Click Here” button text scores +1.5, but valid DKIM gives -1; total score is 2.5 out of 5.0 — inbox safe. Adding “Limited time!” and a shortened URL would push the score over the threshold.

Anti-Spam

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

SPF

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

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 a foundational authentication method required by DMARC. Missing or incorrect SPF leads to emails landing in spam or being rejected outright. If you send through Klaviyo, Omnisend, or Shopify Email, you must include their mail servers in your SPF record for authentication to pass.

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: A Shopify store using Klaviyo adds include:email.klaviyo.com to their SPF DNS record; emails sent via Klaviyo now pass SPF, reducing spam folder placement at Gmail and Yahoo.

Related terms: DKIM, DMARC, Alignment, Subdomain delegation

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.

Spoofing

Forging the From address of a domain you do not own. DMARC at enforcement is what stops spoofed mail from reaching inboxes under your brand.

Authentication Security

Subdomain delegation

Pointing a subdomain’s DNS at a sending platform so it can publish its own SPF, DKIM, and tracking records. It isolates the reputation of that mail stream from your root domain.

Related terms: Sending domain, DNS propagation, Alignment

Authentication

Subscriber acquisition source

Where an address on your list came from, and the record of how and when it was collected.

Sources range from a checkout opt-in or a signup form with double opt-in, through pop-ups and giveaways, to purchased or scraped lists. Providers do not see the source directly, but they see its consequences in engagement and complaints.

Why it matters: Nearly every serious deliverability problem traces back to acquisition rather than to content or authentication. Contest and giveaway addresses complain at rates that ordinary campaigns never reach, and purchased lists are how spam traps get onto a list in the first place. Keeping the source on every record means that when reputation drops you can isolate the cohort responsible instead of sunsetting your whole list.

Technical details: Stored as a profile property in the ESP, ideally with timestamp, IP, and the form or page identifier. It supports segmenting reporting by cohort and is the evidence trail if a provider or blocklist operator asks how consent was obtained.

Example: A Shopify brand’s complaint rate rises after a giveaway. Because every profile carries its source, they segment reporting by cohort, confirm the giveaway addresses complain at roughly ten times the rate of checkout opt-ins, and suppress that cohort rather than cutting send volume across the board.

List Management Reputation

Edge cases: Imported lists often arrive with no source data, which makes the oldest and riskiest cohort the hardest to isolate. Co-registration and partner lists rarely carry usable consent evidence. Source alone does not prove consent without the timestamp and form record alongside it.

Sunset policy

A rule that stops sending to subscribers after a defined period of no engagement, rather than mailing the whole list indefinitely.

Why it matters: Under engagement-based filtering a dormant segment is not neutral, it is actively teaching Gmail that your mail is unwanted, and that verdict spreads to the subscribers who do want it. A sunset policy is how you stop paying reputation for addresses that stopped reading, and it usually costs less revenue than brands fear because dormant subscribers were not buying either.

Technical details: Commonly expressed as no open or click in 90 to 180 days, adjusted for purchase cycle: a brand people buy from twice a year needs a longer window than a weekly consumables brand. Enforced by moving profiles to a suppression list after a final win-back attempt.

Example: A Shopify brand sunsets subscribers with no engagement in 120 days, suppressing 22,000 of 90,000 profiles after one win-back send. Total opens fall, spam rate drops below 0.05%, and revenue per campaign rises because the remaining sends reach the inbox.

List Management Deliverability

Edge cases: Open-based sunsetting misreads MPP traffic as engagement and keeps dormant Apple Mail subscribers alive, which is why click-based windows are safer. Offer a preference center before suppressing; some subscribers want less, not nothing.

Suppression list

A list of email addresses that an ESP will not send to, regardless of which campaigns or flows are active — typically composed of unsubscribers, hard bounces, and manually added contacts.

A suppression list is the definitive opt-out and exclude list maintained in your ESP. When a contact is on the suppression list, no campaign, automation, or flow will email them. Suppression lists are populated by: unsubscribe requests (required by CAN-SPAM/GDPR), hard bounces, spam complaints (via FBL), and manual additions from deliverability tools like InboxEagle’s cost optimization tool.

Why it matters: Maintaining a clean suppression list is fundamental to deliverability and legal compliance. Sending to unsubscribed contacts violates CAN-SPAM and GDPR. Sending to hard-bounced addresses inflates bounce rates and harms reputation. For Shopify brands, Klaviyo manages suppression automatically for unsubscribes and hard bounces — but proactively suppressing unengaged contacts via InboxEagle cost optimization protects both deliverability and budget.

Technical details: ESP-specific implementation; usually a centralized list checked before each send. In Klaviyo, suppressed profiles are in the Suppressions section and are not counted against your billable contact limit if suppressed for spam complaints. Upload via CSV or API. Cross-account suppression requires exporting and re-importing lists.

Example: A Shopify brand exports 18k unengaged contacts identified by InboxEagle cost optimization and uploads them to Klaviyo’s suppression list; next month’s Gmail inbox rate improves from 76% to 84% because the list now reflects a higher proportion of genuinely engaged subscribers.

List Management Compliance

Edge cases: One-click unsubscribe requests must be processed within two days under RFC 8058, which is far tighter than the ten-day window CAN-SPAM allows and is the deadline that actually applies to bulk senders. Suppressed contacts should be retained for compliance records (GDPR subject access requests). Re-importing suppressed addresses from an old backup is a common mistake that triggers spam complaints. Some ESPs distinguish between global suppression (all emails) and list-level suppression.

T

Throttling

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.

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 delays your campaigns and can make time-sensitive promotions (flash sales, limited-time offers) arrive after the window closes. For Shopify brands, throttling is most common when sending large volumes from a new or low-reputation IP — the solution is proper warmup and gradual volume scaling.

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: A Shopify brand launches a flash sale email to 200k subscribers from a new sending IP; Gmail throttles them after the first 8k, returning 421 errors; the remaining 192k emails are delayed by hours, missing the peak sale window entirely — the direct cost of skipping the warmup process.

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

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.

Time-to-click analysis

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).

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 one of the most reliable signals for distinguishing real customer clicks from security scanner activity. Real customers take minutes to hours to click after receiving an email; bots click within seconds. For Shopify brands, this signal is central to how InboxEagle Bot Finder filters your click data to reveal true engagement.

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: InboxEagle Bot Finder analyses a Shopify brand’s campaign: 80% of clicks from Proofpoint IPs arrive within 8 seconds of delivery; real customer clicks have a median time-to-click of 18 minutes; clicks under 10 seconds from known scanner IPs are labelled BOT, dramatically cleaning the CTR metric.

Related terms: Bot click, Prefetching, Human click verification, Bot filtering

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.

TLS

Transport Layer Security. 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.

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: TLS ensures emails are encrypted in transit between servers, protecting your customers’ data, and transmitting over TLS is a named requirement in the Gmail, Yahoo, and Microsoft bulk sender rules rather than a nicety. For Shopify brands, TLS is handled automatically by your ESP. However, if a recipient’s server enforces MTA-STS and TLS fails, your emails may be rejected rather than delivered unencrypted — an increasingly common scenario as security standards rise.

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: Klaviyo delivers a transactional email for a Shopify store; it connects to the recipient’s mail server, initiates STARTTLS, and completes a TLS handshake; all email content (including order details) travels encrypted between servers — automatically protecting customer data.

Related terms: MTA-STS, TLS-RPT, SMTP, Encryption, Bulk sender requirements

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.

TLS-RPT

SMTP TLS Reporting. A standard that asks sending servers to send you daily reports on whether their encrypted connections to your domain succeeded or failed.

You publish a DNS TXT record naming a reporting address; senders that support the standard deliver JSON summaries of successful and failed TLS negotiations, including MTA-STS policy failures.

Why it matters: MTA-STS tells senders to require encryption when delivering to you, but on its own it gives you no way to know whether that is working. TLS-RPT is the feedback half. Publishing MTA-STS without it means a misconfigured certificate or an unreachable policy file can block inbound mail with no signal to you at all.

Technical details: RFC 8460. TXT record at _smtp._tls.<domain> with v=TLSRPTv1; rua=mailto:... or an HTTPS endpoint. Reports arrive daily as JSON, usually gzipped, summarising session counts and failure types per sending source.

Example: A brand enforcing MTA-STS renews a certificate and the new chain is incomplete. TLS-RPT reports show a spike in validation failures from several senders within a day, well before anyone notices missing inbound mail.

Related terms: MTA-STS, TLS, Encryption, MX record, DMARC aggregate report

Infrastructure Security

Edge cases: TLS-RPT covers mail sent to your domain, not mail you send. Not every sender implements it, so reports are a sample. Report volume is low enough that a dedicated mailbox is easier than filtering them out of a shared one.

U

Unauthorized sender

A sending source (IP address or domain) that sends email claiming your From domain but is not authorized by your SPF record or signed with your DKIM key.

Unauthorized senders appear in DMARC aggregate reports as sources that fail DMARC alignment. They fall into three categories: (1) legitimate services you use but forgot to authorize (a CRM, transactional service, or old ESP), (2) spoofing attempts by phishers or spammers abusing your domain, and (3) compromised third-party accounts sending in your name. InboxEagle’s DMARC monitoring dashboard surfaces unauthorized senders automatically once aggregate reports are flowing.

Why it matters: Unauthorized senders directly damage your domain reputation with every message they send. A phisher sending spam impersonating your brand generates spam complaints attributed to your domain, harms your deliverability, and erodes subscriber trust. Enforcing DMARC (p=reject) causes mailbox providers to reject unauthorized mail outright — but only after you have confirmed all legitimate senders are authorized.

Technical details: Identified via DMARC aggregate report data: source IPs with DMARC fail disposition. Compare IP against your SPF record and DKIM selectors. Use tools like MXToolbox or your ESP’s sending IP documentation to identify legitimate sources.

Example: A Shopify brand receives DMARC reports showing an unknown IP in Singapore sending 2,000 emails per day claiming their domain; the DMARC policy is at p=none so these emails are being delivered; after moving to p=reject, the unauthorized source’s messages are rejected by Gmail and Yahoo — stopping the spam campaign and protecting the brand’s reputation.

Related terms: DMARC aggregate report, DMARC, SPF, DKIM, Alignment

Authentication Security

Edge cases: Legitimate senders sending cross-domain mail (e.g., a subsidiary sending from your brand domain via their own ESP) appear as unauthorized until authorized. Some sending sources are impossible to identify — if unrecognized, assume they should be rejected.

Unsubscribe rate

The share of delivered mail that results in an opt-out. A rising unsubscribe rate is an early warning that complaint rate and placement are about to follow.

Since one-click unsubscribe became mandatory for bulk senders, a growing share of opt-outs happen through the mail client’s own button rather than your footer link, so the rate you see in your ESP now depends on whether it records those header-driven unsubscribes alongside footer ones.

Why it matters: An unsubscribe is the cheap outcome and a spam complaint is the expensive one. The same tired subscriber produces one or the other, and the difference is largely whether leaving was easy. A campaign whose unsubscribe rate doubles has told you something is wrong while your domain reputation is still intact; if you read that as a problem to suppress rather than a warning to act on, the next signal you get is complaint rate.

Technical details: Unsubscribes divided by delivered, per campaign or per flow. Rates vary far more by send type than by brand, so compare a campaign against the same campaign last month rather than against a published benchmark. Requests arriving via List-Unsubscribe-Post must be honoured within two days.

Example: A Shopify brand’s weekly campaign normally unsubscribes at 0.15%. A send to a two-year-old segment comes back at 0.9%, with complaint rate still normal. They stop the remaining batches; the following week’s campaigns are unaffected, which would not have been true had they waited for the complaint rate to move.

List Management Analytics

Edge cases: Some ESPs count only footer unsubscribes, understating the true rate now that clients surface their own button. A very low unsubscribe rate alongside a rising complaint rate usually means leaving is too hard, not that subscribers are happy.

URL reputation

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.

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: The URLs in your emails — your Shopify store links, tracking redirects, and any third-party URLs — are checked by spam filters and security tools. Using URL shorteners, newly registered domains, or redirect chains that obscure the destination can trigger spam filtering even if your authentication is perfect. Always link directly to your verified store domain.

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: A Shopify brand uses a third-party discount aggregator link in a campaign; the aggregator domain has poor URL reputation from past spam reports; Gmail routes the campaign to spam despite clean authentication; replacing the link with a direct URL to their store fixes the issue.

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.

User-agent fingerprinting

Reading the User-Agent header — and the other headers that travel with it — on an open or click request to judge what kind of client made it.

Every pixel load and link click carries a UA string. Real clients announce themselves as browsers or mail apps; scanners and prefetchers often announce themselves plainly (“Proofpoint URL Defense”), use a bare HTTP-client string, or send a header set no browser would produce — a UA claiming Chrome with no Accept-Language, for instance.

Why it matters: It is the cheapest signal available and the first one worth checking, because a large share of automated traffic never bothers to hide. It is also the weakest on its own: a UA is a string the client chooses, so nothing stops it from being wrong. In Bot Finder it is one input among several, which is why no configuration is asked of you for it.

Technical details: HTTP User-Agent, read alongside Accept, Accept-Language, and TLS characteristics; matched against known-bot patterns and checked for internal consistency.

Example: Two requests claim to be Chrome on macOS. One sends the full header set a browser sends and resolves to a residential IP; the other sends the UA alone from a data-centre range. The header matched, the fingerprint did not — only the first is counted as a human click.

Bot Detection

Edge cases: A UA can be spoofed outright, so it can never carry a verdict alone. Embedded clients, in-app browsers, and older mail apps send strings that look nothing like a browser without being bots. Scanner vendors change their UA between releases, so pattern lists go stale.

V

VMC

Verified Mark Certificate. 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.

BIMI allows senders to specify a logo URL in DNS, and receivers that display logos require it to be backed by a certificate. The VMC is issued after the CA verifies the brand’s registered trademark and identity. Gmail and Yahoo also accept a CMC, which needs no trademark; Apple Mail accepts a VMC only.

Why it matters: A VMC proves your brand’s right to the logo, and it is the only certificate Apple Mail will accept. Since Apple Mail is where a large share of consumer opens happen, the cheaper trademark-free CMC route leaves most of your audience still looking at a default avatar. The VMC adds cost, roughly $1,500 a year plus trademark registration if you do not already hold one, and it is what makes the logo appear everywhere rather than only at Gmail and Yahoo.

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: A Shopify brand completes DMARC p=reject, obtains a VMC from DigiCert with their trademarked logo, and publishes their BIMI DNS record; Gmail now shows their brand logo next to every campaign and automation email — increasing recognition and improving open rates for the brand’s subscriber list.

Related terms: CMC, BIMI, Domain impersonation, DMARC

Authentication

Edge cases: A VMC requires a registered trademark, which is months of lead time if you do not have one; CMC exists for that case but is not accepted by Apple Mail. Certificates expire and must be renewed, and an expired one removes the logo.

W

Warmup

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.

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: Switching email platforms (for example, moving to a new ESP or dedicated sending IP) without warming up is one of the most common mistakes e-commerce brands make — it causes bulk filtering or blocks that can take months to recover from.

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: A DTC brand moves to a dedicated sending IP for Klaviyo: week 1 sends 1k–5k/day to their most engaged subscribers (recent openers and buyers); week 2 increases to 20k/day; week 3+ scales to full list volume while monitoring reputation and placement in InboxEagle.

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

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.

X

X-headers

Non-standard email headers prefixed with X-, used by senders, ESPs, and filters to carry information the standard headers have no field for.

Common examples are X-Mailer identifying the sending software, ESP-specific campaign and message identifiers, and headers added by receiving filters to record their verdict, such as spam scores from SpamAssassin.

Why it matters: When a campaign lands in spam and you need to know why, the X-headers on the delivered copy are usually where the answer is. A gateway’s spam score, the rule that fired, and the ESP’s own campaign identifier are all there in the raw source, and reading them turns “it went to spam” into a specific cause you can fix.

Technical details: Any header beginning X- is by convention non-standard and ignored by systems that do not recognise it. Receivers commonly add their own on delivery; senders should treat inbound ones as untrusted since they can be forged upstream. They are not covered by DKIM signing unless explicitly listed in the signature’s h= tag.

Example: A Shopify brand’s campaign lands in a corporate spam folder. The raw source shows an X-Spam-Score above the gateway’s threshold and a rule name pointing at a shortened link domain, which they replace with a branded tracking domain on the next send.

Infrastructure Anti-Spam

Edge cases: X-headers added before your ESP saw the message can be spoofed, so never trust an inbound one for authentication. Some gateways strip them on relay, losing the filtering evidence. X-Mailer values are a weak fingerprinting signal filters do sometimes weigh.

Y

Yahoo Sender Hub

Yahoo’s postmaster tool for bulk senders, providing complaint rate data, risk zone classification, and enforcement threshold alerts for Yahoo and AOL email delivery.

Yahoo Sender Hub (sender.yahoo.com) is the Yahoo equivalent of Google Postmaster Tools. It gives email senders direct visibility into how Yahoo and AOL classify their sending program. The key metric is complaint rate — the percentage of Yahoo/AOL-delivered mail that recipients mark as spam. Yahoo groups senders into three risk zones (Normal, Warning, Enforcement) based on complaint rate, with the warning threshold at 0.10%. InboxEagle integrates with Yahoo Sender Hub to surface this data alongside Google Postmaster and overall placement metrics.

Why it matters: Yahoo and AOL together represent a significant share of consumer email addresses in the US. Without Yahoo Sender Hub data, a complaint rate problem at Yahoo is invisible until it causes delivery failures. For Shopify brands with large consumer lists, connecting Yahoo Sender Hub gives the same direct provider visibility for Yahoo that Google Postmaster Tools provides for Gmail — making complaint rate monitoring complete across both major consumer providers.

Technical details: Access at sender.yahoo.com; requires domain verification via DNS TXT record. Complaint rate is normalized against delivered mail to Yahoo/AOL addresses. Data is published approximately once per 24 hours. OAuth-based API access; InboxEagle connects via OAuth and displays data in the deliverability dashboard.

Example: A DTC brand’s Yahoo Sender Hub risk zone changes to Warning after a re-engagement campaign generates elevated complaints from Yahoo/AOL addresses; InboxEagle fires an alert within 1 minute of receiving the data; the brand pauses sends to their oldest Yahoo/AOL segments and the risk zone returns to Normal within 48 hours.

Authentication Reputation Integration

Edge cases: Yahoo Sender Hub requires minimum send volume to Yahoo/AOL addresses before generating complaint rate data. Very low-volume senders may see no data or persistent 0% rates. Domain verification must be completed at sender.yahoo.com before connecting to InboxEagle.

Yahoo sender reputation

Yahoo’s internal reputation score for a sending domain or IP, which determines inbox placement, promotions tab routing, or spam folder delivery at Yahoo and AOL.

Like Google, Yahoo maintains per-domain and per-IP reputation signals based on complaint rate, bounce rate, engagement, and authentication. Yahoo sender reputation is not publicly exposed as a numerical score, but it is reflected in placement outcomes (inbox vs. spam) and in the Yahoo Sender Hub risk zone. Maintaining a Normal risk zone and low complaint rate (below 0.10%) is the primary lever for good Yahoo sender reputation.

Why it matters: Yahoo and AOL together represent a large share of US consumer email. Poor Yahoo sender reputation leads to bulk or spam placement, directly reducing revenue from campaigns and automations. Unlike Google Postmaster’s four-tier domain reputation gauge, Yahoo’s signals are less granular — making complaint rate monitoring via Yahoo Sender Hub the most actionable proxy.

Related terms: Yahoo Sender Hub, Risk zone, Complaint rate, Domain reputation

Reputation

Z

Zero-day

A vulnerability or attack pattern with no existing signature or patch. Mail security gateways scan links and attachments aggressively to catch them, which is a common source of bot clicks.

Related terms: Security scanner, Automated link scanner, Sandbox click

Security

Put this into practice

Getting startedConnect a sending domain and see where your campaigns actually land.

Authenticate your sending domainSet up SPF, DKIM and DMARC step by step, including the alignment rules that trip most stores up.

Bot FinderSeparate bot opens and clicks from real subscriber engagement before they reach your reports and flows.

Start free trial