` element | **Required**. It should reflect the company name | | `` element | Recommended (accessibility) | | External links or references | Forbidden (other than declared XML namespaces) | | Scripts, animation, interactive elements | Forbidden | | `x=` and `y=` attributes on the `
`List-Unsubscribe: `
`List-Unsubscribe-Post: List-Unsubscribe=One-Click` | | Visible unsubscribe | A clearly visible unsubscribe link in the message body as well | | Honor unsubscribes | Process unsubscribe requests within **48 hours** | Details of one-click unsubscribe, from Google's FAQ: - It is required only for **marketing and promotional** messages. Transactional messages are excluded. - A `mailto:` `List-Unsubscribe` on its own does **not** meet the requirement, because RFC 8058 requires the HTTPS POST mechanism. - Other unsubscribe links in the message body do not have to be one-click. - One-click unsubscribe may remove the recipient from that specific mailing list only, not necessarily from all mail from the sender. ## Enforcement timeline | Date | What changed | |---|---| | **February 1, 2024** | The requirements take effect for senders to personal Gmail accounts. Bulk senders (5,000+/day) must authenticate with SPF, DKIM and DMARC, avoid unwanted mail, and make unsubscribing easy. Enforcement began as "gradual and progressive": first temporary errors on part of the non-compliant traffic, then rising rejection rates | | **June 1, 2024** | Deadline for senders that already include an unsubscribe link to add **one-click unsubscribe** to all commercial and promotional messages | | **June 2024** | Bulk senders with a user-reported spam rate **> 0.3%** become **ineligible for mitigation** (escalations to delivery support) | | **November 2025** | Gmail is "ramping up its enforcement on non-compliant traffic". Non-compliant messages meet disruptions, including **temporary and permanent rejections** | ### Mitigation eligibility Google's escalation (mitigation) form for bulk senders only helps senders who already comply: - A sender is ineligible while its user-reported spam rate is **> 0.3%**. - Eligibility returns once the spam rate stays **below 0.3% for 7 consecutive days**. - Full authentication (SPF, DKIM, DMARC) and a working one-click unsubscribe are prerequisites. - The spam rate and other Postmaster Tools data are calculated and updated **daily**. ## Non-compliance error codes Gmail reports failures to meet the guidelines with 4.7.x temporary errors (rate limiting), which escalate to 5.7.x permanent rejections. All Gmail SMTP errors carry the identifier `gsmtp` (and `gcdp` when a Workspace administrator's custom rule caused them). | Requirement failed | Temporary (rate-limited) | Permanent (blocked) | |---|---|---| | PTR or reverse DNS | 451-4.7.23 (also 421-4.7.0 "no PTR record") | 550-5.7.25 | | SPF or DKIM (unauthenticated) | 421-4.7.26 | 550-5.7.26 | | SPF failed | 421-4.7.27 | 550-5.7.27 | | DKIM failed | 421-4.7.30 | 550-5.7.30 | | No DMARC record | 421-4.7.40 | 550-5.7.40 | | From: not aligned with SPF or DKIM | 421-4.7.32 | 5.7.32 | | No TLS | 421-4.7.29 | 550-5.7.29 | | Unusual or unsolicited volume | 421-4.7.28 | 550-5.7.28 | | Suspicious SPF record entries | 451-4.7.24 | 550-5.7.24 | | IPv6 sending guidelines (PTR or authentication) | None | 550-5.7.1 "does not meet IPv6 sending guidelines" | The full list of errors, including format and reputation errors, is in [Gmail troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting). To recover from rate limiting (SMTP 4.7.28 quota errors): wait at least **10 minutes**, then resume with a **single connection**. If that works, add connections **one at a time**. If the single connection still fails, wait another 10 minutes. ## Sending-practice recommendations (non-binding but weighted) - Send from **consistent IP addresses**. Use different IP addresses for different types of message (for example, notifications and promotions), and consistent `From:` addresses for each category. See [Advanced IP segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation). - Increase volume **gradually**, at steady rates, and avoid bursts. See [IP warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up). - On **shared IP addresses**, every sender's activity affects the shared reputation. Monitor the IP address against blocklists and in Postmaster Tools. - Do not buy email lists, send unsolicited mail, or use opt-in forms with pre-checked boxes (regional law may prohibit them). - Monitor **affiliates** and drop any that send spam: "If your brand is associated with marketing spam, other messages sent by you might be marked as spam." ### Display name rules A sender's display name must identify only that sender, and reflect a consistent, clear and accurate identity. The display name must not contain subject-line text or message content ("URGENT REQUEST", "TIME IS RUNNING OUT"), deceptive emoji, the recipient's own name, or anything that imitates a threaded conversation (deception in the style of "Re:"). ## Compliance verification Use [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), in particular the **Compliance status dashboard**, to check each requirement, and the Spam Rate dashboard to track the thresholds of 0.10% and 0.30%. After a fix, changes in compliance status can take up to 7 days to appear. ## Related articles - [DMARC](https://emailmarketing.net/learn/authentication/dmarc), on SPF, DKIM, DMARC and alignment - [Yahoo sender requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements) - [Microsoft sender requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements) - [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools) # Gmail Filtering Internals > How Gmail actually decides placement — per-domain authenticated-sender reputation, ML/LLM spam and phishing classification, tabbed-inbox categorization, and the per-user personalization signals that make one-size diagnosis impossible. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/gmail-filtering-internals If your mail reaches the inbox for some Gmail users and the spam folder for others, the reason lies in how Gmail decides placement. The [Gmail sender requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements) tell you what Gmail checks. What follows is what Gmail does with the result. Two facts dominate, and they explain why Gmail deliverability resists one-size-fits-all diagnosis: 1. **Reputation is computed on the authenticated sending domain, not on the IP address.** This is the reverse of most receivers, which center reputation on IP addresses. Authentication is the prerequisite that makes a message possible to score at all. 2. **Placement is learned for each user.** The same message from the same sender can reach the inbox for one recipient and the spam folder for another, because Gmail lets a user's own history of reporting and marking override the sender's general reputation. There is no single answer to "am I reaching the inbox at Gmail?", only a distribution across recipients. This is documented rather than inferred, mainly from Google's own research (Taylor, CEAS 2006; Taylor, Fingal and Aberdeen, NIPS 2007) and from its help and blog pages. The 2006 paper describes a system from the beta period, and the mechanisms have since been rebuilt on machine learning (see [ML classification](#ml-spam-and-phishing-classification)). But the paper is the only place where Google has set out the logic of reputation concretely, and its principles still describe how the system behaves: scoring on the authenticated domain, self-correction through user votes, and a middle band handed to a statistical filter. Treat the formulas as illustrations of the model, not as the code that runs today. ## The authenticated-domain reputation model Source: **"Sender Reputation in a Large Webmail Service"**, by Bradley Taylor of Google, CEAS 2006 (Third Conference on Email and Anti-Spam). Gmail launched as a beta in April 2004, and the paper describes the reputation system built during that beta. ### Why the domain, not the IP Google rejected IP reputation as the primary key because the IP "is a crude form of authentication". The same sender may not always use the same IP. Because of forwarding, the connecting IP is not always the true sender. IP addresses in `Received` headers cannot be authenticated reliably. And when several domains share a set of IP addresses, one spamming domain "can ruin the reputation for all the other domains." Gmail therefore classifies mail by **who is sending (the authenticated domain)** rather than by **what the content is**. The paper noted Gmail as "the only one" of the major reputation systems that worked on the authenticated domain rather than the IP. These are the authentication methods used to establish the domain, and how they were distributed in the mail arriving at Gmail: | SPF authentication method | Share of SPF-authenticated mail | Mechanism | |---|---|---| | Plain SPF | 52% | A published SPF record | | Best-guess SPF | 38% | No SPF record, or a failing one: assume the mail is authenticated if the sending IP is in the same range as the domain's A or MX records, **or** if the reverse DNS name of the sending IP matches the domain claimed in the email | | PTR zone | 10% | If plain and best-guess SPF both fail, and the sender is a subdomain of the DNS zone of the PTR, treat the mail as if it came from the zone itself (for example, `subdomain.example.com` from an IP with the PTR `host.example.com`) | DomainKeys, the predecessor of DKIM, was the other signal. Gmail adopted it early, partly because SPF breaks under forwarding while a signature survives. Google's recommendation, then and now, is to **implement both**, so that if forwarding or changes to the message break one, the other still authenticates: "if both are present, it is that much stronger of an authentication signal." Authentication rates were very different for wanted and unwanted mail, so authentication is itself a reputation signal: | Method | Nonspam (wanted) | Spam (unwanted) | |---|---|---| | Both SPF and DomainKeys | 20% | 1.5% | | SPF only | 53% | 39% | | DomainKeys only | 1% | 0.5% | | Not authenticated | 26% | 59% | | **Authenticated (any)** | **about 75%** | **about 40%** | ### How the reputation number is computed Every delivered message logs an event with its classification and authentication. Four counters accumulate for each authenticated domain: | Variable | Meaning | |---|---| | `autononspam` | times mail from this sender went to the inbox automatically | | `autospam` | times mail from this sender went to the spam folder automatically | | `manualnonspam` | times a user hit **Not Spam** on this sender | | `manualspam` | times a user hit **Report Spam** on this sender | Reputation is a number in the range **0–100**: "you can think of the reputation as the probability that a given sender's mail is not spam." 0 is the most spammy, and 100 the least. ``` good = autononspam + manualnonspam − manualspam total = autospam + autononspam reputation = 100 × good / total ``` The refined version limits the manual terms, so that a small number of votes cannot dominate, and guards against division by zero (if `total = 0`, there is no reputation): ``` manualnonspam2 = min(autospam, manualnonspam) manualspam2 = min(autononspam, manualspam) good2 = autononspam + manualnonspam2 − manualspam2 reputation = 100 × good2 / total ``` Worked examples from the paper: - `weliketospam.com` sends 100 spam messages. 60 land in the spam folder automatically and 40 get into inboxes as false negatives, which gives a reputation of **40**. When 30 users then mark the spam that was missed, the reputation drops to **10**. - `weneverspam.com` sends 100 messages. 5 wrongly go to the spam folder as false positives, which gives a reputation of **95**. When 3 users unmark them, the reputation rises to **98**. The reputation also works as an expected false-positive rate. For a sender with a reputation of 2, with the spam-folder threshold set below a reputation of 5, "about 2% of the time you'll have false positives on that sender's mail." ### Self-correction, vote-weighting, and recovery dynamics - Reputations are computed **over many days**, so a solid domain "can build up a very solid reputation" and "a little blip of spam ... is absorbed as noise." The other side is that a domain that spams for a long time and later cleans up **takes a few days to recover**. - **Both the Report Spam and the Not Spam buttons are critical.** With only spam reports as input, the reputation has no way to move back up after a filter mistake, so it cannot correct itself. Google calls having both buttons "critical for the success" of the system. - **Not every user votes, and votes are rate-limited.** Only a subset of users, "the ones that will provide the best information", are counted, and users who never report spam or nonspam are excluded. To stop users with heavy mail from dominating, each user is limited to **one spam report per domain per hour**, that is, up to **24 votes per domain per day**. ### How the reputation is used (the three-way split) After authenticating the sender and computing the domain reputation, Gmail acts as follows: 1. A reputation **above a threshold** sends all of the sender's mail to the **inbox**. 2. A reputation **below a threshold** sends all of it to the **spam folder**. 3. **In between (or unknown)**, the message goes, with the reputation value, to a **statistical spam filter that makes the final judgement** on content. Crucially, **a user can override the general policy for individual sender addresses**. This is the documented reason why placement differs between users. ### What the reputation distribution looked like - Spammy domains cluster tightly around **0**, and domains with wanted mail cluster in the **90–100** range. For legitimate bulk senders, a score **below 90** is "a reflection of less-than-ideal sending practices". Hygiene that is not quite good shows up as a middling score, not as a zero. - Selected domain reputations (2006, illustrating the model): `aol.com` 98.5; `yahoo.com` 95.6 with SPF and 95.0 with DomainKeys (DK); `hotmail.com` 95.4; `ebay.com` 95.2 with SPF against 98.2 with DomainKeys; `earthlink.net` 93.3 with SPF against 98.0 with DK. Domains flagged as spam scored 1.5–3.3. - The gap between SPF and DomainKeys for `ebay.com` is instructive. eBay signed only its transactional mail with DomainKeys, and transactional mail "would likely be more wanted by users than other mail," so the signed stream scored higher. This is an early illustration of **stream separation** paying off (see [advanced IP segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation) and [sending infrastructure practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)). ### Documented failure modes and the sender rules that follow The paper calls out these problems, and all of them are still live concerns: - **Forwarding:** users forward mail (including spam) with tools such as `procmail` that rewrite the envelope sender. The forwarded spam then authenticates as the forwarder, and "hurts the reputation of the forwarding domain unfairly." The rule that follows is not to authenticate mail you are only forwarding unless you have filtered out the spam first, because signing it means taking responsibility for the resulting stream. [ARC](https://emailmarketing.net/learn/authentication/arc) later addressed the same problem. - **Mailing lists:** a list domain (the paper's example is Yahoo Groups, signed as `yahoogroups.com`) can have a good overall reputation while individual groups within it send spam, so blanket trust "will allow some spam through." Users also often find **reporting a list as spam easier than unsubscribing**, which hurts the list sender's reputation "worse than it needs to be". This is an argument for a prominent unsubscribe option with little friction (see [List-Unsubscribe](https://emailmarketing.net/learn/list-management/list-unsubscribe)). Sender policies the paper recommends: 1. Authenticate with **both** SPF and DomainKeys or DKIM (you may already have best-guess SPF implicitly). 2. **Do not authenticate mail you are only forwarding**, unless you filtered out spam first. 3. Keep spammers and zombie machines off your network, and follow good practices for bulk sending: "if a sender is doing something bad such as using single opt-in instead of double opt-in, it simply translates into a poor reputation and a greater likelihood of ending up in the spam folder." **Users enforce Gmail's bulk guidelines** through the reputation, not a rulebook. ## ML spam and phishing classification The reputation model above answers the question "is this sender trusted?". For everything in the ambiguous middle band, the verdict on content comes from machine learning (ML) classifiers that have been rebuilt and scaled up repeatedly. - **"The War Against Spam: A Report from the Front Line"** (Taylor, Fingal and Aberdeen, NIPS 2007 Workshop on Machine Learning in Adversarial Environments) presents Gmail's spam filtering as a real-world success story for adversarial machine learning: the overwhelming majority of spam is positively identified, with high precision (few false positives). The adversarial framing matters. Spammers adapt, so filters must retrain continuously instead of running a fixed set of rules. - **2014: a rebuild at TensorFlow scale.** Google's rule-based filters had reached about 99% accuracy. From 2014, Google added **machine learning algorithms built on TensorFlow** that "continuously regenerate" the spam filters, finding new patterns and adapting "far quicker than previous manual systems." The reported outcome: **more than one billion Gmail users avoid spam**, at roughly **99.9%** effectiveness. - **Claims about the security model in 2017** (Google, May 31 2017): **over 99.9% accuracy** in blocking spam and phishing, and **50–70% of all mail Gmail receives is spam**. Classifiers combine **thousands of signals for spam, malware and ransomware** with **heuristics on attachments** and **sender signatures**. Phishing defenses combine **Google Safe Browsing** with **analysis of the reputation and similarity of URLs**. A model for early phishing detection can **selectively delay** risky messages for deeper analysis, which affects **less than 0.05% of messages on average**. Warnings at click time, warnings on replies to external recipients, and defenses against ransomware and polymorphic malware complete the picture. - **2024: large language model classifiers.** Google deployed **a large language model (LLM) trained on phishing, malware and spam** that blocks **20% more spam** and reviews **1,000× more spam reported by users each day**, together with a second "supervisor" model that evaluates **hundreds of threat signals** when a risky message is flagged. See [holiday tightening](#holiday-period-tightening) below. What this means for senders: the classifier is a moving target, trained on everything users report. There is no content allowlist to satisfy, because the filter optimizes for what users treat as wanted. This is the mechanism behind the guidance in [content and design for deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability): avoid spam patterns and optimize engagement, rather than follow a keyword checklist. ## Inbox categorization (the tabs) Categorization is a **separate decision, made after acceptance**, from the verdict between inbox and spam. A message that has already earned the inbox is then sorted into one of five default categories (in Gmail's "Default" inbox type). **Landing in a category tab other than Primary is not a deliverability failure.** Promotions is the inbox, not spam. | Category | Google's definition | |---|---| | **Primary** | "Emails from people you know and messages that don't appear in other tabs." | | **Social** | "Messages from social networks and media-sharing sites." | | **Promotions** | "Deals, offers, and other promotional emails." | | **Updates** | "Automated confirmations, notifications, statements, and reminders that may not need immediate attention." | | **Forums** | "Messages from online groups, discussion boards, and mailing lists." | Mechanics: - Users turn categories on or off in **Quick Settings**, then **Default inbox type**, then **Customize**. Turning categories off entirely requires switching to a different inbox layout. Because the recipient controls which tabs exist, a sender cannot assume that a given recipient even has a Promotions tab. - **Senders cannot choose a tab in advance.** Recipients move messages between tabs by **drag and drop** (with an Undo), which teaches Gmail their preference so that it will "sort your email more accurately" over time. This is another override by the individual user. - Asking engaged readers to drag your mail to Primary is legitimate and effective. See [content and design](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability) for the content factors (personalization, a conversational style, a limited number of images and links) that push mail toward Primary rather than Promotions. ### Category prediction as an ML problem Source: **"Email Category Prediction"**, by Zhang, Garcia Pueyo, Wendt, Najork and Broder (Google, WWW 2017 Companion). The key points for senders: - **About 90% of consumer email is generated by machines.** Categorization targets templated mail (shopping receipts, promotional campaigns, booking confirmations, bill reminders), not mail between people. - The approach uses **template discovery** and the **"causal threads"** of email sequences, because legitimate machine mail follows predictable patterns (an order, then a shipping confirmation, then a delivery alert). Predictable sequences that match their templates classify cleanly; erratic structure does not. - Comparison of models: **neural networks (multilayer perceptrons, or MLPs, and long short-term memory networks, or LSTMs) far outperform** a Markov chain baseline, with **LSTMs slightly ahead of MLPs**. The applications named include filling calendars, shipment alerts, targeted advertising and spam detection, so categorization feeds back into filtering. ## Per-user personalization signals Beyond the vote on spam and nonspam, Gmail runs an **importance** model for each user, and spam controls for each user. These are the mechanisms that make placement individual. **Importance markers** (help topic "Importance markers in Gmail"). Gmail predicts which messages matter to each user from: - how often the user communicates with the sender (frequency); - which messages the user opens and replies to; - **keywords in the emails the user usually reads**; - interactions: starring, archiving, deleting. Users see a yellow importance marker, can correct it (which trains the model), and can find flagged mail with `is:important`. A user can turn off predictive marking ("Don't use my past actions to predict which messages are important") or hide the markers entirely. These settings are changed in the browser but apply across the apps. **Spam controls that feed personalization** (help topic on how Gmail sorts spam): | User action | Effect on future placement | |---|---| | **Report spam** | The message is added to Spam; "as you report more spam, Gmail identifies similar emails as spam more efficiently." Google receives a copy and may analyze it to protect all users. | | **Not spam** | Recovers the message and teaches Gmail that this sender is wanted (the `manualnonspam` vote). | | **Block sender** | "Even when you remove their emails from Spam, Gmail still automatically identifies their emails as spam." A hard override for that user. | | **Add sender to Google Contacts** | "Gmail stops sending their messages to Spam." A hard allow for that user. | | **Unsubscribe** | Offered inline for senders the user opted in to. A less damaging exit than Report Spam. | | **Filters** | Rules the user creates can label or prioritize a sender's mail. | The common thread: **the recipient's own history can override the sender's overall reputation in both directions.** A sender with a strong domain reputation still lands in spam for any recipient who blocked them or repeatedly reported them. A sender with a weak reputation reaches the inbox for recipients who added them to Contacts or clicked Not Spam. ## Holiday-period tightening Google publicly tightens its filters around periods of heavy fraud. For the **2024 holiday season** (blog post, Dec 2024): - Gmail blocks **more than 99.9% of spam, phishing and malware**. - The newly deployed **LLM classifier** and **supervisor model** (see [ML classification](#ml-spam-and-phishing-classification)) launched **before Black Friday**. - Result: users reported **35% fewer scams** reaching inboxes in the first month of the holiday season, compared with the previous year. - The holiday scam patterns Gmail strengthened its defenses against: **invoice scams** (fake invoices that invite the recipient to phone a number to dispute them), **celebrity scams** (impersonation or false endorsement), and **extortion scams** (threats that cite a home address or a personal detail). What this means for senders: filter thresholds are **not constant throughout the year**. A stream with a borderline reputation that reaches the inbox in a quiet month can tip into spam during a tightening period. Build a margin of reputation before Q4, and do not launch new streams or re-warm into the holiday peak. ## Sender takeaways: what actually moves Gmail placement 1. **Authenticate so that your mail can be scored, then build the domain's reputation.** Use SPF and DKIM aligned to the [From domain](https://emailmarketing.net/learn/providers/gmail-sender-requirements). Reputation attaches to that authenticated domain, not to your IP. Unauthenticated mail mostly cannot be scored, and it correlates with spam (about 60% of spam is unauthenticated, compared with about 26% of wanted mail). 2. **The one metric that directly drives the model is the user's spam vote.** Report Spam pushes reputation down; Not Spam and adding the sender to Contacts push it up. Keep the spam rate in [Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools) below **0.10%**, and never let it reach **0.30%**. Those are the [sender requirement](https://emailmarketing.net/learn/providers/gmail-sender-requirements) thresholds that correspond to this vote. 3. **Reputation changes slowly in both directions.** Days of consistent behavior build it, a single bad blip is absorbed as noise, and recovery after sustained abuse "takes a few days." There is no overnight fix; see [reputation incident recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery). 4. **Separate your streams.** Even in 2006, transactional mail signed separately from marketing mail scored higher, because recipients want the two streams to different degrees. Segment by [sending domain or subdomain](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) and by content type. 5. **Categorization is not deliverability.** Promotions is the inbox. Improve tab placement with content (personalization, a conversational tone, fewer images and links), not by trying to game the classifier: you cannot choose a tab in advance. 6. **Personalization for each user defeats one-size-fits-all diagnosis.** Importance markers, blocks, Contacts and overrides for individual addresses all apply recipient by recipient, so "where does my mail land at Gmail?" has no single answer, only a distribution. Seed inbox tests sample a handful of fresh accounts with no history of their own, and therefore **cannot represent** what an engaged (or disengaged) real recipient sees. Trust the trends in aggregate reputation and spam rate in Postmaster Tools over any screenshot of a single inbox (see [tracking and measurement distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). > Note on sources: Gmail help answer **6596** ("Gmail inbox tabs and categories") overlaps with the Gmail tabs guidance in [Content and Design](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability) and with the categorization material above. It was not used separately, because it adds nothing beyond answer 3094499, which is already cited. ## Related articles - [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements), the checkable rules and spam rate thresholds that feed this model - [Gmail SMTP Troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting), including the messages for reputation blocks - [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools) - [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability) - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) - [ARC](https://emailmarketing.net/learn/authentication/arc), the later fix for the forwarding problem described in the 2006 paper # Gmail SMTP Errors and Troubleshooting > Complete catalog of Gmail SMTP reply codes with their enhanced status codes, meanings, and fixes. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/gmail-troubleshooting When Gmail rejects, defers or rate-limits your mail, the SMTP reply tells you why and what to fix. Google publishes the full list of reply codes its servers return for inbound mail, collected below with their meanings and fixes. Every error that Gmail generates ends with the identifier **`gsmtp`**. Errors that also contain **`gcdp`** were triggered by a custom rule that a Google Workspace administrator set up on the receiving domain, not by Gmail's own filtering. General rules of thumb: - **4xx** codes are temporary, so retry later. Many 4.7.x codes are deliberate **rate limiting**, which escalates to a permanent 5.7.x block if you do not fix the underlying problem. - **5xx** codes are permanent for that message. Fix the cause before you send again. - The 4.7.x and 5.7.x pairs about compliance (SPF, DKIM, DMARC, TLS, PTR, alignment) map directly to the [Gmail sender requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements#non-compliance-error-codes). ## Temporary failures (4xx) | Code | Message (abridged) | Meaning and fix | |---|---|---| | 450-4.2.1 | User "is receiving email too quickly" / "at a rate that prevents delivery" | Rate limit on the recipient's side; resend later | | 450-4.2.1 | "Peak SMTP relay limit exceeded for this customer" | Workspace SMTP relay limit; contact the account administrator | | 452-4.2.2 | "The recipient's inbox is out of storage space" | The recipient must free up Google storage | | 421-4.3.0 | "Temporary System Problem. Try again later" | Issue on Google's side; retry | | 451-4.3.0 | "Email server has temporarily rejected this message" | Retry later | | 451-4.3.0 | "Multiple destination domains per transaction is unsupported" | Send to one destination domain per SMTP transaction (RFC 5321) | | 451-4.4.2 | "Timeout - closing connection" | Network or session timeout; retry | | 421-4.4.5 | "Server busy, try again later" | Retry with backoff | | 451-4.5.0 | "SMTP protocol violation" | Fix how the client handles the protocol, following RFC 5321 | | 452-4.5.3 | "Domain policy size per transaction exceeded" | Retry that recipient in a separate transaction | | 452-4.5.3 | "Your message has too many recipients" | Reduce the number of recipients per message | | 421-4.7.0 | "Connection expired, try reconnecting" / "Try again later, closing connection" | Reconnect and retry | | 421-4.7.0 | "IP not in whitelist for RCPT domain" | The receiving (Workspace) domain accepts only allowlisted IP addresses | | 421-4.7.0 | "The IP address sending this message does not have a PTR record" | Add matching PTR and forward DNS records | | 421-4.7.0 | "TLS required for RCPT domain, closing connection" | Deliver over TLS | | 421-4.7.0 | "This message is suspicious due to the very low reputation of the sending IP / sending domain" | Reputation block; see reputation recovery below | | 421-4.7.0 | "This message is suspicious due to the nature of the content" | Content flagged; review the message content | | 454-4.7.0 | "Too many login attempts" / "Cannot authenticate due to a temporary system problem" | Throttling of client authentication; retry later | | 451-4.7.23 | "The sending IP address for this message doesn't have a PTR record" | Add a PTR record | | 451-4.7.24 | "The SPF record of the sending domain has one or more suspicious entries" | Clean up the SPF record (remove compromised or suspicious includes) | | 421-4.7.26 | "Rate limited because it is unauthenticated" | Set up SPF or DKIM | | 451-4.7.26 | "Unauthenticated email from *domain* is not accepted due to domain's DMARC policy" | The DMARC policy of the From: domain itself rejects unauthenticated use; authenticate with aligned SPF or DKIM | | 421-4.7.27 | "Rate limited because SPF authentication didn't pass" | Fix SPF | | 421-4.7.28 | "Unusual rate of email" from your IP address / IP netblock / DKIM domain / SPF domain / a URL domain in the body; or "sender exceeded the quota" | Rate limiting for spam patterns, keyed to that identifier. To recover, wait ≥10 minutes, resume with one connection, and add connections one at a time | | 421-4.7.29 | "Rate limited because you're not using a TLS connection" | Turn on TLS | | 421-4.7.30 | "Rate limited because DKIM authentication didn't pass" | Fix DKIM | | 421-4.7.32 | "Rate limited because the From: header isn't aligned" with the SPF or DKIM domain | Achieve DMARC alignment; see [DMARC](https://emailmarketing.net/learn/authentication/dmarc) | | 421-4.7.40 | "Rate limited because the sending domain doesn't have a DMARC record" | Publish a DMARC record (at minimum `p=none`) | ## Permanent failures (5xx) ### Recipient and addressing | Code | Message (abridged) | Meaning and fix | |---|---|---| | 550-5.1.1 | "The email account that you tried to reach does not exist" | Hard bounce: remove the address and check for typos | | 553-5.1.2 | "We weren't able to find the recipient domain" | Bad domain; check the spelling and the MX record | | 553-5.1.3 | "The recipient address is not a valid RFC 5321 address" | Fix the address syntax | | 553-5.1.7 | "The sender address is not a valid RFC 5321 address" | Fix the syntax of the envelope sender | | 550-5.2.1 | "The email account that you tried to reach is inactive" | Disabled account; suppress it | | 550-5.2.1 | User "is receiving email at a rate that prevents delivery" | Rate limit on the recipient | | 552-5.2.2 | "The recipient's inbox is out of storage space and inactive" | Suppress, or wait | | 550-5.4.5 | "Daily user sending limit exceeded" / "Daily SMTP relay limit exceeded for user" | Outbound limits of Gmail or Workspace reached | | 554-5.4.6 | "Message exceeded 50 hops" | Probably a mail loop; investigate forwarding chains | | 550-5.5.3 | "Too many recipients for this sender" | Reduce the number of recipients | ### Size limits | Code | Message (abridged) | Meaning and fix | |---|---|---| | 552-5.3.4 | Message exceeded size limits | The whole message is too large | | 552-5.3.4 | "The number of attachments exceeds Google's limit" | Send fewer attachments | | 552-5.3.4 | Header size limits exceeded: total headers, a header value, a header name, or the `Subject:` header | Shrink the headers | ### Protocol and session | Code | Message (abridged) | Meaning and fix | |---|---|---| | 502-5.5.1 | "Unimplemented command" / "Unrecognized command" / "Too many unrecognized commands, goodbye" | Fix the behavior of the SMTP client | | 503-5.5.1 | "Bad sequence of commands" / "EHLO/HELO first" / "RCPT first" / "No DATA after BDAT" (RFC 3030) | A bug in the order of commands in the client | | 501-5.5.2 / 555-5.5.2 | "Syntax error" | Malformed SMTP command | | 501-5.5.4 | "HELO/EHLO argument invalid" / "Empty HELO/EHLO argument not allowed" | Send a valid fully qualified domain name (FQDN) in HELO or EHLO | | 530-5.7.0 | "Must issue a STARTTLS command first" (RFC 3207) / "Authentication required" | Start TLS, or authenticate, before sending | | 523-5.7.10 | "No commands allowed to pipeline after STARTTLS" | Violation of RFC 3207 | | 501-5.7.11 | "Syntax error (no parameters allowed)" | Violation of RFC 3207 | | 554-5.7.0 | "Too many unauthenticated commands" | Session terminated | | 503-5.7.0 | "No identity changes permitted" | Do not switch the authenticated identity during a session | ### Content, format, and policy | Code | Message (abridged) | Meaning and fix | |---|---|---| | 554-5.6.0 | "Email message is malformed. Not accepted" | Fix compliance with RFC 5322 | | 552-5.7.0 | "Content presents a potential security issue" | Blocked attachment or file type (see Gmail's list of blocked file types) | | 550-5.7.1 | "The user or domain that you are sending to has a policy" prohibiting the mail | Policy of the receiving Workspace domain (`gcdp` errors); contact the recipient's administrator | | 550-5.7.1 | "This message is likely unsolicited email" / "likely suspicious due to the very low reputation" of the sending IP or domain | Spam or reputation block; see recovery below | | 550-5.7.1 | RFC 5322 violations: a missing or invalid `From:`, multiple `From:` headers, multiple addresses in `From:`, no valid `Message-ID:`, duplicate headers, a malformed header, a non-compliant `From:` value, encoded-word syntax in a header, a Unicode character in a header that does not allow it | Fix how messages are generated, following RFC 5322 | | 550-5.7.1 | "This message does not meet IPv6 sending guidelines" | Over IPv6, PTR records and authentication are mandatory; fix them or send over IPv4 | | 550-5.7.1 | "This email has been rate limited" | Sending or receiving limits | | 550-5.7.1 | "The IP you're using to send email is not authorized" | Mail sent directly from a dynamic or consumer IP address; relay through your provider's SMTP server instead | | 550-5.7.1 | "Invalid credentials for relay" / "Daily SMTP relay sending limit exceeded for this customer" | Configuration or limits of the Workspace SMTP relay | | 550-5.7.0 | "Email relay denied" (invalid credentials or suspended account) | Register the sending IP address in the Workspace SMTP relay settings, or the relay account is suspended for spam | ### Authentication and sender-requirement blocks | Code | Message (abridged) | Meaning and fix | |---|---|---| | 550-5.7.24 | "SPF record of the sending domain has one or more suspicious entries" | Clean up the SPF record | | 550-5.7.25 | "The sending IP address doesn't have a PTR record" | Add a PTR record | | 550-5.7.26 | "Blocked because the sender is unauthenticated" | Set up SPF or DKIM | | 550-5.7.26 | "The (E)MAIL FROM domain has an SPF record with a hard fail policy" (`-all`) but the message failed SPF | Fix the SPF record, or send from an authorized IP address | | 550-5.7.26 | "Unauthenticated email from *domain* is not accepted due to domain's DMARC policy" | The DMARC policy of the From: domain requires aligned authentication | | 550-5.7.27 | "Didn't pass SPF authentication" | Fix SPF | | 550-5.7.28 | "Unusual rate of unsolicited email originating from your IP address" | Block for spam volume; stop, fix list hygiene, and warm up again | | 550-5.7.29 | "Wasn't sent over a TLS connection" | Turn on TLS | | 550-5.7.30 | "Didn't pass DKIM authentication" | Fix DKIM | | 5.7.32 | "Blocked because the From: header isn't aligned" with SPF or DKIM | Fix DMARC alignment | | 550-5.7.40 | "The sending domain doesn't have a DMARC record" | Publish DMARC | ### Client-authentication errors (submission, not deliverability) | Code | Message (abridged) | Meaning and fix | |---|---|---| | 535-5.7.80 | "Username and Password not accepted" | Bad credentials, or sign-in blocked | | 534-5.7.90 | "Application-specific password required" / "Please log in with your web browser" | Use app passwords or OAuth | | 534-5.7.14 | "Please log in through your web browser and then try again" | Account security challenge | | 504-5.7.40 | "Unrecognized authentication type" / "XOAUTH is no longer supported" | Use OAuth 2.0 (XOAUTH2) | ## Recovering from blocks and throttling - **Temporary 4.7.x failures are throttling**, not final verdicts. Google's guidance is to "completely stop sending for a short period of time, then resume sending at a slower rate", which in effect means [warming up](https://emailmarketing.net/learn/ip-management/ip-warm-up) again. - **Rate-limit quota errors (4.7.28)**: wait at least 10 minutes, resume with a single connection, and add connections one at a time. If a single connection still fails, wait another 10 minutes. - **Reputation blocks** ("very low reputation of the sending IP/domain"): check the IP Reputation and Domain Reputation dashboards in [Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), fix the source of spam, and give it time. Reputation recovers only through sustained sending that follows the rules. - **Listings on public blocklists (RBLs)**: Gmail also consults public blocklists. Request delisting directly from the blocklist operator. - **Persistent blocks on compliant traffic**: use Google's Bulk Sender Escalation Form. Mitigation is not available while your spam rate in Postmaster Tools is above 0.3% (see [sender requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements#mitigation-eligibility)). # GMX / WEB.DE (United Internet) — Postmaster Requirements > Sender requirements for GMX, WEB.DE and mail.com (United Internet): mandatory aligned DKIM, strict header/DNS rules, RFC 8058 unsubscribe, error-message format, and the CSA path. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/gmx-web-de-postmaster If your list has European recipients, some of them use GMX, WEB.DE or mail.com, which dominate the German consumer mailbox market. These providers are stricter than most on two points: **DKIM is mandatory (SPF alone is not enough)**, and **generic reverse DNS is rejected outright**. All three are operated by United Internet (1&1) and share one postmaster policy, published in parallel at `postmaster.gmx.net`, `postmaster.web.de` and `postmaster.mail.com`. ## Infrastructure and DNS requirements | Requirement | Detail | |---|---| | Static IP | The delivering server must have a static IP address. IP addresses from dial-up or dynamically assigned ranges are **not accepted** | | Reverse DNS (PTR) | Must resolve to an FQDN **that belongs to the sender's own domain**. Generic provider defaults (for example `123-123-123-123-static.ihrprovider.tld`) "usually result in rejection" | | Forward DNS | The sending domain must have valid **MX or A records** | | HELO or EHLO | Must be a valid **FQDN** | | Blocklists | Neither the IP address nor the domain may be listed on known blocklists (they suggest checking with dnsbl.info) | ## Message-format requirements (RFC 5321 and 5322) - Headers must comply with **RFC 5321** and **RFC 5322**. - Required header fields: **`Date`, `From`, `Message-ID`** (and `Sender` if applicable). - Each of **`BCC`, `CC`, `Date`, `From`, `Sender`, `Subject`, `To`** may appear **only once**. - The `Date` (date, time and time zone) must be correct, and must not differ significantly from the actual time of sending. ## Authentication: DKIM mandatory, aligned - **DKIM is mandatory**: "the use of a valid DKIM signature is mandatory." - **SPF is only recommended.** In their words: "We require DKIM as a minimum requirement; SPF alone is not sufficient." - **DMARC is recommended** to prevent spoofing and phishing. - The DKIM `d=` domain must **align with the `RFC5322.From` domain**, at least in relaxed mode: | DKIM domain (`d=`) | From domain | Mode | |---|---|---| | example.com | child.example.com | relaxed (accepted) | | child.example.com | example.com | relaxed (accepted) | | example.com | example.com | strict | | child.example.com | child.example.com | strict | This is the same concept of alignment that DMARC uses (see [DMARC](https://emailmarketing.net/learn/authentication/dmarc)), but United Internet requires DKIM alignment as a condition of acceptance even when the domain has no DMARC policy. ## Bulk-sender requirements - **Explicit consent only**, ideally through **double opt-in**. - Follow the **M3AAWG** and **CSA** guidelines. Taking part in the CSA is recommended (below). - **Unsubscribe:** every email must contain an unsubscribe option that is easy to find and understand. The preferred method is **RFC 8058** one-click List-Unsubscribe. If a message complies, GMX and WEB.DE show an **unsubscribe button** in their interface. If RFC 8058 is not met, a **valid reply address** must be provided instead. - **List hygiene:** avoid invalid, inactive or outdated addresses, and regularly remove addresses that cannot be delivered. "If many messages are sent to unknown or deactivated addresses, this can lead to temporary suspension" of acceptance. - **Sender identity:** the sender must be clearly and unambiguously identifiable, the content must be relevant, and the frequency appropriate. - **Warm-up caveat:** for mass mailings, "our system may throttle delivery despite IP warm-up". Expect temporary failures on new IP addresses even with a proper ramp-up (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)). ## Error messages United Internet documents the **structure** of its SMTP errors rather than a complete table of codes: - **5xx** codes are permanent errors, and **4xx** codes are temporary errors. - Every rejection contains an SMTP status code, a description of the problem, and a **URL with diagnostic parameters**. The URL points to the matching postmaster page (`https://postmaster.gmx.net/...`, `postmaster.web.de` or `postmaster.mail.com`), which gives explanations and solutions. Always follow that URL, because it identifies the exact reason for the block. - Example: `554 gmx.net (mxgmx104) Nemesis ESMTP Service not available / No SMTP service / IP address is block listed.` The connecting IP address is on a blocklist, and the URL in the message explains how to fix it. ## Filtering behavior, allowlisting, feedback loop - **No allowlist:** "GMX does not offer this service". According to GMX, following the requirements makes allowlisting unnecessary. - **Behavior similar to greylisting:** they delay or reject mail from servers that show "unmistakable characteristics that indicate a spamming server." - Filtering is based on both **IP addresses and content**. If a message is wrongly classified, submit its extended headers through their contact form (`https://postmaster.gmx.net/en/contact`). - **No public FBL of their own.** In practice, complaint feedback for GMX and WEB.DE is available through the **CSA** (certified senders receive complaint data as part of certification). The postmaster site itself points bulk senders to the CSA instead of offering a direct FBL signup. ## Certified Senders Alliance (CSA) and trustedDialog - **CSA**: a positive-list project of eco (Verband der deutschen Internetwirtschaft) together with the DDV. GMX and WEB.DE and several other European providers check certification, and United Internet recommends that senders of newsletters and advertising take part. Information: certified-senders.org. - **trustedDialog**: a paid brand-protection standard from United Internet Media. It combines sender authentication with verification that the content is intact, and in return shows a **seal and brand logo in the inbox**, gives recipients more confidence that the sender is authentic, and (according to United Internet Media) improves open and click rates. It is mainly relevant for large consumer brands that mail German users. ## GMX outbound servers (for receivers / verification) Mail that genuinely comes from GMX arrives from these published hosts: | Role | Hostname | IPs | |---|---|---| | Outbound | mout.gmx.net | 212.227.15.15, 212.227.15.18, 212.227.15.19, 212.227.17.20, 212.227.17.21, 212.227.17.22 | | Bounce handling | mout-bounce.gmx.net | 212.227.15.44–46, 212.227.17.26, 212.227.17.28, 212.227.17.29 | | Lower reputation (forwarded by customers) | mout-xforward.gmx.net | 82.165.159.12–14, 82.165.159.40–42 | ## If GMX blocks you 1. Read the bounce. It contains the exact reason and a postmaster URL. 2. Fix the root cause against the requirements above (the delisting form will not help while problems with PTR, DKIM or consent remain). 3. Contact the abuse team through the postmaster contact form, and provide your email address, contact address, name, **the date of the attempted send, the recipient domain, and the exact error message or mailer-daemon text**. Bounces caused by full inboxes or by a recipient's misconfiguration are not "blocklisting", and do not belong on that form. # Microsoft Escalation Channels > The remediation map for Microsoft blocks: Office 365 anti-spam IP delist portal (sender.office.com), delist@microsoft.com for 5.7.511, the Outlook.com sender support form, SNDS/JMRP prerequisites, what each channel needs, and realistic timelines. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/microsoft-escalation-channels When Microsoft blocks your mail, the channel that can lift the block depends on which of Microsoft's systems applied it. Microsoft runs **two separate filtering systems, each with its own remediation paths**, and escalating to the wrong one wastes days. Start by classifying the block: | Symptom | System | Channel | |---|---|---| | NDR `550 5.7.606–649 Access denied, banned sending IP` from a **business or tenant** recipient (a custom domain on Microsoft 365) | EOP (Office 365) | Delist portal `https://sender.office.com` | | NDR `550 5.7.511 Access denied, banned sender` | EOP (Office 365), on the list that needs deeper investigation | Email `delist@microsoft.com` | | `550 5.7.703 ... Tenant Allow Block List` | A block set by a single recipient tenant | Only that tenant's administrator can fix it; there is no Microsoft channel | | `421 RP-001/002/003`, `550 SC-001..004`, `DY-001/002`, `OU-001/002`, or mail sent to Junk at **@outlook.com, @hotmail.com, @live.com or @msn.com** | Consumer Outlook.com | Sender support form (below), after the SNDS and JMRP prerequisites | For what each code means, see [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements). For diagnosing tenant mail from its headers, see [Microsoft Filtering Internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals). ## Channel 1: Office 365 Anti-Spam IP Delist Portal (sender.office.com) Use this channel for IP addresses on the EOP **blocked senders list** (NDR range `5.7.606–649`, whose message itself points to the portal). It is self-service, and works one IP address at a time. Process: 1. Go to `https://sender.office.com`. 2. Enter the **email address that received the NDR** and the **IP address from the error message** (one email address and one IP address per visit), and pass the CAPTCHA. 3. Microsoft sends a verification email to that address. Click the confirmation link to return to the portal. 4. Select **Delist IP**. You need the exact NDR text (the IP address and the code) and a working mailbox at the address you enter. On timing, Microsoft states that results vary and that full removal **can take up to 24 hours or longer**. Delisting removes only the block at the edge. Mail must still pass EOP and MDO filtering, including composite authentication, and if the traffic stays abusive the IP address is blocked again. As with any [blocklist removal](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus), fix the root cause (a compromise, list quality, authentication) before you delist. ## Channel 2: delist@microsoft.com (error 5.7.511) `550 5.7.511 Access denied, banned sender` means the IP address is on a list that requires **further investigation by Microsoft**, and the self-service portal explicitly cannot fix it. Forward the bounce to **`delist@microsoft.com`**, including the **full NDR text and the IP address**. Microsoft states that it will respond **within 48 hours** with next steps. Expect questions about the traffic, and have evidence of volume, consent and remediation ready. ## Channel 3: Outlook.com sender support form (consumer mailboxes) This channel is only for deliverability problems at consumer Outlook.com, meaning "any address @msn.com, @Outlook.com, @hotmail.com, or @live.com". Use it for mail sent to Junk, for `SC-004` complaint blocks once you have remediated, for throttling (`RP-00x`) that does not recover, and for requests for mitigation during warm-up. **Prerequisites Microsoft expects before you file** (requests without them tend to get standard denials): 1. Check that you comply with the Outlook.com policies page (authentication, PTR records, connection limits; see [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements)). 2. Enroll the IP addresses in **SNDS and JMRP**, or refresh their enrollment. New IP addresses must be added to your JMRP account. See [Microsoft SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp). SNDS data (filter color, complaint rate, share of RCPT failures) is also the evidence you will cite in the ticket. 3. Check the troubleshooting FAQ for your exact error code first. **Where the form lives**: Microsoft's support article "Sender Support in Outlook.com" (`https://support.microsoft.com/en-us/outlook/sender-support-in-outlook-com`) and the postmaster troubleshooting page both link to the form. It was historically at `https://sendersupport.olc.protection.outlook.com/pm/Troubleshooting`, and can also be reached through the redirector `https://go.microsoft.com/fwlink/?LinkID=614866`. The postmaster and SNDS pages have moved to `https://substrate.office.com/ip-domain-management-snds/`, and the old `sendersupport.olc.protection.outlook.com` domain is deprecated from **June 22, 2026**. Expect the redirector link to send you to the form's current location. For the live link, follow the postmaster Troubleshooting page (`https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting`). **What to include**: the affected sending IP addresses, the exact SMTP error string or code, the sending domains, a description of the mail stream (volume, opt-in method), and the remediation you have done (JMRP suppression, list cleaning, authentication fixes). **Realistic flow and timeline** (widely reported by practitioners; this is not an official service level): - The form produces an **automated response**, which often says "no problem detected" or offers a generic conditional mitigation. - **Reply to that automated email** to escalate to a human agent. Responses come from `olcsupport.office.com` addresses, and a human response typically takes from one to several business days. - When mitigation is granted, it is usually temporary or conditional. Reputation must be rebuilt through sending behavior, at low volume first. - New IP addresses need **~2+ weeks** of reputation building at Outlook.com. SPF on a domain that already has a good reputation speeds up the ramp-up. There is also a separate **Outlook.com consumer delisting form** at `https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75`, linked from Microsoft's EOP delisting article for blocks on the consumer side. Read the troubleshooting FAQ before you submit it. ## Channel 4: problems only the recipient tenant can fix (no Microsoft channel) In some cases **no Microsoft channel for senders exists**: when the headers show `SFV:SKB` or `SFV:BLK` (the recipient's block lists), when a Tenant Allow/Block List entry blocks you (`5.7.703`), or when mail is quarantined as high confidence phishing because of a URL or domain the tenant has blocked. The recipient organization's administrator must remove the entry, or submit the message to Microsoft as a false positive through the Defender Submissions page (`https://security.microsoft.com/reportsubmission`). A submission is also the only way to get an allow for verdicts of malware or high confidence phishing. Give the recipient's administrator the full headers and the field guide in [Microsoft Filtering Internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals). ## Escalation checklist (consultant runbook) 1. **Classify** the block from the exact SMTP code or the verdict in the headers (see the table at the top). 2. **Fix the root cause first**: authentication alignment, compromised hosts, the causes of complaints, list hygiene. Microsoft blocks again senders whose remediation exists only on paper. 3. **Enroll in SNDS and JMRP** before any contact about consumer mailboxes, and pull the SNDS view of the days of the incident. 4. **Use the narrowest channel**: the portal for 606–649; `delist@microsoft.com` for 5.7.511; the sender support form for consumer Outlook.com issues; the recipient's administrator for blocks set by a tenant. 5. **Keep the paper trail**: ticket IDs and the automated responses. Replies to the automated email are what reach people. 6. **Verify after mitigation**: watch the SNDS filter results and run seed tests on consumer mailboxes. Increase volume gradually, as after a [warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up). ## Related articles - [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements), with the catalog of error codes and policies - [Microsoft Filtering Internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals), on reading the verdict headers - [Microsoft SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp), the mandatory prerequisites - [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus), since OU-001 blocks are driven by Spamhaus # Microsoft Filtering Internals (EOP / Defender for Office 365) > Reading X-Forefront-Antispam-Report and X-Microsoft-Antispam headers, SCL and BCL scales with per-level actions, compauth reason codes, how EOP/MDO layers filter, and Tenant Allow/Block List mechanics from the sender's perspective. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/microsoft-filtering-internals When your mail to a business that uses Microsoft 365 lands in Junk or quarantine, the message headers tell you why. Below is how Exchange Online Protection (EOP) filters inbound mail for **business tenants**, and how a sender or consultant reads its verdict. This is a different system from the filtering of consumer Outlook.com mailboxes (descended from SmartScreen, and visible in SNDS), which [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements) covers. The two systems share reputation inputs, though, and B2B senders depend on EOP verdicts. To diagnose a message, get a copy of it as delivered (or as junked or quarantined) from a Microsoft 365 recipient, and extract the full headers. Read three headers in order: `Authentication-Results` (did authentication pass?), `X-Forefront-Antispam-Report` (what was the verdict, and why?) and `X-Microsoft-Antispam` (BCL). Microsoft's own parser is the Message Header Analyzer at `https://mha.azurewebsites.net/`. ## How the layers stack 1. **Connection filtering at the edge of the service**, based on IP address. Most spam is caught here. The inputs are Microsoft's blocked senders list (see [Microsoft Escalation Channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels)), the tenant's IP Allow and Block lists, and IP reputation. Entries in a tenant's IP block list drop mail at the edge. 2. **Anti-spam policies (content filtering)** classify each message as bulk, spam, high confidence spam, phishing, or high confidence phishing, and stamp SCL and BCL values. There are three tiers of policy: the **default** policy, **custom** policies created by administrators, and the **Standard and Strict preset security policies**. The presets have progressively more aggressive defaults, and for the recipients they include, preset settings override custom policy settings. 3. **Anti-phishing, spoof intelligence and composite authentication**: Microsoft's implicit authentication layer (`compauth`), which judges the From domain even when no DMARC record exists. 4. **Add-ons in Defender for Office 365 (MDO)**: impersonation protection (for users, for domains, and through mailbox intelligence), Safe Links and Safe Attachments. They exist only in tenants with MDO licenses, and they produce the `CAT` values marked as MDO only below. Policy changes take up to 1 hour to apply. When several detections fire, the policies apply in order of precedence and the verdict with the highest priority wins. ## X-Forefront-Antispam-Report header The header is a list of field:value pairs separated by semicolons, for example `...CTRY:;LANG:hr;SCL:1;SRV:;IPV:NLI;SFV:NSPM;PTR:;SFTY:;...`. Fields that Microsoft does not document are internal diagnostics. The documented fields are: | Field | Meaning | |---|---| | `ARC` | ARC evaluation: `AAR` (recorded Authentication-Results), `AMS` (message signature), `AS` (header signature with `cv=` chain validation: none, pass or fail) | | `CAT` | Threat category applied (see table below) | | `CIP:[IP]` | Connecting IP address, which you can use in the tenant's IP Allow and Block lists | | `CTRY` | Source country or region, from the connecting IP address (may differ from the originating IP address) | | `DIR` | Direction: `INB` inbound, `OUT` outbound, `INT` internal | | `H:[helostring]` | HELO or EHLO string of the connecting server | | `IPV:CAL` | Spam filtering skipped, because the source IP address was on the tenant's IP Allow List | | `IPV:NLI` | IP address not found on any IP reputation list | | `LANG` | Country code of the message language (for example, `ru_RU`) | | `PTR:[ReverseDNS]` | PTR (reverse DNS) record of the source IP address | | `SCL` | Spam confidence level (scale below) | | `SFTY` | Marker for a phishing safety tip: `9.19` domain impersonation, `9.20` user impersonation, `9.25` first-contact safety tip | | `SFV` | Spam filtering verdict (table below) | | `SRV:BULK` | Identified as bulk by the BCL threshold. With `MarkAsSpamBulkMail` on (the default), bulk mail is marked as spam at SCL 6 | | `X-CustomSpam:[ASFOption]` | Matched an Advanced Spam Filter (ASF) setting (content heuristics such as embed tags, JavaScript in HTML, or an empty message). The field is added after mail flow rules run, so rules cannot act on it | ### CAT (category) values | Value | Meaning | Value | Meaning | |---|---|---|---| | `AMP` | Anti-malware | `INTOS` | Intra-org phishing | | `BIMP` | Brand impersonation (MDO) | `MALW` | Malware | | `BULK` | Bulk | `OSPM` | Outbound spam | | `DIMP` | Domain impersonation (MDO) | `PHSH` | Phishing | | `FTBP` | Anti-malware common-attachments filter | `SAP` | Safe Attachments (MDO) | | `GIMP` | Mailbox-intelligence impersonation (MDO) | `SPM` | Spam | | `HPHSH` or `HPHISH` | High confidence phishing | `SPOOF` | Spoofing | | `HSPM` | High confidence spam | `UIMP` | User impersonation (MDO) | ### SFV (spam filtering verdict) values | Value | Meaning | |---|---| | `SFV:NSPM` | Marked as not spam; delivered normally | | `SFV:SPM` | Marked as spam by content filtering | | `SFV:BLK` | Blocked: the sender is on the recipient user's Blocked Senders list (filtering skipped) | | `SFV:SFE` | Allowed: the sender is on the recipient user's Safe Senders list (filtering skipped) | | `SFV:SKA` | Filtering skipped: the sender or domain is on the allowed list of the anti-spam policy; delivered to the Inbox | | `SFV:SKB` | Marked as spam: the sender or domain is on the blocked list of the anti-spam policy | | `SFV:SKN` | Marked as not spam before filtering (for example, a mail flow rule set SCL -1 or a bypass) | | `SFV:SKS` | Marked as spam before filtering (for example, a mail flow rule set SCL 5–9) | | `SFV:SKQ` | Released from quarantine to the intended recipients | How a consultant reads these: `SKA`, `SFE` and `SKN` mean the recipient side has allowlisted you. That is fragile, because placement depends on an override, not on reputation. `SKB` and `BLK` mean the recipient side has blocked you explicitly. No amount of reputation work on the sender side fixes that; the recipient organization must remove the entry. ## SCL: Spam Confidence Level The SCL is stamped as an X-header on every inbound message. Filtering never stamps the values 2, 3 or 4. SCL 7 is typically set not by spam filtering itself, but by analyst grading, DMARC failures or mail flow rules. | SCL | Definition | Default action | |---|---|---| | -1 | Filtering skipped (safe sender or recipient, or IP Allow List) | Inbox | | 0, 1 | Not spam | Inbox | | 5, 6 | **Spam** | Default and custom policies, and Standard preset: Junk folder. Strict preset: quarantine | | 7, 8, 9 | **High confidence spam** | Default and custom policies: Junk folder. Standard and Strict presets: quarantine | ## BCL: Bulk Complaint Level The BCL is stamped in the `X-Microsoft-Antispam` header (for example, `X-Microsoft-Antispam: BCL:5;`). Microsoft assigns it, based on complaint behavior, to mail from recognized **bulk senders** ("gray mail"), whether the sources are internal to Microsoft or external. This is the header that matters most to ESPs, because it is in effect Microsoft's published complaint reputation score for each sender. | BCL | Meaning | |---|---| | 0 | Not from a bulk sender | | 1–3 | Bulk sender generating **few** complaints | | 4–7 | Bulk sender generating a **mixed** number of complaints | | 8–9 | Bulk sender generating a **high** number of complaints | Thresholds and actions (a message is treated as Bulk when its BCL **meets or exceeds** the threshold): | Policy | BCL threshold | Action at or above the threshold | |---|---|---| | Default and new custom anti-spam policies | **7** | Junk Email folder | | Standard preset security policy | **6** | Junk Email folder | | Strict preset security policy | **5** | Quarantine | What this means for a sender: **mail at BCL ≤ 3 reaches the Inbox everywhere. BCL 4 is sent to Junk by tenants with the Strict preset (the recommended minimum for opting in to the Promotions folder feature is 5). BCL 5–6 is sent to Junk or quarantined by tenants using preset policies. BCL ≥ 7 is sent to Junk by default in every tenant.** Recipient administrators can tune the threshold, and can see the bulk volume of each sender in the "bulk senders insight" in the Defender portal. **Promotions folder (preview, 2026)**: tenants can choose to deliver bulk mail that is **below** the BCL threshold (even bulk mail at BCL 0) to a Promotions folder instead of the Inbox. They do this with a mail flow rule that stamps `X-MS-Exchange-Organization-BulkStamping: 1`, plus the "Bulk moves enabled" setting in the anti-spam policy. Microsoft 365 learns from users moving messages into and out of the folder. Mail still reaches the Inbox if the sender is on the user's Safe Senders list. For senders, this means that even bulk mail with no complaints may stop landing in Microsoft 365 Inboxes because of how it is classified, much as Gmail's tabs work. ## Authentication-Results and composite authentication Microsoft stamps the standard `spf=`, `dkim=` and `dmarc=` results (see [Authentication-Results Header](https://emailmarketing.net/learn/authentication/authentication-results-header)), plus fields specific to Microsoft: - The `dmarc=` values include the nonstandard **`bestguesspass`**: no DMARC record exists, but the message would have passed if one did. - `action=` on DMARC: `oreject` (rejected under the policy); `pct.quarantine` or `pct.reject` (failed DMARC but was delivered, because `pct` < 100 randomly exempted it); `permerror`; `temperror`. - **`compauth`** is composite authentication: Microsoft's combined verdict from SPF, DKIM, DMARC and signals in the message, evaluated against the **From (5322.From) domain**. A `compauth=fail` result does not guarantee the message goes to Junk if the other signals are clean. - **`reason`** is a three-digit code that explains the compauth result: | Code | Meaning | |---|---| | 000 | Failed explicit authentication: DMARC fail with `p=quarantine` or `p=reject` | | 001 | Failed implicit authentication: no authentication records, or weak ones (SPF `~all` or `?all`, DMARC `p=none`) | | 002 | The organization's policy explicitly prohibits this pair of sender and domain from spoofing | | 010 | DMARC fail with reject or quarantine, and the sending domain is one of the organization's own accepted domains (spoofing within the organization) | | 1xx (100–130) | Passed: 100 SPF or DKIM passed with alignment. 101 DKIM by the From domain. 102 MAIL FROM and From aligned, and SPF pass. 103 or 104 PTR aligns with the From domain. 108 DKIM fail attributed to a legitimate earlier hop. 109 no DMARC record, but it would pass. 111 DMARC temperror or permerror, but SPF or DKIM aligned. 112 DNS timeout on the DMARC lookup. 115 sent from an M365 organization where From is an accepted domain. 116 the MX of the From domain aligns with the PTR of the connecting IP address. 130 a trusted ARC sealer overrode the DMARC failure | | 2xx (201, 202) | Soft pass on alignment of PTR or subnet (`compauth=softpass`) | | 3xx, 4xx, 9xx | Not checked, or bypassed (`compauth=none`) | | 501, 502 | DMARC not enforced: a valid NDR with an established contact, or a valid NDR for the organization's own mail | | 6xx (601) | Failed implicit authentication; 601 means spoofing of an accepted domain within the organization | | 7xx (701–704) | DMARC not enforced, because the organization has a history of legitimate mail from this infrastructure | | 905 | DMARC not enforced, because of complex routing (an on-premises or third-party hop before M365) | Reason 001 is the code ESP consultants see most often. It means the sender had **no authentication, or weak authentication**, and Microsoft sent the message to Junk on suspicion from implicit authentication. The fix is aligned SPF and DKIM, plus a DMARC record. This is the same remediation as for the Outlook.com [May 2025 mandate](https://emailmarketing.net/learn/providers/microsoft-sender-requirements). ## Tenant Allow/Block List (TABL): what recipient tenants control The TABL is a list of overrides for each tenant, at `https://security.microsoft.com/tenantAllowBlockList`. It applies during mail flow and at the time of a click. The types of entry are: **domains and email addresses** (matched on the **From (5322.From) address**, not on MAIL FROM), **spoofed senders**, **URLs**, **files**, **IP addresses** and Teams domains. **Block entries take precedence over allow entries.** Entries take effect within ~5 minutes. What a block does: | Blocked entity | Effect | |---|---| | Domain or email address | The message is treated as **high confidence phishing** and quarantined (not merely treated as spam). The tenant's own users also cannot send to it (`550 5.7.703 ... blocked by your organization using Tenant Allow Block List`) | | URL or file | The message is quarantined as high confidence phishing or as malware, respectively | | IP address | Dropped at the edge of the service | | Spoofed sender | Manual override of an allow from spoof intelligence | Expiry of block entries: for domains and addresses, files and URLs, entries expire after **30 days** by default (this can be set to 90 days or to never). Entries for spoofed senders, IP addresses and Teams **never expire**. How allow entries work, and why "just get them to allowlist us" has limits: - Administrators **cannot directly create allow entries for verdicts of malware or high confidence phishing**. For those, the message, URL or file must be submitted to Microsoft through the Submissions page (`https://security.microsoft.com/reportsubmission`) and confirmed clean; only then can an allow entry be created. Messages identified as malware or high confidence phishing are **always filtered, whatever the allow entries say**. - Direct allow entries for domains and addresses, and for URLs, can override only these verdicts: bulk, spam, high confidence spam, and phishing that is not high confidence. - Allow entries for domains and addresses, files and URLs are kept for **45 days after the filtering system last judges the entity clean**, and are then removed automatically (or an administrator sets them to expire ≤30 days after creation). Allow entries for spoofed senders never expire. Microsoft may automatically remove allow entries it considers unnecessary, and sends an alert when it does. - An allowed sender still goes through the rest of the stack. The message must also pass authentication, URL and file checks, because an allow entry skips only the filters tied to the allowed entity. - URL allows created through a submission automatically cover variations and sub-paths of the reported URL. What this means for a sender: if your mail is judged high confidence phishing at a customer's tenant, the recipient's administrator cannot simply allowlist you. The usual causes are a URL or domain **blocked** in their TABL, or detection of spoofing or impersonation. The path goes through a submission to Microsoft by the administrator. Ask the recipient's administrator to submit the message as a false positive; Microsoft's review may create the allow entry. ## FAQ material relevant to external senders Microsoft's anti-spam FAQ documents these causes when legitimate mail is sent to Junk at Microsoft 365, and their fixes: | Cause | Fix | |---|---| | Authentication failure (SPF, DKIM or DMARC, leading to compauth fail) | Correct SPF, DKIM and DMARC for the sending domain | | Sender reputation (history of the IP address or domain, blocklists, low volume) | Check third-party blocklists and a valid PTR record, and review [SNDS](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp) | | Content triggers (too many links, URL shorteners, form tags, embedded scripts, image-only messages) | Review the content; the recipient may have ASF options turned on | | BCL met the tenant's threshold | Not spam, but a bulk classification; reduce complaints, or the recipient tunes the threshold or safe senders | | Recipient overrides (mail flow rule, block list in a policy, user's Blocked Senders) | Only the recipient can remove them | | An intermediate filtering service hides the true source IP address | The recipient turns on Enhanced Filtering for Connectors ("skip listing") | Microsoft's own list of outbound best practices for reaching Microsoft 365: - The sending domain resolves in DNS. (**With no A or MX record, mail is routed through Microsoft's high-risk pool, whatever its content.**) - The source IP address has a PTR record. - HELO or EHLO and MAIL FROM are consistent and based on a domain, and HELO matches the PTR record. - SPF is correct. - Mail is **DKIM-signed with relaxed canonicalization**, because strict header canonicalization can break when mail passes through the service. - WHOIS records are accurate. - Bounces use the format of RFC 3464. - Addresses that return an NDR as nonexistent are removed. - SNDS is monitored. Outbound throttling inside the service matters when a compromised customer sends through Microsoft. A user who sends >50% spam within a time window is blocked from sending, and outbound spam is routed through the **high-risk delivery pool** (separate IP addresses) to protect the normal pool. ## Related articles - [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements), on consumer Outlook.com policies, error codes and the 2025 authentication mandate - [Microsoft Escalation Channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels) - [Microsoft SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp) - [Authentication-Results Header](https://emailmarketing.net/learn/authentication/authentication-results-header), the RFC 8601 baseline that Microsoft extends # Microsoft Outlook.com Sender Requirements > Outlook.com postmaster policies, the May 2025 high-volume (>5,000/day) SPF+DKIM+DMARC mandate (Junk folder or 550 5.7.515 rejection, depending on the Microsoft source), connection limits, and SMTP error code reference. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/microsoft-sender-requirements Microsoft's postmaster guidance for senders delivering to consumer Outlook.com mailboxes (outlook.com, hotmail.com, live.com, msn.com). It covers the authentication mandate for high-volume senders announced in April 2025 and enforced from **May 5, 2025**, plus the standing technical and policy requirements that apply to all senders. Comparable mandates exist at Yahoo (see [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)) and Gmail; Microsoft's own sources disagree on whether non-compliant high-volume mail is junk-foldered or **rejected at SMTP time** with `550 5.7.515` — see [Enforcement behavior and timeline](#enforcement-behavior-and-timeline). ## High-volume sender requirements (effective May 5, 2025) Applies to **domains sending more than 5,000 emails per day** to Outlook.com. Enforcement is at the **sending-domain** level. | Mechanism | Requirement | |---|---| | SPF | **Must pass** for the sending domain. The domain's DNS record must accurately list authorized sending IP addresses/hosts. | | DKIM | **Must pass** to validate email integrity and authenticity. | | DMARC | Publish **at least `p=none`**, and the message must **align with either SPF or DKIM (preferably both)**. | ### Enforcement behavior and timeline - **April 2025 (announcement)**: senders urged to audit and update SPF, DKIM, and DMARC records before enforcement. - **Tech Community announcement (published April 2, 2025; updated April 30, 2025)**: the original text said that after May 5, 2025, non-compliant high-volume mail would be **routed to the Junk folder**, with rejection "in the future (date to be announced)". The April 29 update struck that paragraph and replaced it: "we have made a decision to **reject** messages that don't pass the required authentication requirements … This change will state taking effect on May 5th as originally stated." The same post's unstruck "What's Changing?" section still says "Non‐compliant messages will first be routed to Junk. If issues remain unresolved, they may eventually be rejected," so the post is internally inconsistent. - **Outlook.com postmaster Policies page (no published or updated date shown; retrieved September 11, 2026)**: "Messages from high-volume senders that do not meet these requirements will be sent to the junk folder. If issues remain unresolved, messages may be rejected" with the `550; 5.7.515` error below, "Effective May 5th, 2025". - **The two sources disagree.** The Tech Community update says rejection from May 5, 2025; the postmaster page says the Junk folder first, rejection possibly later. The postmaster page gives no date, so which one is newer can't be established from the pages alone. Plan for either outcome: non-compliant mail may land in Junk or be rejected. - Rejection string (given by both sources, for messages that are rejected): `550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` - Outlook additionally "reserves the right to take **negative action**, including filtering or blocking — against non-compliant senders, especially for critical breaches of authentication or hygiene." - Senders below 5,000/day are not initially targeted by enforcement, but Microsoft states all senders benefit from the same practices; small-sender enforcement is not ruled out. ### Hygiene recommendations for large senders Published alongside the mandate as best practices (not SMTP-enforced, but grounds for negative action): | Practice | Detail | |---|---| | Compliant P2 (Primary) sender addresses | The **From or Reply-To address must be valid, reflect the true sending domain, and be able to receive replies** | | Functional unsubscribe links | Easy, clearly visible opt-out, particularly for marketing/bulk mail; must be "easy to find and reliable when clicked" | | List hygiene & bounce management | Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages | | Transparent mailing practices | Accurate subject lines, no deceptive headers, recipients must have consented | To verify compliance, inspect the `Authentication-Results` header on mail received at an Outlook.com mailbox (Microsoft documents header reading at learn.microsoft.com, "message-headers-eop-mdo"). ## Standing policies for all senders From the Outlook.com postmaster policy page: - Comply with the Microsoft Services Agreement and Anti-Spam Policy, plus **CAN-SPAM** and the laws of the sender's jurisdiction; unsubscribe claims must be honored per FTC guidance. - The unsubscribe mechanism must be "clearly documented and easy for recipients to find and use." - **RFC 2821 / RFC 2822** (SMTP / message format) compliance is mandatory. - **Valid reverse DNS (PTR)** records required for sending IPs. - Mail from **dynamic IP space** is not accepted. - No insecure relays or open proxies. - **No namespace mining** (probing for valid addresses without sending mail). ### Connection and retry limits | Rule | Value | |---|---| | Simultaneous connections | Max **500** without prior arrangement | | Repeated non-delivery | Stop sending to an address after multiple non-delivery responses | | Permanent errors | Do **not retransmit** a message after any **500–599** SMTP response | ## SMTP error codes Outlook.com's documented deferral and rejection codes. `421` codes are temporary (reputation-based throttling); `550` codes are permanent. | Code | Meaning | Remediation | |---|---|---| | `421 RP-001` | Sending IP has exceeded the rate limit allowed (IP/domain reputation) | Improve reputation; slow down; escalate via sender support | | `421 RP-002` | Rate limit exceeded on this connection (reputation) | Same as RP-001 | | `421 RP-003` | Connection limit exceeded (reputation) | Reduce simultaneous connections (≤500); improve reputation | | `550 5.7.515` | Sending domain (>5,000/day) does not meet required authentication level | Pass SPF and DKIM; publish DMARC (`p=none` minimum) with alignment | | `550 SC-001` | Rejected for policy reasons — spam-like content or poor reputation | Review content and reputation; request mitigation | | `550 SC-002` | Namespace mining behavior detected | Verify machines aren't compromised; stop address-harvesting | | `550 SC-003` | IP appears to be an open proxy/relay | Close the relay; remediate before requesting delisting | | `550 SC-004` | IP blocked due to user complaints | Enroll in JMRP; remove complainers; request mitigation | | `550 DY-001` | Mail from dynamic IPs is not accepted | Send from static IP space (Spamhaus PBL lists dynamic ranges) | | `550 DY-002` | Sending pattern suggests a compromised or virus-infected host | Clean the host; contact ISP | | `550 OU-001` | Generic policy rejection (third-party listing) | Check/request removal via Spamhaus | | `550 OU-002` | Rejected for spam characteristics or reputation | Review content, authentication, and reputation | Additional documented remediation notes: verify reverse DNS; allow **48 hours** of propagation after updating sender-authentication DNS records when a domain's purpose changes; enroll in JMRP to see what recipients mark as junk. ## Reputation and monitoring tools Microsoft provides two free programs — **SNDS** (per-IP reputation data: complaint rates, spam-filter verdicts) and **JMRP** (a feedback loop returning the full message when a recipient marks it junk/phishing). Both are covered in [Microsoft SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp). Abuse can be reported to Microsoft at `report_spam@outlook.com` in RFC 2822 or ARF format. ## Related - [DMARC](https://emailmarketing.net/learn/authentication/dmarc) — alignment, record syntax, moving to enforcement - [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements) — the parallel 2024 Yahoo mandate - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) — why complaint and engagement signals drive filtering # Provider Escalation and Mitigation Channels > The cross-provider map of sender-support, mitigation, and unblock channels — Google, Yahoo, Apple, Microsoft — with the exact forms, required fields, eligibility gates, and the evidence to gather before any escalation. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels When a mailbox provider blocks or misfiles your mail after you have fixed the cause, you ask that provider for mitigation. Every major provider offers a different channel with different prerequisites, and all of them share one property: **escalation only helps senders who already comply**. Providers use these channels to clear the blocks that remain on traffic that has been fixed. They do not use them to override their filters for senders who have not fixed the root cause. Fix first, and escalate second. ## Universal preparation: evidence to gather before any escalation Every provider form or postmaster mailbox asks for part of the same set of evidence. Put it together before you open any ticket: | Evidence | Details | |---|---| | Exact error strings | The full SMTP reply text from your logs, word for word, including enhanced status codes, any provider identifiers (for example Gmail's `gsmtp` or `gcdp` suffix) and any URLs in the text | | Timeline | When the problem started, whether it is intermittent or constant, and what changed around that date (new IP addresses, a new customer, a jump in volume, a template change) | | Affected infrastructure | Sending IP addresses (one per line, because several forms read them that way), PTR records, sending domains, and which streams and customers use them | | Authentication state | Proof that SPF, DKIM and DMARC currently pass with alignment for the affected domain (an `Authentication-Results` header from a delivered message is ideal) | | Volume history | Daily volume to the affected provider over the preceding weeks. Providers check for spikes before they grant mitigation | | Reputation data | Current spam-rate and complaint figures from the provider's own dashboard ([Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), [Microsoft SNDS](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp), [Yahoo performance feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds)) | | Full headers of an affected message | Recent ones. Google requires headers from messages **less than 12 days old** | | Remediation already performed | What you fixed and when. The escalations that get mitigated are the ones that list concrete corrective actions | ## Google (Gmail) Google runs two escalation channels, and both are subject to a strict eligibility rule. The marketing page at `gmail.com/postmaster` only points to the Postmaster Tools console at `postmaster.google.com`. ### Eligibility gate (applies to both channels) Since June 2024, bulk senders with a user-reported spam rate **above 0.3%** are **not eligible for mitigation**. They become eligible again only after the spam rate in Postmaster Tools stays **below 0.3% for 7 consecutive days**. Full SPF, DKIM and DMARC authentication and a working one-click unsubscribe are prerequisites. See mitigation eligibility in [Gmail sender requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements#mitigation-eligibility). ### Channel 1: "Report delivery issue" inside Postmaster Tools (preferred) Google's newer escalation path, which you can track, is inside the Postmaster Tools console (documented at support.google.com/mail/answer/16740603). Use it for messages **wrongly classified as spam or phishing, rejected, or failing temporarily**. Prerequisites: 1. The domain is **verified** in Postmaster Tools. 2. The domain **complies with the sender guidelines** (SPF and DKIM authentication), and the domain in the `From:` header matches the domain you report under. Procedure: 1. Sign in to Postmaster Tools. 2. Open **Report delivery issue** (in the menu at the bottom left). 3. Select the domain from the dropdown, then **Create new report**. 4. Fill in the message details. The **"Get message info for me"** helper fills in the form for you: open the affected message, choose **Show original**, copy the raw message, paste it into the form field, and click **Get info**. 5. Submit the report. Track its progress under **Reported issues** on the domain dashboard, where each escalation has a status. Google publishes no commitment on response time for this channel. ### Channel 2: the Sender Contact Form (older escalation form for bulk senders) The standalone form at `support.google.com/mail/contact/bulk_send_new` ("Sender Contact Form") is still open. However, Google's own text on it now recommends using the **Report delivery issues** flow in Postmaster Tools instead, because it is easier to track. | Field | Required | |---|---| | Name | no | | Email address | yes | | Issue type (dropdown) | yes | | Short summary of issue | yes | | Detailed description | yes | | Email headers (depending on the issue type) | conditional | The issue-type dropdown offers: 1. "Your messages are incorrectly classified as Spam or Phishing" 2. "You get SMTP temp-fails or rejects" 3. "Other" The form states these rules: - Follow the Sender Guidelines **before** you request mitigation. - Submitted headers must come from messages **less than 12 days old**. - Leave **at least 2 weeks between submissions** so that changes can take effect. - Monitor results in Postmaster Tools rather than waiting for a reply. ### What Google mitigation can and cannot fix The channel handles misclassification and the blocks that remain on traffic that **complies** (for example, 5.7.x blocks that persist after remediation, or "Suspected spam" delivery errors in the dashboard). It cannot override the 0.3% gate, replace fixes to authentication, or guarantee inbox placement. For fixes you can make yourself, error by error, see [Gmail SMTP troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting). ## Yahoo (including AOL) Yahoo's entry point for escalation is `senders.yahooinc.com/contact/`, which leads to four paths: | Path | Channel | |---|---| | Problems delivering mail to AOL or Yahoo mailboxes | **Sender Support Request**, the Salesforce "Email a Specialist" form (embedded iframe: `https://vzmmemberservices.my.salesforce-sites.com/?fc=SSR`) | | Report abuse coming from AOL or Yahoo domains | The Report Abuse form (on the same Salesforce site, `?fc=ReportAbuse`). Include the full message text and headers | | Setting up and managing the Complaint Feedback Loop | Leads to the [CFL page](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop). When the page was captured, the contact page said its newer CFL signup form was temporarily down, and it fell back to the same "Email a specialist" flow in Yahoo Help | | General and developer questions | `mail-questions@yahooinc.com` (general) and `mail-api@yahooinc.com` (developer and API) | ### Sender Support Request: full field list The form offers **New request** and **Status update** (choose one; required). These fields were captured from the live form (\* marks a required field): | Field | Notes | |---|---| | Email address\* (entered twice) | Where Yahoo replies | | Name\*, role at the company\* | | | Company name\*, postal address\*, phone number\* | | | URL of the application or service\* | Its domain **must match the domain of your privacy policy URL** | | Mailing information for each active mail server\* | IP address, reverse DNS record and associated domain, with **one mail server entry per line**. For issues that involve several IP addresses, list every affected IP address, one per line | | Do you use an ESP?\* (yes or no), and which one\* | ESP customers name their provider | | Do you sign with DKIM?\* (yes or no) | | | Type of email sent\* | For example marketing, transactional, forum postings, newsletters, personal, other | | Subscription process\* | For example confirmed or double opt-in, single opt-in, opt-out, co-registration, affiliate marketing, other | | Subscriber count\* and emails sent per month\* | | | ISP checkbox | Check it if you are an Internet Service Provider | | Privacy Policy URL\* and Subscription Form URL\* | | | Do you remove bouncing addresses?\* (yes or no) | | | Unsubscribe-processing time\* | How long it takes to remove an address | | Error message (optional) | The exact text of the error you are seeing | | Additional information (optional) | Use it for the timeline and the account of your remediation | The form is protected by hCaptcha. Much of it asks about **list practices** (opt-in method, bounce handling, how quickly unsubscribes are processed): Yahoo evaluates the sender's whole program, not only the block. ### Realistic expectations - Yahoo publishes **no service-level agreement (SLA)** for responses from sender support. - There is **no formal whitelisting program**. For large launches or legal notifications, the same Sender Support Request is the channel. Yahoo may adjust reputation, but it never guarantees inbox delivery (see [Yahoo sender requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)). - For IP addresses or domains that were just blocked, submit the request **including the error and diagnostic codes** (deferrals prefixed with TS or PH, and 5xx codes; see [Yahoo SMTP error codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes)). - The Sender Hub also offers a **Sender Hub Insights** dashboard, available after you log in, that shows aggregated delivery statistics for your domain. Check it, and the [performance feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds), before and after you escalate. ## Apple (iCloud Mail) Apple has **no self-service unblock form, no allowlist and no FBL**. The escalation path is the postmaster mailbox **icloudadmin@apple.com**, for system administrators only. Contact it only after you have read the SMTP error (Apple's rejections include a URL that explains them) and fixed the problem against the published requirements. The message must include the company name, the email domain, the affected IP addresses, the SMTP errors word for word, and a description that says when the issue started. The full procedure and table of requirements are in [Apple iCloud Mail](https://emailmarketing.net/learn/providers/apple-icloud-mail). (Apple's en-US and en-CA pages for document 102322 have identical content.) ## Microsoft (Outlook.com and Office 365) Microsoft's channels are documented separately in [Microsoft escalation channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels): the SNDS review, the Outlook.com sender support and mitigation flow for blocks in the RP and SC series, and the Office 365 portal for delisting IP addresses. See also [Microsoft sender requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements) and [SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp). ## Other providers (quick pointers) - **Comcast Xfinity**: a block-removal form (limited to 5 requests a day) and a CSA phone line. See [Comcast Xfinity postmaster](https://emailmarketing.net/learn/providers/comcast-xfinity-postmaster). - **GMX, WEB.DE and mail.com**: a form to report blocklisting. Complaint feedback comes through CSA certification, not through a direct FBL. See [GMX and WEB.DE postmaster](https://emailmarketing.net/learn/providers/gmx-web-de-postmaster). - **Blocklist operators** (Spamhaus and others) have entirely separate escalation processes. See [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). ## Operating discipline 1. **Diagnose and remediate before you escalate.** Every provider answers a sender that does not comply by pointing back to its requirements page. 2. **One clean, complete submission** works better than repeated partial ones. Google explicitly asks for 2 weeks between submissions. 3. **Escalate from the provider's own data** (Postmaster Tools, SNDS, Yahoo feeds), so that your claim matches what the provider sees. 4. **Log every escalation** (channel, date, evidence submitted, outcome). Blocks that keep coming back at the same provider are a problem with your sending program, not with a ticket. To recover volume after mitigation, see [reputation monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). # Yahoo Complaint Feedback Loop (CFL) > How Yahoo's DKIM-domain-based Complaint Feedback Loop works: enrollment via Sender Hub, ARF report format, and operational rules. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop If you send mail to Yahoo users, you can receive a report each time one of them marks your message as spam. Yahoo's Complaint Feedback Loop (CFL) sends these reports in **ARF (Abuse Reporting Format)**. The reports let you **suppress complainers from further campaigns** and adjust your targeting and frequency. This matters because spam votes directly damage sender reputation, and count toward Yahoo's 0.3% complaint threshold (see [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)). ## Key properties | Property | Value | |---|---| | Basis | **Domain-based, DKIM only.** Only mail signed with DKIM is supported, because DKIM is how Yahoo identifies the sender actually responsible | | IP-based FBL | **Not offered.** Yahoo no longer supports CFL reporting based on IP addresses or CIDR ranges | | Report format | ARF | | Coverage | All consumer domains hosted by Yahoo, including AOL (thousands of hosted domains) | | Who should enroll | Bulk email senders. ESPs usually enroll DKIM domains on behalf of their clients | ## Enrollment (via Sender Hub) 1. **Create your Sender profile** on Yahoo Sender Hub (senders.yahooinc.com). 2. **Add and verify your domains**: the DKIM `d=` domains you sign with. 3. **Enroll each domain** in the CFL. Notes: - Enrollments made through Yahoo's **old form, from before Sender Hub, did not carry over**. You had to enroll again through Sender Hub. ARF reports for old enrollments stopped on **August 1, 2024**, with no grace period. - The **reporting address can be any email address you control**. Ownership is verified during enrollment, and you can reuse the same verified address to enroll more domains. - Enrolling the organizational domain does not enroll all its subdomains. **ARF reports are sent for the enrolled DKIM domains that match the signature** on the message that received the complaint. Enroll each signing domain. - To check the status of enrollments, edit them or delete them, go to **Manage Services**, then **Complaint Feedback Loop**, in your Sender Hub profile. ## Report mechanics - All reports use the **Abuse Reporting Format (ARF)** and contain **at least three MIME parts**: a plain-text part, machine-readable metadata in MIME format, and the headers of the original message. - Report messages arrive with: - From header display name: **"Yahoo! Mail AntiSpam Feedback"** - SMTP sender: **feedback@arf.mail.yahoo.com** - A DKIM signature with the domain **arf.mail.yahoo.com** (verify the signature before you trust the reports or automate actions on them) - When a message has several DKIM signatures, Yahoo evaluates all of them for the CFL (and also for DMARC alignment and reputation). ## Operational use - **Automate suppression.** Parse incoming ARF reports, and immediately unsubscribe or suppress the recipient who complained. Continuing to mail people who complained adds to the reputation damage. - **Monitor the complaint rate.** Comparing CFL volume with the volume delivered to Yahoo is the practical way to track your position against the 0.3% threshold. The `complaints` metric in the [Performance Feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds) gives an aggregate view. - **Diagnose segments.** A spike in ARF reports after a change in content, frequency or audience identifies the campaign or segment at fault. ## Related articles - [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements), including the 0.3% complaint threshold - [Yahoo Deliverability Performance Feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds), for aggregate complaint and placement metrics - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability), on how complaints affect reputation # Yahoo Email Deliverability Performance Feeds > Yahoo's server-side data feeds for senders: the Placement Feed (inbox/spam/folder/error/complaints) and Campaign Performance Feed (engagement metrics), with schemas and SLAs. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/yahoo-performance-feeds If you want to know whether your mail reaches the inbox or the spam folder at Yahoo, without relying on seed lists, Yahoo's performance feeds give you that answer. They are the only direct way to see ground-truth placement data at this major mailbox provider. The feeds report email placement and engagement **taken directly from the Yahoo mail servers**, rather than from tracking pixels or from seed or panel data. Yahoo presents this as more respectful of privacy than pixel tracking, and more representative than panel sources with small samples, given that Yahoo has hundreds of millions of active users. ## The two feeds ### Placement Feed The Placement Feed tracks where messages land (inbox, spam, folders), as well as errors and complaints. The data is filtered by an **allowlist of sender domains or sender IP addresses that the feed's user supplies**. | Dimensions | Metrics | |---|---| | `dkim_domain`, `sender_domain`, `ip_address`, `xheader`, `xheader_value` | `inbox_delivers`, `spam_delivers`, `folder_delivers`, `error_delivers`, `complaints` | The `xheader` and `xheader_value` dimensions let a sender break results down by a custom X-header (for example, a campaign ID added to outgoing mail). ### Campaign Performance Feed The Campaign Performance Feed measures engagement after delivery, broken down by sender domain and campaign. It is filtered by a **sender allowlist of sender domains**. | Dimensions | Metrics | |---|---| | `declared_template_namespace`, `declared_template_id`, `declared_template_goal`, `delivery_type`, `client`, `sender_domain`, `sender_email`, `engagement_date`, `user_local_hour`, `is_scrubbed` | `delivered`, `opened`, `link_clicked`, `deleted`, `marked_read`, `forwarded`, `starred`, `archived`, `moved`, `push_notif_opened`, `replied`, `marked_spam`, `dwell_time_read`, `dwell_time_glance`, `dwell_time_skim` | The engagement signals go deep. They include deletions, replies, spam votes, opens of push notifications, and categories of dwell time (read, glance and skim). These are the same kinds of signals that mailbox providers use internally for reputation (see [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). ## Feed specifications | Spec | Placement Feed | Campaign Performance Feed | |---|---|---| | Reporting granularity | Hourly | Hourly | | Delivery granularity | Hourly | Daily | | SLA (data latency) | 12 hours | 48 hours | | Retention | 30 days | 30 days | | File format | Avro | Avro | | Timezone | UTC | UTC | | Filtering | Allowlist of sender domains or sender IPs | Allowlist of sender domains | ## Access Yahoo publishes no pricing, no formal eligibility criteria and no way to enroll yourself. Contact **mail-questions@yahooinc.com** to learn about the program and its access requirements. ## How it fits a deliverability workflow - **Placement monitoring**: replace or check seed-list testing at Yahoo with actual counts of inbox and spam placement for each domain and IP address. Watch `error_delivers` alongside your SMTP logs (see [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes)). - **Complaint-rate tracking**: `complaints` divided by `inbox_delivers` approximates the rate that Yahoo checks against its **0.3% threshold** ([Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)). Combine it with the suppression of individual recipients through the [Complaint Feedback Loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop). - **Engagement optimization**: dwell time and action metrics (deletions compared with reads, `user_local_hour`) help decide on content, segmentation and send times for each campaign or template. - **Stream comparison**: the `dkim_domain` and `ip_address` dimensions show how separate mail streams perform compared with each other (see [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)). ## Related articles - [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements) - [Yahoo Complaint Feedback Loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop) - [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) # Yahoo Sender Requirements & Best Practices > Yahoo Mail's requirements for all senders and bulk senders (authentication, one-click unsubscribe, 0.3% complaint threshold) plus recommendations on list hygiene, infrastructure, and reputation. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/yahoo-sender-requirements If you send to Yahoo Mail addresses, your mail must meet Yahoo's published sender requirements to reach the inbox. Yahoo began enforcing them in **February 2024**, with a gradual rollout, and began enforcing the List-Unsubscribe policy in **June 2024**. The requirements apply to **all domains and consumer brands hosted by Yahoo Mail**, including AOL and the other domains Yahoo hosts. **Yahoo Japan operates independently** and is not covered. Mail that fails the requirements may be delivered to spam, or rejected outright with an error code (see [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes)). ## Requirements for all senders | Requirement | Detail | |---|---| | Authentication | Implement **SPF or DKIM at a minimum** | | Complaint rate | Keep the spam complaint rate **below 0.3%** | | DNS | Valid **forward and reverse (PTR) DNS records** for sending IP addresses | | Standards | Comply with **RFC 5321** and **RFC 5322** | ## Additional requirements for bulk senders Yahoo does not publish a volume threshold that defines a "bulk sender": a bulk sender is one that sends a significant volume of mail. For enforcement, a "sender" is evaluated at the level of the **authenticated domain or the From header domain**, and Yahoo uses all the information available (content, IP and so on) to review compliance. | Requirement | Detail | |---|---| | SPF **and** DKIM | Both must be implemented, not just one | | DMARC | Publish a valid DMARC policy of **at least `p=none`**, and **DMARC must pass**. A `rua` tag for aggregate reports is recommended. **Relaxed alignment is acceptable**: the From header domain must align with the SPF domain or the DKIM domain. | | List-Unsubscribe header | A working **List-Unsubscribe header that supports one-click unsubscribe** on marketing and subscribed messages. **The POST method of RFC 8058 is highly recommended**; the `mailto:` method is acceptable. | | Visible unsubscribe | An obvious, visible unsubscribe link in the message body that **does not require a login**. Body links may lead to preference pages, but they do not replace the header | | Unsubscribe honoring | Honor unsubscribe requests **within 2 days**, with no grace period beyond that | | Complaint rate | Spam rate below **0.3%**, calculated on mail delivered to the inbox | | DNS and RFC | The same forward and reverse DNS, and compliance with RFC 5321 and RFC 5322, as for all senders | ### Scope of one-click unsubscribe - It applies **only to promotional or marketing messages**, not to transactional messages (order confirmations, password resets). - If a class of message that does not require it generates many complaints, Yahoo suggests adding unsubscribe options anyway. - When the List-Unsubscribe header is set up correctly according to RFC 8058 **and** the sender has enough reputation and engagement, Yahoo webmail shows a blue "Unsubscribe" option next to the From address. Test it at https://mail.yahoo.com/. ### Spoofing counts against you Spoofed mail that uses your domain **counts toward Yahoo's enforcement thresholds**. If your domain is being spoofed, move DMARC to an enforcement policy (`p=quarantine` or `p=reject`). See [DMARC](https://emailmarketing.net/learn/authentication/dmarc) for how to reach Enforcement safely. ## Authentication details - **DKIM key length**: at least **1024 bits**, with **2048 bits recommended**. - **Multiple DKIM signatures**: Yahoo evaluates all signatures for DMARC alignment, for reputation calculation and for the Complaint Feedback Loop. Several signatures that do not pass do not add up to a DMARC pass. - **SPF**: publish the specific set of IP addresses authorized to send. - **ARC** (Authenticated Received Chain): recommended for mail that is forwarded. - Yahoo publishes `p=reject` for its own domains, so mail that spoofs From addresses such as @yahoo.com is rejected. ## Recommendations beyond the requirements ### List acquisition and hygiene - Send only to users who **specifically requested** the mail: no purchased lists, and no pre-checked opt-in boxes. - Use **double opt-in** (a confirmation click) to improve list quality. - Set expectations at signup (what mail to expect, how often, and what it looks like), and **keep to the frequency the list was set up for**, without raising it unexpectedly. - Monitor hard and soft bounces and inactive recipients, and **remove invalid recipients promptly**. - Periodically send a **reconfirmation email to inactive subscribers**. ### Infrastructure - Publish **valid, meaningful, non-generic reverse DNS (PTR) records** that reflect your domain name, and avoid names that look like dynamically assigned IP addresses. - **Separate mail streams**: do not send bulk or marketing mail from the IP addresses (or DKIM domains) you use for transactional mail, alerts or user mail. See [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation). - Keep servers patched, and make sure they are not **open relays or open proxies** (Yahoo rejects mail from these). - Add Border Gateway Protocol (BGP) routes for IP space you own. - **Connection management**: limit the number of messages per SMTP connection, reconnect if the connection ends without an error code, and open concurrent connections with restraint. Yahoo publishes no specific limits per connection or on concurrency. ### Monitoring and reputation - Enroll all DKIM domains in the [Complaint Feedback Loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop), and suppress complainers. - Yahoo's reputation inputs include **IP reputation, URL reputation, domain reputation, sender reputation, autonomous system number (ASN) reputation, DKIM signatures, DMARC authentication**, and user spam votes. - A good domain reputation alone does not guarantee the inbox. A combination of factors (high complaints, obfuscated URLs, missing rDNS, non-compliance with RFCs) can still send mail to spam. Rules set by individual users override the system's decisions. - Control spikes in traffic, and warm up new IP addresses gradually. See [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up). - Yahoo evaluates complaint rates for enforcement **continuously**, and domains with high complaint rates may be deferred. ### Compliance - Follow the **CAN-SPAM Act**: no false or misleading headers, and no deceptive subject lines. ## Operational FAQ points | Topic | Yahoo's answer | |---|---| | Whitelisting | There is no formal allowlisting program. For large launches or legal notices, submit a Sender Support Request. Reputation may be adjusted, but inbox delivery is never guaranteed. | | New IP addresses or domains blocked | Submit a Sender Support Request that includes the error and diagnostic codes from your logs. | | Maximum message size | Approximately **25 MB** of attachments. It varies with several factors, and neither users nor the Postmaster team can configure it. | | Reporting abuse by Yahoo users | Mark the message as spam in the product, or use Yahoo's Report Abuse form, with the full message text and headers. | | BIMI logo not displaying | Requirements: a valid SVG record for Brand Indicators for Message Identification (BIMI), a DMARC policy of quarantine or reject, bulk mail being sent, and enough reputation and engagement. Allow time for DNS propagation, and verify at https://mail.yahoo.com/ with the cache cleared. | ## Related articles - [Yahoo Complaint Feedback Loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop), to monitor the complaints that count toward the 0.3% threshold - [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) - [Yahoo Deliverability Performance Feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds) - [DMARC](https://emailmarketing.net/learn/authentication/dmarc) - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) # Yahoo SMTP Error Codes > Yahoo Mail's SMTP error/deferral categories (4XX temporary, 5XX permanent, TS* deferrals, PH* content blocks) with causes and recommended actions. Source: emailmarketing.net — https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes When Yahoo Mail defers or rejects your mail, its SMTP response tells you whether to retry and what to fix. Yahoo documents these errors (Delivery Status Notifications, DSNs) **by category rather than in an exhaustive table of individual codes**. Extended tokens such as `TS*` (temporary deferrals) and `PH*` (blocks for content or phishing) appear in the DSN text next to the numeric code. When you contact Yahoo about persistent errors, include the **exact error and diagnostic codes from your logs** in a Sender Support Request. ## Top-level classes | Class | Codes | Meaning | Retry? | |---|---|---|---| | 4XX temporary | 421, 451 | A temporary problem is blocking delivery | Yes, retry later | | 5XX permanent | 550, 553, 554 | A permanent problem, and the message is refused | **No.** Never retry, and remove addresses that generate 5xx bounces | ### Causes of 4XX (421 and 451) temporary errors - Yahoo observed unusual traffic patterns from your sending server's IP address. - The message had characteristics of spam. - Mail from your server has been generating complaints from Yahoo users. - Yahoo mail servers were busy at the time of connection. - Other suspicious behavior triggered **dynamic deprioritization** of your server. - Your name server was temporarily unavailable. - A temporary error prevented Yahoo from determining the authentication results for your domain. Action: review Yahoo's Sender Requirements & Recommendations (see [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)) and retry later. If you do not administer the mail server, contact its administrator. ### Causes of 5XX (553 and 554) permanent errors - The recipient address is invalid. - The message failed authentication against the DMARC or DKIM policy of the sending domain. - Yahoo does not accept the content, for policy reasons. - Other suspicious behavior led to permanent rejection of the SMTP connection. - **The IP address is listed by Spamhaus.** Check https://www.spamhaus.org. Action: do **not** retry. Consistent 5xx errors signal a widespread problem, and list managers should have a policy for removing addresses that generate 5xx bounces. ## Error categories | Category | Typical codes | Cause | Recommended action | |---|---|---|---| | RFC compliance failures | 4xx or 5xx | Duplicate headers, badly formatted headers, incorrect MIME types, and other violations of RFC 5321 and 5322 | Fix how messages are built so that they comply with the RFCs | | From domain that does not resolve (RFC 5321 or 5322) | 451 (timeout or SERVFAIL) or 554 (permanent failure) | The domain to the right of the @ in MAIL FROM or in the header From does not appear valid. Yahoo checks that it exists with an **SOA query**, so subdomains used in MAIL FROM or the header From need **SOA records**, not only A or MX records (even wildcard ones) | Make sure every subdomain used in From or MAIL FROM resolves and is covered by an SOA record | | Excessive user complaints | Deferral or rejection | Mail that generates too many spam votes from Yahoo users | Monitor your reputation (even senders with a good reputation get spam votes). If the error persists for more than 48h, or follows changes to content or policy, review outgoing mail for objectionable content or practices. On shared IP addresses, traffic from other domains may be hurting you, so consider dedicated IP addresses. Check that recipients opted in properly | | Excessive unsolicited messages | Deferral or rejection | Very high volume from a single IP address, which is typical of unsolicited bulk mail. Often a **new IP address ramped up too fast** | Do not resend until you have reviewed your practices. Warm up IP addresses slowly (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)). Confirm that all recipients asked for the mail. If the error persists for more than 48h, review content and practices | | Excessive unknown recipients | Rejection | A server sending to many invalid recipients. It may be an **open relay or open proxy**, and Yahoo does not accept mail from these | Secure your servers, remove bouncing addresses from lists, and examine outbound queues for abuse by spammers | | Authentication failures | Rejection | Failed SPF, DKIM or DMARC verification. Yahoo rejects mail for a DKIM failure when the signing domain publishes a policy requiring all its mail to be DKIM-signed, the domain is in the DKIM `d=` tag, and the message could not be authenticated (a missing or bad signature) | All senders: SPF or DKIM. Bulk senders: SPF, DKIM and DMARC. Senders on Microsoft 365 or Google Workspace: configure DKIM following their guides. Mailing lists (listservs): put the list address in From: and the actual sender in Reply-To:. Forwarded mail: consider ARC | | Content-based blocks | **PH\*** errors | Content Yahoo does not accept: viruses, phishing, ransomware, other malware, or links to any of these | Examine outbound queues for objectionable content, and secure servers against abuse | | Recipient does not exist | 554 (for example `554 delivery error: dd This user doesn't have a yahoo.com account (user@yahoo.com) [-5]`) | The Yahoo account does not exist | Never retry. Remove the address from your list, and confirm the address with the recipient directly | | Message temporarily deferred | **TS\*** errors (421) | Substantial complaints from Yahoo users, objectionable or spam-like content, **poor IP reputation (of the IP address or its /24 subnet)**, or unusual traffic patterns | Retrying later is acceptable. Review outgoing content. Servers that do not send bulk mail (personal, corporate, education or ISP servers) should check their queues for abuse by spammers. If the error continues over an extended period, submit a Sender Support Request with the error and diagnostic codes | | Resources temporarily unavailable | 4xx | Yahoo mail servers were busy at the time of connection | Usually brief. Retry after a short period | | Other policy errors | 550, 554 | A **null MX record (RFC 7505)**. A header that is too big (From, Subject, To). A Date out of range. A header value that cannot be decoded (From, Subject). An address that contains unusual or forbidden characters (for example `,$%?{}<>`) | Fix the record, header or address at fault | ## Reading a Yahoo bounce A Yahoo failure notice (from "MAILER-DAEMON" or "Mail Delivery Subsystem", with a subject such as "Failed Delivery") has two parts: the reason for the bounce, then a copy of the original message. Here is an example of the line reporting what the remote host said: ``` Remote host said: 554 delivery error: dd This user doesn't have a yahoo.com account (testing123@yahoo.com) [-5] - mta123.mail.mud.yahoo.com ``` The most common cause of failure is an invalid recipient address. If the account "doesn't exist", check the spelling. If bounces continue, the account may have been closed or moved. ## Related articles - [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements), the requirements whose violation causes most of these errors - [Yahoo Complaint Feedback Loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop), to prevent deferrals caused by complaints - [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up), to avoid "excessive unsolicited messages" errors on new IP addresses # Content and Design for Deliverability > Content-level filtering factors — spam-trigger-word myths vs reality, image/text balance, link practices, headers, subject lines, Gmail tabs, and engagement-optimizing design. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/content-and-design-for-deliverability Reputation and list quality weigh most in filtering decisions (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)), but content is the one filtering input you control directly on every message you send. Litmus reports that **70% of emails show at least one spam-related issue** that could keep them out of the inbox. Modern spam filters are machine learning systems, trained on spam and phishing patterns and adjusting in real time. Content rules are therefore best understood as avoiding spam patterns and optimizing engagement, not as a fixed checklist of keywords. ## Spam trigger words: myth vs. reality **Myth**: certain words ("free", "buy now", "sale") automatically send mail to spam, and avoiding a magic list of words guarantees inbox placement. **Reality**: specific trigger words are not a problem in themselves; what matters is how they are used. A genuinely free offer described as free is fine. A misleading "free" claim, or a "flash sale" that repeats every week, generates spam complaints and list churn, and it is those complaint and engagement signals that sink placement. Filters trained on real user feedback punish deceptive patterns, not vocabulary. Some content patterns still genuinely match spam: | Pattern | Why it hurts | |---|---| | Misleading subject lines or false claims | They drive complaints, and deception is the core signal filters target | | ALL CAPS and strings of exclamation marks | A strong, classic correlate of spam | | Excessive symbols ($$$, walls of emoji) in subjects | Same | | Misspellings (especially deliberate spellings meant to evade filters) | A historic spammer technique | | HTML-only messages with no text part | Poorly received by providers, and they render badly when images are blocked | ## Image, text and link balance - **Higher ratios of text to images and of text to links are better.** Too many images or links relative to text trigger spam flags. Filters are suspicious of emails dominated by images, because the all-image email is a classic technique for evading filters. - Providers commonly **block images by default**, so an email made only of images shows the recipient nothing, which hurts the engagement signals that drive placement. Always send **multipart (text and HTML)** or text only. - Include **alt text** on images. It preserves meaning when images are blocked, supports screen readers, and reduces complaints driven by frustration. - Readable layouts and adequate contrast affect engagement, and engagement affects placement. Broken links and missing images frustrate subscribers and reduce clicks. - Test rendering in the major clients before sending. A message that displays broken in one client silently loses the engagement signal from that provider. ## Link practices - **Link domains should match the sending domain**, or at least share the same organizational root. Links that point to unrelated domains are a phishing pattern. - **Avoid public URL shorteners.** Spammers use them heavily, and some filters penalize them outright. - Avoid **too many links**, and never send **broken links**. - Use a **branded click-tracking domain (with SSL)** rather than the shared tracking domain of an email service provider (ESP). It aligns tracking links with your brand or root domain, keeps the behavior of other senders on a shared tracking domain from affecting you, and measurably increases the likelihood of clicks. ## Headers and structural details - **The From domain must match the actual sending domain.** This is a DMARC alignment issue, not only a cosmetic one, and Microsoft's Hotmail is particularly strict. Even `mail.example.com` against `example.com` can be enough to send mail to the spam folder at some receivers. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc). - Gmail scrutinizes the **Message-ID and Received headers**. A malformed Message-ID (missing the `< >` brackets, or the wrong domain after the `@`) reads as spamware. If your infrastructure generates Message-IDs correctly, do not override them in application code. - **Personalize the To: field** with the recipient's actual address, and use the recipient's name in the greeting. - Include a working **unsubscribe link and List-Unsubscribe headers**. Several providers (notably Hotmail and Outlook) filter mail that lacks them, and one-click unsubscribe is a requirement for bulk senders at Gmail and Yahoo. An unsubscribe option that is hard to find turns into spam complaints, which are a far more damaging signal. - Include a **physical mailing address**, and ideally a link to your privacy policy (CAN-SPAM requires the unsubscribe mechanism and the postal address). ## Subject lines - The subject line is the first thing a recipient sees. It drives the decision to open, and opens drive placement. - Never mislead. A mismatch between subject and body is a top cause of complaints and a direct filtering signal. - Keep symbols to a minimum and avoid all caps. - **A/B test subject lines systematically.** Testing for a winning variant (with reporting on confidence in the winner) is the content experiment with the most leverage on open rates. Measure against the benchmark of an open rate of at least 33% (see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring) for the full table of thresholds). ## Gmail tabs (Primary, Promotions, Updates, Social, Forums) - Gmail's algorithms decide tab placement after delivery. Senders cannot choose a tab in advance, but content shapes the outcome. - **Promotions is not spam.** Studies show that emails in the Promotions tab did not suffer the feared decline in open rates, and landing there is normal for marketing mail. - Factors that push mail toward Primary: personalization (for example, inserting the first name, with fallbacks), a conversational one-to-one style, and a limited number of images and links. Heavily templated mail that is dominated by images and dense with links is sorted to Promotions. - Users can drag a message to another tab and tell Gmail to keep doing that, so asking engaged readers to move you to Primary is legitimate and effective. - Seed testing tools can predict the tab placement of a given message before sending (see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring)). ## Engagement-optimizing practices Content earns inbox placement indirectly, by producing the engagement signals that providers reward: - **Relevance and targeting matter more than anything else.** Segment and personalize. Content that does not match the segment shows up as unsubscribes and complaints. - **Make it easy to reply.** Send from an address that accepts replies, and invite them. Replies and forwards are among the strongest positive signals, and a real conversation "does wonders" for reputation. - **Set expectations at signup and honor them**, for example with a welcome series that states the content and frequency. Then match frequency to engagement: reduce frequency as a recipient's engagement drops. Sending often to unengaged profiles damages reputation, while sending too little to engaged ones only loses revenue. - **Provide value beyond offers** (educational content, useful information). Streams of pure promotion wear out engagement. - **Test content before sending.** Run messages through a spam filter or seed test (for example, Mail-Tester or commercial tools) to catch content flags before a live send, and change one variable per test. - Track opens, clicks, read time, deletions without reading, replies and forwards, complaints, and spikes in unsubscribes for each campaign. Content problems show up here first. Production speed is also a risk close to content. Teams now produce campaigns in 1–3 days (compared with 2+ weeks in 2024), and a sharply increased sending cadence can itself look suspicious to providers if volume jumps with it. ## Related articles - [Reputation Monitoring and Remediation](https://emailmarketing.net/learn/operations/reputation-monitoring), on metric thresholds and the testing and monitoring stack - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability), on how engagement signals feed filtering - [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability), on why wanted and expected content beats gaming the filters # Deliverability Metrics and Benchmarks > Concrete definitions of bounce, complaint, and engagement metrics, with the numeric thresholds major ESP guides consider healthy — and the corrective actions when a metric goes out of range. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/metrics-and-benchmarks To know whether your mail is healthy, you need to track the same signals mailbox providers use to decide whether it is wanted and expected (see [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). Below are the definitions of those metrics and the numeric targets published by major ESP guides: AWS SES, Postmark, Twilio SendGrid and Klaviyo, with open-rate bands from Braze and Bird. Where the sources differ, every figure is given with its attribution. The [canonical threshold table](#canonical-threshold-table) below collects the thresholds in one place. For dated industry survey figures to compare these targets with, see [Deliverability Benchmarks](https://emailmarketing.net/learn/reference/deliverability-benchmarks). It covers Validity's seed-measured inbox, spam and missing rates by provider and industry, and engagement benchmarks for each industry, all attributed to their vendors. ## Message lifecycle events Twilio SendGrid lists nine primary events in a message's lifecycle. The names are labels from its interface, but every sending infrastructure produces equivalent states: | Event | Definition | |---|---| | Processed | Message received by the sending system and queued for delivery | | Dropped | Not sent at all (for example, the address is on a suppression list, bounced before, or the content was flagged as spam) | | Deferred | Receiving server temporarily refused; delivery is retried (SendGrid retries for up to 72 hours) | | Bounce | Receiving server rejected the message; often indicates invalid or outdated addresses | | Delivered | Accepted by the receiving server. This does **not** mean Inbox; the message may still land in Spam | | Open | Recipient (or a proxy, see below) rendered the message | | Click | Recipient clicked a tracked link | | Spam report | Recipient marked the message as spam (a complaint) | | Unsubscribe | Recipient clicked an unsubscribe link | ## Bounces A **bounce** occurs when an email cannot be delivered to the intended recipient. - **Hard bounce**: a permanent failure. The address or domain does not exist, authentication fails (SPF, DKIM or DMARC misalignment), or there are severe reputation or blocklist issues. SMTP reply codes are in the **5.X.X** range (for example, 550). - **Soft bounce**: a temporary failure. The mailbox is full, the receiving server is overloaded or temporarily unavailable, or a temporary block applies to content or reputation. SMTP reply codes are in the **4.X.X** range (for example, 421, 451, 452). Sending systems typically retry soft bounces at intervals over several days before giving up. (Code 250 means the message was accepted and delivery is complete.) A high hard-bounce rate tells receivers that you do not know your recipients, which is a strong negative reputation signal. Remove hard-bouncing addresses immediately and never send to them again; see [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). ### Bounce composition (transactional mail) Postmark's transactional bounce data breaks down as follows: **80%** hard bounces, **10%** soft bounces, **3.5%** spam complaints and ISP blocks, **2.5%** delayed, **2.5%** auto-responders, and **1.5%** other (DNS errors, DMARC rejections, challenge verification, unsubscribes). Automate hard-bounce handling first. ## Complaints A **complaint** occurs when a recipient clicks "Mark as Spam" (or its equivalent) in their mail client. Some mailbox providers, but not all, report complaints back to senders through a **feedback loop** (see [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)). Accumulated complaints tell the provider you are sending spam, which directly harms deliverability and sender reputation. ## Opens and clicks: measurement caveats Open rates are inflated by **Apple Mail Privacy Protection (MPP)** and by Gmail's image prefetching, which load the open pixel without a person reading the message. SendGrid's guidance is to identify proxy opens (for example, by the prefetch user agents in event data) and to **prioritize click and conversion metrics over open rates** when you judge engagement. ## Canonical threshold table The thresholds below are collected from several sources, so other guidance can refer to one set of numbers. Where the sources genuinely differ, the range is given with attribution, and a stricter vendor "house number" is labelled as such rather than presented as consensus. ### Reading thresholds by scope Read this part first. The numbers below partly disagree because **they are not the same measurement.** A rate depends on three things, and two thresholds are comparable only if all three match: - **Who measures it**: the mailbox provider (Gmail or Yahoo, measuring what their users do), or the sending side (your ESP or MTA, measuring what your logs and feedback loops see). A provider sees only the complaints its own users file. A sender sees only bounces and the complaints feedback loops (FBLs) return. - **The reputation entity (network, IP or domain)**: reputation is tracked at all three at once. Blocklists list **IP addresses** (Spamhaus SBL and CSS) and **domains** (DBL) separately. Gmail Postmaster Tools reports **IP reputation** and **domain reputation** on separate dashboards. AWS SES enforces at the **account** level to protect its shared-IP **network**. - **The denominator**: complaints or bounces divided by mail **sent**, by mail **delivered**, or by mail **delivered to the inbox**. Gmail's spam rate is user reports divided by mail delivered to the inbox, counting only DKIM-authenticated mail, so a low Gmail number can hide mail Gmail has already routed to spam. SES and Klaviyo divide by mail delivered. The raw events are the same, but the percentage differs. | Scope | What it is | Who measures it | Example threshold | |---|---|---|---| | **Network or shared pool** | aggregate reputation of an ESP's shared IP space | sending infrastructure (AWS SES, per **account**) | SES pause at 0.5% complaint rate or 10% bounce rate | | **IP** | reputation of a single sending IP | blocklists; provider dashboards for IP reputation | Spamhaus listing; Gmail IP Reputation dashboard | | **Sender domain** | reputation of the From or DKIM domain the recipient sees | mailbox provider (Gmail or Yahoo, per **domain**) | Gmail 0.1% target and 0.3% ceiling (divided by mail delivered to the inbox) | **Which line you act on depends on your role:** - **Sender (you own the domain):** the mailbox provider's ceiling for each **domain** determines your inbox placement. Keep the Gmail and Yahoo complaint rate under **0.1%**, and never let it approach **0.3%**. The numbers on your ESP dashboard are an early warning, not the target. - **ESP operator (shared platform):** one number cannot protect every scope, so you need **three** guards: (1) a guard for the **network or pool** that protects the reputation of shared IP addresses (the SES-style line for each account); (2) a guard for each **domain**, so each customer stays under the Gmail and Yahoo ceiling; and (3) a tighter guard for each **tenant or IP address**, which catches a bad sender before either of the others trips (well below 0.3%, near 0.1% or your own house line). See [Account Enforcement](https://emailmarketing.net/learn/esp-operations/account-enforcement), [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) and [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture). - **Compliance:** a rising complaint rate signals a problem with **consent quality** before it signals a deliverability problem. Sustained complaints above about 0.1% point to a problem with permission or expectations, not a technical one (see [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods)). ### Complaint (spam) rate | Line | Value | Scope and who measures it | Denominator | |---|---|---|---| | Consensus healthy target | **< 0.1%** (≤ 1 per 1,000) | sender side, per account or list: AWS SES, Postmark, SendGrid | mail delivered | | Klaviyo house number (stricter) | **< 0.01%** (≤ 1 per 10,000) | sender side, per account or list: Klaviyo (deliberately conservative, not consensus) | mail delivered | | "High" in practice | even **0.08%** can be high | sender side: SendGrid | mail delivered | | **Gmail and Yahoo violation ceiling** | **0.3%**, which must never be reached | **mailbox provider, per sender domain**: the Google and Yahoo bulk-sender rules of Feb 2024 | **mail delivered to the inbox** (Gmail: DKIM-authenticated mail delivered to the inbox) | | SES enforcement (network or pool) | review at **0.1%**, pause at **0.5%** | **infrastructure, per AWS account**. It protects the shared-IP network and is not a target that keeps deliverability safe; see [Account Enforcement](https://emailmarketing.net/learn/esp-operations/account-enforcement) | mail delivered | **These lines are not directly comparable.** The provider measures the Gmail and Yahoo **0.3%** ceiling against mail delivered to the inbox for each domain, while the sender-side and SES numbers are measured against mail delivered, at the scope of an account or pool. Because Gmail's denominator excludes mail already sent to spam, **your ESP dashboard can read 0.1% of delivered mail while your Gmail spam rate is already near the 0.3% limit**. In practice, senders should aim for the provider target of **< 0.1%** for each domain. ESP operators should set their own auto-pause lines for pools and tenants below the 0.3% ceiling (near 0.1%), and never at SES's looser 0.5% network line. ### Bounce rate | Line | Value | Source and meaning | |---|---|---| | Klaviyo house number (aspirational) | total bounce rate **< 1.0%** | Klaviyo, stricter than consensus | | Healthy during warm-up | **< 2%** | Postmark (domain warm-up guide) | | Operating ceiling | keep the hard-bounce rate **under 5%** | AWS SES ("reasonable and attainable goal, but isn't a universal rule across all ISPs"); Postmark (for the whole domain) | | Absolute ceiling | **never exceed 10%** | Postmark: investigate immediately at or above this rate | | SES enforcement | hard bounces under review at **5%**, account may be paused at **10%** | AWS SES (per **account**, at network or pool scope); see [Account Enforcement](https://emailmarketing.net/learn/esp-operations/account-enforcement) | **Scope note:** the bounce rate is by nature a **sender-side** metric. No mailbox provider publishes a bounce ceiling, because bounces are what your MTA observes, not what recipients do. All the lines above are therefore measured by the sender. They differ by the entity they apply to: Klaviyo and Postmark quote quality lines for each **list** or domain, while SES enforces for each **account** to protect its shared-IP **network**. They also differ by denominator: hard bounces divided by mail sent, or total bounces divided by mail delivered. The complaint rate above is different, because there the binding ceiling is set by the mailbox provider for each domain. ### Open rate (after MPP) Since Apple Mail Privacy Protection, a raw open rate is really a rate of pixel loads, inflated by machine opens (see [Open and Click Tracking Mechanics](https://emailmarketing.net/learn/operations/open-and-click-tracking-mechanics) and [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). Read every open benchmark according to whether it **includes machine opens** (raw pixel loads, inflated by MPP) or **excludes machine opens** ("human" opens, with prefetches and bots filtered out): | Basis | Healthy | Spam-folder warning | Source | |---|---|---|---| | Machine opens included (raw) | **≥ 33%** | Not stated | Klaviyo | | Machine opens excluded (human, no prefetch) | **> 25%** (Braze) or **> 35%** (Bird) indicates widespread inbox placement | **< 20%** suggests placement in the spam folder | Braze, Bird; see [Open and Click Tracking Mechanics](https://emailmarketing.net/learn/operations/open-and-click-tracking-mechanics#opens-as-a-deliverability-signal--the-honest-reading) | The older GreenArrow band of "5%–20%+ for good senders" predates MPP and is outdated as a benchmark for raw opens (see [Two Worlds](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability)). Do not use it to judge a modern list with many Apple users. Whatever the number, judge **audience** engagement on clicks and conversions, not opens, and use the trend in open rate only as a rough signal of placement. ## Corrective-action triggers Postmark's domain warm-up guide pairs each metric breach with a concrete change in volume. The pairs are useful during any ramp-up (see also [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)): | Trigger | Action | |---|---| | Bounce rate exceeds 3% | Reduce volume 40–50% | | Open rate falls below 10% | Reduce volume 25–30% and refocus on engaged subscribers | | Spam complaints exceed 0.1% | Immediately identify and pause the affected segments | | Throttling or deferrals from a provider | Reduce daily volume 20–30% or spread sends across more hours | | Listed on a major blocklist | Stop sending immediately; delist; restart at significantly reduced volume | The same guide sets a general rule: **never** increase volume until you have reviewed performance **for each receiving provider**. If engagement and bounce rates look normal, the next day's increase is likely safe. ## Content quality as a metric input Beyond behavioral rates, receivers run **content filters** over every message. AWS SES gives this guidance for staying on the right side of them: - Modern content filters adapt continuously and do not use a fixed set of rules. Third-party services for seed and content testing can identify content that triggers filters before you send. - Check every URL in the message against DNS-based blocklists (DNSBLs) such as URIBL.com and SURBL.org. - **Avoid link shorteners.** When spammers abuse a shortening service and it is denylisted, every message that links through it is filtered. - Test that every link points where you intend. - Link to up-to-date Privacy Policy and Terms of Use pages from each email. - For content you send often (for example, daily deals), vary the content of each send. Repetitive identical content reads as spam. Postmark adds three recommendations: avoid shortened URLs (especially bit.ly), limit image-heavy layouts, and always include a plain-text alternative to the HTML part. Tiny changes can trigger content filtering. In one Postmark case, adding a phone number to a template triggered Gmail's spam filtering. When placement drops after a template change, revert the changes one at a time to isolate the cause. ## Related articles - [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies), on what to do with the addresses behind bad metrics - [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), on feedback loops and reputation monitoring tools - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) # Delivery Events and Diagnostics > The delivery-event taxonomy an ESP/MTA emits (processed, deferred, delivered, bounce, blocked, dropped, spam-report, open, click), plus insights reporting, delay diagnosis, and engagement-quality scoring — the instrumentation layer beneath the troubleshooting playbooks. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/delivery-events-and-diagnostics When you need to know what happened to a message, or why a campaign is underperforming, the answer starts in the event stream. Every message an email service provider (ESP) handles passes through a series of states. Each change of state is an **event** that the platform records and can stream to you. Bounce and complaint rates, estimates of inbox placement for each provider, delay analysis and engagement scores are all built from these events. The SendGrid Event Webhook is used below as the reference example, because it is fully specified. After the events come the reporting, delay diagnosis and engagement scoring built on them. For the thresholds these events feed and the corrective actions they trigger, see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). For step-by-step diagnosis, see [Delivery Troubleshooting Playbooks](https://emailmarketing.net/learn/operations/delivery-troubleshooting-playbooks). Both rely on the data described here. ## The event taxonomy Events fall into three families. **Delivery events** record what the sending system and the receiving servers did with the message. **Engagement events** record what the recipient did. **Account events** record changes of status at platform level. SendGrid's Event Webhook posts these as JSON. The names are SendGrid's labels, but every sending infrastructure produces equivalent states. ### Delivery events | Event | Meaning | What triggers it | |---|---|---| | **processed** | The platform accepted the message and can deliver it | The message was injected, validated and queued for the outbound mail transfer agent (MTA) | | **deferred** | The receiving server **temporarily** refused the message | A 4.x.x reply from the remote MTA (greylisting, a rate limit, "try again later"); the platform retries | | **delivered** | The receiving server accepted the message (`250 OK`) | The remote MTA returned a 2.x.x success reply to `DATA` | | **bounce** | The receiving server rejected the message | A 5.x.x permanent rejection (or a temporary failure after all retries were used up), returned during the SMTP session or later in an asynchronous delivery status notification (DSN) | | **blocked** | A *soft* bounce subtype: a temporary rejection for reasons of reputation, content or a technical problem | The remote MTA rejected the message, but not because the address is invalid; recorded as a bounce with `type: "blocked"` | | **dropped** | The **platform itself** refused to send, so the message never left | The recipient is on a suppression list (after an earlier bounce, unsubscribe, spam report or invalid address), the content was flagged as spam, a header or template was invalid, or a quota was exceeded | The distinctions an operator needs to know well: - **A deferral is not a bounce.** A deferral is a temporary refusal that the platform keeps retrying. It becomes a bounce only if the retries run out. Persistent deferrals are the classic sign of throttling or rate limiting (see [Delay and latency diagnosis](#delay-and-latency-diagnosis)). - **Bounced and blocked are different.** SendGrid records both as a `bounce` event and tells them apart with the `type` field. `type: "bounce"` is a hard bounce, which is permanent (for example, the address does not exist). `type: "blocked"` is a soft bounce: a temporary rejection because of reputation, content or a technical problem. In the Bounces & Blocks reports in the interface, a **Bounce** means an invalid email address (one that never existed or was deactivated), while a **Block** means the message was rejected for "content and reputation issues or technical failures." A block is the receiver's judgment of you, not of the address, and it can clear once the reputation or content problem behind it is fixed. See [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). - **A drop is the platform protecting you, or your own mistake.** The platform suppressed the send before transmitting it. Most drops are healthy, because suppressing a known-bad address protects reputation. A spike in drops for unexpected reasons (an invalid template, an exceeded quota) points to a defect on the sending side, not to a problem at the receiver. [Suppression-List Architecture](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture) explains how suppression is scoped. - **Delivered does not mean in the inbox.** `delivered` is posted when the receiving server answers `250 OK`. After that, the receiver may still put the message in the inbox, queue it, file it in the spam or junk folder, drop it silently, or (at Gmail) sort it into a tab, and the sending platform receives **no further signal** about any of it. The only later evidence is recipient engagement (opens and clicks). A high delivered rate with near-zero engagement is the typical sign of mail going to the spam folder. This is why inbox placement can only be *estimated*, with seed tests and provider postmaster dashboards, and never read directly from the delivery events. See [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion) and [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). ### Bounce classification For `bounce` events, SendGrid adds a `bounce_classification` that places the SMTP failure in a category of cause an operator can act on: | Classification | Meaning and what the operator should do | |---|---| | **Invalid Address** | The address does not exist or never existed. Remove it permanently (list hygiene) | | **Mailbox Unavailable** | The mailbox is full or temporarily unreachable. Often soft; may recover | | **Technical** | A DNS, connection, protocol or TLS failure, on the infrastructure side | | **Content** | The message content triggered a rejection or filtering. Fix the content or links | | **Reputation** | The reputation of the sending IP address or domain caused the rejection. Work on reputation | | **Frequency/Volume** | The sending rate or volume is too high for the receiver. Throttle (see [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning)) | | **Unclassified** | The failure could not be mapped to a category | The Content and Reputation categories feed engagement quality scoring (below) as an early warning, because they show that the receiver is judging you, not that the address is bad. ### Engagement events | Event | Meaning | What triggers it | |---|---|---| | **open** | The recipient displayed the HTML message | The open-tracking pixel loaded (Open Tracking must be enabled) | | **click** | The recipient clicked a tracked link | A wrapped link was followed (Click Tracking must be enabled) | | **spamreport** | The recipient marked the message as spam (a *complaint*) | The recipient's "mark as spam" action, passed on through the provider's feedback loop | | **unsubscribe** | The recipient clicked the global link to opt out of all mail | Subscription Tracking is enabled | | **group_unsubscribe** | The recipient unsubscribed from one suppression group | A group unsubscribe link or the preferences page | | **group_resubscribe** | The recipient subscribed to a group again | The preferences page (Subscription Tracking enabled) | Two cautions keep the engagement events from misleading you: - **Machine opens.** SendGrid sets `sg_machine_open: true` when Apple Mail Privacy Protection (MPP), rather than a person, generated the open. Filter these out of any real measure of engagement. Gmail's image prefetching also triggers opens without a person. See [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion) and [Non-Human Interactions](https://emailmarketing.net/learn/operations/non-human-interactions). - **spamreport is your complaint signal.** It is the part of the provider feedback loop that the sender sees. A sustained spamreport rate is the most damaging single input to reputation. See [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). ### Account events SendGrid emits `account_status_change` when the platform changes an account's standing for compliance reasons (phishing, high spam rates, "other bad behavior"). The `type` field gives the action, in increasing severity: | `type` | Effect | |---|---| | `compliance_suspend` | Blocks delivery; queues messages and bounces them at delivery time | | `compliance_deactivate` | Blocks delivery; rejects queues; deletes queued messages; bans the user after 48 hours | | `compliance_ban` | Blocks delivery; rejects and deletes queues; removes console access; cancels billing; removes IP addresses | | `reactivate` | Returns the account to active status | For how an ESP operator detects and contains these problems and applies the enforcement ladder, see [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts), [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) and [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture). ## Event payload fields The webhook JSON has a common set of fields plus fields specific to each event. These are the fields you correlate to answer "what happened to this message?" | Field | Type | Events | Meaning | |---|---|---|---| | `email` | string | all | Recipient address | | `timestamp` | int (UNIX) | all | When the event occurred | | `event` | string | all | Event type identifier | | `sg_event_id` | string | all | Unique event ID (URL-safe, ≤100 characters), the key for removing duplicates | | `sg_message_id` | string | all | Unique message ID, the key that joins all events for one message | | `smtp-id` | string | delivery events, plus bounce, spam and group events | Message-ID assigned by the originating system | | `category` | string or array | delivery and engagement | Custom tags the sender sets to organize mail | | `asm_group_id` | int | most | Unsubscribe (suppression) group ID | | `marketing_campaign_id` and `_name` | int and string | delivery and engagement | Campaign identifiers | | `pool` | object `{name, id}` | processed | IP pool the message was sent from | | `ip` | string | delivered, open, click, group unsubscribe and resubscribe | Sending IP address (delivered) or recipient IP address (engagement) | | `response` | string | delivered, deferred | Full text of the receiving server's response | | `reason` | string | bounce, deferred, dropped | Readable reason for the error or drop | | `status` | string `X.Y.Z` | bounce, dropped | Enhanced status code (see [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes)) | | `attempt` | int | deferred | Number of delivery attempts so far | | `type` | string | bounce, account | `bounce` or `blocked`, or the account status action | | `bounce_classification` | string | bounce | Category of cause (table above) | | `tls` | bool | bounce, delivered | Whether the connection used TLS | | `url` | string | click, group unsubscribe and resubscribe | The URL involved | | `url_offset` | int | click | Zero-based position of the link in the HTML (repeated URLs get different positions) | | `useragent` | string | open, click, group unsubscribe and resubscribe | Client program that generated the event | | `sg_machine_open` | bool | open | True if Apple MPP generated the open | | `unique_args` | object | delivery and engagement | Custom parameters supplied by the sender | > SendGrid warns never to put personal data in `category` or `unique_args`. The platform may use these fields for internal operations, they cannot be redacted, and they may be kept for a long time. A typical diagnostic query joins all events that share an `sg_message_id` and sorts them by `timestamp` to rebuild the full history of one message: processed, then deferred one or more times, then delivered, then opened. Another aggregates by `event`, `bounce_classification` and receiving domain to find which provider is rejecting which category of mail. ## Deliverability-insights reporting A diagnostic dashboard built from the event stream follows the "Deliverability Insights" pattern (in SendGrid, under **Stats**, then **Deliverability Insights**). Its data is roughly **48 hours** behind real time. It has four views: | View | Shows | |---|---| | **Overview** | Processed ("how much mail you tried to send"), Delivered (% accepted by mailbox providers), Bounce & Blocked (% not delivered) and Unique Opens (% of *delivered* messages that were opened), as trends over time | | **Mailbox Providers** | The same metrics for each provider (Gmail, Yahoo, Microsoft, AOL, …): delivered rate, open rate, and the split between bounces and blocks | | **Bounces & Blocks** | The two failure types separately: a **Bounce** is an invalid address; a **Block** is a rejection for reasons of content, reputation or a technical problem | | **Spam & Unsubscribes** | Complaints and opt-outs, by provider | The most important design choice is **segmenting by mailbox provider**. A combined delivered rate of 95% can hide a complete block at one provider. Reputation is held separately at each provider, so diagnosis and remediation must be done provider by provider too (see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring) and [Per-Provider Tuning Baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines)). SendGrid publishes these thresholds for reading this view: | Signal | Threshold | |---|---| | Block rate | Target **≤ 3%** at each main mailbox provider | | Spam report rate | **≥ 0.1%** at any single provider is excessive | | Bounce rate | **consistently over 5%** is concerning | | Sunset trigger | No opens or clicks for **3 months**: stop mailing that address | These are consistent with the thresholds gathered from several sources in [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks): the consensus of ≤0.1% complaints and <5% bounces, and the 0.3% line that Gmail and Yahoo treat as a violation. ## Delay and latency diagnosis "Delay" can mean two very different things, and confusing them sends the diagnosis in the wrong direction. **1. Delay at the receiver (deferrals and throttling).** The message has left the platform, but the receiver is holding it back through greylisting, rate limiting or "try again later". This shows up as **deferred** events with a rising `attempt` count and a 4.x.x `response`. The platform retries on a schedule. SendGrid retries deferred messages for up to **72 hours**, then turns the message into a bounce. Persistent deferrals concentrated at one provider mean you are going beyond what that provider accepts in rate or volume. The remedy is to shape traffic for that receiver (reduce concurrency or rate, spread the send over more hours), not to retry more. See [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) and [Greylisting (RFC 6647)](https://emailmarketing.net/learn/rfc/rfc6647-greylisting). **2. Delay on the platform or at injection (stuck in Processing).** The message never reaches a receiver; it stays in the **processed** state. SendGrid documents several causes: - **A volume limit on a new dedicated IP address.** A volume cap applies for the first **3 days** on a new dedicated IP address, to prevent abuse. Increase volume gradually with the [IP warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up) process. - **A compliance hold.** For an account under review, or one where unusual activity was detected, sending is paused until the Compliance team confirms. - **Backpressure in the MTA queue.** Very high sending volume can back messages up in the outbound MTA queue. Pause sending or bring another IP address online. - **Suspension of a dormant account.** Accounts with no logins are suspended automatically. Messages stay pending for up to **72 hours**. If the underlying problem is not resolved by then, they become **hard bounces**. **3. Transport latency (integration and network).** The message is slow getting into the platform. SendGrid's guidance focuses on throughput and the network path: - Use the official client libraries (C#, PHP, Ruby, Node.js, Python, Go, Java) rather than code written from scratch. - SMTP throughput: up to **5000 messages per connection**, and up to **1000 `To:` recipients per message** (through the `x-smtpapi` header). - Open more concurrent connections, up to a recommended **maximum of ~10 concurrent connections**. - Network diagnostics: `hping` and `Test-NetConnection` measure response time and TTL, and **anything above ~150 ms** of response time is a first warning sign. Traceroute mode shows the latency at each hop; watch for sudden jumps between hops. Header analyzers (such as Google's) show the message's path through each MTA and how long it waited at each hop. Wireshark captures the SMTP conversation for close inspection. Diagnose in this order. Check the `event` state first. **processed** points to a platform or compliance issue; **deferred** points to throttling by the receiver; **delivered but no engagement** points to the spam folder, which is a placement problem, not a delay. Use transport latency tools only once you have confirmed the message is leaving the platform normally. ## Engagement-quality scoring The highest level of aggregation turns the whole event stream into a single health score. SendGrid's **Engagement Quality (SEQ) API** is the reference example. It returns a score from **1 to 5**, where higher means better engagement and deliverability. The score lets an operator rank senders and subusers at scale and spot a decline before it becomes a reputation incident. A score is generated only with **open tracking enabled** and **≥ 1,000 messages sent in the previous 30 days**. Scores are kept for a maximum of **90 days**. The endpoints return scores for the account and for each subuser. The score combines five weighted components, which are the event signals described above, condensed: | Component | What it measures | |---|---| | **Engagement Recency** | The % of unique addresses mailed in the past **30 days** that also engaged (opened or clicked) in the past **90 days** | | **Unique Open Rate** | The lowest rate over the last **7 and 30 days** at the **top 5 mailbox providers**, excluding Apple machine opens and messages not delivered | | **Bounce Rate** | The permanent bounce % over the last 7 and 30 days, using the **higher** (worse) of the two | | **Bounce Classification** | Gives weight to bounces classified as **Reputation** or **Content**, the categories where the receiver is judging you | | **Spam Rate** | Recent spam complaints over a **7-day** window | The design shows what a platform actually treats as quality: recent engagement (are you mailing people who still want the mail?), real rather than machine opens at the providers that matter, permanent bounces moving in the wrong direction, reputation and content bounces in particular, and complaints. An ESP can use these scores to group subusers into [IP pools](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), flag underperforming senders for [outbound monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring), and decide when to move senders between shared and dedicated infrastructure. ## Related articles - [Delivery Troubleshooting Playbooks](https://emailmarketing.net/learn/operations/delivery-troubleshooting-playbooks) - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) - [Enhanced Status Codes (RFC 3463)](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes), for reading the `status` field - [Delivery Status Notifications (RFC 3464)](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications), the format of asynchronous bounces - [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion), on why opens and clicks mislead - [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) - [Complaint Feedback Loops (RFC 6449)](https://emailmarketing.net/learn/list-management/complaint-feedback-loops) - [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring) # Delivery Troubleshooting Playbooks > Symptom-driven decision procedures (symptom → hypothesis → discriminating test → fix) for the four delivery failure modes — not delivered, delayed, in spam, missing — with per-provider branches and a scenario library. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/delivery-troubleshooting-playbooks When a customer or a dashboard reports a delivery problem, start from the symptom and run the test that tells the likely causes apart. Each playbook below gives that test and says where each result leads. A checklist tells you what is true about reputation, content or infrastructure. Diagnosis works differently: you narrow the possible causes one test at a time. The playbooks are written so that a person or an automated agent can follow one from the top and stop at the first branch that matches. The playbooks point to more detailed material: the error code catalogs for [Gmail](https://emailmarketing.net/learn/providers/gmail-troubleshooting) and [Yahoo](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) and the [enhanced status codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes), the [reputation monitoring stack](https://emailmarketing.net/learn/operations/reputation-monitoring), [Microsoft filtering internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals) and the [escalation channel map](https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels). When the diagnosis finds systemic damage, [reputation incident recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery) covers what to do next. ## Step 0: was the message accepted? Every delivery problem belongs to one of two very different classes, and the first job is always to find out which. Do not run a spam-placement playbook on a message that never received a 250. Do not run a bounce playbook on a message that was accepted and then placed in the junk folder. | | **Not accepted** (transfer failed) | **Accepted** (transfer succeeded) | |---|---|---| | SMTP evidence | 4xx (deferred, will retry) or 5xx (bounced, gave up) | `250 ... OK` recorded in your logs or your MTA | | Recipient sees | Nothing, or the sender receives a non-delivery report (NDR) or bounce | The message is somewhere on the recipient's side | | Postmark event | `Bounced`, `Delayed`, `Queued`, `Processed` | `Delivered` | | Runs playbook | **A** (not delivered) or **B** (delayed) | **C** (in spam) or **D** (missing) | **How to establish acceptance:** - **In your own MTA or ESP logs:** read the last SMTP response for that recipient. A `250` means the receiver took responsibility for the message. Any other response means it did not. - **API senders (the Postmark model):** a `Delivered` event means the remote server returned `250 2.0.0 OK`. `Delivered` means acceptance, not inbox placement: the message can still go to spam or be dropped later. `Processed` means the message was handed to the sending MTA and is waiting for the remote server's verdict. `Queued` means the platform accepted the message but has not sent it yet. Check whether the account or stream is paused for high bounce or complaint rates, and check the platform's status page. - **Microsoft 365 on the recipient's side:** run a **message trace** (Exchange admin center, then mail flow, then message trace). `Delivered` in the STATUS column means accepted. For any other status, the Details view gives a "How to fix it" explanation. Trace data appears 10 min to 1 hr after sending. Traces older than 7 days are available only as CSV and can take up to an hour to generate. If you cannot find the message in your logs at all, the problem happened before delivery: the send never took place. Common reasons are a paused stream, an API error, a suppression-list hit, or a filter or rule on the sending side. Check the sending platform's own response code before you blame the receiver. --- ## Playbook A: message not delivered (bounced or rejected, 5xx) **Symptom:** the sender's logs show a permanent failure, or the sender received an NDR. The receiver refused the message outright. The signal that tells causes apart is the **rejection text**, not the numeric code alone. Read the full SMTP response and the enhanced status code ([RFC 3463 class](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes): `5.1.x` for addressing, `5.7.x` for policy or security). Route by what the text says: | Rejection says… | Hypothesis | Test that tells causes apart | Fix | |---|---|---|---| | "user unknown", "mailbox does not exist", `5.1.1`, `550 5.1.1` | Invalid recipient | Is it one address or many? One points to a typo or a churned address. Many point to a list-quality problem | Suppress the address (a hard bounce means permanent suppression). If many: audit the acquisition source and see [list hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) | | "quota exceeded", "mailbox full", "out of storage", `5.2.2` | The recipient's mailbox is full | A single recipient, and temporary | Treat it as a soft, temporary failure: retry, then suppress after repeated failures. It does not reflect on your reputation | | Names a **blocklist** (Spamhaus, Barracuda, SpamCop, SURBL) or says "listed in DNSBL" | The IP address or domain is blocklisted | A DNSBL lookup on every sending IP address and domain | Find the root cause first, then request delisting. See [blocklists](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) and the [delisting workflow](https://emailmarketing.net/learn/operations/reputation-monitoring#blocklist-delisting-workflow). Do not request delisting before you fix the behavior | | "banned sending IP", "access denied", reputation language, `5.7.x` | The provider has blocked you for reputation | Is it one provider or all of them? One provider with a red dashboard points to reputation at that provider | Follow the provider branch below, and escalate through the [provider's channel](https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels) | | Mentions content, links or attachments, "message content rejected", or "spam" in a 5xx | A content filter blocked the message | Run a seed test or a spam check on the exact message, and remove elements one at a time | Fix the content ([content and design](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability)): remove URL shorteners and fix the HTML | | Authentication language: SPF, DKIM or DMARC failure, `5.7.1`, `5.7.26`, "unauthenticated" | Authentication failure | Inspect `Authentication-Results` and check the DMARC policy | Fix alignment ([DMARC](https://emailmarketing.net/learn/authentication/dmarc)). Authentication is mandatory for bulk senders at Gmail and Yahoo | | HELO or EHLO error, `501 5.5.4`, "invalid HELO", nonroutable IP address | Connection identity or reverse DNS (rDNS) | Verify that a PTR record exists and matches, and that HELO gives a fully qualified domain name (FQDN), not a private IP address | Fix rDNS and HELO. Receivers, including Microsoft, reject mail that advertises `10.x`, `172.16–31.x` or `192.168.x` | | "too many messages", or rate or connection language (`421`, `4.7.x`, which is technically a deferral) | Rate limiting | See Playbook B | Slow down. See [MTA delivery tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) | **Provider-specific 5xx branches** (for the reputation and content rejections in the table above): - **Gmail:** [Gmail SMTP Troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting) lists the full catalog of `421` and `550-5.7.x` codes with a fix for each. Gmail's own guidance on non-delivery also lists sending more than 500 messages a day or one message to more than 500 recipients (the limits for personal Gmail accounts), a recipient that does not exist, a recipient whose storage is full, and a malformed HELO or EHLO. - **Microsoft:** for `550 5.7.606-649 Access denied, banned sending IP [x.x.x.x]`, use the **delist portal** at `sender.office.com` ([Microsoft escalation channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels)). For diagnosis from headers, the spam confidence level (SCL) and the bulk complaint level (BCL), see [Microsoft filtering internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals). Microsoft's full list of NDR codes is in its guide "Email non-delivery reports in Exchange Online." - **Yahoo:** the code catalog is in [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes). - **B2B and corporate gateways** (Proofpoint, Mimecast, Barracuda, M365 tenants): these use entirely different reputation systems and delisting portals. See [B2B gateway deliverability](https://emailmarketing.net/learn/providers/b2b-gateway-deliverability). --- ## Playbook B: message delayed or deferred (4xx, "Delayed", stuck in the queue) **Symptom:** the message is not delivered yet but has not failed permanently. The sender's queue shows `4xx` or `421`, or Postmark shows `Delayed`: the remote server asked to wait, and Postmark retries most domains every ~10 min for up to 12 hours before it bounces the message. The receiver is saying "not now", and the diagnosis is about why and for how long. Deferrals have four common causes. They look identical at first, and each needs a different response: | Cause | Signature | Test that tells causes apart | Response | |---|---|---|---| | **Greylisting** | The first message from a new combination of IP address and sender is deferred, and it clears when retried from the same IP address | Does it deliver on the next attempt with no change? Is the deferral tied to the combination of IP address, sender and recipient? | Do nothing except retry from the same IP address. This is why keeping a sender on the same pool or IP address matters. See [greylisting](https://emailmarketing.net/learn/rfc/rfc6647-greylisting) | | **Throttling or rate limiting** | Deferrals rise with volume and concentrate at one provider: `421`, "try again later", `4.7.28` | Do deferrals grow with your sending rate? Is it one provider? | Reduce concurrency and rate to that destination, and back off. See [MTA delivery tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) and [per-provider baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines) | | **Reputation deferral (before a block)** | Sustained 4xx responses that do not clear, a provider dashboard that is getting worse, often before a hard block | Is your reputation in Google Postmaster Tools (GPT) or Smart Network Data Services (SNDS) trending down? Does the deferral text mention reputation? | Treat it as an early incident: run Playbook C and see [incident recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery). Do **not** simply retry harder | | **Recipient server down, or network trouble** | Deferrals to one destination domain whatever your rate, and connection timeouts | Is it one destination domain, temporary, and unrelated to your volume? | Wait and keep the normal retry schedule. Microsoft's own guidance names "the intended destination isn't responsive" as the most likely cause of a delay | **The critical mistake to avoid** is responding to a reputation deferral by retrying more aggressively. Retrying hard against a provider that is deferring you for reputation turns a soft block into a hard block. To tell throttling from a coming block, slow down. A throttle clears when you slow down. A reputation problem persists, and the dashboard gets worse. **Microsoft:** `host xxxx.outlook.com [x.x.x.x]: 451 4.7.550 Access denied, please try again later` means that Microsoft has temporarily restricted the IP address because it detected suspicious activity and is evaluating it. The restriction lifts automatically once the traffic is judged acceptable. Reduce volume, let the evaluation run, and do not escalate immediately. **Deferrals of one-time passwords (OTP) and other transactional mail** need special handling. For the user, a deferred one-time password has failed, even though SMTP still considers it in transit. If transactional mail shares a stream or IP address with marketing mail, and the marketing volume triggers throttling, the OTP is deferred too. This is the argument for [stream separation](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), with transactional mail on its own subdomain and pool. To diagnose it, compare the timestamps of OTP deferrals with the times of marketing send bursts. --- ## Playbook C: accepted but placed in spam or junk **Symptom:** the logs show `Delivered` or `250`, but the message is in the spam or junk folder, or in a Gmail tab that the sender does not count as the inbox. This is the placement problem, and it is the most common ticket a deliverability consultant receives. There is no SMTP signal: the receiver accepted the message and then decided where to route it. The tests that tell causes apart are dashboards, headers and seed tests, not response codes. ### C-1. Scope the failure first The most valuable early test is whether the problem affects **one provider or all providers**. The answer splits the possible causes in two: - **All providers point to a cause on the sender's side.** Every filter sees an authentication, content, list or reputation problem. Start with authentication and content. - **One provider points to that provider's reputation or filter.** Go to the provider branch (C-3). A message that reaches the inbox at Yahoo but goes to spam at Gmail does not have a content problem. It has a Gmail reputation problem or a Gmail personalization problem. Establish the scope with a **seed or inbox-placement test** across providers (Litmus, Validity/Everest, GlockApps, Mailgun), and keep its limits in mind. Seed addresses have no engagement history with you, so they miss the personalization for each user and tend to be conservative (see [the limits of placement measurement](https://emailmarketing.net/learn/operations/reputation-monitoring#4-seed--inbox-placement-testing) and [tracking distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). Compare seed results with Postmaster Tools and with live engagement at each provider. ### C-2. Tests on the sender's side (when mail goes to spam at every provider) Run these in order, and stop when a test reveals the cause: 1. **Authentication.** Inspect the headers of a message that was delivered to junk. `Authentication-Results:` must show `spf=pass dkim=pass` **and** DMARC alignment (the `From` domain matches the DKIM `d=` domain or the Return-Path domain). Every major provider flags unauthenticated mail as high risk, and the bulk-sender rules at Gmail and Yahoo disqualify it. Verify that SPF stays within the [10-lookup limit](https://emailmarketing.net/learn/authentication/spf), that DKIM verifies, and that a custom Return-Path is in place for alignment. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc). 2. **Complaint rate.** This is the most damaging signal. Postmark's working rule is that a complaint rate above **0.1%** (1 per 1,000) predicts a drop in deliverability, and Google enforces a hard ceiling of **0.3%** (see [Gmail requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements)). Check complaint data for each provider in [GPT](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools) and in [SNDS and JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp). 3. **Bounce rate.** A high rate of invalid addresses looks like a spammer's list practices. Postmark's working ceiling is a hard-bounce rate below 5%, and never above 10%. Klaviyo's stricter target is a total bounce rate below 1%, and Postmark's healthy rate during warm-up is below 2%. The full range, with each figure attributed, is in the [canonical threshold table](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#canonical-threshold-table). High bounces point to a list-quality problem that is damaging reputation. 4. **Content.** Run the exact message through a check based on SpamAssassin (Postmark Spam Check's target is a score below 5, and negative is better) and through mail-tester. Common triggers are URL shorteners (bit.ly) instead of branded links, messages made only of images or with oversized images, broken or incomplete HTML, link and image domains that do not match the `From` domain, and a missing or broken unsubscribe link. If a **template change came just before the drop**, revert it step by step, removing one element at a time, to isolate the trigger. See [content and design](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability). 5. **Reputation.** Check domain and IP reputation in the provider dashboards and with DNSBL lookups. A poor rating here means the cause is accumulated history, not this one message. See [incident recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery). ### C-3. Placement branches for each provider (when mail goes to spam at one provider) | Provider | Test that tells causes apart | What it shows | Route | |---|---|---|---| | **Gmail** | [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools): domain and IP reputation (Bad, Low, Medium, High), the spam-rate dashboard, authentication pass rates | A drop in domain reputation from High to Medium predicts placement in the junk folder. Gmail personalizes for each user based on their contact history, so one Gmail user can receive a campaign in the inbox while another receives the same campaign in spam. Seed results that disagree with real placement are therefore expected | Send only to engaged Gmail users and encourage positive engagement. GPT shows no data below its volume thresholds, so diagnose through engagement instead | | **Microsoft** (Outlook.com and M365) | Inspect the headers: **SCL** and **BCL** in `X-Forefront-Antispam-Report`, and `compauth` | A high SCL means a spam verdict based on content or reputation. A high BCL means a penalty for bulk mail. The header tells you which filter fired. [Microsoft filtering internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals) decodes it in full | For a false positive, the recipient submits the message to Microsoft for analysis. Check the filter color in [SNDS](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp) (green, yellow or red) and any trap hits, and escalate through [Microsoft's channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels) | | **Yahoo and AOL** | [Yahoo performance feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds) and the complaint feedback loop (FBL) | Placement is driven by complaints, and Yahoo gives engagement a lot of weight | Suppress complainers and send only to engaged recipients. See [Yahoo requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements) | | **Apple iCloud** | There is no sender dashboard, so infer placement from seed tests and engagement | Mail Privacy Protection (MPP) inflates opens, so treat opens as unreliable. Placement depends on authentication and reputation | [Apple iCloud](https://emailmarketing.net/learn/providers/apple-icloud-mail) | | **B2B gateway** | The gateway's own IP reputation checker (ipcheck.proofpoint.com, barracudacentral.org) | Placement depends on the tenant policy set by the administrator and on the gateway's reputation data, not on consumer-style filtering | [B2B gateway deliverability](https://emailmarketing.net/learn/providers/b2b-gateway-deliverability) | ### C-4. Microsoft: the workflow for mail placed in Junk Microsoft documents this path for a false positive: 1. Confirm that the message was delivered (message trace STATUS = Delivered, not blocked). 2. Have the recipient **report the message to Microsoft** as a false positive for analysis. 3. Verify that the sender is not advertising a nonroutable IP address and is not failing reverse DNS. 4. Confirm that the From name and subject are transparent and that redirect domains are consistent: all links go to one domain, not to a scattered set such as `unsubscribe.bulkmailer.com`, `profile.excite.com` and `options.yahoo.com`. 5. For a systemic reputation problem, work with SNDS and sender support. --- ## Playbook D: message "missing" (accepted, not in the inbox, not in spam) **Symptom:** the logs show `Delivered`, but the recipient cannot find the message anywhere, neither in the inbox nor in spam. This is the hardest case to diagnose, because the receiver reported success. The possible causes, from most to least likely: 1. **The message is in spam or junk and the recipient did not look there.** This is the most common explanation. Have the recipient search every folder, including the Gmail tabs (Promotions, Updates, Social), Outlook's Focused and Other views, and Junk. Then run Playbook C. 2. **The message was filtered out or dropped after acceptance.** The provider accepted it and then discarded it through aggressive reputation filtering. The provider dashboard and, at Microsoft, a message trace reveal a filter verdict made after acceptance. This is a reputation problem: see Playbook C-3 and [incident recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery). 3. **A rule or a forward on the recipient's side.** An inbox rule moved or deleted the message, or a broken forward lost it. Microsoft's first triage step is to have the user check **Outlook on the web**. If the message is there but not in the desktop or mobile app, the problem is the app or a local rule, not delivery. For Outlook issues that affect a single user, run Microsoft's **Support and Recovery Assistant**. 4. **Delivery to the wrong address.** An alias or a typo happened to match a valid mailbox. Confirm the exact recipient address in your logs. 5. **A service incident.** Before a deep investigation, check the provider's service health (Microsoft 365 admin center, then Service health, or the provider's status page). A degraded receiving service delays or misroutes mail across the whole organization, and no fix on the sender's side is needed. **One user or many** is the key question in Playbook D. If one recipient is missing a message, the cause is the mail app, a rule or the address (use the tools above). If many recipients at one provider are missing messages, the cause is reputation or filtering (Playbook C). If many recipients across all providers are missing messages, the cause is authentication or an incident on the sending side. --- ## Scenario library (worked examples) Concrete tickets and the branch each one takes: | Ticket | Playbook | Test, finding and fix | |---|---|---| | "Delivered but spam at Gmail only" | C, one provider | A seed test confirms that only Gmail is affected. GPT shows domain reputation at Medium. Content is not the cause, because Yahoo delivers to the inbox. Send only to engaged Gmail users, encourage engagement, and expect recovery over weeks | | "Sudden Microsoft junk-foldering after years of inboxing" | C-3 Microsoft | The header shows a jump in SCL or BCL. SNDS turned yellow or red, or shows trap hits. A recent change in list or volume is the trigger. Suppress the bad segment, submit the false positive, and use [Microsoft's escalation channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels) | | "Transactional OTP deferred at Yahoo" | B, throttling | Deferrals coincide with a marketing burst on the shared stream. Move transactional mail to its own stream and pool, and the deferral clears | | "Open rates collapsed at one provider" | C, or a measurement artifact | First rule out [distortion from MPP and bot clicks](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion), since opens are unreliable after MPP. If clicks and conversions also fell, placement really dropped: run Playbook C | | "New IP: mail suddenly rejected / deferred" | A or B | Read the text. `5.7.1` citing the IPv6 guidelines means the authentication and PTR requirements in [IPv6 sending](https://emailmarketing.net/learn/operations/ipv6-sending). `451 4.7.550` from Microsoft means a throttle on a new IP address: let it ramp up, which takes weeks. Greylisting means retrying from the same IP address | | "Bounces spiked overnight, one provider" | A, reputation | Run DNSBL lookups and check the dashboard. If it is a blocklisting or a provider reputation block, fix the root cause and then follow the [delisting workflow](https://emailmarketing.net/learn/operations/reputation-monitoring#blocklist-delisting-workflow). If volume also spiked, suspect a [compromised account](https://emailmarketing.net/learn/esp-operations/compromised-accounts) | | "Recipient says never arrived, log says Delivered" | D | Search all folders first. Then ask whether one user or many are affected. For a single user, test Outlook on the web | --- ## Escalating to the provider (when self-service is exhausted) Before you open a provider channel, run the playbooks until you have a specific hypothesis backed by evidence. Provider support closes tickets that arrive without a diagnosis. Bring the sending IP addresses and domain, the exact SMTP rejection or NDR text, sample headers (`Authentication-Results`, `X-Forefront-Antispam-Report`), screenshots of the GPT or SNDS dashboards, the date the problem started, and what you changed around that date. [Escalation and Mitigation Channels](https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels) and [Microsoft Escalation Channels](https://emailmarketing.net/learn/providers/microsoft-escalation-channels) map the channels: Google's bulk-sender form and its eligibility condition (0.3% over 7 days), Microsoft's delist portal (`sender.office.com`) as distinct from sender support, Yahoo sender support, and Apple's `icloudadmin@` address. Each channel fixes only some problems. Delist portals clear IP blocks. They do not clear content or complaint problems, which correct themselves only after the sender's behavior changes. ## Related articles - [Reputation Monitoring and Remediation](https://emailmarketing.net/learn/operations/reputation-monitoring), including the delisting workflow - [Reputation Incident Recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery) - [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), on Postmark's 5-area framework: authentication, content, engagement, reputation and infrastructure - [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) - [Per-Provider Tuning Baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines) - [Gmail SMTP Troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting) - [Microsoft Filtering Internals](https://emailmarketing.net/learn/providers/microsoft-filtering-internals) - [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) - [Escalation and Mitigation Channels](https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels) - [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes) - [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) # List Hygiene and Sunset Policies > How to acquire addresses safely, validate them at signup, handle bounces and complaints operationally, and sunset unengaged recipients before they hurt reputation. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies The addresses on your list decide the metrics that mailbox providers use to score you (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)). Keeping those metrics healthy means managing each address through its whole life: how you acquire it, how you validate it at signup, how you handle its bounces and complaints, and when you stop mailing it because it no longer engages (sunset). ## Acquisition: dos and don'ts **Never rent, buy or scrape email lists.** The guides from all three ESPs agree, for concrete reasons: - Purchased lists contain large numbers of invalid addresses, which make hard bounce rates spike (AWS SES). - They contain **spam traps**: addresses placed specifically to catch senders who are not legitimate. Hitting one can damage delivery rates and reputation "irrevocably" (AWS SES). - Scraping or harvesting addresses (bots crawling websites for them) is especially risky, because none of the recipients opted in (SendGrid). Grow the list legitimately instead. Give people opportunities to provide their address voluntarily: landing pages that explain what the email program offers, display ads that lead to an opt-in, and explicit, documented consent before any sending (SendGrid). ## Validation at signup | Practice | Detail | Source | |---|---|---| | Double opt-in | Send a confirmation link at signup, and do **not** mail the address until it is clicked. This removes hard bounces caused by typos and proves intent. | AWS SES, SendGrid | | Syntax and MX validation | When the form is submitted, check that the address is well formed (`recipient@example.com`) and that the domain has valid MX records. | AWS SES | | CAPTCHA on signup forms | Prevents bots from signing up and poisoning the list. | SendGrid | | Detection of typos and disposable addresses | Validate at signup to flag disposable domains and suggest corrections for common typos (for example, through a validation API). | SendGrid | | Reject role and watchdog aliases | Addresses such as `postmaster@`, `abuse@` and `noc@` almost never sign up on purpose. They can be added maliciously as sabotage, and by custom they are reserved for people who watch for abuse. | AWS SES | | Guard content generated by users | Forum registrations and form submissions can be filled with spammers' content. Never put user input into outbound mail without checking it. | AWS SES | | Validation through the welcome email | Send a welcome email to every new address, and automatically remove addresses whose welcome email bounces. | SendGrid | A welcome message also sets expectations. Recipients who understand why they are getting mail complain less (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). ## Spam traps There are two kinds (SendGrid): - **Pristine traps (honeypots)**: addresses that never signed up for anything, placed by ISPs and anti-spam organizations. You can only get them from purchased or scraped lists. - **Recycled traps**: real addresses that their owners abandoned and that were later turned into traps. After roughly **12 months** without activity, an abandoned address is either switched off completely (so it produces hard bounces) or converted into a spam trap. Recycled traps are why a sunset policy based on engagement is necessary, even for lists built entirely on consent. An address that stopped engaging a year ago may now be a trap. ## Bounce handling These rules come from AWS SES and Postmark: - **Remove hard bounces immediately.** Never send again to an address that hard-bounces. Repeated hard bounces add up and harm your reputation with that ISP. Postmark's practice for transactional systems is to suspend delivery to the address automatically, and to require someone to reactivate it after the underlying problem is fixed. - **Retry soft bounces, then treat them as hard.** Sending systems retry soft bounces at intervals over the following days. If an address soft-bounces repeatedly across sends, treat it as a hard bounce and suppress it. - **A full mailbox is usually permanent in practice.** According to SendGrid, only about **8.5%** of addresses with a full mailbox become active again within 30 days. Track repeated mailbox-full responses, and suppress addresses that show the pattern consistently. - **Make sure you receive your bounce notifications.** The address that collects bounce and complaint notifications must itself accept mail. Avoid using a mailbox hosted by an ISP for this, because a flood of bounce notifications may be sent to the spam folder or dropped. If you cannot avoid it, check the spam folder, and never mark bounce messages as spam (AWS SES). - **Make bounces traceable.** A bounce identifies the mailbox that refused the message. To connect it to a campaign, add an X-header with a value your internal tracking system can trace (AWS SES). ### Operational tactics for transactional bounces (Postmark) For product or transactional email, a bounce often means a user you cannot reach. That is a product problem, not only a list problem: 1. Stop delivery to the address immediately after a hard bounce or a spam complaint (this protects reputation) 2. Alert the support team automatically so they can investigate 3. Show the affected user a notice in the application when they log in ("we can't reach your email") 4. Record the bounce event on the account 5. Let the user reactivate delivery themselves after correcting their address 6. Use other channels (SMS, a secondary email address) when they are available 7. Notify account administrators and collaborators when an important user's email bounces 8. Optionally, show automatic replies (out-of-office messages) where people work together 9. Process bounce webhooks in the application code instead of polling 10. Use a sandbox environment for testing, so that test sends never reach real recipients ## Complaint handling - Keep the complaint rate below **0.1%** (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) for the full table of thresholds). - When a recipient complains about a **marketing** email, stop sending them marketing email immediately. If the program also sends **transactional or notification** mail, it may be acceptable to keep sending those types of message to that recipient (AWS SES). - Complaint notifications from feedback loops usually hide the address of the person who complained. Add custom X-headers or identifiers to the message body, so that you can identify and suppress the address (AWS SES). - Check that your own systems are not filtering complaint notifications as spam. ## Unsubscribe and preference management - One-click unsubscribe (RFC 8058 `List-Unsubscribe`) is required by Google's and Yahoo's rules for bulk senders, and it is a basic CAN-SPAM requirement (SendGrid). - Put a clear unsubscribe link in the footer. When unsubscribing is difficult, people complain instead. - Offer a **preference center** with control over frequency and a "down-subscribe" option (fewer emails rather than none). It keeps the subscriber while reducing negative signals (SendGrid). ## Sunset policies A **sunset policy** "reduces the frequency that an email address receives campaigns or suppresses it entirely based on engagement, or lack thereof" (SendGrid). Addresses that do not engage pull down engagement rates, and after ~12 months without activity they may become hard bounces or recycled spam traps. A complete sunset process, combining the sources: 1. **Define inactivity** by how recently the address opened or clicked. Remember that open tracking is inflated, so give clicks more weight (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)). 2. **Reduce frequency first** for segments that are cooling, rather than cutting them off. 3. **Check the address's status through other channels** where possible, such as website logins or purchase history, before you mail an address that has been dormant for a long time (AWS SES). 4. **Run a re-engagement campaign** as the last step: a message saying you have not heard from the recipient and asking them to confirm they still want the mail. AWS calls this a *win-back* campaign, and SendGrid a *re-engagement campaign*, "one last chance". 5. **Remove the people who do not respond.** After the win-back campaign, remove every recipient who did not respond (AWS SES). 6. If you mail a list that has not been contacted for a long time, send a welcome-style message first, reminding recipients who you are and why they receive your mail. This reduces complaints (AWS SES). Sending less often to fewer, better recipients usually increases delivery to the inbox (see [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability)). ## Related articles - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), the thresholds that list hygiene protects - [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), including the feedback loops that feed suppression # Mandated and Regulatory Email > How to send legally required bulk notices — breach notifications, recalls, policy changes — to entire databases (including suppressed and unengaged addresses) without destroying sender reputation. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/mandated-and-regulatory-email Some messages must reach recipients regardless of engagement, consent status, or deliverability metrics: senders can be legally required or compelled to mail their entire database — including addresses that are long-unengaged, unsubscribed, or previously suppressed. This is exactly what normal deliverability practice forbids (see [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies)), which is why these sends need a dedicated process. M3AAWG's guidance is explicit: this process is **only** for mandated messages that are an exception to normal sending practices and likely to be of special relevance to the recipient — never for standard marketing or transactional notices. ## Definition and examples Mandated (high-risk) emails inform individuals of a significant change in policy, help them mitigate damage, offer assistance, or provide noncommercial information about their account. Typical examples: | Type | Example | |---|---| | Breach notification | Account compromise disclosure with password reset / free credit monitoring offer | | Product recall | Health and safety notices | | Policy change | Privacy-policy or terms-of-service updates | | Account status | Noncommercial notices about the recipient's account | ## Why these sends are deliverability-dangerous - They are bulk messages **highly likely to exhibit poor delivery metrics** — elevated bounces (dead addresses back on the list) and complaints (recipients who unsubscribed or forgot the brand). - They may need to go to individuals who were **previously suppressed or unsubscribed** — reintroducing exactly the negative signals that suppression exists to prevent (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) for the thresholds at stake). - Volume spikes to a whole database break normal sending patterns and can trigger anti-spam mechanics at receivers (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) on how providers score senders). Each organization bears the responsibility to determine whether a high-risk send is necessary, balancing it against the potentially abusive nature of the messages and how frequently they occur. Keep them non-intrusive and minimally disruptive to users and mailbox providers. ## Pre-send preparation (sending organization) **Notify mailbox providers in advance.** Use each MBP's preferred point of contact (`postmaster@mailboxprovider.com` or its postmaster contact page — see the [providers/](https://emailmarketing.net/learn/providers) articles for known channels). Send personalized notifications to the MBPs most relevant to the audience; where appropriate, use a personal contact or industry groups, at the discretion of the sending platform and the organization. **Coordinate internally and externally:** - Consult your ESP for technical requirements and solutions that maximize effectiveness and minimize impact on IP and domain reputation. - Provide guidance, instructions, and timelines from the relevant regulators or legal team. - Internal teams (social, call center, frontline staff) should coordinate a consistent message across all customer-service channels. - Determine whether information is needed for auditing purposes, and what that entails. ## Infrastructure and authentication choices | Practice | Detail | |---|---| | Dedicated alias | Use a new email alias for these notifications instead of the usual marketing alias (e.g., `notice@sub.example.com`) | | Branded, verified domain | Send from a branded organization domain, unequivocally verified with domain authentication (per the [M3AAWG Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp)) | | **No cousin domains** | Do **not** use a newly registered cousin domain (a variation of the normal sender domain) or register a new domain for these notices — that pattern is indistinguishable from phishing | | SPF + DKIM + DMARC | All three configured on the sending domain — see [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim), [DMARC](https://emailmarketing.net/learn/authentication/dmarc) | | TLS | Supported on the sending server for receivers that implement it | | Dedicated IP range | Some mailbox providers encourage reserving an IP range exclusively for mandated-email notification addresses (see [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)) | ## Message content and identification - From name like "[Organization name]: Notification"; "Important notification" in the subject line. - **Minimal tracked elements**: limit links to only those required — or none at all. - Content exclusively relevant to the issue, **no marketing at all**. - Plain or minimal template style appropriate to the notification type (see [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability)). - **Suspend marketing communications during the notification period** — the mandated message should not compete with promotional mail. ## Audience segmentation and list handling Decide who must receive the message based on the actual requirements of the notification, and sequence the send **from least risky to most risky** communication groups: 1. Impacted users 2. Active users 3. Subscribed users 4. Unsubscribed users 5. Bounced users — **exclude known dead addresses entirely**; they will never reach the intended recipient and only generate reputation damage For known bounce addresses and users who have previously reported the brand as spam, use **alternative contact channels** instead of email: postal mail, SMS, website notification, social media, or traditional media (newspaper, radio, TV). Some recipient groups are inherently complicated to reach by email; alternative methods may satisfy the mandate with zero deliverability cost. ## ESP tasks: coordinating with mailbox providers ESPs often cannot influence message content much — it is typically written by legal counsel to satisfy the organization's obligations under the notice. The ESP's role is coordination and pacing. Advance notifications to MBPs should include: - Contact details for the organization or agency where recipients can get more information, plus a copy of the message itself if possible - Sending volumes and the days required - The sending infrastructure to be used: sending domains/hostnames, IP addresses (ideally a reserved range), dates and times, volume expectations During the send: - **Throttle sending speed over time** to avoid volume peaks that burden receiving networks and trigger anti-spam mechanics. - Verify SPF, DKIM, DMARC, and TLS are in place before the first message leaves. **Contractual preparation:** consider defining a preferred breach/mandated-email process in the customer contract or Data Protection Agreement in advance, so the workflow exists before the emergency does. ## Post-send Monitor the send like any high-risk event: bounce and complaint rates against the thresholds in [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), blocklistings and provider dashboards per [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). Addresses that hard-bounce or complain during the mandated send go back into normal suppression — the mandate exception ends with the notification period, and normal [sunset policy](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) resumes. ## Related - [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) — the normal rules this send temporarily overrides - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) — why unengaged-database sends are penalized - [M3AAWG Senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) — the baseline these practices deviate from, deliberately and narrowly - [Provider articles](https://emailmarketing.net/learn/providers) — postmaster contact points for advance notification # MTA Delivery Tuning > Outbound queue theory and delivery tuning as a discipline — queue-age diagnosis, per-destination concurrency and rate shaping, connection reuse, adaptive backoff and dead-site detection, scheduler fairness, and bounce-driven traffic-shaping automation. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/mta-delivery-tuning If your outbound queues are growing or providers are deferring your mail, the cause is often how hard your mail server pushes each destination. Delivery tuning covers how a mail transfer agent (MTA) decides that pressure, and how operators diagnose and correct delivery congestion. The concepts below apply to any MTA. The models for queue diagnosis, concurrency feedback and scheduling come from Postfix's documentation, and the models for shaping rules and automation come from KumoMTA's. Every serious MTA, commercial or open source, implements some version of each. For the concrete numbers for each provider that these mechanisms enforce, see [Per-Provider Tuning Baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines). ## Why this is a deliverability discipline Mailbox providers enforce caps on connections per sender, on message rate and on messages per connection, and they answer violations with 4xx deferrals (often `421`) or throttling penalties. An MTA that pushes past those limits turns good mail into deferred mail and ages its queues. At providers that score "unusual traffic patterns", it also damages IP reputation. Delivery tuning is the practice of keeping outbound pressure just under each destination's tolerance, backing off automatically when the destination signals distress, and diagnosing queue problems quickly when they appear. ## Queue-age distribution as diagnosis (the "qshape" model) The single most informative view of an outbound MTA is a two-dimensional table, with **destination domain on one axis and message age on the other**, and counts in each cell. Postfix ships this view as `qshape`. Age buckets are fine-grained for recent mail, typically 5, 10, 20, 40, 80, 160, 320, 640, 1280 and 1280+ minutes, with a total column for each domain. Run it separately against the incoming and active queues (mail being worked on now) and against the deferred queue (mail that has already failed temporarily). Reading rules: 1. **Problems live in the top left.** Large counts for a single domain in the young buckets mean an active, ongoing problem. A concentration in old ages means a past problem that is now draining. 2. **Concentration on a domain identifies the bottleneck.** Sort by row total. The domains that dominate are where delivery is failing or throttled. 3. **A backlog in the active queue matters more than a backlog in the deferred queue.** Mail stuck in the active queue blocks new work, while deferred mail is only waiting for a retry. 4. **A full active queue with an incoming queue that is not full** means that one or more destinations drain more slowly than mail arrives for them. 5. **A view by sender detects backscatter.** Pivoting the same table by sender instead of recipient shows when bounce messages (MAILER-DAEMON) dominate the queue, which means the load is self-inflicted bounce processing, not fresh mail. Characteristic patterns: | Pattern | Signature in the age table | Diagnosis | |---|---|---| | Healthy | Incoming and active queues nearly empty; small deferred totals spread across old buckets | Normal operation | | Deferred backlog, old ages | Large deferred totals, with counts growing toward the oldest buckets; short incoming and active queues | A past problem already resolved, with retries draining. "high volume of deferred mail is not a direct cause for alarm" by itself | | Bounce backscatter | As above, but the sender view shows mostly MAILER-DAEMON | An earlier bad send (for example, to a list hit by a dictionary attack) still generating bounce work | | Active-queue saturation | Active count near its cap (Postfix example: 9,996 of a limit of 10,000; 20,000 in later versions), almost all in the youngest bucket, with one domain dominating | A destination is draining far more slowly than mail arrives. Delivery agents are tied up, and new mail is delayed for all destinations | | High-volume destination backlog | One domain with large counts in every bucket younger than the start of the problem, and still growing | The destination has been down or throttling since roughly the oldest affected bucket; congestion is ongoing | Scale expectations (Postfix figures, indicative for any store-and-forward MTA): a deferred queue handles roughly 100,000–1,000,000 messages, and good performance is unlikely beyond that. ## Per-destination concurrency shaping MTAs open a limited number of parallel connections to each destination, and adapt that number according to delivery outcomes. This is deliberately similar to TCP slow start. - **Initial concurrency** is small (Postfix default: 5 simultaneous deliveries), so that a new or recovering destination is probed gently. - **Maximum concurrency** caps parallelism for each destination (Postfix default: 20). Overrides for individual destinations are how provider caps are honored, for example for a provider that tolerates only 2 connections. - **Positive feedback** raises concurrency after successful deliveries, and **negative feedback** lowers it after connection or handshake failures. The feedback increment is a function of the current concurrency N: - `+1` per success gives an exponential ramp (5, then 10, then 20): fast, but prone to oscillation; - `+1/N` per success gives a linear ramp, one extra slot after N successes: the gentlest; - `+1/√N` sits in between. Fractional feedback combined with integer truncation gives natural hysteresis: concurrency only steps up after `1/g(N)` consecutive successes. - **The asymmetry matters.** Negative feedback is applied at the start of a sequence of failures ("reverse hysteresis"), so that overload is corrected immediately, not after a full window of failures. - Measured effect (Postfix scheduler tests against a receiver that enforces concurrency limits with `421` responses): fixed feedback of ±1 deferred about 50% of mail; `1/N` feedback deferred about 16.5%; `1/√N` about 24.5%. Gentler feedback sharply reduces deferrals at receivers that enforce limits. - Caveat: feedback below 1 has little effect when volume to a destination is low, because deliveries are too infrequent for the counters to move. ### Dead-site detection and penalty boxes This is separate from concurrency feedback. When a whole cohort of delivery attempts (N attempts, where N is the current concurrency) fails with connection or handshake errors, the destination is declared **dead** after a configurable number of failed cohorts (Postfix default: 1 cohort). Dead destinations go into a penalty box, where they are skipped entirely for a period, instead of being hammered at a concurrency of 1. Separating "the site is down" from "the site is slow" lets concurrency feedback stay gentle without wasting delivery agents on unreachable hosts. ## Rate shaping, connection reuse, and the shaping-parameter vocabulary Beyond concurrency, modern MTAs shape traffic to each destination along several independent axes (the names come from KumoMTA, and every MTA has equivalents): | Parameter (concept) | Meaning | Typical global default (KumoMTA) | |---|---|---| | Connection limit | Maximum simultaneous connections to the destination | 10 | | Connection rate | Maximum new connections per unit of time | 100 per minute | | Message rate | Maximum messages per unit of time, regardless of connections | 100 per second | | Deliveries per connection | Messages sent before an SMTP session is closed and reopened | 100 | | Idle timeout | How long a cached connection may stay idle before it is closed | 60 s | | Data timeouts | Timeouts for the DATA phase and the final dot | 30 s and 60 s | | TLS mode | Opportunistic or Required, per destination | Opportunistic | | Consecutive connection failures before delay | The number of failures that triggers backoff | 100 | **Connection reuse** (sending many messages over one connection) is a big lever. Setting up a connection, negotiating TLS and the receiver's accounting for each connection all cost more than an extra `MAIL FROM`. But providers cap messages per connection and answer the excess with errors such as "Max message per connection reached", so the right value depends on the provider (50 for Gmail, 20 for Yahoo, 5 for Apple in community baselines). A related setting is the number of recipients per copy of a message (Postfix default: 50 recipients per copy; larger recipient lists are split into parallel copies). **Destination grouping (MX rollup)**: shaping limits should apply to each receiving infrastructure, not to each recipient domain. Thousands of hosted domains share the MX fleets of Google or Microsoft. Rolling up all the domains whose MX records match a suffix (for example, `.google.com` or `.googlemail.com`) into one shaping bucket prevents you from accidentally multiplying your effective connection count by the number of recipient domains. Conversely, a provider whose MX names are regional silos (for example, Mimecast site names) should be limited per MX site, not per provider. ## Retry scheduling and adaptive backoff on 4xx Mail that failed temporarily (4xx) is given a future timestamp with **exponential backoff** between a floor and a ceiling (Postfix defaults: minimum 300 s, maximum 4,000 s), and the deferred queue is scanned again periodically (by default every 300 s). Messages that cannot be delivered within the **queue lifetime** (default 5 days; bounces often get their own lifetime, also 5 days) are returned as permanent failures. Operational rules: - **Do not shorten retry intervals to "clear the backlog."** Retrying undeliverable mail more often saturates the active queue and ties up delivery agents on dead sites, which starves deliverable mail. Fixing the cause always works better than retrying harder. - **Timeouts limit worst-case throughput.** For example, with 100 delivery agents, a destination with 2 MX hosts of which one is down, and a connect timeout of 30 seconds, throughput tops out at about 6 messages per second, because half the connection attempts use up a full timeout. Shorter connect timeouts (and trying the next MX quickly) restore throughput during partial outages. - **Isolate problem destinations.** Give destinations that are chronically slow or unreliable a dedicated delivery pool with shorter timeouts and adjusted concurrency, or move them to a fallback "graveyard" relay with its own retry schedule, so that they cannot degrade mainstream delivery. ## Scheduler fairness and preemption Inside the MTA, a scheduler decides which message gets the next free delivery slot: - **Round-robin across transports and destinations** makes sure that no single destination monopolizes delivery agents. - **First in, first out (FIFO) within a destination**, by the time mail entered the queue, except for preemption. - **Preemption** lets small messages get past bulk ones without starving the bulk mail. As a large message's recipients are delivered, it accumulates "delivery slots" (one for every K delivered recipients; Postfix default cost K=5). A candidate to preempt it is picked by maximizing `enqueue_time / recipient_count` (the oldest relative to its size first), and needs a minimum number of slots (default 3). **Slot loans** (by default up to 3 slots, at a 50% discount) let a small message jump ahead immediately and "pay back" the advance from later deliveries. This expedites mail the size of transactional messages without giving up fairness to bulk campaigns. It is the equivalent, inside the MTA, of the practice among email service providers (ESPs) of separating transactional and bulk streams. ## Bounce-driven traffic-shaping automation Static shaping tables set the ceiling, and automation adjusts below it in real time by parsing what providers say in their SMTP responses. The model is KumoMTA's Traffic Shaping Automation, which runs as a separate daemon that watches delivery logs and pushes configuration back to the MTA. It can be clustered, so that all nodes react together: - **Match**: regex rules over the text of bounce and deferral responses, scoped to a provider or site, a tenant, or a campaign. - **Trigger**: fire immediately, or only past a threshold (for example, 2 matches an hour, which tells a one-off from a pattern). - **Act**: either **Suspend** (stop sending to that destination from that queue entirely) or **SetConfig** (tighten a shaping parameter: drop `connection_limit` to 1, cap `max_message_rate` at 1 per minute, cut `max_deliveries_per_connection`). Suspension scoped to a tenant exists for responses that indicate a sender problem (for example, missing authentication) rather than a traffic problem. - **Expire**: every action has a duration (commonly 15 minutes–4 hours). When it lapses, normal shaping resumes automatically. This makes automated throttling self-healing: no operator has to remember to remove the throttle. Representative community rules (see [Per-Provider Tuning Baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines) for the full table): - Gmail "unusual rate" responses: cap at 10 messages per minute for 30 minutes. - Yahoo `[TSS04]` complaint deferrals: suspend for 2 hours. - Outlook "exceeded the maximum number of connections": a connection limit of 1 for 1 hour. - A generic default rule matches the family of texts seen across providers, such as "temporarily deferred", "rate limited due to IP reputation" and "Server busy", and drops both the message rate to 1 per minute and connections to 1, for 90 minutes. Design principles for building your own rules: 1. **Parse the provider's words, not only the code.** `421` alone is ambiguous, while `[TS02]`, `[TS03]` and "Max message per connection reached" each call for a different response (see the error code guides for [Gmail](https://emailmarketing.net/learn/providers/gmail-troubleshooting), [Yahoo](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) and [Microsoft](https://emailmarketing.net/learn/providers/microsoft-sender-requirements)). 2. **Match the action to the complaint.** For complaints about connections, cut connections. For complaints about volume, cut the message rate. For deferrals about reputation or complaints, and for blocklistings, suspend and let the reputation cool. For content rejections, suspend and alert a person, because throttling will not fix content. 3. **Throttle harder for reputation signals than for mechanical limits.** Hitting a connection cap is a tuning miss; "deferred due to user complaints" is a reputation event. 4. **Keep durations short, and let rules fire again.** A penalty of 30–120 minutes that renews while the provider keeps complaining converges on the right rate without permanently crippling the queue. ## Layering shaping configuration Keep shaping data in layers, so that updates do not destroy local knowledge: a vendor or default layer, a community or shared layer, and a local layer with your own rules. Later layers override earlier ones, with an explicit option to "replace everything for this domain". Never edit the distributed layers in place, because upgrades overwrite them. Most deployments need local rules, because the shared baselines are deliberately not all-encompassing. ## Related articles - [Per-Provider Tuning Baselines](https://emailmarketing.net/learn/operations/per-provider-tuning-baselines), with community-maintained starting values for each provider - [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up), the policy for ramping volume that these mechanisms enforce - [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes), the vocabulary of codes that automation rules parse - [Gmail SMTP Troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting) - [Yahoo SMTP Error Codes](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes) - [Comcast and Xfinity](https://emailmarketing.net/learn/providers/comcast-xfinity-postmaster) # Non-Human Interactions (NHI) and Email Metrics > M3AAWG's Nov 2020 study of automated "bot clicks" from security scanners — <10% B2C vs 20–80% B2B click/open inflation, why filtering NHI out is unreliable, and the practices that reduce it. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/non-human-interactions If your click or open rates look higher than real engagement could explain, software may be clicking your links and opening your messages before your recipients do. These non-human interactions (NHI) can inflate business-to-business (B2B) metrics by a large margin, and they cannot be filtered out reliably. The figures below come from a study by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG): *M3AAWG Exploring the Impact of Nonhuman Interactions on Email Send Metrics*, November 2020 (M3AAWG-136). The document gives its own address as m3aawg.org/sites/default/files/nhi.pdf. The original queue URL on m3aawg.org now returns a 404 error, so the document was retrieved through the Wayback Machine (snapshot 2025-12-11). NHI, also called "automated clicks", is the automated handling of received email by software rather than by the recipient. It typically happens during **security scans by a mailbox provider's antivirus and security software**. The system follows the links in an email and visits the target site to analyze its content (looking for malware and phishing pages). Along the way it registers a "click" or an "open" for the campaign and pollutes website analytics. The scanning patterns are deliberately hard to recognize, so that bad actors cannot get around the scanning. Symptoms range from clicks on some of the links to **every link in every email to a domain being clicked in quick succession**. What began as a statistical anomaly has become "a major issue affecting email campaign metrics in a massive way". Senders who relied on open and click rates to measure performance may need additional measures of success. NHI on clicks is closely related to the way Apple Mail Privacy Protection (MPP) and Gmail's image prefetching inflate opens (see [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)). ## Measured impact (M3AAWG benchmark study) Method: the study used benchmark data from large and small ESPs and from B2B and business-to-consumer (B2C) senders across the industry, in some cases covering several years of send, click and open data. It set out to test whether browser **user-agent strings could reliably identify NHI**, and whether NHI could be reliably filtered out to recover a true click rate. | Segment | NHI impact on metrics | Notes | |---|---|---| | **B2C** | Generally **< 10%** | Large volumes go to a smaller set of large consumer inbox providers. The figure was consistent throughout the research. **The impact is weaker for more reputable brands** | | **B2B** | **20–80%** | Enterprise anti-spam software is stricter on inbound mail. The range correlated with recipient engagement: **the lower the engagement at an inbox provider, the higher the probability of NHI scans** | The study could not break NHI levels down by vertical market segment in a meaningful way. An overall effect across the industry is hard to quantify, because **filter vendors and internet service providers (ISPs) actively hide their scanning from detection**, which they must do so that filters are not circumvented. Any filtering effort therefore leaves a margin of error in "NHI-adjusted" rates. The study did find a strong **correlation between reputation and NHI**. M3AAWG recommends building and maintaining a positive reputation to reduce the impact of NHI on open and click rates. ## Business impact - **E-commerce**: automated clicks and opens can **trigger marketing automations and follow-up emails**. Unreliable metrics make planning for return on investment (ROI) and return on ad spend less accurate. The cost is more in lost opportunities than in lost revenue. - **Media and content marketing**: clicks and site visits are often the conversion metric itself. Strategies based on guaranteed clicks, opens or article views can no longer rely on those numbers. This directly reduces advertising and subscription revenue, and threatens marketing revenue that depends on lead generation. M3AAWG advises strengthening **form and email verification** to keep list quality high. - **Brand and ESP reputation**: as engagement indicators become less reliable, it gets harder to segment by engagement and to sunset recipients. List quality then declines, and real engagement falls, which lowers domain reputation. ESPs that host **click-tracking links on their own domains** are also exposed. - **List hygiene**: NHI produces false "engagement". List cleaning based on last activity **can keep addresses on the list that were only ever "active" because of NHI**, which defeats re-engagement series and policies for removing unengaged addresses ([List Hygiene & Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies)). - **Harm to recipients**: NHI may trigger actions the recipient never agreed to, such as completing a double or confirmed opt-in, confirming details, joining a new list, leaving a current list, or registering interest in items they do not care about. The result is more unwanted mail, abuse complaints and damage to the brand. ## Best practices that reduce NHI (from the research) - **Use HTTPS for every link.** Tracking links that mix secure and non-secure addresses appear to be targeted disproportionately. An HTTP advertiser link behind an HTTPS tracking link "seems to trigger the most unwanted behavior." - **Send separate campaigns to confirmed engaged recipients and to non-engaged recipients**, especially where inbox placement at certain domains is a problem. - **Monitor content quality** at the level of links and beyond (for example, the ratio of images to text). "Aggressive" marketing, such as emoticons in subject lines or large catch words, tends to attract more NHI. - **Sender reputation matters**: NHI is considerably lower for senders whose recipients are highly engaged. The standing guidance also applies. Follow the [Senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) for deliverability and engagement, and the [Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp), which lets providers attach reputation to the sender's brand. Good content practices reduce the impact of NHI. Version 4.0 of the [M3AAWG Sender Best Common Practices](https://www.m3aawg.org/senderbcp) (August 2026) reads engagement the same way during domain warm-up. A sharp rise in opens or clicks can mean security filters are inspecting the mail more closely, while a fall can mean it is landing in the junk folder. ## Conclusions and limits - There is **no definitive guide to mitigation**. The study's data covers only the interactions that could be identified as NHI, not 100% of it. - Scanners use **simulated behavior designed to be indistinguishable from natural human interactions**. Identifying it is already very difficult and "will become nearly impossible in the future." - Removing NHI changes the numbers, but a sender can never be sure it caught everything, and the effort may not be worth it. If every ESP filters NHI differently, metrics become even harder to compare. - In short, NHI has measurable and significant consequences. Re-evaluate how you use engagement data to decide mailing frequency or segmentation, and allow for the inflation when you read click and open dashboards. # Open and Click Tracking Mechanics > How ESPs actually count opens and clicks — pixel and link-wrapping mechanics across Pardot, Eloqua, Bird, Customer.io, and Braze — with unique-vs-total definitions, the "read rate" concept, and what each metric does and doesn't prove. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/open-and-click-tracking-mechanics Before you trust an open rate or a click rate, it helps to know how the number was produced. Every engagement metric an email service provider (ESP) reports, whether open rate, click rate, click-to-open rate or read rate, is derived from two changes made to the message when it is sent: a tracking pixel and rewritten links. Below is how platforms implement and count these events, how they define unique and total counts, and exactly what each number can and cannot prove. The privacy features and scanners that distort these counts (Apple Mail Privacy Protection (MPP), Microsoft Safe Links, link detonation by security gateways, image proxies) are covered in depth in [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion). The thresholds these metrics feed are in [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). ## Open tracking: the pixel An open is inferred, never observed. The ESP places a transparent **1×1 image** (a "tracking pixel", "beacon" or "web bug") in the HTML body. Its URL, on a tracking domain, encodes the recipient's unique identifier. When the mail client displays the message and loads remote images, the request reaches the tracking server, which records an open with the requesting IP address, user agent and time. Because the event is an image request, some facts hold on every platform: - **No image load means no open.** Clients with images turned off, plain-text reading panes and text-only clients produce false negatives. An "open rate" is really a pixel-load rate. - **Any image load counts as an open**, including the sender's own previews, a campaign forwarded or posted on the web, and a template that reuses a tracking code. - **Plain-text parts cannot be tracked.** A pixel only exists in HTML, so a message displayed as text produces no open. For this reason Pardot calls an open detected by the pixel an **"HTML open"**: there is no such thing as a text open. - **Total and unique counts differ.** Raw pixel requests are *total* opens, so a recipient who reloads the message counts each time. ESPs remove duplicates to get *unique* opens for each recipient, because they know which identifier belongs to which subscriber. Benchmarks and comparisons between platforms should always use the **unique** rate. ### The click-to-open fallback Several platforms record an open when a click arrives from a recipient with no earlier open. The reasoning is that a click proves the message was viewed, even if the pixel never loaded because images were off. - **Eloqua** states this explicitly: "If a clickthrough occurs without a recorded email open for that RecipientID, Oracle Eloqua automatically records an email open along with the clickthrough." Eloqua therefore detects opens in two ways: when the pixel loads, and when a click implies an open. - **Customer.io** builds it into its definition: an open is counted "when the recipient's email client loads an invisible image (tracking pixel) **or** when the recipient clicks one of the links in the email." This fallback is why audiences that click a lot but keep images off (much of B2B) still show opens. It is also why, since MPP, a click is the only signal that shows a genuine human open by an Apple Mail recipient whose pixel loaded automatically (see [distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). ## Click tracking: link wrapping Click tracking rewrites every `href` in the message at send time so that it points to the ESP's redirect domain (often called the "tracking", "click" or "links" domain), with the destination and the recipient encoded. When someone clicks, the redirect server records the request and sends an HTTP redirect to the real URL. Only the sending platform can do this, because the links must be rewritten before the message leaves. That is why analytics-only tools cannot offer click tracking, and why link wrapping belongs to the ESP. Clicks are a stronger signal than opens for these reasons, but not a clean one: - **The redirect domain carries a reputation.** URL blocklists and content filters evaluate the link domains in the body, so a shared redirect domain spreads reputation, good or bad, across every sender that uses it. Tracking hostnames branded for each customer keep reputations separate. Bird serves click and open tracking from **a branded tracking hostname on your own domain**: a CNAME under the sending domain (by default `links.yourdomain.com`), over HTTPS, through which it rewrites the visible links. - **Scanners inflate clicks.** Security gateways (Safe Links, Proofpoint, Mimecast) "detonate" wrapped links by requesting them seconds after delivery, and each request registers as a click no person made. For details and ways to tell bots from people, see [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion). - **Unique and total counts** work in the same way as for opens. Total clicks count every request; unique clicks count one for each recipient (some platforms also show unique clicks for each link). ### Tracking must be switched on before it runs A message does not get tracking automatically just because it has links. Bird tracks a send only when all three of these conditions are true: 1. the flag on the send (`track_opens` or `track_clicks`, true by default) is true. A `false` on a send always turns tracking off, whatever the domain settings; 2. tracking is enabled for the domain; 3. the tracking **CNAME has been verified**: "Click and open tracking only run once that CNAME has verified; until then nothing is rewritten or pixelled." Bird reports whether the tracking CNAME is ready separately from whether the domain can send (`capabilities.tracking` and `capabilities.sending`). A domain can therefore send mail while recording no engagement, without any warning. In practice, when a customer's open and click data suddenly drops to zero, the cause is often a broken or unverified tracking CNAME, not a change in the audience. ## Bot and non-human filtering built into the count Scanners request pixels and wrapped links as well as people do, so mature platforms filter out machine activity before it reaches the main metric, instead of simply reporting raw requests. - **Customer.io** shows both sides explicitly. Since **2025-03-20**, a **Human Opened** metric excludes Apple MPP, Gmail prefetching, bots and scanners. Since **2025-04-20**, a **Human Clicked** metric excludes security scanners, bots, proxies and other non-human patterns. The matching **Machine Opened** and **Machine Clicked** metrics capture the automated events that were excluded. Nothing is counted twice: "if a single email was opened by both a machine and a human, that counts as one in the aggregate metric." All opens in Apple Mail are counted as non-human, and an open is counted as human again only if the recipient also clicks, so human opens are undercounted. - **Pardot (Account Engagement)** includes **Metrics Guard** in all accounts. It detects bursts of opens or clicks from one IP address, using thresholds. The thresholds are "conservative averages of peak email activity within a certain time frame across the Account Engagement ecosystem", and when an IP address goes over one, "activity tracking on that location is paused until the activity level falls back below the threshold." It filters out most scanner activity without blocking legitimate visitors, but it cannot catch every bot: activity below the thresholds is still recorded. - **Eloqua** stores automatic opens and clicks from email scanning tools, and automatic opens from Apple's privacy features, **separately** from real contact engagement, instead of counting them as engagement. - **Bird** marks opens requested by a proxy with `is_prefetched: true`, and defines its open rate as **"unique non-prefetched opens over delivered"**. Prefetched opens are removed from the main rate, not just labeled. - **Braze** offers reports that "either exclude or include machine opens (like Apple's MPP)." If you run an ESP, never compare an unfiltered open rate with one filtered for bots, and know which of the two your platform's default dashboard shows. On lists with many Apple users, the gap between "opens" and "human opens" is often 30–70%. ## What the platforms actually name and expose | Platform | An open is counted when… | Click counted as open | Bot handling | Notable metric definition | |---|---|---|---|---| | **Pardot (Account Engagement)** | The HTML pixel loads ("HTML open"); there is no text open | Not documented | Metrics Guard: burst thresholds for each IP address pause tracking | Also reports **read rate** (tiers of time spent on the message, see below) | | **Eloqua** | The pixel loads, *or* a clickthrough arrives with no earlier open for that RecipientID | Yes, explicitly | Automatic opens by scanners and Apple stored separately from engagement | By default the pixel is `` at the bottom of the message | | **Bird** | A pixel load that was not prefetched | (an open on any tracked event) | `is_prefetched:true` excluded from the open rate | Open rate = unique opens not prefetched ÷ delivered; **rates are calculated on the time of the event, not the time of the send** | | **Customer.io** | The pixel loads **or** a link is clicked | Yes, in the definition | Human and Machine Opened and Clicked (2025); nothing counted twice | Metrics use **delivered** messages as the base by default (configurable); events on messages > 6 months old are ignored | | **Braze** | A 1×1 pixel loads (a proxy for an open) | Not documented | Reports can include or exclude machine opens | Presents the unique open rate as a proxy for inbox placement (see below) | Watch the base of each rate. Customer.io and Bird calculate engagement rates against **delivered** messages, and Bird attributes engagement to the **time of the event**, so a click today on last week's send appears in today's numbers. Two platforms can report different "open rates" for identical behavior only because they choose different denominators and time attribution. Before comparing, always confirm the numerator (unique? filtered for humans?) and the denominator (delivered? sent?). ## Read rate: a different measurement entirely "Read rate" is not a pixel metric. It measures **how long a message stayed open in the foreground, or in focus,** before the reader moved on, sorted into tiers. Pardot reports **deleted (< ~2 s), skimmed (~2–8 s) and read (> ~8 s)**. The data comes from a different source than opens: - According to oimetrics, read rates come from **a panel of monitored inboxes**. They are estimated rates, not direct measurements, so expect them to differ from your own opens. - They are **unique rates, not total rates**. They are calculated by observing when a subscriber marks or keeps a message as read, not by loading a pixel, so they **mostly avoid the effect of Apple MPP**. MPP inflates pixel opens, but it does not invent time spent reading. - Their value for deliverability: "read rates use the same methodology as ISPs, like Gmail and Outlook," so they "more accurately estimate what ISPs are calculating" for engagement scoring. Read rate is therefore closer than any pixel open to the engagement signal the mailbox provider calculates itself. - Compare read rate only with the **unique open rate, not the total open rate**; "higher is better." A panel read rate estimates how a list performs as a whole; it says nothing reliable about any single recipient. Its value is as a check on pixel opens and as a proxy for the provider's own engagement calculations. A healthy read rate alongside a collapsing open rate points to distortion of the pixel by MPP, not to a real fall in engagement. ## Opens as a deliverability signal: the honest reading Braze states the current position plainly: a pixel load is "more likely to indicate **inbox placement** as opposed to a human being actually selecting your message and choosing to read it." That is the useful way to see opens when you run an ESP: - **A unique open rate that excludes machine opens and is over ~25% indicates widespread inbox placement.** Below ~20% suggests placement in the spam folder, and a **steady downward trend often comes before deliverability problems** (Braze). Bird's dashboard marks an open rate above **35%** as "Healthy", and a delivery rate above **95%** as healthy. Treat these specific numbers as calibrated by each vendor, not as universal. They are ranges that **exclude machine opens**. A benchmark on raw opens that include machine opens, such as Klaviyo's ≥33%, cannot be compared with them. The [canonical threshold table](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#canonical-threshold-table) sorts the open rate figures by whether they include or exclude machine opens. - Mailbox providers judge engagement on data that senders **cannot see**: "time-to-open, time-to-click, forwards, replies, deleted, etc." (Braze). Your open metric is a rough shadow of the provider's real model, and read rate is a slightly less rough one. - So, to judge how engaged an audience is, and to decide on sunset and re-engagement, rely on **clicks and conversions rather than opens**. To judge placement, the trend of the aggregate open rate is still a legitimate early warning: a drop means messages stopped reaching the inbox. The rule in practice is to use opens for the direction of placement, and clicks and conversions for decisions about engagement. ### What each metric does and doesn't tell you | Metric | Proves | Does **not** prove | |---|---|---| | Delivered | The receiving MX server accepted the message | Whether it went to the inbox or the spam folder | | Open (raw pixel) | An image was requested (by a client, a proxy or a scanner) | That a person saw it, when or where, or on which device | | Unique human open | A person's client displayed images at least once | Attention, or that people who did not open did not read (images off) | | Aggregate open **trend** | The direction of change in inbox placement | Actual placement, or the interest of any one recipient | | Click (raw) | A wrapped link was requested | That a person clicked (scanners detonate links) | | Unique human click | A person acted on the message | That the destination was reached (warning pages can block it) | | Read rate (panel) | An estimated distribution of reading time, resistant to MPP | What happened for any one recipient; it is an estimate from a sample | | Conversion or activity on the site | A real session and a completed goal | (the strongest positive signal, and the hardest to fake) | ## Related articles - [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion), on how MPP, Safe Links, link detonation and image proxies break these counts - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) - [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies), on engagement definitions that depend on which events you trust - [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability), including tracking domain reputation and link handling - [Customer Domain Authentication](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication), including branded tracking CNAME setup for customers # Per-Provider Tuning Baselines > Community-maintained per-provider MTA shaping baselines — connection limits, messages per connection, rates, TLS requirements, and automated-throttle rules — from the KumoMTA shaping files, attributed and dated. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/per-provider-tuning-baselines When you configure how your MTA shapes traffic to each destination, you need concrete values to start from. The values below come from the shaping files that the KumoMTA project maintains publicly. There are two files: - the `policy-extras/shaping.toml` file maintained by the vendor, with defaults and the major providers (several sections are marked "provided directly by" the provider); - the `community/shaping.toml` file contributed by the community, with more providers and automation rules driven by bounces. **Fetched 2026-07-20 from the `main` branch.** These values drift as providers change their policies. Treat them as attributed starting points to check against your own deferral data, not as facts about current provider limits. See [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) for what each parameter means and how the automation model works. How to read the tables: - **MX rollup**: limits apply to each **receiving MX infrastructure**, so all recipient domains that resolve to the same set of MX hosts share one bucket. Provider blocks match by MX suffix. For example, anything with an MX under `.google.com` or `.googlemail.com` counts as "google", which covers Gmail **and** domains hosted on Google Workspace. According to the file's note of 2024-09-03, their MX hostnames resolve to common IP addresses, so they are shaped together. - **`provider_connection_limit` vs `connection_limit`**: the provider variant is enforced across the whole provider rollup, and the plain variant applies to each site. Mimecast deliberately uses limits for each site, because each Mimecast site name is a separate regional fleet of MTAs. - Where a cell is blank, the global default applies. ## Global defaults | Parameter | Default | |---|---| | connection_limit | 10 | | max_connection_rate | 100/min | | max_deliveries_per_connection | 100 | | max_message_rate | 100/s | | idle_timeout | 60 s | | data_timeout / data_dot_timeout | 30 s / 60 s | | enable_tls | Opportunistic | | consecutive_connection_failures_before_delay | 100 | | remember_broken_tls | 3 days | A **default automation rule**, for all destinations, matches the family of deferral messages that many providers use: `Messages from temporarily deferred`, `All messages from will be permanently deferred`, `has been temporarily rate limited due to IP reputation`, `Unfortunately, messages from weren't sent`, `Server busy. Please try again later from`. On a match, it sets `max_message_rate = 1/minute` **and** `connection_limit = 1` for **90 minutes**. ## Provider baselines | Provider (MX match) | Conn. limit | Deliveries per conn. | TLS | Other | |---|---|---|---|---| | Google (`.google.com`, `.googlemail.com`) | 5 (provider-wide) | 50 | **Required**: Google tempfails and rate-limits injection without TLS | consecutive_connection_failures_before_delay = 5 | | Yahoo (`.yahoodns.net`), values "provided by Yahoo directly" | default (10) | 20 | default | | | Microsoft consumer (`.olc.protection.outlook.com`) | 5 (provider-wide) | 50 | default | The consumer, O365 and DANE sets of MX hosts are separate groups of edge servers, shaped separately | | Office 365 (`.mail.protection.outlook.com`) | 5 (provider-wide) | 50 | default | | | Office 365 DANE (`.mx.microsoft`) | 5 (provider-wide) | 50 | default | DANE left off in the baseline (DNSSEC is not ready at most sites) | | Apple iCloud (`.icloud.com`) | 10 (provider-wide) | 5 | default | Note the very low number of deliveries per connection | | Comcast (`comcast.net`), "provided directly by Comcast" | 25 | 1000 | Required | idle_timeout = 30 s; consecutive_connection_failures_before_delay = 24 | | Mimecast (`.mimecast.com`, `.mimecast.co.za`, `.mimecast-offshore.com`), "provided directly by Mimecast" | 10 **per site** | 100 | default | For each site, not provider-wide (regional fleets) | | mail.com, "provided directly by mail.com" | default | 100 | default | | | Orange (`.orange.fr`) | 2 (provider-wide) | 100 | Required | | | GMX and WEB.DE (`.web.de`, `.gmx.net`) (community) | 4 | 20 | Required | consecutive_connection_failures_before_delay = 5 | | Yahoo Japan (`yahoo.co.jp`) (community) | 2 | 20 | default | max_message_rate = 10/s; a separate fleet of MX hosts from Yahoo itself | | Barracuda (`.barracudanetworks.com.`) (community, dated 2026-03-27) | 10 (provider-wide) | 15 | Required | | | Netvigator (`.netvigator.com.`) (community, dated 2026-03-27) | 5 (provider-wide) | 10 | Required | | | KPN (`.kpnmail.nl.`) (community) | 10 | 10 | Required | | | Tencent QQ (`.qq.com`) (community) | 4 | 8 | Required | | | NetEase 163.com (`.netease.com`) (community) | 4 | 7 | RequiredInsecure (TLS forced, but certificates not validated) | | | Mailgun smarthost (`smtp.mailgun.com`), "provided directly by Mailgun" for senders relaying through Mailgun | 7000 | 3 | default | A smarthost, not a mailbox provider | ## Automated-throttle rules per provider (community-contributed) The community file adds these adjustments on top of the baselines, in response to bounces. A trigger of `N/hr` means the rule fires once the response has matched N times in an hour, and every action expires after its duration. For what each response means, see the error codes for [Gmail](https://emailmarketing.net/learn/providers/gmail-troubleshooting), [Yahoo](https://emailmarketing.net/learn/providers/yahoo-smtp-error-codes), [Microsoft](https://emailmarketing.net/learn/providers/microsoft-sender-requirements), [Apple](https://emailmarketing.net/learn/providers/apple-icloud-mail), [Comcast](https://emailmarketing.net/learn/providers/comcast-xfinity-postmaster) and [GMX and WEB.DE](https://emailmarketing.net/learn/providers/gmx-web-de-postmaster). | Provider | Response matched (regex, abridged) | Trigger | Action | Duration | |---|---|---|---|---| | Gmail | "Our system has detected that this message" | 5/hr | Suspend | 1 h | | Gmail | "Our system has detected an unusual rate" | 2/hr | max_message_rate = 10/min | 30 m | | Gmail (example, shipped commented out, because it suspends whole tenants) | "This message does not have authentication information" | None | SuspendTenant | 3 h | | Yahoo | `[TS02]` (unusual traffic patterns, submit IPs for review) | 3/hr | max_message_rate = 1/min | 30 m | | Yahoo | `[TS03]` (unusual traffic patterns) | 3/hr | max_message_rate = 10/min | 30 m | | Yahoo | `421 4.7.0 [TSS04]` (deferred, user complaints). The vendor file also has: any `[TS?S04]` leads to Suspend for 2 h, with no threshold | 2/hr | Suspend | 2 h | | Yahoo | `421 4.7.0 [TSS05]` (deferred, user complaints) | 2/hr | Suspend | 4 h | | Yahoo | `421 [IPTS04]` | 2/hr | Suspend | 2 h | | Yahoo | `421 [IPTS05]` | 2/hr | Suspend | 4 h | | Yahoo | `553 5.7.1 [BL` (IP listed by Spamhaus) | 5/hr | Suspend | 2 h | | Yahoo | "Max message per connection reached" | 3/hr | max_message_rate = 10/min | 1 h | | Yahoo Japan | "VS98-IP0 deferred" (`553 Mail from not allowed`) | 2/hr | Suspend | 1 h | | Yahoo Japan | `421 [TSS04]` or `421 [IPTS04]` (volume or complaints) | 2/hr | Suspend | 1 h | | Yahoo Japan | "Timeout waiting for command" | 2/hr | Suspend | 30 m | | GMX and WEB.DE | "Too many connections" | 3/hr | connection_limit = 1 | 30 m | | GMX and WEB.DE | "Reject due to policy restrictions." | 5/hr | max_message_rate = 1/min | 1 h | | GMX and WEB.DE | "Reject due to policy violations." | 5/hr | Suspend | 1 h | | GMX and WEB.DE | `554 … Reject due to policy restrictions.` | 5/hr | Suspend | 2 h | | Outlook | "Unfortunately … part of their network is on our block list" | 5/hr | Suspend | 2 h | | Outlook | "Access denied, please try again later" | 5/hr | Suspend | 1 h | | Outlook | "Server busy. Please try again later" | 5/hr | Suspend | 30 m | | Outlook | same "Server busy" text (second rule) | 3/hr | max_message_rate = 1/min | 15 m | | Outlook | "has been temporarily rate limited" | 3/hr | Suspend | 30 m | | Outlook | "exceeded the maximum number of connections" | 2/hr | connection_limit = 1 | 1 h | | Outlook | "exceeded maximum number of messages per connection" | 2/hr | max_deliveries_per_connection = 2 | 1 h | | Outlook | "Connection refused … exceed max concurrent connections. IB007" | 2/hr | connection_limit = 1 | 1 h | | Outlook | "Temporary server error. Please try again later" | 5/hr | Suspend | 1 h | | Apple | "Service unavailable - try again later" | 5/hr | Suspend | 15 m | | Apple | `[BS02] Temporary server error.` | 5/hr | Suspend | 15 m | | Apple | `[HCM1] Your mail from was deferred` | 3/hr | Suspend | 15 m | | Apple | "rejected due to having a domain present in the Spamhaus DBL" | 3/hr | Suspend | 4 h | | Comcast (vendor file) | `RL0000` (rate limited) | 2/hr | max_connection_rate = 10000/h | 2 h | | Comcast (vendor file) | `RL000010` (domain throttled) | Immediate | SuspendTenant | 5 m | | Orange | "Trop de connexions" | 2/hr | connection_limit = 1 | 1 h | | Orange | "Service refuse" | 2/hr | Suspend | 1 h | | Orange | "Client host blocked for spamming issues" (variant with the Cloudmark reset URL) | 5/hr | Suspend | 2 h | | Orange | "Client host blocked for spamming issues … spamhaus" | 5/hr | Suspend | 2 h | | Mimecast | "Internal resource temporarily unavailable" | 3/hr | Suspend | 30 m | | Netvigator | "Too many messages for this session" | 3/hr | Suspend | 30 m | | QQ | `550 Sender frequency limited` / `550 Ip frequency limited` / `550 Connection frequency limited` / `550 Domain frequency limited` / `550 Mail content denied` | 5/hr each | Suspend | 1 h | | 163.com | `451 DT:SPM` (anti-spam deferral) | 5/hr | Suspend | 15 m | | 163.com | `421 Too many connections` | 2/hr | connection_limit = 1 | 1 h | | 163.com | `554 DT:SPM` | 2/hr | connection_limit = 1 | 1 h | | 163.com | `550 RP:ORQ` or `554 HL:ITC` (daily limit reached) | 2/hr each | Suspend | 1 h | ## Reading the pattern Across providers, the community's throttling logic follows the design principles in [MTA Delivery Tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning): - Responses about mechanical limits (too many connections, or too many messages per session) get a parameter cut for about an hour. - Brief capacity problems ("server busy", "service unavailable") get short suspensions of 15–30 minutes. - Reputation events (deferrals for user complaints, blocklist rejections) get the longest suspensions (2–4 hours), because continuing to send through them makes reputation worse. Note also how low the baselines are compared with the global default. The biggest providers are shaped to 5 connections across the provider, and several regional providers (Orange, Yahoo Japan) to just 2. ## Caveats - The values are what worked for KumoMTA operators as of the fetch date. Providers change limits without notice, and the reputation of each IP address affects what a given sender actually gets. Check the values against your own deferral logs. - Several entries carry dates in the file (Barracuda and Netvigator are marked 2026-03-27, and the note on the Google and Workspace rollup is dated 2024-09-03). Each row has its own freshness. - The community file states explicitly that its rules are contributed as-is, and must be combined with the vendor's defaults file for full coverage. - These are limits that senders impose on themselves, not guarantees published by providers, except where a row is marked "provided directly by" the provider (Yahoo, Comcast, Mimecast, mail.com, Mailgun). # Placement Measurement Methodology > How inbox placement is actually measured — seed lists, subscriber panels, pixel/read-rate telemetry, and mailbox-provider dashboards — and the systematic bias each method carries, including Google Postmaster Tools' no-data blind spots. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/placement-measurement-methodology When you quote an inbox placement rate, you are quoting an estimate, because nobody outside a mailbox provider can see directly where a delivered message landed. SMTP tells you that a message was accepted (250 OK), but says nothing about whether it went to the inbox, to spam or to a Promotions tab, or was silently dropped. Every placement number an operator quotes therefore comes from one of four indirect methods, and **each method is wrong in a known, systematic direction**. Choose the method that fits your question, and correct for the bias built into its answer. For the monitoring program these methods feed, see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). For why the engagement signals behind some methods are themselves distorted, see [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion). For the most detailed dashboard from a single mailbox provider, see [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools). ## The four measurement methods at a glance | Method | What it observes | Real recipients? | Engagement captured? | Sees missing or blocked mail? | Provider coverage | Systematic bias | |---|---|---|---|---|---|---| | **Seed list** | Placement of a test message in dedicated test mailboxes | No | No | Yes | Broad (100s of providers) | Conservative and noisy: no engagement history, tiny sample | | **Subscriber panel** | Placement and behavior in real, monitored mailboxes of consenting people | Yes | Yes | No | Narrow (a few big webmail providers) | Optimistic: excludes mail that is missing or blocked at the gateway | | **Pixel or read-rate telemetry** | Open events on your own real sends | Yes (implicitly) | Opens only | Indirectly (a drop implies filtering) | Any provider you send to | Distorted by Apple Mail Privacy Protection (MPP) prefetch, proxies and scanners | | **Provider dashboard** | The receiver's own view of your reputation and spam rate | Yes (all of them) | Complaints, aggregate | Partially (delivery errors) | One provider each; only the major providers publish one | Blind below a volume floor; delayed; covers consumer mailboxes only | No single method is enough, and honest programs triangulate. The sections below explain how each method is built and where it misleads. ## Method 1: Seed lists (and personal test accounts) A **seed test** sends a copy of the campaign to a curated list of seed addresses. These are dedicated test mailboxes that the seed vendor maintains across many mailbox providers, spam filters and regions. The test reports where each copy landed: the inbox, spam, a specific tab (Gmail's Primary, Promotions, Updates, Social or Forums), a folder of a corporate filter, or **missing** (accepted and then dropped, or blocked at the gateway). Done well, the seeds are injected into the production send itself (the same message, the same infrastructure and IP, the same send window), so that their treatment approximates that of the real campaign rather than that of a test copy built by hand. What seed testing is genuinely good for: - **Quality checks before launch**: catching authentication failures (SPF, DKIM, DMARC), broken rendering and dead links before the real list sees them. - **Comparison between providers**: isolating a problem such as "we inbox everywhere except Microsoft." - **Testing changes**: one variable at a time, such as a new template, tracking domain or sending IP. - **Incident triage**: a quick read on whether a live problem comes from content, authentication or reputation. - **New programs with no history**: a panel needs your mail to reach real engaged users before it can say anything, whereas seeds report placement "irrespective of user-initiated or engagement-based filtering." For a cold program, a seed list may be the only signal available. ### Where seed lists lie The criticisms from Mailgun, the Certified Senders Alliance (CSA) and Suped agree on the same structural flaws: 1. **No engagement, while modern filters run on engagement.** Seed addresses do nothing. In the CSA's words, they "don't open or read emails, click on links, unsubscribe or complain." Placement at Gmail, Microsoft and Yahoo is now dominated by subscriber behavior (opens, clicks, forwards, complaints, deletes, saves), so a metric with no engagement input at all can differ sharply from what real subscribers experience. A seed result is a snapshot of how filters score content, authentication and reputation with no human in the loop. 2. **Providers do not treat seeds as real recipients.** Mailgun states plainly that "mailbox providers don't treat seed inboxes the same as actual recipients." Seed mailboxes have no history of receiving your mail, so their placement leans conservative (no accumulated goodwill), and they miss the personalized filtering that a real, engaged subscriber would benefit from. 3. **A tiny, unrepresentative sample.** A handful of test addresses cannot stand in for thousands of real recipients who vary in volume, timing and list quality. The results show a **single moment**, not an ongoing pattern. 4. **Both false positives and false negatives occur.** Seeds may show the inbox while real subscribers are filtered, or the reverse. **One poor seed result is usually noise**, so act only on a pattern repeated across several sends. 5. **Cost.** Professional seed list services are a recurring expense. Testing with your own personal accounts removes the cost but keeps every other limitation (a small sample, unrepresentative conditions, no real reputation dynamics). Practical rule: use seeds as a **directional signal and a quality gate**, review them separately for each mailbox provider, and cross-check them against real-world data (DMARC aggregate reports, complaint rates, bounce logs, blocklist status) before you change anything. ## Method 2: Subscriber panels A **panel** is a body of real mailboxes, owned by actual people who consent to be monitored by the measurement vendor. Validity (formerly Return Path) calls its panel a "Consumer Network", and others build equivalents. When your mail reaches a panelist, the vendor observes not only placement but also **behavior**: inbox or spam, whether the message was read, whether it was reported as spam, and other user actions. Panel data can therefore reveal the **filtering factors and thresholds based on engagement that non-interactive seeds cannot see**, which are exactly the signals that drive placement at the large providers. ### Where panels lie Their weaknesses mirror those of seeds: 1. **Narrow coverage of providers.** A panel only measures providers where it has enough panelists, historically the big consumer webmail services (Google, Microsoft's Outlook.com, Yahoo and, in the 2018 data, AOL). It says little about corporate or business-to-business (B2B) gateways, regional providers, or the long tail that seeds reach. 2. **No visibility of missing or blocked mail, so the number runs optimistic.** Panel measurement only sees mail that was accepted at the gateway and delivered to a panelist's mailbox. Mail blocked or dropped upstream never enters the denominator, so **inbox placement rates from panels are structurally higher than rates from seeds.** Validity's own illustration from 2018 (below) shows the size of this gap. 3. **Bias from the panel's composition.** Results reflect the demographics, provider mix and behavior of the panel, which may not match your audience. ### The seed-vs-panel gap, quantified (dated: 2018) > Note on sources: the figures below come from the **Return Path (now Validity) 2018 Deliverability Benchmark**, which sampled more than 2 billion promotional messages sent from July 2017 to June 2018 across 140+ mailbox providers. The cuts of panel and industry data use about 17,000 senders, 2 million panelists and 2 billion messages to Microsoft, Google, Yahoo and AOL. **The absolute rates are old and have been superseded** by newer benchmarks (see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring) for current Litmus figures, and [Deliverability Benchmarks](https://emailmarketing.net/learn/reference/deliverability-benchmarks) for current inbox, spam and missing rates measured with Validity seeds, by provider, region and industry). They are cited here only because the report puts the two methods side by side on identical mail. The relationship between the methods is the lesson that lasts. The same 2018 period, the same population of senders, two methods: | Metric | Panel data | Seed data | |---|---|---| | Global inbox placement | **91%** | **85%** | | Spam-folder rate | 9% | 6% | | Missing or blocked rate | **N/A** (not measurable) | **10%** | The panel's 91% and the seed's 85% describe the same mail. The gap of 6 points is almost entirely the roughly 10% of mail that seeds counted as missing or blocked and that the panel never saw. In Validity's own words: "inbox placement rates calculated with panel data do not factor in missing/blocked emails, so the resulting inbox placement rate will always be higher." **Whenever you compare two placement numbers, first ask which method produced each one.** A "91%" and an "85%" can be the same reality measured in two ways, not a real difference. A second panel cut, dated but illustrative, is worth keeping. In 2018, placement at the top four providers averaged 96% at AOL, 92% at Gmail, 92% at Yahoo and **75% at Outlook**. Microsoft was already the hardest major mailbox provider to reach in 2018, consistent with the pattern of Microsoft being the strictest that persists in current benchmarks. ## Method 3: Pixel and read-rate telemetry as a placement proxy Your own open tracking does not measure placement, but a collapse in it is a placement signal, because a message must reach the mailbox before any pixel can fire. This is the cheapest, broadest and most timely method (it covers every provider you actually send to, in real time), and also the most contaminated. [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion) explains the full mechanics. These are the points that matter when you use opens as a proxy for placement: - **Apple MPP fires the pixel when it prefetches on the receiving side**, for nearly every message delivered to an Apple Mail user, engaged or not. This makes individual opens almost worthless as a sign of attention, but it turns the aggregate MPP open rate into a de facto **proxy for inbox delivery in the Apple segment**, because an MPP open still requires the message to have reached the mailbox. - **A sudden drop in the aggregate open rate at one provider, while others hold steady**, is the classic sign of mail going to spam at that provider. It is the most sensitive early warning most senders have, precisely because it runs on your full real audience rather than on a sample. - It cannot tell the inbox from the Promotions tab, cannot see missing mail directly, and is polluted by opens from scanners and proxies. It tells you whether placement moved, not where it moved to. Confirm the direction and the location with a seed test or a dashboard. ## Method 4: Mailbox-provider dashboards, and their blind spots Provider dashboards ([Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), [Microsoft SNDS and JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp), Yahoo feeds) are the only "real data" straight from the receiver: the provider's own verdict on your reputation, your spam complaint rate and your authentication pass rates. They are authoritative where they report at all. Their weakness is not bias but **absence**: the dashboard goes blank exactly when a small or new sender most wants an answer. ### Google Postmaster Tools' no-data conditions Google Postmaster Tools (GPT) shows nothing, or shows gaps in a chart that is otherwise populated, for several distinct reasons. It matters to tell them apart, because "no data" is routinely misread as "a problem": | Cause of missing or blank data | What is actually happening | |---|---| | **Below the privacy volume floor** | Gmail suppresses reputation and dashboard data when a domain or IP has too little qualified traffic, to protect recipients' privacy. This is the most common cause and is not a fault. | | **Only @gmail.com counts** | Volume is measured against **personal Gmail recipients only**. Google Workspace and business mailboxes, and other domains, do not count toward the threshold. A "high-volume" B2B sender can be below the threshold at Gmail. | | **Low-volume days omitted** | Individual days with little volume are dropped for privacy, which produces gaps in an otherwise populated series. A gap means "too few that day", not zero. | | **Domain or subdomain scope mismatch** | Data is tied to the exact verified authentication domain, and the verified domain must match the **DKIM `d=` signing domain**. Traffic on the root domain and on subdomains is reported separately, so verifying the wrong one shows a blank. | | **Reporting gaps without backfill** | Google has had periods when reputation data stopped and came back later **without backfilling** the missing dates. This is an outage on Google's side, not a problem with your sending. | | **Reputation-chart retirement** | Google retired the legacy High, Medium, Low and Bad reputation charts around **September 30, 2025**, and historical reputation views became unreliable whatever your volume. | ### The volume you need, and how fast data appears Google publishes **no fixed minimum**. These thresholds were observed by practitioners (Suped), and all of them count **personal Gmail recipients per day**: | Daily Gmail volume | Dashboard behavior | |---|---| | **Under about 100 per day** | Sparse: often no data, many missing days | | **About 100–300 per day** | Intermittent: some dashboards populate, but daily movement is weak | | **Hundreds per day** | Usually useful, consistent trend data | | **5,000+ per day** | This is the line for bulk senders in the [Gmail requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements), a compliance threshold and **not** the threshold for display. You get useful data well below it | Plan on **hundreds of messages a day to personal Gmail addresses** for reliable dashboards. Once the volume is enough, the timing is: | Signal | Delay before it appears or updates | |---|---| | Initial data after a new domain is verified | About 24–48 hours | | Spam-rate metric | About 1–2 days | | Domain reputation trend | About 1–2+ days | | Compliance status | Up to **7 days** (a rolling calculation) | In Google's own words, dashboard data is "usually updated within 24 hours, but can take longer." There is **no retroactive data**. A domain enrolled after an incident has no history for the period of the incident, which is why every authentication domain should be enrolled before problems occur. The general blind spot: **every provider dashboard is an instrument for consumer mail, above a floor, and delayed.** Below the floor, and for B2B or corporate destinations that publish no dashboards at all, you are back to seeds and panels. ## When to trust which | The question you're answering | Reach for | Why | |---|---|---| | "Will this campaign render and authenticate before I send it?" | Seed list | Quality checks before sending are exactly what seeds do, and engagement does not matter for a check of rendering or authentication | | "At which providers is my mail going to spam right now?" | Panel and seed | Seeds for broad coverage, including missing mail; the panel for the major providers driven by engagement | | "Did placement just move for my real audience?" | Pixel or read-rate trend | The broadest and most timely; a drop in open rate at one provider is the earliest warning | | "What does Gmail actually think of my reputation?" | Google Postmaster Tools | The receiver's own verdict, authoritative where it reports | | "Am I reaching the inbox with a new or cold program?" | Seed list | Panels and dashboards need real engaged volume that you do not have yet | | "How bad is my missing or blocked mail?" | Seed list | The only method that measures mail accepted and then dropped, or blocked at the gateway | | "What is my true complaint rate at Microsoft?" | SNDS and JMRP | Complaints reported by the provider beat any inference | | "What is my inbox rate at a corporate B2B gateway?" | Seed list (with caution) | No panel or dashboard covers these; seeds are the only lens, and a thin one | Two rules follow from the whole table: - **Never compare one placement number with another without knowing both methods.** Panel rates are higher than seed rates by construction, because the panel excludes blocked and missing mail. A vendor that quotes a higher number may simply be using panel data. - **Corroborate before acting.** Seeds and pixel trends bring up candidates; DMARC reports, complaint rates, bounce logs, blocklist status and provider dashboards confirm them. One bad seed result, or one day's dip in opens, is noise until a second method agrees. ## Related articles - [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring), including the monitoring stack these methods feed and current benchmark inbox rates - [Tracking and Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion) - [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools) - [Microsoft SNDS and JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp) - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), the thresholds these measurements are judged against - [Deliverability Testing Tools](https://emailmarketing.net/learn/reference/deliverability-testing-tools), including seed and inbox placement vendors # Reading Received Headers: Hops, Delays, and What They Prove > How to read the Received trace fields of a delivered message: the field syntax, bottom-to-top order, which hops you can trust, computing per-hop delay across time zones, and how Received relates to Authentication-Results. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/reading-received-headers Every SMTP server that accepts a message adds a `Received:` line to the top of it. Read together, those lines record the route the message took and when each host received it. They are the first thing to check when a message arrived late or by an unexpected path. Some of the lines are reliable evidence and some are only claims, and this article explains how to tell which is which. The rules come from [RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp) §4.4 (trace information) and [RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format) §3.6.7 (trace fields). The relationship with `Authentication-Results` comes from RFC 8601 (see [the Authentication-Results header](https://emailmarketing.net/learn/authentication/authentication-results-header)). ## Where Received lines come from RFC 5321 §4.4: "When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content." Three consequences follow directly from the same section: - **Each line is written by the receiving host, not the sender.** A `Received:` line records one host accepting the message. - **Lines are only added at the top.** "SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location." - **Existing lines are not edited or removed.** "An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section." These are requirements on compliant software, not guarantees about every message. RFC 3848 §3 notes that "some people in a misguided attempt to hide information about their internal servers will strip Received headers of useful information", so a chain can have gaps. When the message leaves SMTP at final delivery, the delivering server also adds `Return-Path:`, which holds the envelope `MAIL FROM` address. RFC 5321 §4.4 says the delivered message will "begin with a return path line, followed by one or more time stamp lines." RFC 5322 §3.6.7 treats these fields as "strictly informational, and any formal interpretation of them is outside of the scope of this document." There's nothing to validate: a `Received:` line is only as trustworthy as the host that wrote it. ## Field syntax RFC 5321 §4.4 defines the line (abridged; `FWS`/`CFWS` are folding whitespace and comments from RFC 5322): ``` Time-stamp-line = "Received:" FWS Stamp Stamp = From-domain By-domain Opt-info [CFWS] ";" FWS date-time Opt-info = [Via] [With] [ID] [For] [Additional-Registered-Clauses] ``` A line can be folded over several physical lines, so unfold it before reading. The clauses, in order: | Clause | What it records | Who supplies the value | |---|---|---| | `from` | The host that handed the message over. RFC 5321: it "SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection." The parenthesized part (`TCP-info`) is "Information derived by server from TCP connection not client EHLO." | The **name before the parentheses** is what the client said in `EHLO`. **The address inside the parentheses** is what the receiving server observed on the connection. | | `by` | The host that received the message and wrote this line. | The receiving server. | | `via` | The link type (`TCP`). RFC 5321: "'Via' is primarily of value with non-Internet transports." | The receiving server. | | `with` | The protocol: `SMTP` or `ESMTP` in RFC 5321, plus names registered with IANA. RFC 3848 registered `ESMTPS` (STARTTLS negotiated), `ESMTPA` (SMTP AUTH succeeded), `ESMTPSA` (both), and `LMTP` with its `A`/`S`/`SA` variants. | The receiving server, describing **this hop only**. | | `id` | An identifier chosen by the receiving server, an atom or a `msg-id`. RFC 5321: it "MAY contain an '@'… but this is not required." RFC 5321 doesn't define what it identifies. | The receiving server. If you operate that host, look the value up in its logs. | | `for` | The recipient. RFC 5321: "If the FOR clause appears, it MUST contain exactly one `` entry, even when multiple RCPT commands have been given." | The receiving server. It is optional. | | `; date-time` | When this host received the message, in RFC 5322 `date-time` format. RFC 5321 forbids the obsolete forms, "especially two-digit years". | The receiving server's own clock. | Don't read the `with` keyword as proof of encryption or authentication. RFC 3848 §3 says these keywords "can be modified by an active attacker" and "do not provide any real-world security assurance." The grammar allows comments (`CFWS`) between clauses, so implementations add parenthesized free text. The content of those comments isn't standardized, so don't parse it as if it were. ## Reading order: bottom to top Every server prepends its own line, so the lines read newest first: - The **bottom** `Received:` line is the earliest hop recorded: the first server that accepted the message and wrote a line. - The **top** `Received:` line is the most recent hop. - Compare the `by` host of each line with the `from` host of the line above it. They often won't be written the same way, because the `from` name is the client's `EHLO` claim, and a host's `EHLO` name can legitimately differ from the name it writes in `by`. A mismatch is a reason to look closer, not proof that a hop is missing or a line is false. The IP addresses in the `from` parentheses are the better thread to follow. To trace the route, start at the bottom and read up. ## Which hops you can trust Knowing where the lines came from tells you how far to trust them. 1. **A line is only as reliable as the host that wrote it.** Any SMTP client can open a connection and write anything into the message content before `DATA` ends, including text that looks like earlier `Received:` lines. RFC 5321 §7.1: "it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else." 2. **Your servers preserve whatever they were given.** Existing lines "MUST NOT" be changed or deleted, so a receiving server keeps the fabricated lines along with the real ones. 3. **So you can trust only the lines your own receiving infrastructure added.** Here "your own" means the receiving side's ADMD, the administrative domain RFC 8601 §1.2 describes as being inside its "trust boundary". Find the lowest line whose `by` host is one of your own servers. That is the **first trusted hop**, the moment the message entered your infrastructure. 4. **In the first trusted hop, trust only what your server observed.** That means its timestamp, its `id`, its `with` protocol, and the **IP address in the `from` parentheses**, which came from the TCP connection. The `from` name before the parentheses came from the client's `EHLO` and is a claim. 5. **Everything below the first trusted hop can be forged.** Lines below it were already in the message when your server accepted it. They may be accurate: a legitimate sender's own relays write accurate lines, and they help you debug that sender's side. But the connecting IP in the first trusted hop is the only address in the chain your infrastructure verified. The same logic applies when you're the sender reading a copy that reached a mailbox you don't operate. Only the lines added by the **receiving** provider's infrastructure are the receiver's observations. The lines below them are your own systems' records, which you can check against your own logs. ## Per-hop delay Each timestamp marks when *that* host received the message. The difference between two adjacent timestamps is how long the message spent between one receipt and the next: queued on the lower host, or in transit from it. ### Normalize time zones first RFC 5321 §4.4 asks servers to use numeric offsets: "SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) SHOULD be used rather than UT when feasible." RFC 5322 §3.3 defines the offset: "+hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes." A timestamp of `-0000` means "the time was generated on a system that may be in a local time zone other than Universal Time and that the date-time contains no information about the local time zone." To compute a delay, convert every timestamp to UTC by subtracting its offset (`09:00:02 -0400` is `13:00:02 UTC`), then subtract adjacent values. If you compare the wall-clock times without converting, a hop can appear to take hours, or even to happen before the hop below it. ### Clock skew Each timestamp comes from the clock of the host that wrote it, and nothing in RFC 5321 requires those clocks to agree. RFC 5321 does say "comparability of Received header fields is important for detecting problems, especially slow relays", which is why the offsets matter. The following is practical reasoning from how the timestamps are produced, not an RFC requirement: - A **negative** delay, where a later hop's timestamp is earlier than the hop below it, means the two clocks disagree. It can't mean the message went back in time. Report the hop as "clock disagreement" rather than as a delay. - A **small** delay between hosts run by different operators can be within the clocks' margin of error. Give more weight to a small delay between two hosts on the same infrastructure. ### What a long delay can indicate A long gap between two hops means the message waited somewhere between those two receipts. Known causes consistent with such a gap: - **A temporary failure and a retry.** After a `4xx` reply the sending host keeps the message and tries again later. RFC 5321 §4.5.4.1: "In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery." That's a recommendation, not a floor. A deferral retried in line with it leaves a gap of about 30 minutes or more, but a sender using another strategy can retry sooner. See [MTA delivery tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning). - **Greylisting.** RFC 6647 describes it as "degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours)", and notes that "Some popular MTAs do not retry failed delivery attempts for an hour or more." See [greylisting](https://emailmarketing.net/learn/rfc/rfc6647-greylisting). - **The lower host holding the message** in its queue before its first attempt. The header does not record why. See [MTA delivery tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) for how sending queues schedule work. ### What a long delay does not prove - **It doesn't tell you the cause.** RFC 6647 §3 puts it plainly: "A client does not know, nor is it entitled to know, the reason for the temporary failure status code being returned; greylisting could be in effect, or it could be caused by a local resource issue at the server." The header shows *where* time passed. The *why* is in the reply codes and text logged by the host that held the message: check its logs using the `id` from the line it wrote. See [delivery troubleshooting playbooks](https://emailmarketing.net/learn/operations/delivery-troubleshooting-playbooks). - **It doesn't prove anything below the first trusted hop.** A delay between two lines you can't trust may be invented. - **It says nothing about what happened after the top line.** Time between the last `Received:` stamp and the moment a person saw the message isn't recorded here. - **It says nothing about folder placement or filtering.** `Received:` lines record acceptance and timing only. ## How Received relates to Authentication-Results The receiver that checked SPF, DKIM, and DMARC records its verdict in an `Authentication-Results:` field (RFC 8601). Both kinds of field face the same forgery problem, and they share the same solution: rely only on fields added inside your own trust boundary. RFC 8601 §5 allows one exception: a border MTA "MAY elect not to delete" results from an upstream host it explicitly trusts, "even though they exist in completely disjoint administrative boundaries." - **Authentication-Results behaves like a trace field.** RFC 8601 §4.1: it "MUST be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL] and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done." - **Forged copies are stripped at the border.** RFC 8601 §5: an MTA "MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA." Section 1.6 explains the reason: "valid use of the header field requires removing any occurrences of it that claim to be associated with the ADMD when the message enters the ADMD." - **Position can serve as a validity test.** RFC 8601 §7.1 lists this among several proposed approaches, none of which it standardizes. The test assumes "internal MTAs are fully compliant" and use their own hostnames or the ADMD's domain as the `authserv-id`. Under that assumption, "this header field should always appear above a Received header added by a trusted MTA. This can be used as a test for header field validity." - **Trust is an explicit list, not a default.** RFC 8601 §7.1: "It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy; however, this list should initially be empty." The **trust anchor** is therefore the receiver that added both your first trusted `Received:` line and an `Authentication-Results:` field whose `authserv-id` it owns. Read that pair together: - The `Received:` line gives the connecting IP it observed. - The `Authentication-Results:` line gives the verdicts it computed for that connection. An `Authentication-Results:` field below the first trusted hop, or carrying someone else's `authserv-id`, is another party's claim. For how authentication results can survive a forwarder, see [ARC](https://emailmarketing.net/learn/authentication/arc). Even a trusted `pass` is limited in what it tells you. RFC 8601 §7.2: "the existence of this header field indicating a "pass" does not render the message trustworthy." ## Worked example The message below was sent by a customer of `example.net`'s sending platform to a recipient at `example.com`. Names, IDs and addresses are fictitious; the IPs are from the documentation ranges. The header section is shown top to bottom as it appears in the delivered message, and non-trace fields are omitted: ``` Return-Path: Received: from mx1.example.com (mx1.example.com [192.0.2.25]) by store.example.com with LMTP id 9KcQ2 for ; Thu, 10 Sep 2026 13:31:11 +0000 Authentication-Results: mx1.example.com; spf=pass smtp.mailfrom=bounce.example.net; dkim=pass header.d=example.net; dmarc=pass header.from=example.net Received: from out1.example.net (out1.example.net [198.51.100.20]) by mx1.example.com with ESMTPS id 4Q8kx2 for ; Thu, 10 Sep 2026 15:31:10 +0200 Received: from submit.example.net (submit.example.net [198.51.100.5]) by out1.example.net with ESMTP id A71F3; Thu, 10 Sep 2026 13:00:03 +0000 Received: from workstation.example.net (workstation.example.net [203.0.113.10]) by submit.example.net with ESMTPSA id 0e2c9; Thu, 10 Sep 2026 09:00:02 -0400 ``` **Step 1: read bottom to top and check continuity.** The route is `workstation` → `submit.example.net` → `out1.example.net` → `mx1.example.com` → `store.example.com`. Each line's `by` host is the next line's `from` host, so the chain is continuous. **Step 2: find the first trusted hop.** The receiving infrastructure is `example.com`. The lowest line written `by` an `example.com` host is the `mx1.example.com` line. That is the first trusted hop, and the connecting IP it observed was `198.51.100.20`. The two lines below it were written by `example.net` hosts. They are the sending platform's own records: useful to its operators and checkable against their logs, but unverified claims from the receiver's point of view. **Step 3: tie in Authentication-Results.** The `Authentication-Results:` field carries `authserv-id` `mx1.example.com` and sits directly above the `Received:` line `mx1` wrote. That matches the position test in RFC 8601 §7.1. Its SPF, DKIM, and DMARC verdicts are `mx1`'s judgement of the message that arrived from `198.51.100.20`. **Step 4: normalize timestamps and compute delays.** | Hop (written by) | Timestamp as written | UTC | Delay from the previous hop | |---|---|---|---| | `submit.example.net` | 09:00:02 -0400 | 13:00:02 | — (first hop) | | `out1.example.net` | 13:00:03 +0000 | 13:00:03 | 1 s | | `mx1.example.com` (first trusted) | 15:31:10 +0200 | 13:31:10 | **31 min 7 s** | | `store.example.com` | 13:31:11 +0000 | 13:31:11 | 1 s | Read as local times, the `mx1` hop looks 2.5 hours later than `out1`. The actual gap is 31 minutes, and the message spent them between `out1.example.net` receiving it and `mx1.example.com` accepting it. **Step 5: interpret carefully.** A 31-minute gap fits a single temporary failure followed by a retry in line with RFC 5321's recommended interval of at least 30 minutes. It also fits greylisting, or queueing on `out1`. The header alone can't tell these apart. The sending platform's delivery log for queue ID `A71F3` on `out1` records whether an attempt was deferred and what the reply text said. And since `out1`'s timestamp comes from the sending side, clock disagreement between the two operators is part of the margin. ## Checklist - Unfold every `Received:` line, then read from the bottom up. - Compare each `by` host with the `from` host of the line above it. A mismatch is a reason to look closer, not proof of a missing or false hop. - Find the lowest line written `by` your receiving infrastructure. Trust that line and the lines above it; treat everything below it as a claim. - In the first trusted hop, rely on the IP in the `from` parentheses, not the `EHLO` name. - Convert every timestamp to UTC before subtracting. Treat negative delays as clock disagreement. - Use a long delay to locate the host that held the message, then find the cause in that host's logs using the line's `id`. - Read the `Authentication-Results:` field whose `authserv-id` belongs to the receiver and that sits above that receiver's own `Received:` line. ## Related articles - [RFC 5321 — SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp) · [RFC 5322 — Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format) · [RFC 5598 — Email Architecture](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture) - [The Authentication-Results header](https://emailmarketing.net/learn/authentication/authentication-results-header) · [ARC](https://emailmarketing.net/learn/authentication/arc) · [SPF](https://emailmarketing.net/learn/authentication/spf) · [DKIM](https://emailmarketing.net/learn/authentication/dkim) - [Greylisting (RFC 6647)](https://emailmarketing.net/learn/rfc/rfc6647-greylisting) · [MTA delivery tuning](https://emailmarketing.net/learn/operations/mta-delivery-tuning) · [SMTP TLS practice](https://emailmarketing.net/learn/transport-security/smtp-tls-practice) - [Delivery troubleshooting playbooks](https://emailmarketing.net/learn/operations/delivery-troubleshooting-playbooks) # Reputation Incident Recovery > The recovery runbook after a compromise or reputation collapse — securing the account, purging queues, rebuilding suppressions, re-warming vs cold warm-up, reading deferrals during recovery, automated warmup schedules as vendors implement them, and when to replace vs rehabilitate an IP or domain. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/reputation-incident-recovery When a compromised account or API key has pumped spam through your infrastructure, or a list accident or another event has collapsed the reputation of your IP addresses or domains, recovery takes days or weeks of deliberate work. The runbook below covers the recovery sequence, how re-warming differs from a cold warm-up, and how to read push-back from receivers while you rebuild. For detection, diagnosis and blocklist delisting, see [Reputation Monitoring and Remediation](https://emailmarketing.net/learn/operations/reputation-monitoring). For building reputation from scratch, see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up). ## Post-compromise restoration sequence The sequence below combines SendGrid's documented guidance on restoring reputation after a compromise with standard incident practice at email service providers (ESPs). Order matters, because every step assumes that the previous one is complete. Re-warming on top of an unsecured account or a dirty queue only burns again the reputation you are trying to rebuild. ### 1. Stop the bleeding - **Pause all sending for several days.** SendGrid's guidance is explicit: stop sending, to prevent further reputation damage, before you attempt anything else. Mail sent while receivers are actively penalizing you makes the damage deeper. - **Secure the account.** Rotate every credential and API key, revoke unknown API keys and teammate or subuser access, enable and enforce two-factor authentication (2FA), and check for domains, senders, webhooks or templates the attacker added. Close the route of the compromise before any recovery mail goes out. Otherwise the attacker resumes the moment you do. - **Purge the queues.** Drain or delete everything that is still queued or deferred from the period of the incident. Deferred spam that keeps retrying for hours or days after "recovery" goes on generating complaints, trap hits and blocks under your name. ### 2. Rebuild the data layer - **Rebuild suppression lists.** Attackers commonly delete or export suppression lists (bounces, complaints, unsubscribes), and the mail sent during the compromise generated new bounces and complaints that you must honor. Restore suppressions from backup, merge in every bounce and feedback loop (FBL) complaint from the period of the incident, and permanently suppress any address the attacker mailed that was not on your opt-in list. - **Cut the send list down to recently engaged recipients** ("remove unengaged recipients from your contact list", in SendGrid's words). Recovery sending uses only your best data, the recipients who recently opened or clicked, exactly as at the start of a [warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up), but with even less margin for error. ### 3. Re-verify infrastructure - **Confirm authentication end to end:** SPF, DKIM and an enforced [DMARC](https://emailmarketing.net/learn/authentication/dmarc) record on all sending domains. SendGrid lists setting up DMARC on all sending domains as a core restoration step. It blocks continued spoofing of your domain, and it signals to receivers that you are in control. - **Check again that you meet the providers' requirements for bulk senders** ([Gmail](https://emailmarketing.net/learn/providers/gmail-sender-requirements), [Yahoo](https://emailmarketing.net/learn/providers/yahoo-sender-requirements), [Microsoft](https://emailmarketing.net/learn/providers/microsoft-sender-requirements)). An incident is often the moment when enforcement that was previously dormant becomes active. - **Enroll in every monitoring channel before you resume:** [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), [Microsoft SNDS and JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp), and [Yahoo's complaint feedback loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop). They give you each provider's verdict, which decides whether you can take each step up in volume. ### 4. Delist and notify - Request blocklist delisting by following the [delisting workflow](https://emailmarketing.net/learn/operations/reputation-monitoring#blocklist-delisting-workflow), after you have fixed the root cause. A compromise is one of the few causes of listing where operators routinely delist quickly, once you can show that the account is secured. - If blocks persist at a specific provider after recovery, contact that provider's postmaster or support channel directly, with a description of the incident and of the remediation. SendGrid explicitly recommends asking the support teams of the major providers for help tailored to your case. ### 5. Gradual re-ramp - Resume with a **manual warm-up process**: small volumes to engaged recipients, increased gradually (see the schedules below). On platforms with automated warmup, you may need to re-arm the automation or put the IP back into warmup. An IP that kept its "graduated" warmup status inside the platform has still lost its reputation with receivers outside it. - **Set expectations** using SendGrid's stated timeline. Internal reputation measures (the platform's own engagement scores) recover relatively quickly. External reputation with recipient servers can take **up to a month** or longer of patient, consistent sending. Full inbox recovery after severe damage, as documented by the community, takes **8–12 weeks** (see [Recovering inbox placement](https://emailmarketing.net/learn/operations/reputation-monitoring#recovering-inbox-placement)). - Track the quality of engagement continuously during the ramp. SendGrid points to **engagement recency** and **unique open rate** as the scores to watch. On any platform, the equivalents are the trends in opens, clicks and complaint rate at each provider. ## Re-warming after an incident vs cold warm-up Re-warming uses the same mechanics as a [cold warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up), but the situation differs in ways that change the plan: | Dimension | Cold warm-up (new IP or domain) | Re-warm (after an incident) | |---|---|---| | Starting reputation | Slightly negative: unknown, and treated with suspicion | Actively negative: receivers have a concrete bad history tied to the asset | | Prerequisite | Nothing beyond setting up DNS and authentication | Root cause fixed, queues purged, suppressions rebuilt, delistings requested. Ramping before this triggers the penalties again | | Pacing | A standard schedule (for example, +50% per week, or a vendor's stage plan) | The same shape, but expect to hold or step back at individual providers. Receivers that blocked you throttle again, harder and for longer | | Audience | Recently engaged recipients | Even stricter: only recently engaged recipients, with high-risk flows (win-back, re-engagement, third-party) suspended for the whole recovery | | Signals that gate each increase | Deferral and failure rates, inbox placement | The same, plus a blocklist check before each increase. A new listing during a re-warm is treated more harshly than the first listing | | Timeline | Weeks to full volume | External trust: from up to a month (SendGrid) to 8–12 weeks for full inbox recovery | Two further rules documented by vendors bear on re-warming: - **Dormancy resets warm-up.** SendGrid says that if an IP has not sent mail in **over 30 days**, warm-up should be resumed before returning to volume. A recovery pause of several weeks therefore creates a re-warm requirement by itself, independently of the incident. - **Prevention is cheaper.** In SendGrid's own words, "establishing a positive reputation as a sender takes less effort than repairing an existing reputation." Budget recovery time accordingly. ## Deferral handling during recovery Deferrals (4xx temporary failures) are the main real-time feedback during a re-ramp. Receivers rarely explain a reputation penalty, but they always throttle. The concepts below come from SendGrid's documentation on deferrals, and the mechanics apply to any mail transfer agent (MTA). **What a deferral is:** the recipient server cannot accept the message at the moment. It is a temporary condition, not a rejection, and retries may succeed. All senders receive some deferrals. The signal is in their rate and their pattern, not in their existence. **Retry behavior (SendGrid's implementation, typical of ESPs):** deferred messages are retried with exponential backoff for **up to 72 hours**. A message that is still undelivered after that is finalized as blocked or expired. During automated warmup, a warming IP that reaches its hourly cap stops sending, and the account's other IP addresses carry the traffic. With no backup IP addresses, messages are retried roughly every **15 minutes for 72 hours** before they expire. **Types of deferral.** Work out who is doing the throttling: | Type | Example reasons | Meaning during recovery | |---|---|---| | External (initiated by the receiver) | "IPs were throttled by recipient server" | The provider is limiting you because of your reputation. This is the core recovery signal | | External (based on limits) | "IPs reached ISP-suggested hourly limits" | You exceeded the warmup or ramp threshold for that provider. This is a pacing problem, not necessarily a reputation problem | | Internal (initiated by the platform) | "reached ISP-suggested max connection limits", "max port limit", "max connection limit" | Your own platform is deliberately slowing delivery to protect reputation. Do not fight it | **Operational rules during a re-ramp:** - **When the deferral rate rises at one provider, hold or reduce volume at that provider.** Deferrals are throttling, the step before blocking (see [warning signs](https://emailmarketing.net/learn/operations/reputation-monitoring#warning-signs-and-thresholds)). Do not advance the ramp while a provider is deferring at elevated rates. - **Do not force your way through deferrals.** Opening more connections, or injecting deferred mail again as new messages, turns throttling into blocks. - **For deferrals caused by limits**, reduce the delivery rate, or spread delivery across more warmed IP addresses. For deferrals where the receiver is throttling you, let the retry system pace delivery. SendGrid's documented remediation table says "no action required; delivery auto-slowed." - **Measure the impact through end-to-end delivery time**, the gap between your platform accepting the message and its final delivery. Deferrals with short end-to-end times mean the throttle is absorbing your ramp without harming campaigns. Growing end-to-end times mean you are ramping faster than the receiver will accept. - **Pause entirely** when deferrals at a provider turn into hard blocks, or into 72-hour expirations, at meaningful rates. That provider is telling you the reputation is not ready. Drop volume there to near zero, and rebuild with only your most engaged recipients. ## Automated warmup schedules as implemented Vendor automation is useful reference data when you build your own ramp logic. The mechanics are described conceptually, and each number is attributed to its vendor. ### SendGrid automated warmup (41-day hourly-cap schedule) SendGrid throttles a warming dedicated IP with an hourly sending cap that grows by about 40% per day over 42 days (day 0–41). When the cap is reached, the warming IP stops for the rest of the hour, and the account's other IP addresses carry the overflow, including other warming IP addresses that still have room. With no backup IP addresses, mail is retried about every 15 min for up to 72 h. After day 41 the IP leaves warmup. The schedule, as published by the vendor: | Day | Hourly cap | Day | Hourly cap | Day | Hourly cap | |-----|-----------|-----|-----------|-----|-----------| | 0 | 20 | 14 | 2,222 | 28 | 246,953 | | 1 | 28 | 15 | 3,111 | 29 | 345,735 | | 2 | 39 | 16 | 4,356 | 30 | 484,029 | | 3 | 55 | 17 | 6,098 | 31 | 677,640 | | 4 | 77 | 18 | 8,583 | 32 | 948,696 | | 5 | 108 | 19 | 11,953 | 33 | 1,328,175 | | 6 | 151 | 20 | 16,734 | 34 | 1,859,444 | | 7 | 211 | 21 | 23,427 | 35 | 2,603,222 | | 8 | 295 | 22 | 32,798 | 36 | 3,644,511 | | 9 | 413 | 23 | 45,917 | 37 | 5,102,316 | | 10 | 579 | 24 | 64,284 | 38 | 7,143,242 | | 11 | 810 | 25 | 89,998 | 39 | 10,000,539 | | 12 | 1,000 | 26 | 125,997 | 40 | 14,000,754 | | 13 | 1,587 | 27 | 176,395 | 41 | 19,601,056 | SendGrid adds two caveats. Transactional streams should not be forced onto a strict schedule, because you cannot control how often they are triggered. And no schedule replaces good sending practices: a gradual ramp alone does not guarantee reputation. ### Mailgun warmup (volume-stage model and API) Mailgun's automatic warmup uses **stages based on volume** rather than calendar days. Each stage has a daily cap, and the IP moves to the next stage once it has sent that stage's volume. Stage progression and the 24-hour window are independent: sending the full volume of a stage moves you on however many hours have passed, and the 24-hour window starts with the first message. The stage caps Mailgun publishes are **1,000 per day for Stage 1 and 2,500 per day for Stage 2**. Later caps are not published, and according to the schedule model in the API, a plan can run to 15 stages. Reaching a daily cap early stops all sending from that IP until the 24-hour window resets. **Overflow traffic is rerouted, not dropped**: volume beyond the warming IP's cap moves to the account's shared IP addresses or to other dedicated IP addresses, so the mail is still sent, just not from the warming IP. A full warmup typically takes **4–8 weeks**. You can drive the warmup through the API (Mailgun API reference, specific to this vendor): | Operation | Endpoint | Purpose | |---|---|---| | GET | `/v3/ip-warmups` | List the status of IP warmups in progress | | GET | `/v3/ip-warmups/{addr}` | Status of one warmup in progress (current stage, stage and hourly limits, total number of stages) | | POST | `/v3/ip-warmups/{addr}` | Create a warmup plan for an IP | | DELETE | `/v3/ip-warmups/{addr}` | Cancel the warmup plan | Mailgun's guidance for manual warmup (an archived help-center article, 2023 snapshot) makes three recommendations: - Use dedicated IP addresses from **100,000 emails per month**. This is Mailgun's own rule. To compare it with other vendors' minimums and with the general statistical floor for each IP, see the canonical [table of volume floors for dedicated IP addresses](https://emailmarketing.net/learn/operations/sending-infrastructure-practices#dedicated-ip-volume-floors-canonical). - Start at **100 emails on day one** and increase by about **20% per day**, sending every day. Sending three times a week or less works, but builds trust more slowly. - Do not use domains **less than 30 days old** at all. Receivers associate newly purchased domains with spammers who cycle through burned domains. **Design implications for your own ramp automation.** The two implementations agree on four points. Cap the warming asset instead of queueing and forcing mail, and send the overflow down a path that is already warm. Grow caps geometrically (about 20–50% per day). Make progression depend on volume actually sent, not only on elapsed time. And treat push-back from receivers (deferrals) as a stop condition that the automation must respect. ## Replace or rehabilitate? Decision points After a severe incident, the tempting shortcut is a fresh IP address or domain. The default answer is to **rehabilitate**, because replacement rarely escapes the problem: - **New assets start negative, not neutral.** Receivers presume that a new IP belongs to a blocked spammer who has moved (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)), and they treat domains younger than about 30 days as a sign of spammers cycling domains (Mailgun). Swapping assets is exactly the pattern filters are built to catch. - **Reputation follows the mail, not only the asset.** Domain reputation, content fingerprints and list quality move with you to the new IP. If the root cause is not fixed, the new asset burns out faster than the old one recovered. - **Listings caused by a compromise clear quickly.** Blocklist operators and providers routinely reverse listings caused by a compromise that is documented and remediated, so rehabilitation is a real option in this scenario (see the [delisting workflow](https://emailmarketing.net/learn/operations/reputation-monitoring#blocklist-delisting-workflow)). Replacement, with a full warm-up from zero, is the right choice only when rehabilitation is not possible or costs more than starting over: | Factor | Favors rehabilitation | Favors replacement | |---|---|---| | Listing status | Can be delisted; the operator responds to evidence of remediation | Permanent or repeated listing after badly handled requests; the asset is on lists with no practical way to be removed | | History depth | A short incident on an otherwise good asset | A long history of abuse that predates you (for example, an IP or domain you inherited that was abused before) | | Provider response after remediation | Deferrals easing, and reputation dashboards recovering within weeks | Sustained hard blocks at major providers despite a clean re-warm over several weeks | | Asset role | The primary brand domain (organic, inherent reputation, Brand Indicators for Message Identification (BIMI), customer recognition: effectively irreplaceable) | A dedicated sending IP or a sending subdomain, cheap to rotate and warm up again | | Time economics | Recovery expected to take roughly no longer than a warm-up (a re-warm on a rehabilitated asset can be faster than the 4–8+ weeks a cold warm-up takes) | Recovery has stalled beyond the timeline of a cold warm-up | For domains, there is a practical middle path. Never replace the organizational domain. Rehabilitate it, and move mail streams to a fresh, properly delegated subdomain warmed up from zero. This isolates the damage without the penalty for a new domain. For the mechanics of isolating streams, see [M3AAWG Sending Domains BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-sending-domains) and [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation). Whatever you replace, retire the burned asset cleanly, keeping it authenticated and its protective DNS records in place (see [Brand Protection: Domain Management](https://emailmarketing.net/learn/reference/brand-protection-domain-management)). ## Related articles - [Reputation Monitoring and Remediation](https://emailmarketing.net/learn/operations/reputation-monitoring), including the recovery playbook based on engaged segments - [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up) - [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), on subdomain strategy and domain warm-up - [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) - [Mandated and Regulatory Email](https://emailmarketing.net/learn/operations/mandated-and-regulatory-email), for sends that cannot wait for a recovery window # Reputation Monitoring and Remediation > How senders monitor IP and domain reputation in practice — blocklist monitoring, seed/inbox-placement testing, provider dashboards, feedback loops, warning signs, and the delisting/recovery workflow. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/reputation-monitoring Your sender reputation can slip at any time, and when it does, the consequences escalate from placement in the spam folder to blocklisting to outright rejection. Below is how to watch reputation continuously, and what to do when it drops. Sender reputation works like a credit score. With no sending history, you have neither a bad reputation nor a good one: a history of performance must exist before mailbox providers extend "credit", in the form of tolerance for your volume and placement in the inbox. Reputation is not fixed. For what reputation is built from, see [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability). For building it on new IP addresses, see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up). ## Delivery vs. deliverability: why you need to monitor - **Delivery**: the receiving server accepted the message (visible in your logs as a 250 OK). - **Deliverability**: where the message landed after it was accepted. That may be the inbox, a tab such as Promotions or Updates, the spam folder, or nowhere, because it was silently dropped ("missing"). Confirming delivery from SMTP responses is straightforward. Knowing placement is much harder, because each mailbox provider applies its own private routing and filtering algorithms after it accepts a message. A message that reaches the inbox at Yahoo may go to the spam folder at Gmail or Microsoft. Without placement data, deliverability problems are hard to detect and diagnose: engagement metrics quietly decline while the delivery rate stays high. How much mail actually goes missing: Litmus's 2026 benchmark found that **87.25%** of legitimate marketing email reached the inbox (so about **1 in 7 never does**), with wide differences between providers: | Provider | Market share | Inbox rate | Spam rate | Missing | |---|---|---|---|---| | Gmail | 42.9% | 89.8% | 6.4% | 3.8% | | Yahoo | 15.7% | 87.3% | 6.4% | 6.3% | | Microsoft | 14.4% | 77.4% | 15.1% | 7.5% | | Apple | 3.6% | 82.0% | 10.8% | 7.2% | For a wider set of dated benchmarks, attributed to their vendors, to judge your own numbers against, see [Deliverability Benchmarks](https://emailmarketing.net/learn/reference/deliverability-benchmarks). It covers Validity's seed-measured placement by provider, country, region and industry, and engagement rates for each industry. ## The monitoring stack A working program for monitoring reputation combines five independent sources of data. No single one is enough. ### 1. Your own engagement and delivery metrics The earliest warning signs are in data you already have. Track these metrics for each mailbox provider, not only in aggregate: - Open rate, click rate and conversion rate. A significant drop at one provider while the others hold steady is the classic sign of placement in that provider's spam folder. - Bounce rate, broken down by category (invalid address, policy block, reputation block, temporary). - Unsubscribe rate and spam complaint rate. - Messages deleted without being read, replies and forwards, where available. Look at **trends from week to week**, not at daily noise. Mailbox providers base their decisions on patterns over time, and daily metrics are too volatile to act on. Spam filters increasingly use machine learning that adjusts in real time, so the goal is to spot a trend before it becomes a problem. ### 2. Blocklist (DNSBL and RBL) monitoring A blocklist, either a DNSBL (DNS-based Block List) or an RBL (Realtime Block List), is a list you can query of IP addresses (and sometimes domains, URLs or usernames) suspected of sending spam. Two facts shape how you should use them: - **Blocklists do not block anything themselves.** Mailbox providers use blocklist data **together with their own internal metrics** to decide what to block. A listing is an input, not a verdict. - **Not all lists carry the same weight.** There are hundreds of DNSBLs, and most have negligible impact. Different providers give weight to different lists, and Gmail largely ignores third-party blocklists in favor of its own systems. These are the lists worth monitoring, roughly in order of impact: | Blocklist | Notes | |---|---| | Spamhaus | The most impactful; used by the majority of ISPs and email service providers | | SpamCop | Based on reports from SpamCop users; moderate impact | | Barracuda Reputation Block List | Widely consulted | | Invaluement | Subscription-based IP and domain anti-spam list | | SORBS | Lower impact; still monitored by some receivers | In practice, reputation blocks show up as **failed or bounced events in your delivery logs**. Read the full SMTP rejection text, which typically names the blocklist. Automated, regular DNSBL lookups on all your sending IP addresses and domains catch listings before recipients' servers do. ### 3. Mailbox-provider dashboards (postmaster tools) The major providers show you directly how the receiving side sees your reputation: - **Google Postmaster Tools**: ratings of domain and IP reputation, spam complaint rate, pass rates for SPF, DKIM and DMARC, and delivery errors for mail to Gmail. - **Microsoft SNDS (Smart Network Data Services)**: data for each IP address on mail to Microsoft's consumer domains, including volume, the filter verdict (green, yellow or red), complaint rate and spam-trap hits. These tools are free. Set them up before problems occur, because they provide history you cannot reconstruct later. ### 4. Seed / inbox-placement testing Seed testing sends a campaign to a panel of test mailboxes at different providers, and reports where each copy landed: the inbox, spam, a specific Gmail tab (Primary, Promotions, Updates, Social or Forums), or missing. Commercial tools (for example, Litmus Spam Testing, Mailgun Inbox Placement, and Validity's Everest) report: - **Inbox Placement Rate (IPR)**: the percentage of successfully delivered emails that reach the inbox rather than spam, broken down by provider. - Scans before sending against major commercial spam filters, plus blocklist and authentication checks (validation of SPF, DKIM and DMARC). - A prediction of the Gmail tab for a given message. Seed tests have limits. Seed panels cannot measure the engagement of real recipients, and seed mailboxes have no engagement history with you, so results lean conservative. Use them to isolate problems with content, templates or infrastructure. Test one variable at a time, since content testing is most useful when it is limited to specific messages. Combine the results with your live engagement data for the full picture. ### 5. Feedback loops (FBLs) Most major mailbox providers offer feedback loops that report which recipients marked your mail as spam. Signing up matters for your overall deliverability. FBL data lets you suppress people who complain immediately (see [suppression handling](#suppression-lists-as-a-reputation-defense)), and it measures negative feedback for each provider. Check whether your sending platform enrolls you automatically or whether you must register yourself. **If you ignore FBL feedback, your reputation drops sharply and your sending is throttled or blocked entirely.** ## Warning signs and thresholds The table below gives the operating thresholds that Klaviyo publishes, which apply whatever platform you use. These are **Klaviyo's house numbers**, deliberately stricter than the consensus across sources. For the range of values with attribution, and the enforcement lines that other providers publish, see the [canonical threshold table](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#canonical-threshold-table): | Metric | Klaviyo target | Signal when breached | |---|---|---| | Open rate | ≥ 33% (raw, including machine opens) | Unengaged list, or placement in the spam folder | | Click rate | ≥ 1% | Weak content or call to action, or a placement problem if opens also fell | | Bounce rate | < 1.0% | List not cleaned; providers read this as poor practice | | Unsubscribe rate | < 0.3% | Expectations not met, or frequency too high | | Spam complaint rate | < 0.01% | The single most damaging signal | On complaints specifically, Klaviyo's **< 0.01%** is a conservative house number. The broader industry consensus target is **< 0.1%** (AWS SES, Postmark, SendGrid), and the **0.3%** ceiling set by Gmail and Yahoo is a hard limit you must never reach. The [canonical threshold table](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#canonical-threshold-table) reconciles all of these. Klaviyo's open-rate target is a **raw** number, which includes machine opens and is inflated by Apple Mail Privacy Protection (MPP). Do not compare it with a rate that filters out bots. Other red flags come before a loss of reputation: - **Volume spikes.** Tripling your usual sending volume can trigger providers' detection of compromised accounts, and sudden increases invite filtering whatever the quality of the content. Keep sending consistent, and ramp up gradually for planned large increases (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)). - **Rising rates of soft bounces or deferrals at one provider.** This is often throttling, the step before blocking. - **Spam-trap hits** (visible in SNDS). They are evidence of poor list acquisition or hygiene, and ISPs flag senders whose traffic hits a higher than normal percentage of traps. - **A decline in the baseline quality of your list.** Marketing databases degrade by about **22% per year** (addresses change, people change jobs, mailboxes are abandoned), so a list that is not actively maintained is always drifting toward trouble. ## Suppression lists as a reputation defense Automatic suppression turns negative signals into protection. These are the standard mechanics, as major sending platforms implement them; replicate them on any infrastructure: - **Hard bounces** (permanent, such as an invalid address): suppress immediately and permanently. - **Soft bounces** (temporary, such as a full mailbox or a server that is down): suppress after repeated consecutive failures (for example, 7 consecutive soft bounces). - **Spam complaints** (from FBLs): suppress immediately, and never mail that person again. A rejection such as "not delivering to a user who marked your messages as spam" is the suppression system working as intended, so do not bypass it. - **Unsubscribes**: suppress from marketing mail immediately. Transactional mail (confirmations of orders, shipping or account changes) is not tied to subscription status and may still be sent to suppressed recipients. Welcome series, abandoned-cart messages and back-in-stock messages, however, are marketing, not transactional. These mechanics fit the removal rule in the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) *Sender Best Common Practices* (Version 4.0, August 2026, section 2.2). M3AAWG considers it a best practice to remove an address that bounces at least twice in a row, across a span of two weeks or more, whatever the failure code or text, and leaves the exact count and time span to each sender. The soft-bounce example above is Klaviyo's platform setting. It is a higher count than M3AAWG's minimum of two, so it follows the rule while waiting longer before removing an address. Count one bounce per campaign rather than one per retry, since M3AAWG's rule is about consecutive campaigns. Two cautions keep the rule from removing good subscribers: - **"Hard bounce" above means a failure about the address**, such as an unknown user. M3AAWG also asks senders to read the bounce text, because the code alone does not say whether to remove the address, and the text can reveal a blocklisting of the sender. A permanent refusal for policy or reputation reasons (a `5.7.x` code) is usually about your sending, not about the recipient. Investigate it instead of suppressing the address. - **Do not count bounces from a period when you were blocked** toward any address's removal count. They say nothing about the addresses. [SMTP Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes#status-codes-and-the-m3aawg-removal-rule) sets out how to apply the M3AAWG rule to each class of code. ## Remediation when reputation drops ### Systematic diagnosis (in order) 1. **Verify infrastructure and authentication.** SPF, DKIM and DMARC should pass and be aligned (see [DMARC](https://emailmarketing.net/learn/authentication/dmarc)). A mismatch between the From domain and the actual sending domain (even `mail.example.com` against `example.com`) is enough for some receivers to send mail to spam or reject it. 2. **Check blocklists** for every sending IP address and domain, and read the rejection texts in your logs. 3. **Check provider dashboards.** Did domain or IP reputation degrade, and when? Match the date against changes to campaigns or lists. 4. **Review changes to segmentation and lists.** A new acquisition source, an imported list, or a campaign to contacts who have lapsed is the most common trigger. 5. **Evaluate content and timing.** Run the failing message through a seed or spam test to separate content problems from reputation problems. 6. **Track complaint trends from week to week** to confirm whether your changes are working. ### Blocklist delisting workflow 1. **Identify the list and the listed asset** (an IP address or a domain) from rejection messages or DNSBL lookups. 2. **Find and fix the root cause first.** Requesting delisting is delicate. If you ask for removal without changing the behavior that caused the listing, your future requests lose credibility, and repeated requests handled badly can lead to a **permanent** listing. Typical causes are a bad acquisition source, spam-trap hits, a compromised account or form, and a spike in complaints. 3. **Follow that list's own removal process.** Each DNSBL handles removal differently, with different timelines. Some let listings expire automatically; others require a request with evidence of remediation. 4. **If you send through a shared provider**, its abuse or compliance team has often already started delisting. Coordinate with it rather than filing duplicate requests. Established relationships with blocklist operators speed up resolution considerably. 5. **After delisting, keep monitoring.** A listing that comes back soon after a delisting is treated more harshly. ### Recovering inbox placement Recovery is slow, and providers do not explain it. They require a **sustained pattern of better signals** before they change placement, and when the damage runs deep, whole subdomains and IP addresses can become effectively unusable. The proven approach is to shrink your sending to your most engaged recipients and rebuild: - Stop sending to anyone outside recently engaged segments. This is a new warm-up, following the same logic as a [warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up). - Suspend high-risk flows during recovery: sends for third parties or affiliates, and win-back, sunset and re-engagement flows. - Fix the root cause you diagnosed (the list source, the content or the authentication). - Expect **8–12 weeks** to fully return to the inbox. This is the recovery timeline Litmus documented for itself after it focused on engaged subscribers. - As a stopgap for critical mail, ask recipients to add your **sending domain** to their safe senders. Asking them to safelist an IP address makes sense only for dedicated IP addresses, because assignments of shared IP addresses are effectively dynamic. ## Related articles - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability), on the signals reputation is computed from - [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability), on why recovery based on engagement works and gaming the system does not - [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability), on the content factors that seed tests reveal - [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation), on containing damage to reputation by isolating mail streams # Reverse DNS in IPv6 (RFC 8501) and Email > Why per-address PTR provisioning breaks at IPv6 scale, the five approaches RFC 8501 enumerates (with trade-offs), and what mail receivers expect from IPv6 reverse DNS. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/ipv6-reverse-dns If you send mail over IPv6, each sending address needs reverse DNS that matches its forward DNS, yet the IPv4 habit of creating a PTR record for every address in advance becomes mathematically impossible. RFC 8501, *Reverse DNS in IPv6 for Internet Service Providers* (November 2018, Informational), analyzes how operators can populate `ip6.arpa` instead. Mail is its headline use case, because SMTP is where missing or mismatched reverse DNS actually blocks traffic. ## Why per-address PTR breaks at IPv6 scale - In IPv4, an Internet service provider (ISP) with a /24 writes 256 PTR records, often generated automatically, and moves on. Forward and reverse DNS match, which satisfies the expectation in RFC 1912 that "every Internet-reachable host should have a name" whose forward and reverse entries agree. - A single IPv6 **/64** (one LAN) contains 2^64 addresses, and a customer **/48** contains 2^80. RFC 8501 does the arithmetic: at 1,000 zone-file entries written per second, populating one /48 "would still not be complete after 38 trillion years." - Hosts also assign their own addresses, through stateless address autoconfiguration (SLAAC) and privacy addresses that rotate. The operator often does not know which addresses are in use, so even selective pre-population cannot keep up with reality. An IPv6 operator must therefore choose a strategy other than static PTR records for every address. For an email service provider (ESP), this is also a question of sending infrastructure. Every IPv6 address you send mail from needs correct, matching reverse DNS (see what receivers expect, below), and the rest of your address space needs a deliberate policy. ## The RFC 8501 option catalog | # | Approach | How | Trade-offs | |---|---|---|---| | 1 | **Negative response (NXDOMAIN)** | Answer authoritatively that no PTR exists | Honest when no name is known, but violates the matching expectation of RFC 1912. SSH and web services may stall while they wait for lookups. **Mail servers may reject the connection outright**, and the RFC notes that this rejection "can help fight spam" | | 2 | **Wildcard match** | A wildcard PTR for each customer prefix (/48, /56, /64) | It scales, but the forward lookup of the wildcard answer cannot return the same name, so forward-confirmed reverse DNS (FCrDNS) fails. Inadequate for mail sources | | 3 | **Dynamic DNS (DDNS)** | Hosts (or the customer gateway, or the ISP using DHCPv6 or RADIUS data) update the PTR and AAAA records as addresses are configured | Produces genuine matching records. But it is not the default on most hosts, there is no standard way to discover the update server, it needs authentication and rate limiting (it is exposed to denial of service), and recovery from an outage causes storms of updates | | 4 | **On-the-fly (synthetic) generation** | Generate the PTR with an algorithm at query time (and synthesize the matching AAAA for the generated name) | Guarantees that forward and reverse match, with no provisioning. The algorithm must be identical on all servers for the zone. It leaves less room for hostnames chosen by users. Signing synthetic answers live with DNSSEC has a performance cost | | 5 | **Delegation to the customer** | Delegate the reverse zone (for example, per /48) to authoritative servers that the customer runs | Correct for enterprises with DNS skills. Impractical for residential users. Conflicts with the security defaults for customer premises equipment (CPE) in RFC 6092 | RFC 8501's conclusion: "When address assignment and name are under the same authority, or when a host has a static address and name, AAAA and PTR records should exist and match." For everything else, such as residential pools, the realistic choices are wildcards, negative responses (where nothing needs a PTR), or on-the-fly generation. ## What mail receivers expect (FCrDNS) - The RFC states it plainly: "most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match". This is **forward-confirmed reverse DNS (FCrDNS)**: the PTR for the connecting address returns a name, and the AAAA (or A) record of that name includes the connecting address. - Only options 3 (DDNS), 4 (on-the-fly) and 5 (delegation) can produce matching pairs. Wildcards and NXDOMAIN cannot. A mail source behind a wildcard or an empty reverse zone will be rejected or heavily penalized. - Gmail is the model of enforcement on IPv6. Sending hosts must have a PTR whose forward lookup confirms the IP, and must also pass authentication, or mail is rejected with IPv6-specific `550 5.7.1` errors (listed in [Gmail SMTP Troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting), with the requirements in [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements)). Receivers generally apply stricter rules on IPv6 than on IPv4, because reputation per IP is diluted across the huge address space. See [IPv6 Sending](https://emailmarketing.net/learn/operations/ipv6-sending) for sending policy as a whole. - PTR names that look generic or synthetic (for example, `2-2-2-2.pool6.example.net`) signal "not a deliberate mail server," so receivers also use the naming of PTR records as a spam heuristic. Guidance from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), cited by NIST SP 800-177 ([summary](https://emailmarketing.net/learn/transport-security/nist-sp-800-177)), says that reverse trees should identify the authoritative mail servers for a domain. ## Security and privacy considerations (RFC 8501 §5) - **Matching records do not mean trust.** An attacker who controls their own reverse zone can easily make forward and reverse DNS agree, and without DNSSEC the answers can be spoofed in transit. Treat FCrDNS as a minimum standard of hygiene, not as authentication. [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) provide authentication. - **DNSSEC interactions:** records that are added dynamically or synthesized complicate signing (the cost of live signing, and key exposure on online signers). Unsigned reverse zones are increasingly read as a signal of reduced trust. - **Privacy:** hostnames that encode a location or a subscriber's identity leak information (RFC 8117). Hostnames supplied by users risk offensive or abusive content. - **Denial-of-service surface:** DDNS update channels need authentication and rate limits, and on-the-fly generators must limit their state and cache size. ## Operational checklist for an ESP running IPv6 mail infrastructure 1. **Every IPv6 address that sends SMTP gets a static, descriptive PTR that passes FCrDNS** (`mtaN.esp.example`, with a matching AAAA record), provisioned like a production asset. Use the "static records" option, never wildcards. 2. Decide the policy for the rest of your allocations, the part that sends no mail. NXDOMAIN is clean and honest. Never let a wildcard cover address space that could originate SMTP. 3. Before the first send, confirm that your upstream provider or local Internet registry (LIR) delegates `ip6.arpa` for your prefix to your name servers (typically on nibble boundaries: /32, /36, ... /48, /56, /64). 4. Sign the reverse zone with DNSSEC if you can. This is consistent with the authentication posture in [NIST SP 800-177](https://emailmarketing.net/learn/transport-security/nist-sp-800-177), and receivers that care about security expect it. 5. Keep PTR names consistent with the forward branding you use in HELO and EHLO. Receivers compare the HELO, PTR and certificate names when they score a connection (see [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)). 6. When you troubleshoot a sudden rejection such as `550 5.7.1` that cites an IPv6 address, check FCrDNS for that specific address first. The classic cause is an app server that started sending mail over IPv6 from rotating privacy addresses. Then check authentication alignment. The broader dual-stack strategy is covered in [IPv6 Sending](https://emailmarketing.net/learn/operations/ipv6-sending). # Sending Email over IPv6 > Why receivers impose stricter rules on IPv6 mail — M3AAWG's 2014 inbound-policy paper (/64 aggregation, reject-without-PTR, reject-without-authentication) and what that means for senders and ESPs today. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/ipv6-sending If you plan to send mail over IPv6, expect receivers to apply stricter rules than on IPv4: a PTR record and passing authentication are effectively mandatory. The basis for those rules is a paper from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), *M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts* (M3AAWG084, **September 2014**). **Note its age.** It is a position and requirements paper from 2014, written as "an initial list of requirements for future services", not an operational guide. Its core predictions have held: major receivers, notably Gmail, do require a valid PTR and passing authentication on IPv6 connections. Treat its specific references to institutions as historical, for example the IETF WEIRDS working group, whose work has since been completed as RDAP. ## The core problem: IP reputation does not scale to IPv6 - IPv4 anti-abuse relies on reputation for each address (/32): rate limiting, blocklisting and reputation assessment. It is less stable and reliable than one would like, but it works, and "most anti-spam systems will be unable to function if the effectiveness of these mechanisms are degraded." - The /128 addresses of IPv6 break this. Tracking every /128 is impractical at scale, and **a sender that can send each individual email from a unique /128 makes mechanisms based on single addresses ineffective**. - IPv6 therefore makes **domain-based reputation** essential (with or without an associated IP), together with better mechanisms for aggregating addresses. M3AAWG set three goals for IPv6 mail: aggregate the address space into assignments that can be tracked; require operators to identify the hosts meant to act as outbound mail transfer agents (MTAs); and require a valid **identifier based on domain authentication** for reputation assessment. ## Recommendation 1: track and act on aggregate assignments, not /128s - IP-based mechanisms (connection rate limiting, blocklisting) must treat a large enough IPv6 range as a single entity to remain effective. A range that is too large causes false positives, because it lumps together the MTAs of unrelated actors. - Ideally, Internet service providers (ISPs) would publish their aggregation sizes through a standard open service that anti-spam mechanisms could query. Without one, conventions on common aggregation boundaries are enough. - **Initial heuristic: use /64 as the minimum default assignment size.** Under RFC 4291, the first 64 bits identify the routing prefix and subnet and the second 64 bits identify the interface, and a single interface is unlikely to contain the MTAs of several actors with significant volume. Operators may act on larger or smaller ranges where appropriate, and anti-spam vendors are expected to collect data on assignment sizes as part of their services. **What this means for senders:** the whole /64 (or larger block) shares the same fate. Reputation damage from one host, or from one customer of an email service provider (ESP), can get the entire aggregate blocklisted. Segment IPv6 sending by allocating a separate /64 to each stream or class of customer, as in [IP allocation practice](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). ## Recommendation 2: reject mail from hosts not identified as outbound MTAs - Botnets send abuse from compromised hosts whose owners never meant them to be MTAs, so accepting mail only from explicitly authorized sources greatly reduces the value of compromised hosts. Managing outbound port 25 (the MAAWG Port 25 recommendation) helps, but it is not implemented everywhere, and the Internet of Things (IoT) will greatly increase the number of vulnerable devices. - No standard existed for operators to declare which hosts are intended outbound MTAs. SPF identifies a domain's authorized outbound MTAs, but "also permits malicious domain owners to identify large ranges of IP space that they do not actually own." M3AAWG called for a standardized method, keyed on IP address, that could be queried automatically. Nothing has been broadly adopted since. - The interim mechanism is **reverse DNS**. Many operators already reject IPv4 connections without PTR records, or treat them as highly suspicious. Under IPv6 this is an even more effective high-pass filter, because operators will not publish PTR records for the vast majority of their IPv6 space (the benefit is small, and it is cumbersome at that scale), while PTR records can feasibly be maintained for the small set of dedicated relay hosts. - **"In the absence of a more appropriate mechanism … M3AAWG recommends rejecting email from host IPv6 addresses without reverse DNS records"**, until a better standard exists (none has replaced it). **What this means for senders:** every IPv6 sending address must have a PTR record and, as receivers generally expect, a matching forward confirmation. A missing PTR on IPv6 is grounds for outright rejection, not only for suspicion. ## Recommendation 3: reject mail without valid domain authentication - The need for stable, accurate reputation identifiers is even greater under IPv6 than under IPv4, and domain names are considerably more stable than IP addresses, even in IPv4. - DKIM and SPF provide the authenticated domain for accountability: the **`d=`** value of DKIM, and the envelope **MAIL FROM** domain of SPF (or the **EHLO or HELO** domain for bounces). Large providers had already deployed domain reputation alongside IP reputation. - **"M3AAWG therefore recommends moving toward rejecting email that does not contain a valid DKIM signature or that does not pass SPF checks"**, which enables consistent, reliable reputation based on the authenticated domain for delivery decisions. **What this means for senders:** on IPv6, unauthenticated mail is not only penalized; the industry position is that it should be rejected. This is exactly what Gmail and other major providers adopted for IPv6 connections (see [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements): delivery over IPv6 requires a PTR record and a pass on SPF or DKIM). Never send over IPv6 from a stream whose SPF and DKIM are not fully in order. When you enable IPv6 on an MTA, verify authentication first, or expect hard bounces that the same stream would not get on IPv4. ## Accountable domains Accurate WHOIS information is "a critical component of a domain's reputation". Complete WHOIS records should be mandatory for domains that act as SMTP clients, with working abuse contacts. (The paper points to the WHOIS replacement from the IETF WEIRDS working group, which was delivered as RDAP.) ## Practical summary for an ESP (the 2014 paper and current practice) | 2014 recommendation | Current operational reality | |---|---| | Aggregate reputation at /64 minimum | Receivers and DNS-based blocklists (DNSBLs) list IPv6 at /64 granularity; plan allocations accordingly | | Reject IPv6 mail without PTR | Enforced by major receivers; a PTR record with forward confirmation is mandatory | | Reject IPv6 mail failing SPF and lacking valid DKIM | Enforced by Gmail on IPv6 since the mid-2010s; assume it applies everywhere | | Domain reputation over IP reputation | The general direction of all modern filtering | IPv6 leaves almost no tolerance for authentication mistakes, and dual-stack delivery makes failures intermittent (mail is sometimes routed over IPv6 and sometimes over IPv4). For these reasons, many ESPs still deliberately prefer IPv4 for outbound marketing mail, or enable IPv6 only on streams whose authentication is proven clean. ## Related articles - [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) - [SPF](https://emailmarketing.net/learn/authentication/spf) - [DKIM](https://emailmarketing.net/learn/authentication/dkim) # Sending Infrastructure Practices > Dedicated vs. shared IPs, subdomain strategy, domain warm-up, From-address hygiene, feedback-loop wiring, reputation monitoring tools, and a troubleshooting framework. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/sending-infrastructure-practices Before you size a fleet of IP addresses, you have to decide whether you need a dedicated IP at all, how to build the reputation of your domains, and how to monitor both. ESP guides from Postmark, AWS SES and Twilio SendGrid agree on most of the answers, collected below. For sizing and segmenting IP fleets, see [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). ## Dedicated vs. shared IPs [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) explains how to size dedicated-IP fleets. The question that comes first is whether to use a dedicated IP at all. | Aspect | Dedicated IP | Shared IP | |---|---|---| | Impact of other senders | None: the reputation is entirely yours | Other senders in the pool can raise or damage your standing | | Volume requirement | High, sustained volume is mandatory | Any volume | | Warm-up | Required, over weeks to months | None; send immediately | | Cost | Premium | Lower | | Reputation management | Yours to manage | Managed by the provider | | Tolerance for errors | Low: every mistake lands on your reputation | Higher: the volume of the pool absorbs errors | ### Dedicated-IP volume floors "How much volume justifies a dedicated IP?" has no single answer, because the published numbers measure **different things**. The floors and vendor minimums below span roughly 5–10x, but they do not contradict each other: they answer different questions. The two floors below are the reference figures; other guidance on dedicated IP addresses refers to them. | Floor | Number | What it measures | |---|---|---| | Floor for isolating transactional mail | ~**1,000 messages/day** | The low-end volume at which isolating transactional mail on its own dedicated IP stays readable to receivers (GreenArrow, [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)). Transactional mail is isolated because it is highly relevant, even below the general statistical floor. | | General statistical floor for each IP | **40,000 messages/week** (~5,700/day) | The minimum sustained volume that any IP needs for mailbox providers to gather statistically significant data on engagement and complaints (GreenArrow, [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation)). Below this, an IP does not send enough for its reputation to stabilize. | **Vendor thresholds for dedicated IP addresses (house rules).** ESPs publish their own minimums. These reflect each vendor's product tiers and support costs as much as receiver statistics. Depending on the vendor's model, they sit above or below the two floors, and they do not contradict each other: | Vendor | Threshold | Framing | |---|---|---| | AWS SES | "a few hundred per day" to allocate the first dedicated IP; below that, customers are steered to shared IPs | The lowest bar. SES automatically moves low-volume dedicated IPs back to the shared pool (see [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)) | | Twilio SendGrid | ~**50,000/month** (~1,650/day) recommended | Below this, a well-managed shared pool is advised | | Mailgun | ≥ **100,000/month** (~3,300/day) recommended | See [Reputation Incident Recovery](https://emailmarketing.net/learn/operations/reputation-incident-recovery) | | Postmark | ~**300,000/month** (~10,000/day) to properly maintain a dedicated IP | The highest bar | In short, a dedicated IP for transactional mail can be justified at ~1,000/day. Any IP that carries a general or bulk stream needs ~40,000/week before receivers can read its reputation statistically. The vendor minimums are commercial house rules on top of both. Postmark adds caveats. A dedicated IP is **not a silver bullet**: for senders below the volume bar it can hurt deliverability, and "a dedicated IP is a way for ESPs to lower their support overhead" as much as it is a delivery feature. Dedicated IPs also demand **consistent, predictable volume**, and sudden spikes are flagged as suspicious. Modern filtering gives **domain reputation** more and more weight compared with IP reputation. ## Domain reputation and subdomain strategy **Domain reputation** is the opinion that receivers (mailbox providers and anti-spam services) hold of your domain. Unlike IP reputation, it is **portable**. It follows the domain across sending systems and providers, so a domain with a history of spam carries that history to any new infrastructure. Poor domain reputation can drag down even transactional mail (Postmark). IP reputation and domain reputation are evaluated separately, but they interact: a poor IP reputation can harm a domain that sends through that IP, even when the domain's own record is good. ### Subdomain separation Both AWS SES and Postmark recommend separating mail streams by **subdomain**. This is the domain-level counterpart of separating IP addresses by reputation, as described in [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation): - Send marketing from a subdomain such as `marketing.example.com` and transactional mail from `orders.example.com`, rather than everything from `example.com` (AWS SES). - Subdomains develop **independent reputations** (for example, `notify.example.com` and `newsletter.example.com`), so a marketing incident, such as a spam-trap hit or a content filter trigger, does not take down transactional delivery. They affect each other only indirectly (Postmark). - Monitor **cousin domains** (for example, `company.com` and `company-mail.com`). Their reputations and any abuse of them can affect how mail from your brand is judged (SendGrid). ### The four domains in every message (Postmark) 1. **DKIM signing domain (`d=`)**: sign with your own domain, not a vendor default, so the reputation builds up for you. 2. **Return-Path domain**: use a custom Return-Path (CNAME) that matches or aligns with your From domain. It is required for SPF alignment under [DMARC](https://emailmarketing.net/learn/authentication/dmarc). 3. **Domain of the From and Reply addresses**: it should clearly identify the brand. Publish a DMARC policy on it. 4. **Domains in the URLs in the content**: third-party links harm delivery only when the linked domains are observed doing something deceptive or malicious. Still, link only to trusted sites you control (SendGrid). ## From-address hygiene (AWS SES) - Some ISPs attach reputation to the **From address** itself, and it is also the recipient's first impression. - Never send bulk mail from an address at a mailbox provider (for example, `sender@hotmail.com`). Large volumes from a consumer mailbox address are treated with suspicion. Send from a domain you own. - **Avoid `no-reply@` addresses** as the From or Reply-To address. They signal that you do not want feedback from recipients, and replies are a positive engagement signal. - Keep the domain's WHOIS record accurate. An honest, current record signals legitimacy. ## Domain warm-up New domains and subdomains need warm-up just as new IP addresses do (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)), and the domain keeps its history for longer. Postmark's schedule gives volumes **for each receiving provider**, for example for each of Gmail, Yahoo and Microsoft: | Period | Daily volume per provider | |---|---| | Days 1–2 | 50–100 | | Days 3–4 | 200 (if metrics healthy) | | Days 5–7 | 400 | | Days 8–10 | 600–800 | | Days 11–14 | 1,000–1,500 | | Days 15–17 | 2,000–3,000 | | Days 18–21 | 4,000–5,000 | | Days 22–25 | 7,500–10,000 | | Days 26–30 | Full intended volume | Pace the growth by roughly doubling volume each day at the start. At substantial volumes, slow to daily increases of 20–50% (30–50% a day in weeks 2–3, then 20–30% a day). Expect an established reputation and dependable delivery at full volume in **3–6 weeks**. No single schedule fits the thresholds of every provider. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) gives a different figure. Its *Sender Best Common Practices* (Version 4.0, August 2026, section 2.5) suggests treating **6 weeks** as an average domain warm-up, which sits at the top of the range above. The two figures answer slightly different questions: the range above is when Postmark expects dependable delivery at full volume, and M3AAWG's figure is a typical length for the whole warm-up. M3AAWG adds these points: - Warm a **new subdomain** too, to be safe, even when the organizational domain already has an established reputation. A domain with no sending history is treated with the same caution as a domain with a bad one. - Spread each day's messages over the day instead of sending the batch at once, and send campaigns on a regular schedule until the domain is warm. - Watch SMTP logs for deferrals and bounces, and slow down if deferrals spike. Watch for spikes in unsubscribes and complaints. A large spike in opens or clicks may mean security appliances are scanning your mail, and a drop may mean it is going to the junk folder. - M3AAWG does not recommend artificial warming, and warns that it may be against the law. During warm-up, start with your best-engaged recipients and widen the audience in tiers (compare the rule of sending to the best-engaged first in [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)): | Days | Audience | |---|---| | 1–4 | Most engaged (previously opened **and** clicked) | | 5–7 | Opened within last 60 days | | 8–10 | Opened within last 90 days | | 11–14 | Engaged within 120 days | | 15+ | Progressively less recent engagement; re-engagement campaigns last | The most important rule: never increase volume before you review the engagement and bounce metrics of the previous send for each provider. If metrics degrade, cut volume by 25–30% until they return to normal. [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) lists the specific triggers for corrective action. It is better to take an extra week or two than to rush and damage long-term deliverability. ## Feedback loops and notification wiring A **feedback loop (FBL)** is a channel through which a mailbox provider reports recipients' spam complaints back to the sender. It has these operational requirements: - Register for the FBLs of the providers you send to (only some offer them). Word to the Wise maintains a reference list of where to sign up for each ISP's FBL (Postmark). ESP platforms typically set these up in advance and forward complaints automatically, as AWS SES does. - Complaint notifications redact the address of the person who complained. Embed traceable X-headers or identifiers in the body so you can map each complaint to an address and a campaign (AWS SES). - The mailbox that receives bounce and complaint notifications must reliably accept mail and must not filter the notifications as spam (AWS SES). See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) for what to do with the data. - **Gmail** provides complaint data through Postmaster Tools rather than through an FBL that reports each message. Tag campaigns with unique **Feedback Loop identifiers** to see complaint rates broken down by campaign or sender, and to isolate problem content quickly (SendGrid). ## Reputation monitoring tools | Tool | What it gives a sender | |---|---| | Google Postmaster Tools | Domain and IP reputation at Gmail, rated **Bad / Low / Medium(Fair) / High** (Bad means mail is almost always rejected or sent to spam; High means it is rarely filtered); a spam rate dashboard (monitor it daily); FBL identifier data | | Microsoft (Outlook.com) postmaster tools and SNDS | Reputation and complaint data for Microsoft properties | | Yahoo postmaster | Delivery and complaint data at Yahoo | | Senderscore.org | Proprietary 0–100 score of overall IP performance | | Cisco Talos Intelligence | Reputation of IP addresses and domains, rated Good / Neutral / Poor, with volume history | | MXToolbox | Blocklist status checks for IP addresses and domains, plus health checks for DNS and domains; SendGrid calls it "the best free lookup option" | Also verify that **reverse DNS (PTR)** records exist and match for every sending IP, which is a bulk-sender requirement at Google and Yahoo (SendGrid). Validate authentication (SPF, DKIM and DMARC) with public checkers. ### Blocklists (denylists) - Providers and anti-spam services list IP addresses and domains that show many spam-trap hits, high complaint volumes, or both (SendGrid). - The impact varies widely. Some lists strongly influence major providers; many are noise. - If you are listed on a major blocklist, **stop sending immediately**, complete the delisting procedure, then resume at significantly reduced volume (Postmark). - Beware of pay-to-play lists that charge for delisting rather than assessing sender behavior (SendGrid). ## Troubleshooting framework (Postmark) When placement or delivery drops, diagnose these five areas in order: 1. **Authentication**: verify SPF, DKIM, alignment of the custom Return-Path, and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) with public validators. 2. **Content**: score the message with a checker based on SpamAssassin, and run seed tests. If a template change preceded the drop, revert the changes one at a time (see the content rules in [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)). 3. **Engagement**: audit bounce, complaint and open rates against the thresholds; suppress hard bounces; avoid `noreply@`. 4. **Reputation**: check domain and IP reputation in the postmaster tools and blocklist lookups above. 5. **Infrastructure**: confirm rDNS (PTR) records, FBL registrations and the health of the IP pool, and check that the sending software signs with DKIM correctly. There is no silver bullet. Deliverability means ongoing monitoring across all five areas, built on clean lists and strong engagement. ## Related articles - [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) and [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation) - [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up), the IP-level counterpart of domain warm-up - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) - [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies), on acting on feedback loop and bounce data # Tracking and Measurement Distortion > How open and click tracking work mechanically, and how Apple MPP, Microsoft Safe Links, gateway scanners, and image proxies distort the resulting metrics — with guidance on which signals remain trustworthy. Source: emailmarketing.net — https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion If your sunset policy, your warm-up segments of "recent openers" or your open-rate benchmarks depend on engagement data, they depend on two tracking mechanisms that privacy features and security scanners now distort systematically. Below is how open and click tracking work, what distorts each one, and which metrics you can still trust. > A note on sources: the three Litmus help center articles cited have moved to a Validity knowledge base (knowledge.validity.com) that only loads with JavaScript and cannot be retrieved as static pages. The content here comes from Wayback Machine snapshots of the original help.litmus.com pages (captured 2024-09-16, 2024-12-11, and 2025-02-13; the pages show "last updated" dates from Aug 2023 – Nov 2024). ## How tracking works ### Open tracking: the 1×1 pixel Open tracking inserts a transparent **1×1 image** (the "tracking pixel") into the HTML body. Its URL is unique to each recipient and points to the tracking domain of the sender or the ESP. When the mail client displays the message and fetches remote images, the request for the pixel reaches the tracking server, which logs an "open" together with the requesting IP address, the user agent and a timestamp. Litmus describes its own analytics in the same way: "Email Analytics uses a 1x1 tracking pixel, similar to how most ESPs provide open rate metrics. Every time this pixel is loaded, we detect an open." Some consequences follow from the design itself, before any privacy feature comes into play: - **If no image loads, no open is recorded.** Clients with images turned off, plain-text display or text-only clients produce false negatives. An "open rate" is really a *pixel-load rate*. - **Every image load records an open.** That includes the sender previewing the campaign in the ESP or in a browser, the message being posted on a website or on social media, and a tracking code reused across templates (all failure modes that Litmus documents). - **Total and unique opens:** raw pixel hits are *total* opens. ESPs remove duplicates to count *unique* opens for each recipient, because they know which subscriber each request belongs to. - ESPs already filter out obvious loads by machines. Litmus notes that some providers "discard any [pixel loads] that appear to be multiples, for example if more than 4 hits are recorded in less than one second… to counteract proxy opens that some inbox providers use to speed email loading." ### Click tracking: wrapped redirect links Click tracking rewrites every `href` in the message so that it points to the redirect (tracking) domain of the sender or the ESP, with an encoded identifier. The redirect server logs the hit and sends an HTTP redirect to the original destination. In Litmus's words, recipients "are redirected to a special web server hosted by your ESP that makes a note of the 'hit' and then sends them on their way." Only the sending platform can do this, because the links must be rewritten when the message is sent. That is why tools that only provide analytics, such as Litmus, do not offer click tracking. The tracking domain has a reputation of its own. URL blocklists and content filters evaluate the redirect domain found in the body, so a shared tracking domain spreads reputation across every sender that uses it (see [Content & Design](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability)). ## Distortion source 1: Apple Mail Privacy Protection (MPP) MPP was introduced with iOS 15 and macOS Monterey (2021). It is available in Apple Mail on iOS, iPadOS, visionOS and macOS, and on iCloud.com. It applies to **any mailbox read in Apple Mail**, not only to @icloud.com addresses. ### What Apple's own documentation says it does From Apple's legal and privacy page: - Remote content is downloaded "**in the background by default — regardless of whether you engage with the email**." The pixel is fetched in advance when the message arrives, not when a person views it. - Downloads pass through **two separate relays**: "The first knows your IP address, but not any third-party Mail content you receive. The second knows the remote Mail content you receive, but not your IP address." The sender therefore sees the IP address of an Apple proxy, not the recipient's. - Its stated purpose is to prevent senders from learning "when and how many times you opened their email, whether you forwarded the email, your Internet Protocol (IP) address, and other data." From the macOS Mail support guide (Mail > Settings > Privacy): - With **Protect Mail Activity** turned on, "your IP address is hidden from senders and remote content is privately downloaded in the background **when you receive a message (instead of when you view it)**." - With it turned off, two independent options appear: **Hide IP Address** (the IP address is hidden, but content is not fetched in advance) and **Block All Remote Content** (nothing remote loads at all; the user sees a banner and can load the content manually). - According to the legal page, Hide IP Address "will still mask your IP address" even when MPP itself is turned off. The feature is offered when Mail is first opened and stays on unless the user turns it off. In practice, almost all Apple Mail users have it on. The settings are in Settings > Apps > Mail > Privacy Protection on iOS, iPadOS and visionOS, in Mail > Settings > Privacy on the Mac, and in Settings > Privacy & Security on iCloud.com. ### What this does to sender data | Signal | Effect under MPP | |---|---| | Open event | Recorded for ~every message delivered to an Apple Mail user, whether engaged or not: **false positives at scale** | | Open timestamp | Reflects Apple's schedule for fetching content in advance, not when the message was read. Useless for optimizing send times for these recipients | | Open count and repeat opens | Suppressed. Several views by a person cannot be told apart | | Recipient IP address | Replaced by the outgoing IP address of an Apple relay. Geolocation points to Apple's infrastructure, at best roughly to a region | | Device and client fingerprint | Hidden. The proxy's request does not reveal the real client | | Live content (countdown timers, images targeted by location) | Rendered at the time and place of the advance fetch, not when the message is viewed | Operators should know one caveat: the advance fetch is not guaranteed for every message, because devices must be on power or connected to a network for background activity. MPP opens are therefore close to, but not exactly, 100% of the volume delivered to these recipients. You can identify MPP opens in event data by the **Apple proxy user agent and Apple's IP address ranges** on the pixel requests. MPP does **not** affect clicks. A click still comes from a real action by the user. The IP address of the following visit to the landing page may be hidden by iCloud Private Relay for Safari users, but the click event itself is genuine. ## Distortion source 2: Microsoft Safe Links (clicks) Safe Links is the URL protection in Microsoft Defender for Office 365. It matters to senders because it both **rewrites their links** and **fetches them without any person clicking**. How it works, according to Microsoft's documentation of Safe Links policies: - **Coverage is on by default.** There is no default Safe Links policy object, but the **Built-in protection** preset security policy "provides Safe Links protection to all recipients by default" in any organization licensed for Defender for Office 365 (Plan 1/2, included in Microsoft 365 E5 and various business plans). The Standard and Strict presets and custom policies apply on top of it. Policy changes take up to 6 hours to apply. - **URL rewriting:** the default email setting is "Safe Links checks a list of known, malicious links when users click links in email. **URLs are rewritten by default**". Links in the delivered message point to `*.safelinks.protection.outlook.com`, with the original URL encoded as a parameter, which allows **verification at the time of the click**. Every click passes through Microsoft before it reaches the sender's tracking redirect. - **Real-time scanning and detonation:** the option "Apply real-time URL scanning for suspicious links and links that point to files" (`ScanUrls`) scans the linked content, and "Wait for URL scanning to complete before delivering the message" (`DeliverMessageAfterScan`, recommended On) holds delivery until the scans finish. These scans **fetch the sender's URLs from Microsoft's infrastructure**. Each fetch of a wrapped tracking link registers at the ESP as a "click" that no person made, typically seconds after delivery. - **API-only mode:** "Do not rewrite URLs, do checks via SafeLinks API only" leaves the URLs in the body unchanged, and supported Outlook clients call Safe Links when the user clicks. In this mode the sender's links do not look rewritten, but checks at the time of the click still happen. - **Lists of URLs not to rewrite:** administrators can exempt URLs (`DoNotRewriteUrls`) from being wrapped as mail flows through. Microsoft notes that exempted URLs "might still be blocked at time of click" unless they are also allowed in the Tenant Allow/Block List. - **Click telemetry:** "Track user clicks" (`TrackUserClicks`) is on by default. Warning pages for blocked URLs can prevent the user from continuing to the link at all (`AllowClickThrough $false`). A genuine click on a tracking domain that was flagged by mistake then never reaches the sender. This path produces **false negatives** for clicks, alongside the false positives from detonation. Senders see these effects most on B2B lists (Microsoft 365 tenants). Corporate recipients under the Strict preset policy produce the most aggressive fetching of links before delivery. ## Distortion source 3: other gateway and security scanners Other products follow the Safe Links pattern. Secure email gateways (Proofpoint, Mimecast, Barracuda, Cisco IronPort, advanced protection in Google Workspace, and many antivirus products) commonly: - **Fetch every link** in a message at delivery or shortly after, to check the destinations ("link detonation" or sandboxing). That includes the unsubscribe link. This is why one-click unsubscribe under RFC 8058 uses POST rather than GET (see [List-Unsubscribe](https://emailmarketing.net/learn/list-management/list-unsubscribe)): scanners send GET requests, so an unsubscribe that acts on a GET gets triggered by robots. - **Rewrite links** through their own redirectors (e.g., `urldefense.com`, Mimecast link protection), which adds a second redirect in front of the ESP's tracking redirect. - **Fetch the tracking pixel** while scanning content, which produces "opens" by scanners from data center IP addresses. Patterns of behavior that tell scanner clicks from human clicks: | Heuristic | Pattern of a scanner or bot | Pattern of a person | |---|---|---| | Time after delivery | Seconds to ~2 minutes after the SMTP server accepted the message, often before any open | Minutes to days later, usually after an open | | Coverage | Every link in the message, or nearly every one, is clicked, including unsubscribe and footer links | One content link, or a few | | Order | Links are hit in the order they appear in the HTML, almost at the same moment | Irregular, and usually a single click | | Source IP address | A data center or the network (ASN) of a security vendor (Microsoft, Proofpoint or Barracuda ranges), often one IP address clicking for many recipients | The recipient's residential or mobile ISP, or the outgoing address of their company | | User agent | Headless or generic agents, or agents that do not match the client that opened the message | Consistent browser and device agents | | Behavior after the click | No session on the landing page, and no further page views | A normal web session | To filter out bot clicks in practice, score each event against several of these heuristics rather than any single one. Some scanners click only a random selection of links, and some corporate outgoing IP addresses serve both scanners and people. Never trigger an action that cannot be undone, such as an unsubscribe, a change of preferences or a one-click purchase, on a bare GET request. ## Distortion source 4: image proxies at Gmail (and at Yahoo and AOL) Gmail rewrites all image URLs through its **image proxy** (`googleusercontent.com`). The recipient's client fetches images from Google's cache, and Google's proxy fetches them from the sender's server. The effects, confirmed by Litmus's page on the limitations of its analytics: - **The IP address and geolocation are hidden.** Pixel requests come from the IP addresses of Google's proxy, and device details are reduced to the proxy's user-agent string. - **Caching suppresses repeat opens.** Once an image is cached, later views may be served without fetching it again from the sender, so repeat opens are undercounted. Litmus reports these as "image cache opens" and **excludes them from its reports of engagement (reading time)**, because "engagement is also masked by the providers' processes." - Yahoo and AOL run an equivalent proxy and cache. Litmus notes that since **August 2018** "both Yahoo! Mail and AOL are processed by the same backend servers", and that the two cannot be told apart ("Yahoo/AOL Mail via Yahoo/AOL's Image Cache"). - Unlike Apple MPP, the Gmail proxy has historically fetched images **when the message is viewed**, so an open through the Gmail proxy still indicates that a person opened the message. It distorts who opened it, where and on what device, but not whether it was opened. (Gmail has at times fetched images in advance for some messages, so treat Gmail opens as mostly human but not guaranteed.) ## What analytics vendors themselves admit (Litmus) Litmus documents the limits of its own Email Analytics. That documentation is a useful, honest baseline for what analytics based on pixels can and cannot claim: - It cannot track recipients with **images turned off** or text-only clients. Its analytics are "a way to break down your open rate", in other words a view of the recipients who opened, and only of them. - **No reliable data on forwarding or printing** remains for any inbox provider (Litmus dropped it for reasons of privacy and accuracy). - **Apple MPP** and provider image caches get their own caveats. The opens they affect are separated out or excluded from engagement reports. - Webmail (Gmail, Outlook.com, Yahoo, AOL) loads content asynchronously and keeps fetching after the reader has moved on, so **tracking of reading time and engagement is excluded** for all webmail. Clients that cannot be tracked export a reading time of **-1**. - Identification of the client is coarse. All modern Windows versions of Outlook (2016+) "return the same identifiers". Outlook for Mac renders with WebKit and is reported as Apple Mail. Lotus Notes cannot be tracked. - Pixel hits from ESP previews, from campaign pages that have been shared or posted, and from reused tracking codes all count as opens unless they are removed before sending. If a specialist analytics vendor documents this much noise, an ESP's raw open metric carries at least as much, plus the inflation from MPP's advance fetching. ## Operational consequences ### Which metrics you can still trust | Metric | Trust level | Notes | |---|---|---| | Delivery and bounce rates | High | Measured at the SMTP level, and unaffected by distortions in tracking | | Spam complaint rate | High | Based on feedback loops (FBLs), and a genuine negative signal from people | | Unsubscribe (one-click, by POST) | High | A POST under RFC 8058 resists GET requests from scanners | | Conversions and activity on your site | High | They require a real session. This is the strongest positive signal | | Clicks (bots filtered out) | Medium-high | Genuine once scanner patterns (above) are filtered out | | Clicks (raw) | Medium | Inflated by detonation in Safe Links and gateways, especially on B2B lists | | Opens, overall trend | Medium-low | Still usable to compare campaigns within a stable mix of audiences (MPP inflation is roughly constant from one campaign to the next) | | Opens, for an individual recipient | Low | An "open" from an Apple Mail user proves delivery, not attention | | Open timestamps, location, device | Low | Proxied or fetched in advance for recipients at Apple, Gmail, Yahoo and AOL | The overall open rate keeps one legitimate use: a sudden drop still signals a delivery problem. Even opens from advance fetching require the message to reach the mailbox, so for recipients at Apple, MPP opens act in effect as a measure of inbox placement. ### Adjusting sunset policies for opens inflated by MPP The classic rule, "suppress after N months without an open", now fails in both directions. MPP users look engaged forever, so they are never sunset and the list decays. Users with images turned off look dormant forever, so engaged readers get removed. Redesign the policy as follows (this extends [List Hygiene & Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies)): 1. **Group recipients by how far their opens can be trusted**, using the user agent and IP address of pixel requests: opens through the MPP proxy, opens from provider caches, and direct opens. 2. For recipients affected by MPP, define inactivity by **clicks, conversions, site logins and purchases**, never by opens. Lengthen the lookback period to match, since clicks are rarer than opens. A 90-day rule based on opens might become a 180–365-day rule based on clicks and conversions. 3. For recipients whose direct opens can be trusted, opens may still count, with less weight than clicks. 4. Keep the check against activity outside email (visits to the website, purchases). It is now the main signal, not a fallback. 5. Do not let bot clicks trigger re-engagement, so that a detonation by Safe Links does not "rescue" a dead address. In the same way, never count a scanner's GET on the confirmation link of a win-back campaign as consent. The same correction applies to warm-up segments. The "most engaged" segments built for [IP warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up) should be ranked by how recently recipients clicked or converted, not by opens, or they will be filled with unengaged Apple users. ### Optimizing send times and content - Models that optimize send times and are trained on open timestamps are polluted by the schedules of advance fetching. Train them on click timestamps only. - Live or dynamic content (countdown timers, images personalized by location) is rendered when Apple fetches it in advance or when Google's proxy fetches it. Design the content so that the version rendered at the time of the advance fetch is still acceptable. - A/B tests judged on opens mostly measure noise for recipients at Apple. Judge subject-line tests on clicks and conversions, or limit the reading of opens to opens that did not pass through a proxy. ## Related articles - [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), with the thresholds that these caveats qualify - [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) - [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe), including why one-click unsubscribe uses POST - [Content & Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability), including the reputation of tracking domains - [Seven-Step Delivery Model](https://emailmarketing.net/learn/foundations/seven-step-delivery-model) # Google Postmaster Tools > What Google Postmaster Tools provides — enrollment, every dashboard (compliance, spam rate, reputation, feedback loop, authentication, encryption, delivery errors) and how to interpret each. Source: emailmarketing.net — https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools If you send to Gmail users, Google Postmaster Tools shows you how Gmail sees your mail. It is Google's free monitoring console for senders, at https://postmaster.google.com/ (you need to sign in with a Google account). Once you verify that you own a domain, you get dashboards on spam rate, IP and domain reputation, authentication success, encryption, delivery errors, feedback loop data, and compliance with the [Gmail sender requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements). **All data covers mail to personal Gmail accounts only** (`@gmail.com` and `@googlemail.com`), not recipients on Google Workspace. ## Enrollment Prerequisites: a Google or Google Workspace account. The domain you add must be the **DKIM `d=` domain or the SPF (Return-Path) domain** that authenticates your mail. 1. **Add the domain**: sign in at postmaster.google.com, click Add, and enter the authentication domain. 2. **Verify ownership**: copy the TXT record you are given into the domain's DNS, then click Verify. Verification is usually instant, and takes up to ~10 minutes. Dashboards show no data until the domain is verified. 3. **Grant access (optional)**: go to Manage Domains > More > Manage > Add a Google email address. You can share read access, but the person you grant it to is not notified automatically. Common issues: verification fails because of DNS propagation delay or a mistyped record (retry, or generate a new string); the person you grant access to must have a Google account; and missing dashboard data usually means your volume is too low to pass the privacy threshold. ## Data characteristics - The data is updated **daily**, typically within 24 hours. Compliance status can take up to **7 days** to reflect changes. - Timestamps are in **UTC**. - You can select ranges of **7, 30, 60, 90, or 120 days**. - Days with **low volume are left out** to protect user privacy, so a gap does not mean zero. - Google tries to **exclude forwarded messages** from the data, but some may still appear in the dashboards. - Unauthenticated mail is largely invisible: most dashboards cover only mail that passed SPF or DKIM for the verified domain. ## Dashboards ### Compliance status This dashboard checks each requirement of the Email Sender Guidelines and rates it **Compliant**, **Needs work**, or **No data found** (not enough volume). - For all senders, it checks SPF and DKIM authentication, DNS (PTR) records, message formatting, TLS encryption and the user-reported spam rate. - For bulk senders (~5,000+/day), it also checks DMARC, support for one-click unsubscribe, and whether unsubscribes are honored. Compliance is displayed for the **primary domain**, but traffic from both the primary domain and its subdomains feeds the calculation. Allow up to 7 days after a fix for the status to change. ### Spam rate This is the percentage of your delivered mail that Gmail users **mark as spam themselves**, for each day. Stay **below 0.10%**, and never reach **0.30%** ([threshold details](https://emailmarketing.net/learn/providers/gmail-sender-requirements)). One caveat is critical for reading this number: the denominator is mail delivered to the inbox. As Google puts it, "if Gmail automatically sends a significant number of your messages to spam, the rate shown in the dashboard might seem low." You can therefore have a low spam rate and poor inbox placement at the same time, so read this dashboard together with reputation. ### IP reputation and Domain reputation Both dashboards use the same scale of four tiers: | Tier | Meaning | |---|---| | **High** | Very low spam rate; complies with Gmail's sender guidelines; mail rarely filtered | | **Medium** | Known to send legitimate mail with occasional low-volume spam; fair deliverability | | **Low** | Significant history of sending spam; mail likely marked as spam | | **Bad** | High spam volume; mail nearly always marked as spam or rejected at SMTP time | Domain reputation covers only messages authenticated with the **exact DKIM or SPF domain you verified**. Recovering reputation takes time and sustained sending that follows the rules; there are no shortcuts. The two dashboards separate problems with infrastructure (IP) from problems with the brand or content (domain). See [advanced IP segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation) for how to use this separation deliberately. ### Feedback loop (FBL) Gmail's FBL is **aggregate, not per message**: it does not return individual complaint reports. Instead, senders add a `Feedback-ID:` header, and Postmaster Tools reports the **average spam rate for each identifier, each day**, plus the volume of unique identifiers flagged. Header format: ``` Feedback-ID: a:b:c:SenderId ``` - `SenderId` (the rightmost field) is **mandatory**, 5–15 characters, and unique and consistent for each sender. - `a`, `b` and `c` are up to three optional custom fields (for example, campaign, customer or mail stream). Data is aggregated for the first 4 fields separated by colons, counted from the right. - Do not reuse the same identifier value in different fields, because the aggregates would mix. Do not use values unique to each message, such as a Message-ID, because each identifier needs enough daily volume and enough distinct spam reports to produce data. To get FBL data, your traffic must be DKIM-signed by a domain you control, that domain must be verified in Postmaster Tools, and your sending IP addresses must be in the SPF record with valid PTR records. The dashboard can show data by `From:` header domain, or by all DKIM signing domains. FBL data covers @gmail.com recipients only. The main use is to pinpoint which campaign, customer or stream drives complaints. This matters especially for ESPs whose customers share domains. ### Authentication This dashboard shows, for each day, the percentage of attempted mail that passed **SPF**, **DKIM** and **DMARC**. Correctly configured senders typically reach **≥95%** success for DKIM and DMARC. SPF rates are naturally lower, because delivery through third parties and forwarding breaks SPF, which checks the path (see [DMARC](https://emailmarketing.net/learn/authentication/dmarc)). Domains that do not send mail show no results. To debug a low rate: - For DKIM, check the formatting of the TXT record, that the key is correct, and the DNS TTL and expiration. - For SPF, check the record syntax, and that every authorized sending IP address or service is listed. - For DMARC, make sure SPF or DKIM passes first, and consider relaxed alignment. ### Encryption This dashboard shows the percentage of traffic sent over **inbound TLS** (your mail arriving at Gmail over TLS) and **outbound TLS**. TLS is a hard requirement of the sender guidelines, so this should be at or near 100%. ### Delivery errors This dashboard shows the percentage of **authenticated** mail that was rejected or failed temporarily, compared with all authenticated mail, broken down by the reason for the error: | Error reason | Typical cause | Action | |---|---|---| | Rate limit exceeded | Suspiciously high sending rate | Pause, then resume slowly ([warm up](https://emailmarketing.net/learn/ip-management/ip-warm-up) again) | | Suspected spam | Message classified as likely spam | Usually low reputation; if it persists on compliant mail, escalate through the bulk sender form | | Email content is possibly spammy | Content flagged | Review the content; use the escalation form if needed | | Bad or unsupported attachment | Blocked file type | Send only attachment types that Gmail supports | | DMARC policy of the sender domain | Your own DMARC policy (`p=reject` or `quarantine`) is rejecting your mail | Check the DMARC aggregate reports; consider `p=none` while you fix alignment | | Low IP reputation, or low domain reputation | Poor reputation tier | Fix the root cause and rebuild reputation | | IP in one or more public RBLs, or domain in RBLs | Listing on a public blocklist | Request delisting from the blocklist operator | | PTR record missing | No reverse DNS | Add a PTR record (verify it with the Dig tool in Google Admin Toolbox) | Temporary failures are throttling. Google's advice is to "completely stop sending for a short period of time, then resume sending at a slower rate." [Gmail troubleshooting](https://emailmarketing.net/learn/providers/gmail-troubleshooting) lists the specific SMTP codes. ## Fit in a deliverability workflow 1. **Enroll every authentication domain** (the DKIM d= domains and the SPF Return-Path domains) before problems occur, because there is no data for the period before you enroll. 2. **Every day**: watch the spam rate against 0.10% and 0.30%, and both reputation tiers. 3. **For each campaign**: use `Feedback-ID` and the FBL to attribute complaints to streams, customers or campaigns. 4. **When delivery incidents happen**: match the reasons in Delivery Errors against your SMTP logs, and check the Authentication and Encryption dashboards for regressions. 5. **For compliance**: check every item in Compliance Status. Only compliant senders with a spam rate <0.3% over 7 consecutive days qualify for mitigation from Google. Google's recommendations on list hygiene that go with these tools: send only to recipients who opted in, confirm addresses at signup (confirmed opt-in), ask periodically whether people are still interested, stop mailing people who do not engage, and make unsubscribing very easy. Yahoo offers similar facilities. See [Yahoo complaint feedback loop](https://emailmarketing.net/learn/providers/yahoo-complaint-feedback-loop) and [Yahoo performance feeds](https://emailmarketing.net/learn/providers/yahoo-performance-feeds). # Microsoft SNDS & JMRP > Smart Network Data Services (per-IP reputation data for Outlook.com: filter results, complaint rates, trap hits) and the Junk Email Reporting Program feedback loop — data provided, thresholds, and enrollment. Source: emailmarketing.net — https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp Microsoft's two free programs for senders to Outlook.com (outlook.com, hotmail.com, live.com, msn.com): - **SNDS (Smart Network Data Services)** — a dashboard of per-IP sending data: "Deliverability to Outlook.com is based on your reputation. The Outlook.com Smart Network Data Services (SNDS) gives you the data you need to understand and improve your reputation at Outlook.com." It also helps IP owners detect compromised servers, malware, viruses, and botnets on their networks. - **JMRP (Junk Email Reporting Program)** — Microsoft's feedback loop: reports on junk email issues reported by Outlook.com users, returning the full message of any email a recipient marked as junk or phishing. These are the Microsoft counterparts to Google Postmaster Tools and Yahoo's Complaint Feedback Loop. They report on mail to **consumer Outlook.com mailboxes**, not Microsoft 365/Exchange Online tenants. ## Portal migration (2026) SNDS moved from the legacy `sendersupport.olc.protection.outlook.com` domain to a new portal at `https://substrate.office.com/ip-domain-management-snds/` (short link `https://aka.ms/snds`). Automated-access consumers had to update URLs off the legacy domain before its **June 22, 2026** deprecation. As of **July 22, 2026**, **trap hit counts are no longer shown** in SNDS data, to protect the integrity of Microsoft's anti-abuse systems. ## SNDS: data provided Data is aggregated per IP, per day. Around **midnight PST** a process aggregates the previous day's data (it can take a couple of hours to complete). Data is retained and viewable for **90 days**. | Field | Meaning | |---|---| | Activity period | First and last hour of the PST day during which activity was seen from the IP | | RCPT commands | Count of `RCPT TO` commands issued. Benchmark: more than a third of IPs sending to Outlook.com keep the fraction of RCPT commands that don't result in message recipients **under 10%** — a high failure fraction indicates list-quality problems or namespace mining | | DATA commands | Count of actual message transmissions | | Message recipients | Final count of intended recipients. Well-behaved senders show only minor discrepancy vs. RCPT count | | Filter result | Color-coded spam-filter verdict for the IP's mail that day (see below) | | Complaint rate | Complaints ÷ message recipients. Benchmark: more than 30% of IPs sending to Outlook.com keep complaint rate **below 0.3%** | | Trap hits | Messages sent to nonexistent trap accounts maintained by Outlook.com. Legitimate senders hit them rarely; spammers cannot easily avoid them. **Removed from reports as of July 22, 2026** | | Sample HELO / MAIL FROM | Actual examples of the SMTP identity commands seen from the IP — useful for spotting traffic that isn't yours (compromise, spoofed infrastructure) | ### Filter-result thresholds | Color | Meaning | |---|---| | Green | Spam < 10% of the IP's mail | | Yellow | 10% ≤ spam ≤ 90% | | Red | Spam > 90% | ### How to read SNDS in a deliverability workflow - **Red/yellow filter results** with normal volume → content or reputation problem; check authentication and complaint drivers. - **Complaint rate ≥ 0.3%** → above the practical safe line (the same figure Yahoo and Gmail publish as a hard threshold); tighten list hygiene and consent. - **Unexpected volume, HELO values, or trap hits** → likely compromised host or unauthorized use of your IP space. - No data for an IP usually means it sent too little mail to Outlook.com that day to be reported. ## SNDS: enrollment and access 1. Sign in to SNDS with a **Microsoft Account**. 2. **Request access** to the IPs (or CIDR range / ASN) you are responsible for. 3. SNDS determines authorized contacts via **reverse DNS and WHOIS lookups** on the range and offers the associated email addresses; ranges up to a **/23** can be authorized via reverse DNS when the range has consistent domain patterns. 4. Click the link in the verification email sent to the chosen address to confirm authorization. **Automated access**: SNDS provides a simple data-access URL (keyed, no interactive login) intended for automated systems to pull the daily data — suitable for feeding monitoring/alerting. ## JMRP: the Outlook.com feedback loop - Free service providing "reports on junk email issues reported by Outlook.com users." - Returns the **full message with headers** of any email a recipient marked as **junk or phishing**. - Purpose: identify recipients who no longer want your mail (remove them immediately) and spot content/segments driving complaints. - Enrollment: through the SNDS portal at `https://substrate.office.com/ip-domain-management-snds/snds/jmrp` (requires the same Microsoft Account sign-in and IP authorization as SNDS). - Feedback typically starts arriving **within as little as 72 hours** of enrollment. - Enrolling in JMRP is Microsoft's documented remediation step for the `550 SC-004` block (IP blocked due to complaints) — see [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements). Unlike ARF-based feedback loops at some providers, JMRP reports are keyed to **sending IP**, so the mail must come from IP space you have authorized in SNDS. Process every JMRP report as an unsubscribe: continuing to mail a complainer directly raises the SNDS complaint rate and the odds of an SC-004 block. ## Related - [Microsoft Sender Requirements](https://emailmarketing.net/learn/providers/microsoft-sender-requirements) — policies, the 2025 authentication mandate, and SMTP error codes - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) — complaint and trap signals in reputation systems - [IP Warm-Up Recommendations](https://emailmarketing.net/learn/ip-management/ip-warm-up) — use SNDS to watch new IPs during warm-up # Brand Protection — Domain Management > Securing a domain portfolio against hijacking, lookalike/cousin-domain abuse, and spoofing — inventory, registrar/registry locks, defensive registration, monitoring, takedown paths, and the protective DNS records for non-sending and parked domains. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/brand-protection-domain-management Your domains can be attacked even if nobody breaks into them. Attackers who cannot take control of a brand's real domains do the next best thing: they register a variant of them, or spoof mail from them. Protecting a brand's domains works in three layers: **minimum security requirements** that every organization should meet, **increased measures** as the brand matures, and **mitigations for specific attacks**. The authentication mechanics are covered in [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc). The practices below concern managing the domain portfolio around them. ## Minimum security requirements | Requirement | Practice | |---|---| | **Domain inventory** | Record every domain the company owns. A spreadsheet is enough, but a dedicated tool is better, because it can also manage certificates and nameservers. For each domain, write down its purpose and name the people responsible for its security and maintenance. Keep the inventory current as domains and staff are added, removed or changed. Track how each domain is hosted and configured in DNS, and make sure any outsourced provider works with your DNS infrastructure provider. | | **Protect registrant accounts** | Make protecting domain names a permanent part of security policy. Keep the credentials of registrant accounts private, and allow recovery only by the most senior domain administrators, in extreme circumstances. When staff change, change the credentials of the corresponding accounts, especially passwords. Never use a transfer contact's email address as the login for self-service domain administration pages: hijackers look up transfer contacts in WHOIS and routinely test whether that address is also the username. Use role addresses, not personal addresses, for contacts. **Multi-factor authentication (MFA) on every domain account.** | | **Current contact info** | Any change to the company name, legal address, phone number or email address must trigger an update with every registrar. Registrars are a key defense against hijacking attempts, and current details put them in the best position to protect you. | | **Official policies** | Write down decisions and processes, especially for retiring or reconfiguring domains, for change control, and for which departments have authority to make changes. | | **Document everything** | Policies, registers and regular communication with staff keep the business ready for incidents, and able to accept legitimate changes quickly. | ## Increased security measures ("quick wins") - **Role aliases for domain control and notifications**: send notifications from registrars and DNS providers to a role account (`domainregistrar@example.com`), not to one person's mailbox, so that they still arrive when staff leave, go on vacation or take leave. - **Choose the DNS authority deliberately.** Local open-source authoritative servers, an on-premises appliance and a cloud authoritative DNS service each have different strengths in their support for DNSSEC, email authentication and security. Audit the resulting configuration with free tools (e.g., Zonemaster, https://zonemaster.iis.se/en/). - **Choose the right registrar.** Registrars specialize: some serve budget buyers and hobbyists, some bulk speculators, some particular languages. Register production and core domains with a **corporate registrar** that specializes in protecting critical assets. A retail registrar may be fine for defensive registrations. The minimum features to require are redundant infrastructure, protection against accidental expiry, domain monitoring (is the domain up and responding?), two-factor authentication (2FA) on the management console, a **registrar lock** service (the combination of `clientTransferProhibited`, `clientUpdateProhibited` and `clientDeleteProhibited`, which prevents unauthorized deletion, transfer or modification), and DNSSEC support. - **Defensive registration.** Register other top-level domain (TLD) variants of the brand in advance (`brand.co.uk` when you are `brand.com`). Create a policy for high-risk domains that will never be used in production: look-alike names, typos, common abbreviations and short forms (e.g., "BofA" for "Bank of America"), combined with commonly abused words such as "login" or "account", and any variant you have already had to fight. You cannot register an unlimited number, so set priorities and a budget, review them in the light of experience, and coordinate with your monitoring and takedown programs. **Whatever your risk tolerance and budget do not let you buy, monitor.** - **Manage SSL and TLS certificates together with DNS.** The same team faces similar legal and technical challenges for both. Monitor certificate transparency logs for **look-alike certificate registrations**, not only for look-alike domains. Publish **CAA records** to prevent unauthorized certificates from being issued for your domains. - **EPP status codes and locks.** Set `clientTransferProhibited`, `clientDeleteProhibited` and `clientUpdateProhibited` on organizational domains. Beyond that, consider a **registry lock** (protection against unauthorized change or deletion, confirmed through a separate channel and arranged through the registrar), and above that, **registrar lock** services that require confirmation through a separate channel before any change. After locking, check WHOIS regularly to confirm that the domain is still locked, and that its nameservers, DNS configuration and contacts have not been changed without your knowledge. Consider a third-party service that alerts you to changes. - **Back up the DNS configuration.** Storing the DNS configuration securely means you can always restore it, for example after an account is compromised. Include urgent restoration of domains and DNS in business-continuity planning and tabletop exercises, check whether your insurance covers domain and DNS incidents, and include domain hijacking in incident response. - **Monitor for abusive third-party domains.** Commercial services do this reliably. Not doing it exposes the brand to significant abuse. ## Attack vectors and mitigation ### Squatters, lookalike domains (homographs), and encroachments Monitor newly registered domains for look-alike names. Many brands outsource this to a managed service. The data sources are: - **ICANN CZDS** (Centralized Zone Data Service): zone files for all generic top-level domains (gTLDs), but **not for country-code top-level domains (ccTLDs)**. Add ccTLD zone files according to the threats you face. - **SSL certificate registrations** (certificate transparency logs). - **Paid feeds of newly registered or newly observed domains.** Each look-alike domain you discover must be classified as benign or malicious. The kit defines a **malicious domain** as one used for malware distribution, botnet command and control, phishing, business email compromise or spam. A trademark registration made in bad faith, but not also used for those activities, offends the brand without being malicious. The distinction decides which remediation path works. | Class | Path | Notes | |---|---|---| | **Malicious** (proof of phishing, credential theft, malware, botnet C2, spam) | **Send a takedown request to the domain's registrar** (found through WHOIS). Provide detailed evidence: screenshots of the offending content, and a sample lure email with full headers. If the hosting company is a separate entity, contacting it may remove the content faster. If the registrar does not respond, escalate to ICANN, which accredits registrars. | Registrars accredited by ICANN normally treat a domain as malicious only if it was **registered and used** for phishing, malware or botnet C2. **Compromised domains (legitimate but hacked) are a different problem, and suspension is usually the wrong remedy.** After a takedown, monitor for renewed activity. Alternatively, buy the domain (some registrars will transfer it to the brand), which is useful for alerting victims and gathering statistics. | | **Brand-offensive** (trademark infringement, not malicious) | The same takedown path works only if phishing, malware or C2 is also involved (for gTLDs; processes for ccTLDs depend on the terms of service of each ccTLD). Otherwise, appeal informally to the owner (identified through the hosted content or WHOIS), unless the registrant appears malicious. Then use formal **UDRP** or **URS** proceedings, or civil litigation. UDRP and URS proceedings cost money and take a few months, but success can transfer control of the domain to the brand. | Pure trademark disputes are legal matters. Involve trademark counsel, and see [compliance](https://emailmarketing.net/learn/compliance) for legal information by jurisdiction. | | **Suspicious but unproven** (or failed takedowns) | Buy the domain, or monitor it for changes in hosted content and DNS records. | Best practice: buy a limited number of highly suspicious or potentially useful domains, and monitor the rest with technology plus human review. | ### Spoofing (for email) Spoofing is mail that appears to come from the legitimate domain (or a near miss such as `microsoftt.com`) but does not. An attacker does not need any control over a domain to send spoofed mail that claims to come from it. Mitigation: - Monitor for look-alike domains (with open-source tools or third-party vendors). When you find abuse, file a complaint with the registrar, following the takedown process above. - **Authenticate every domain you own, including domains that never send mail.** Apply SPF, DKIM and DMARC across the whole portfolio, as the [M3AAWG Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp) recommends. - Consider **removing MX records** from domains on which you never receive or send mail. ### Protective DNS records for non-sending and parked domains The kit refers to the M3AAWG Protecting Parked Domains BCP for the form of these records (see also the [document index](https://emailmarketing.net/learn/industry-best-practices/m3aawg-document-index)). For a domain (or subdomain) that sends no mail, publish all four: | Record | Value | Effect | |---|---|---| | SPF | `example.com. TXT "v=spf1 -all"` | No host is authorized to send mail with this MAIL FROM, so receivers hard-fail forgeries. | | DKIM | `*._domainkey.example.com. TXT "v=DKIM1; p="` | A wildcard key record with an **empty public key**. It revokes all selectors, so no DKIM signature for the domain can verify. | | DMARC | `_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@yourbrand.example"` | Tells receivers to reject anything that uses the domain in the From: header. The `rua` address still shows you attempted abuse. Subdomains inherit `p=reject` by default (when `sp` is not set). See [DMARC deployment](https://emailmarketing.net/learn/authentication/dmarc-deployment). | | Null MX | `example.com. MX 0 .` | RFC 7505. It declares explicitly that the domain receives no mail, so senders fail immediately instead of retrying, and the lack of an MX record cannot fall back to the A record. | Apply these records to defensive registrations on the day you buy them. A cousin domain that was registered defensively but left unprotected is exactly what a phisher wants to spoof. When a parked domain is later brought into use for sending, remove these records as part of normal [authentication setup](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp) and domain warm-up ([sending-infrastructure practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)). ### Account takeover (ATO) of the registrar account A single credential that is guessed, phished or obtained by social engineering can give an attacker the **entire domain portfolio**, and make it harder for you to access it yourself. Specific points: - **Email is often the only channel registrars use to tell registrants about account activity.** An attacker who controls the account can change DNS so that those notifications never arrive, for example when the registrant's administrative and technical contact addresses are hosted in the compromised domain. **Register a contact address outside your own domain**, so that notifications of a takeover still reach you. - Phishers also impersonate registrars and DNS providers to collect registrants' credentials. The usual goal is to change your **nameserver IPs**. Control of name resolution gives access to your inbound mail, a real-time copy of your website, captured credentials, and use of the domain for spam or crime. - **Domain shadowing** is a stealthier variant. The attacker leaves your site and mail untouched, and quietly creates new subdomains under their own control (or entirely new domains, billed to your stored payment method), for example `login.yourcompany.com` or `email.yourcompany.com`, pointed at the attacker's infrastructure. It is very hard to detect, because few registrars offer monitoring for new domains or subdomains added to an account. Countermeasures: use that monitoring where the registrar offers it, schedule regular spot checks of the domain-management account for recent changes, and pull **passive DNS reports of new hostnames appearing on your domains**. Mitigation checklist: MFA on all accounts, monitoring for unusual behavior (such as unusual logins), monitoring for look-alike domains, a complaint to the registrar when you identify abuse (following the takedown process above), and documented mitigation processes shared with security teams. ### Software vulnerability Attackers scan registrar and administration portals for vulnerabilities in the web application (e.g., SQL injection). One successful exploit can reveal the credentials of many domain accounts at once. Keep software patched, and run a responsible vulnerability disclosure program. ## ESP relevance For an ESP, the portfolio is larger than the corporate brand. Sending domains, bounce and return-path domains, tracking domains, and subdomains delegated by each customer are all assets that attackers can shadow, squat or spoof. [Sending-infrastructure practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) covers how the reputation of cousin domains spills over and how customer domain delegation is organized, and [blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) covers domain strategy for ESP customers. [DMARC](https://emailmarketing.net/learn/authentication/dmarc) explicitly does not protect against look-alike domains. Monitoring and defensive registration are the only controls for that gap. ## Further reading named by the kit - ICANN SSAC-044, "A Registrant's Guide to Protecting Domain Name Registration Accounts", for more thorough security measures. - ICANN Centralized Zone Data Service: https://czds.icann.org/home (gTLD zone files only). - ICANN Trademark Clearinghouse: https://newgtlds.icann.org/en/about/trademark-clearinghouse (consult legal counsel). - M3AAWG Protecting Parked Domains BCP: https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf # Deliverability Benchmarks (Quantitative Reference) > Dated, vendor-attributed benchmark tables — Validity seed-measured inbox/spam/missing rates by provider, country, region, and industry; Marigold and Freshworks per-industry engagement rates; and Sinch's sender-adoption and maturity figures. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/deliverability-benchmarks If you want to know whether your inbox rate is normal, what open rate your industry sees, or how many senders have DMARC, the figures below give the published answers. They come from vendor reports, so they are **directional context, not ground truth**. Use them to judge whether your program is roughly within the normal range, never as a target to game or as a promise of what you will achieve. For what these metrics mean and the thresholds that call for action, see [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). For how placement and engagement are measured, and why each method is biased, see [Placement Measurement Methodology](https://emailmarketing.net/learn/operations/placement-measurement-methodology) and [Tracking & Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion). Measurement is not explained again here. ## How to read every number here (guardrails) 1. **Every figure is dated and attributed.** A benchmark with no year and no publisher is worthless, so read past it. Every number below has both. 2. **Never combine Validity's seed data with Sinch's survey data.** They measure different things with different methods: - **Validity** figures measure placement with seed addresses: test mailboxes report whether mail reached the inbox, went to spam or went missing. This shows where mail landed, but there is no engagement from real recipients ([Placement Measurement Methodology](https://emailmarketing.net/learn/operations/placement-measurement-methodology) lists the structural weaknesses of seed data). - **Marigold and Freshworks** figures are engagement rates (opens, clicks, unsubscribes) calculated from real sends. **Engagement is not placement.** A high open rate does not prove that mail reached the inbox, and both measures are inflated or distorted by the effects described in [Tracking & Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion) (Apple Mail Privacy Protection, clicks by security scanners). Open-rate benchmarks from before and after MPP cannot be compared. - **Sinch** figures are answers to a survey in which senders describe their own practices. They are subject to selection bias (the respondents are ESP customers) and to reporting error. They describe what senders say they do, not measured outcomes. 3. **Directional, not authoritative.** Each vendor measures its own customer base with its own method. Absolute rates change from year to year and differ between reports that measure "the same" thing. The relationships between figures last longer than the exact percentages: Microsoft is harder than Gmail, Apple is worst on placement, Finance does worse than Real Estate, and engagement varies by ~2x across industries. 4. **No invented figures.** Only figures printed in the source reports appear here. Where a report gives a range or a caveat, it is reproduced. --- ## 1. Inbox-placement benchmarks: Validity (seed data, 2022) **Source:** Validity, *2023 Email Deliverability Benchmark*. **Method:** seed data. Customers of Validity Everest send campaigns to seed addresses at hundreds of mailbox providers (MBPs) and spam filters worldwide. Software records whether each message reached the inbox, went to spam or went missing, and the results are combined in the Everest Mailbox Provider Community. **Period:** the report is dated 2023, but the placement data covers **calendar year 2022** ("inbox placement rates were just below 85 percent in 2022"). Only senders who agreed to have their data combined are included, and the figures are a snapshot in time. Three metrics are used throughout: - **Inbox placement rate (IPR):** messages delivered to the inbox, divided by all messages sent. - **Spam placement rate:** messages delivered to the spam or junk folder, divided by all messages sent. - **Missing rate:** messages accepted and then deferred or blocked, which never arrived in the inbox or in spam. Compare this with the "delivered rate" that ESPs show. Validity puts the average combined bounce rate (hard+soft) for permission-based programs at **~1.5%**, so the "delivered" rate an ESP reports is ~98.5%. That figure only measures acceptance, not placement. ### Global | Metric | Rate | |---|---| | Inbox | **84.8%** | | Spam | 6.1% | | Missing | 9.1% | The headline: roughly **1 in 6** legitimate, permission-based marketing emails never reached the inbox (15.2% went to spam or went missing), and ~**1 in 10** was not accepted at all. ### By global mailbox provider (MAGY and Apple) "MAGY" stands for Microsoft, AOL, Gmail and Yahoo. The combined MAGY IPR was **86%**, above the global average. Gmail performed best of the global MBPs and Microsoft was the hardest, while Apple did substantially worse than all of them. | Provider | Inbox | Spam | Missing | |---|---|---|---| | **Gmail** | 88.1% | 3.8% | 8.1% | | **Yahoo** (incl. AOL) | 87.4% | 3.8% | 8.8% | | **Microsoft** (Outlook and Hotmail) | 82.5% | 6.6% | 10.9% | | **Apple** (iCloud and me.com) | 66.3% | 22.9% | 10.8% | Validity attributes Apple's low IPR, and its spam rate of ~3x the average, largely to how hard it has become to measure engagement since **Mail Privacy Protection (MPP)**: senders who rely on opens end up mailing lists that respond less. The Apple figure covers subscribers on Apple domains, but the effect reaches further, because many Gmail, Microsoft and Yahoo users read their mail in Apple Mail (see [Apple iCloud Mail](https://emailmarketing.net/learn/providers/apple-icloud-mail) and [Tracking & Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). ### Mailbox provider market share (share of a typical list) | Provider | Relative market share | |---|---| | Gmail | 47% | | Yahoo | 17% | | Microsoft | 16% | | AOL | 6% | | Other | 14% | MAGY holds **87%** of relative market share ("seven of every eight emails"). At least ~75% of a typical list is with these four providers, which are effectively three, since Yahoo and AOL are one company. ### By country (9) | Country | Inbox | Spam | Missing | |---|---|---|---| | **Germany** | 97.8% | 0.3% | 1.9% | | **China** | 92.7% | 3.6% | 3.7% | | **Canada** | 90.0% | 3.9% | 6.1% | | **United Kingdom** | 89.8% | 2.2% | 8.0% | | **Australia** | 89.7% | 2.4% | 7.9% | | **France** | 88.7% | 2.0% | 9.3% | | **Brazil** | 86.9% | 6.6% | 6.5% | | **United States** | 84.6% | 6.3% | 9.1% | | **India** | 68.9% | 5.7% | 25.4% | Validity's interpretation: the best performers (Germany, Canada) have strict consent regimes (double opt-in is the norm in Germany, and Canada has CASL). The US lags because permission is still mostly opt-out. India's very high missing rate reflects widespread email scams and poorer data quality. The report's global map labels India 69.8%, while the country detail page gives the full breakdown of 68.9% / 5.7% / 25.4% used here. ### By region Each region has an overall figure (all MBPs, including MAGY) and a figure for **regional MBPs only** (excluding MAGY). Regional providers filter more on rules than on engagement, and their figure is consistently lower than the overall one. | Region | Overall Inbox | Overall Spam | Overall Missing | Regional-only Inbox | Regional-only Spam | Regional-only Missing | |---|---|---|---|---|---|---| | **Europe** | 91.0% | 2.0% | 7.0% | 80.2% | 9.9% | 9.9% | | **Latin America** | 87.4% | 6.4% | 6.2% | 81.1% | 3.8% | 15.1% | | **North America** | 84.6% | 6.3% | 9.1% | 87.9% | 3.0% | 9.1% | | **Asia Pacific** | 78.2% | 3.6% | 17.2% | see split below | | | Europe performed best of the regions (91%), and Asia Pacific worst (78%). Asia Pacific splits sharply: | Asia Pacific sub-group (regional MBPs, excl. MAGY) | Inbox | Spam | Missing | |---|---|---|---| | Australia & New Zealand MBPs | 90.6% | 1.1% | 8.3% | | Asian MBPs (excl. Oceania) | 58.0% | 8.5% | 33.5% | The main regional MBPs named for each region: **North America**: AT&T, Comcast, Charter, Bell, Shaw, Telmex. **Latin America**: BOL, Terra, UOL. **Europe**: Alice, BT Mail, GMX, Orange, Virgin Media, T-Online. **Asia Pacific**: Telstra/Bigpond, QQ (Tencent), 126 (Netease). ### By industry (15 verticals) Industry sectors were assigned using ZoomInfo, and a sector needed at least 10 customers to appear. | Industry | Inbox | Spam | Missing | |---|---|---|---| | Real Estate | 97.1% | 0.8% | 2.1% | | Media & Internet | 94.9% | 1.9% | 3.2% | | Travel & Hospitality | 94.5% | 2.6% | 2.9% | | Holding Companies | 91.6% | 3.5% | 4.9% | | Construction | 90.9% | 3.3% | 5.8% | | Healthcare | 89.8% | 6.9% | 3.3% | | Consumer Services | 89.7% | 4.3% | 6.0% | | Education | 89.5% | 4.6% | 5.9% | | Software | 89.1% | 2.7% | 8.2% | | Retail | 87.7% | 2.4% | 9.9% | | Manufacturing | 84.7% | 3.3% | 12.0% | | Nonprofit Organizations | 83.5% | 5.9% | 10.6% | | Business Services | 83.4% | 7.0% | 9.6% | | Telecoms | 80.8% | 8.4% | 10.8% | | Finance & Insurance | 80.0% | 8.4% | 11.6% | Business Services, Telecoms, and Finance & Insurance performed worst, with a combined spam and missing rate on average ~33% above the global benchmark. Real Estate led at 97.1%. ### B2B: hosting platform and filtering gateway B2B mail passes through a **hosting platform** and often also a separate **third-party filtering gateway**. That is two layers, and either one can send mail to spam or block it. B2B IPRs are lower than B2C, with substantially higher missing rates. Validity notes that B2B inbox placement **could be as low as 68%** once the hosting platform and the filtering application are considered together. **Global share of B2B hosting** (95% of B2B marketing mail goes to Google Workspace or Microsoft 365): | Hosting platform | Share | |---|---| | Microsoft Office 365 | 48% | | Google Workspace ("Google Apps") | 47% | | Other | 5% | **Global placement at hosting platforms:** Inbox **79.6%**, Spam 4.1%, Missing **16.3%**. **Global share of filtering gateways:** | Gateway | Share | |---|---| | Proofpoint | 46% | | Barracuda | 15% | | Mimecast | 15% | | Cisco Email Security | 13% | | Other | 11% | **Global placement at filtering gateways:** Inbox **84.9%**, Spam 4.6%, Missing 10.5% (close to the global averages). See [B2B Gateway Deliverability](https://emailmarketing.net/learn/providers/b2b-gateway-deliverability) for how these gateways filter, rewrite links and handle delisting. --- ## 2. Engagement benchmarks by industry **These figures measure engagement, not placement.** Opens, clicks and unsubscribes are calculated from real sends. They are distorted by Apple MPP (which inflates opens), by clicks from security scanners and bots, and by false negatives when images are turned off (see [Tracking & Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion)). Treat them as rough context for comparing yourself with peers within a stable mix of audiences, not as indicators of placement. The two vendors below are kept in **separate, attributed tables** because they use different lists of industries and different methods. Do not merge or average them. ### Marigold (Campaign Monitor by Marigold), 18 verticals **Source:** Marigold, *The Essential Guide to Deliverability*: "Campaign Monitor by Marigold analyzed billions of emails." The metrics are open rate, click-through rate (CTR), click-to-open rate (CTOR) and unsubscribe rate. Marigold cites Litmus for the email return on investment (ROI) of **$36 per $1**, and gives an average CTR of "2.3% across regions." | Industry | Open | Click-Through | Click-to-Open | Unsubscribe | |---|---|---|---|---| | Advertising & Marketing | 20.5% | 1.8% | 9.0% | 0.2% | | Agriculture, Forestry, Fishing, Hunting | 27.3% | 3.4% | 12.5% | 0.3% | | Consumer Packaged Goods | 20.0% | 1.9% | 11.1% | 0.1% | | Education | 28.5% | 4.4% | 15.7% | 0.2% | | Financial Services | 27.1% | 2.4% | 10.1% | 0.2% | | Restaurant, Food & Beverage | 18.5% | 2.0% | 10.5% | 0.1% | | Government & Politics | 19.4% | 2.8% | 14.3% | 0.1% | | Healthcare Services | 23.7% | 3.0% | 13.4% | 0.3% | | IT/Tech/Software | 22.7% | 2.0% | 9.8% | 0.2% | | Logistics & Wholesale | 23.4% | 2.0% | 11.7% | 0.3% | | Media, Entertainment, Publishing | 23.9% | 2.9% | 12.4% | 0.1% | | Nonprofit | 26.6% | 2.7% | 10.2% | 0.2% | | Other | 19.9% | 2.6% | 13.2% | 0.3% | | Professional Services | 19.3% | 2.1% | 11.1% | 0.2% | | Real Estate, Design, Construction | 21.7% | 3.6% | 17.2% | 0.2% | | Retail | 17.1% | 0.7% | 5.8% | 0.1% | | Travel, Hospitality, Leisure | 20.2% | 1.4% | 8.7% | 0.2% | | Wellness & Fitness | 19.2% | 1.2% | 6.0% | 0.4% | | **Average totals** | **21.5%** | **2.3%** | **10.5%** | **0.1%** | ### Freshworks, 12 verticals **Source:** Freshworks, *Email Deliverability Best Practices*, "data compiled from multiple industry reports". No measurement period is given, so treat the figures as undated. The metrics are open rate, click-through rate, hard bounce, soft bounce and unsubscribe. Because of the bounce columns, this table is partly a benchmark of list quality, not only of engagement. | Industry | Open | Click-Through | Hard Bounce | Soft Bounce | Unsubscribe | |---|---|---|---|---|---| | Agriculture and Food Services | 23.1% | 3.1% | 0.40% | 0.61% | 0.23% | | Beauty and Personal Care | 16.5% | 1.8% | 0.25% | 0.32% | 0.30% | | Computers and Electronics | 21.4% | 2.1% | 0.45% | 0.80% | 0.27% | | E-Commerce | 16.2% | 2.01% | 0.21% | 0.25% | 0.27% | | Education and Training | 32.4% | 2.85% | 0.29% | 0.54% | 0.21% | | Financial Services | 28.57% | 1.26% | 0.55% | 0.34% | 0.29% | | Games and Sports | 29.44% | 3.44% | 0.37% | 0.44% | 0.20% | | Health and Fitness | 21.42% | 2.83% | 0.31% | 0.40% | 0.36% | | IT and Software | 23.1% | 2.12% | 0.40% | 0.43% | 0.27% | | Media, Marketing, and Advertising | 23.9% | 3.12% | 0.21% | 0.28% | 0.18% | | Real Estate, Design, and Construction | 18.97% | 1.68% | 0.41% | 0.59% | 0.28% | | Restaurant and Dining | 24.01% | 1.47% | 0.32% | 0.51% | 0.31% | The two tables disagree on levels for verticals with similar names (for example, an open rate of 17.1% for Marigold's Retail against 16.2% for Freshworks' E-Commerce, and 28.5% for Marigold's Education against 32.4% for Freshworks' Education). That shows directly why engagement figures from different vendors must not be pooled. --- ## 3. Sender adoption and maturity: Sinch (survey, July 2024) **Source:** combined from **Sinch Mailgun, *State of Email Deliverability 2025*** and **Sinch Mailjet, *Road to the Inbox 2025***. Both reports use the **same survey**, which Sinch ran in **July 2024** with **1,100+ email senders** in the US, UK, France, Germany and Spain. Respondents were users of Mailjet, Mailgun and Email on Acid, invited by email or in the app, with one prize as an incentive. The figures are **self-reported** by ESP customers. Read them as what senders say they do, not as measured outcomes, and do not compare them with the Validity placement data above. Where both reports cite the same statistic (e.g. DMARC 53.8%), it is one figure from one survey, and it is reported once below. The sample leans toward small senders, which matters if you generalize from it: **62.5%** send fewer than 50,000 emails a month, and **52.3%** have ≤10 employees. ### Authentication adoption | Metric | Value | Source detail | |---|---|---| | Using DMARC (2024) | **53.8%** | Up from **42.6%** in 2023 (a rise of 11.2 points, or ~26% in relative terms, attributed to the Google and Yahoo requirements of Feb 2024) | | Bulk or highest-volume senders using DMARC | ~56% (2023), rising to **~70%+** (2024) | Adoption rose fastest among high-volume senders | | Using both SPF and DKIM | 66.2% | ~9% use only one; >25% are unsure | | DMARC policy is `p=none` | ~31.8% | The most common policy | | DMARC policy is `p=quarantine` | ~19.3% | | | DMARC policy is `p=reject` | ~17.7% | | | Unsure of their DMARC policy | ~31.3% | Down from >40% in 2023 (awareness rose with adoption) | | Implemented BIMI | <6% | A further 11.4% are "working on it"; 24.5% are unsure | Most DMARC users stay at `p=none`, which enforces nothing. Sinch and the experts it cites point to this as the gap in maturity: adoption rose, but most senders have not moved to a policy that enforces. See [DMARC Deployment](https://emailmarketing.net/learn/authentication/dmarc-deployment) for how to roll out a policy, and [BIMI](https://emailmarketing.net/learn/authentication/bimi), which requires `p=quarantine` or `p=reject`. Google and Yahoo required only `p=none` at launch, and a stricter minimum is expected (see [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements) and [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)). ### The misunderstanding about delivery rate Sinch's headline finding is that senders consistently misunderstand what "delivery rate" measures. When asked to define it: | Belief about "delivery rate" | Share | |---|---| | The % of emails that reach the **inbox** (wrong) | 50.9% | | Overall deliverability (wrong) | 22.8% | | "Don't know" | 11.6% | | The total number of emails sent (wrong) | 2.5% | | **Correct:** the % delivered to **any folder** (including spam) | **12.3%** | **~88% could not correctly say what delivery rate measures.** Delivery rate counts mail accepted into any folder, spam included, so a 98% delivery rate says nothing about reaching the inbox. [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) and [Placement Measurement Methodology](https://emailmarketing.net/learn/operations/placement-measurement-methodology) warn about exactly this confusion between delivered and inboxed mail, and the survey puts a number on it. ### Monitoring and list hygiene | Practice | Value | |---|---| | Rate the importance of deliverability at 8/10 or higher | 78.5% | | Feel "very confident" in their deliverability knowledge | 27% | | Call "staying out of spam" a major challenge | 48% | | **Do not** monitor their reputation with major MBPs (e.g. Gmail Postmaster Tools) | 70% | | Started using Google Postmaster Tools after the 2024 requirements | 19.2% | | Actively monitor open and click rates | 57.4% | | Actively monitor delivery rate | 53.1% | | Actively monitor bounce rate | 46.5% | | Actively monitor unsubscribe rate | 39.5% | | Actively monitor spam complaint rate | 32% | | Monitor email blocklists | 32.7% (>50% do not; 14.5% are unsure) | | Rarely or never clean their lists | 39% | | Have a sunset policy for unengaged subscribers | ~24% (~59% have none; ~17% are unsure) | | Admit buying a list or scraping addresses | 9.4% | | Use double opt-in to confirm new subscribers | ~40% | | Separate transactional and promotional mail streams | ~37% (50.3% do not; 12.6% are unsure) | Actions senders reported taking after the requirements: 37% began closely monitoring their spam complaint rate, 35.8% increased list hygiene, 33.1% implemented one-click unsubscribe (RFC 8058), 19.2% adopted Google Postmaster Tools, 18.6% adjusted how often they send, and 12.5% changed their opt-in process. Fewer than a quarter (23%) reported any deliverability trouble caused by the changes at Google and Yahoo. Only **32%** monitor their spam complaint rate, even though Gmail and Yahoo enforce a threshold of **0.3%**. The metric most directly tied to the requirement is one of the least watched. See [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools), [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe), and [List Hygiene & Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). ### Apple Branded Mail and BIMI (Marigold) **Source:** Marigold, *The Essential Guide to Deliverability*. This is a comparison of features, not survey data. There are two ways to show a brand logo in the inbox: | | BIMI | Apple Business Connect — Branded Mail | |---|---|---| | Where it displays | Several providers, including Gmail, Yahoo, Fastmail and Apple Mail | Apple Mail only (the Apple ecosystem) | | Requires DMARC at `p=quarantine` or `p=reject` | Yes | Yes | | Certificate cost | A Verified Mark Certificate (VMC), which must be purchased, is required to display in Gmail and Apple | Free | | Benefit | Brand recognition, trust, sender authenticity | Same | Both require a DMARC policy that enforces, which is why the majority at `p=none` above cannot use either yet. See [BIMI](https://emailmarketing.net/learn/authentication/bimi). --- ## Related articles - [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), on what each metric means and the thresholds for action - [Placement Measurement Methodology](https://emailmarketing.net/learn/operations/placement-measurement-methodology), on the known bias of seed, panel, pixel and dashboard figures (context for Section 1) - [Tracking & Measurement Distortion](https://emailmarketing.net/learn/operations/tracking-and-measurement-distortion), on why the engagement rates in Section 2 are distorted - [B2B Gateway Deliverability](https://emailmarketing.net/learn/providers/b2b-gateway-deliverability), on the filtering gateways behind the B2B figures - [DMARC Deployment](https://emailmarketing.net/learn/authentication/dmarc-deployment), behind the adoption figures in Section 3 - [BIMI](https://emailmarketing.net/learn/authentication/bimi) - [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements), on the 2024 bulk-sender rules that drove adoption - [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements) # Deliverability Community and Expert Resources > Annotated guide to the key independent deliverability expert sites — Word to the Wise, Spam Resource, EmailKarma — and how to use them for current events. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/deliverability-community-resources When you need to know whether something changed at a mailbox provider this week, or why a filter behaves the way it does, vendor documentation rarely has the answer. The deliverability field is small, and much of its authoritative, practitioner-level knowledge lives on a handful of independent expert blogs. Three of them are the standard references. Below is what each is known for, and how to use them when you research current events such as policy changes at mailbox providers, blocklist behavior and new authentication standards. ## Word to the Wise (wordtothewise.com) - **Who**: Laura Atkins (CEO) and Steve Atkins. Laura is a recognized anti-spam veteran with decades of experience tracing internet abuse. Steve covers the deep protocol and technical side. They run a consulting practice (strategy, deliverability, training, mentoring) alongside the blog. - **Coverage**: email authentication (SPF, DKIM, DMARC, and emerging work such as DKIM2 and BIMI), sender reputation, inbox placement, B2B deliverability, and explaining technical filtering behavior to non-technical stakeholders. It is strong on why filters behave the way they do, and on the fundamentals of permission and consent. - **Signature resources**: - The blog at `wordtothewise.com/blog/`. It has a long-running archive dating from the 2000s era and is frequently cited by the rest of the industry. - The *Email Best Practices* white paper, summarized in [WttW Email Best Practices](https://emailmarketing.net/learn/industry-best-practices/wttw-email-best-practices). - Explainers on spam traps ("A Brief Guide to Spamtraps", 2011; "What Spamtraps Tell Us", 2025), summarized in [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps). - **Tools for Email People** (`tools.wordtothewise.com`): practical utilities for email professionals. - **AboutMy.Email** (`aboutmy.email`): send a test message and get a detailed technical report on its authentication and standards compliance. ## Spam Resource (spamresource.com) - **Who**: Al Iverson. The site has been running for 24+ years and posts almost daily, which makes it the best single feed for breaking deliverability news: provider shutdowns, filter changes, regulatory and FTC actions, and acquisitions. - **Coverage** (from the site map, `spamresource.com/p/site-map.html`): | Topic area | Notable resources | |---|---| | Deliverability guides for each mailbox provider | Gmail, Yahoo and AOL, Microsoft Outlook and Hotmail (OLC), Apple iCloud, GMX and Mail.com, Mail.de, indexed under the `ISP Deliverability Guides` label | | MAGY compliance | *2025 MAGY Sender Compliance Guide* (the bulk-sender standards of Microsoft, Apple, Gmail and Yahoo): `/2025/04/2025-magy-sender-compliance-guide.html` | | Domain and infrastructure data | MAGY domains list (`/2025/04/magy-domains-list-2025-update.html`), lists of mailbox provider domains, MX record data, tracking of dead or inactive domains | | Authentication | SPF, DKIM, DMARC, ARC, BIMI (including which providers support logos, and guides to creating a logo). See also [DMARC](https://emailmarketing.net/learn/authentication/dmarc) | | **DELIVTERMS** | A signature glossary series ("33 DELIVTERMS and counting") with one post per deliverability term, for example Deliverability, DKIM, Blocklists, Spamhaus, Google Postmaster Tools | | Tools | How-tos for Google Postmaster Tools, Wombatmail tools and domain rankings, SPF, DKIM and DMARC validators, SMTP field manuals, DNS tools | | Compliance and law | CAN-SPAM, CASL, GDPR and consent, policies on cold email | | Specific platforms | Tips for Salesforce Marketing Cloud and Pardot; analysis of ESPs | - **Key URLs of the provider guides**: Gmail `/2024/02/isp-deliverability-guide-gmail-updated.html`; Yahoo, AOL and Verizon `/2019/12/isp-deliverability-guide-yahooaolverizon.html`; Microsoft `/2023/04/isp-deliverability-guide-microsoft-olc.html`; Apple iCloud `/2020/05/isp-deliverability-guide-apples-icloud.html`. - The site also publishes a newsletter (signup at `ml.spamresource.com`). ## EmailKarma (emailkarma.net) - **Who**: Matt Vernhout (Pickering, Ontario, Canada), a long-standing figure in deliverability and email policy. He is particularly strong on **Canadian regulation (CASL)** and on the work of industry bodies. - **Coverage**: email marketing knowledge, industry news, authentication (SPF, DKIM and DMARC), sender reputation, inbox placement, and compliance with changing provider requirements. It publishes several posts a month and has 50+ pages of archives. - **Recurring content**: question-and-answer columns on common email marketing questions; the "Email Deliverability Fundamentals" educational series (for example, explainers on SPF); coverage of major announcements from inbox providers (Gmail, Yahoo, Outlook); guest contributions; and curated lists of other deliverability blogs and recommended books. - The site includes a disclosure about its use of AI ("I use AI to help improve my writing as an editor... all the thoughts and content are mine"). ## How to use these sources 1. **Breaking news, such as "did something change at Gmail this week?"**: search Spam Resource first, because it posts almost daily. Then read Word to the Wise for deeper analysis, then EmailKarma, especially for Canadian angles. 2. **Provider requirements**: Spam Resource's ISP Deliverability Guides and its MAGY compliance guide are maintained, dated summaries of the bulk-sender requirements of Gmail, Yahoo, Microsoft and Apple. Always check the post date, and prefer the most recent update. 3. **Terminology**: Spam Resource's DELIVTERMS series is a glossary you can cite for individual terms. 4. **Conceptual "why" questions** (why filters behave a certain way, how to reason about permission and consent, what spam traps mean): Word to the Wise is the strongest analytical source. 5. **Diagnostics**: point senders to AboutMy.Email (from Word to the Wise) for a technical and authentication report on a single message, and to Google Postmaster Tools (Spam Resource has how-tos) for Gmail reputation data at the domain level. 6. These are blogs, so each post is a dated snapshot. For anything that depends on current policy, check the provider's own current documentation before you advise anyone. # Deliverability Glossary > Alphabetical one-stop definitions of the deliverability terms of art used across this knowledge base, with links to the deep articles. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/glossary When you meet a deliverability term you do not know, look it up here. Each entry gives a short working definition and a link to where the topic is covered in depth. The glossary covers deliverability terms only, not the vocabulary of email design or copywriting. ## A **Acceptance rate (delivery rate)**: the percentage of sent messages that receiving servers accept (SMTP 250). Acceptance is not inbox placement, because an accepted message may still go to the spam folder. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **Allowlist (safelist)**: a list kept on the recipient's side of senders (addresses, domains or IP addresses) whose mail bypasses some filtering. The opposite of a blocklist. Asking recipients to add your sending domain to their safelist is a stopgap for critical mail, not a deliverability strategy. Formal allowlisting programs run by ISPs are largely historical, although CSA certification still exists (see [GMX and WEB.DE](https://emailmarketing.net/learn/providers/gmx-web-de-postmaster)). **Apple Mail Privacy Protection (MPP)**: an Apple Mail feature that fetches images in advance through a proxy. It fires open-tracking pixels without anyone reading the message, and hides recipients' IP addresses. It is a main reason open rates are inflated and clicks should be given more weight. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **ARC (Authenticated Received Chain)**: the RFC 8617 protocol that lets intermediaries (forwarders, mailing lists) preserve earlier authentication results, so that mail that legitimately breaks SPF or DKIM in transit can still be evaluated. See [ARC](https://emailmarketing.net/learn/authentication/arc). **ARF (Abuse Reporting Format)**: the RFC 5965 message format that complaint feedback loops use to report a recipient's "this is spam" action back to the sender. See [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). **Authentication-Results header**: the RFC 8601 header that the receiver adds to record its SPF, DKIM and DMARC verdicts (and related ones) for a message. It is where you can read how a receiver actually judged your authentication. See [Authentication-Results Header](https://emailmarketing.net/learn/authentication/authentication-results-header). ## B **Bayesian filter**: a spam filter that classifies messages statistically, from the frequency of tokens learned from known spam and legitimate mail (ham), rather than from fixed rules. It is one of many content-analysis layers modern providers run. See [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability). **BIMI (Brand Indicators for Message Identification)**: a standard for displaying a brand logo next to authenticated messages. It requires DMARC at enforcement (`quarantine` or `reject`) and, at most providers, a Verified Mark Certificate. See [BIMI](https://emailmarketing.net/learn/authentication/bimi). **Blocklist (DNSBL or RBL)**: a list, queried through DNS, of IP addresses or domains suspected of sending spam. Receivers use blocklist data as one input alongside their internal metrics, and Spamhaus carries the most weight. See [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). **Bounce**: a delivery failure returned to the sender. Hard bounces (5.X.X) are permanent, such as an invalid address or a policy rejection. Soft bounces (4.X.X) are temporary, such as a full mailbox or a deferral. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) and [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes). **Bounce rate**: bounced messages as a percentage of messages sent. Common operating targets: under 2% is healthy, investigate above 5%, and never exceed 10%. See the [threshold table](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **Bulk sender**: a sender that exceeds a provider's volume threshold (at Gmail, about 5,000 messages a day to Gmail), which triggers stricter requirements such as authentication, one-click unsubscribe and complaint-rate ceilings. See [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements). ## C **CAN-SPAM**: the US law (2003) that governs commercial email. It requires truthful headers and subject lines, a physical address, and a working opt-out honored within 10 business days. It is based on opt-out, unlike CASL and GDPR. See [CAN-SPAM](https://emailmarketing.net/learn/compliance/can-spam). **CASL**: Canada's Anti-Spam Legislation. It requires express or implied consent before commercial electronic messages are sent, and sets requirements for identification and unsubscribing. See [CASL](https://emailmarketing.net/learn/compliance/casl). **Complaint (spam report)**: a recipient marking a message as spam. It is the most damaging single reputation signal, and some providers report it back to senders through feedback loops. See [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). **Complaint rate**: complaints as a percentage of delivered mail. Aim for below 0.1%. Gmail and Yahoo enforce a ceiling of 0.3% that you must never reach. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **Consent (express vs. implied)**: express consent is an explicit opt-in that is recorded. Implied consent is inferred from an existing business relationship. Which one is enough, and for how long, depends on the jurisdiction (CASL puts time limits on implied consent). See [Compliance](https://emailmarketing.net/learn/compliance). **CSA (Certified Senders Alliance)**: a German sender certification program whose allowlist is honored by GMX and WEB.DE and other European receivers. See [GMX, WEB.DE and mail.com](https://emailmarketing.net/learn/providers/gmx-web-de-postmaster). ## D **DANE for SMTP**: a mechanism based on DNSSEC (TLSA records) for authenticating a receiving server's TLS certificate. It closes the downgrade gap in opportunistic STARTTLS. See [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp). **Dedicated IP**: a sending IP address used by a single sender, which gives full control over its reputation and full responsibility for it. It is only worthwhile above a sustained minimum volume, because a sender with low volume keeps a dedicated IP too "cold" to build reputation. See [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). **Deferral (greylisting or throttling response)**: a temporary 4XX refusal that tells the sender to retry later. Rising deferrals at one provider often mean throttling, the step before blocking. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **Delivery vs. deliverability**: delivery means the receiving server accepted the message. Deliverability is about where it landed afterward: the inbox, a tab, the spam folder, or dropped without notice. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **DKIM (DomainKeys Identified Mail)**: the RFC 6376 cryptographic signature over selected headers and the body, verified with a public key published in DNS. It proves that a domain takes responsibility for the message, and that the message was not altered in transit. See [DKIM](https://emailmarketing.net/learn/authentication/dkim). **DMARC**: Domain-based Message Authentication, Reporting and Conformance. A domain publishes a policy (`none`, `quarantine` or `reject`) for mail that fails aligned SPF or DKIM, and receives reports. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc) and [DMARC Deployment](https://emailmarketing.net/learn/authentication/dmarc-deployment). **DMARC alignment**: the requirement that the domain in the visible From header matches (exactly, or at the organizational level) the domain that SPF or DKIM validated. Authentication without alignment does not pass DMARC. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc). **Double opt-in (confirmed opt-in)**: a signup flow in which the address is not mailed until the subscriber clicks a confirmation link. It eliminates bounces from typos, blocks malicious sign-ups, and proves consent. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **DSN (Delivery Status Notification)**: the RFC 3464 machine-readable bounce message that reports delivery failure, delay or success, with status codes for each recipient. See [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications). ## E **Email harvesting (scraping)**: collecting addresses without consent, typically by crawling websites. Harvested lists are full of spam traps and invalid addresses, so never mail them. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **Email validation**: checking before sending that an address is syntactically valid, has working MX records and (through verification services) an existing mailbox. Done at signup, it prevents hard bounces later. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **Engagement**: the recipient interactions that providers use to score senders, such as opens, clicks, reading time, replies, deletion without reading, and moving messages out of spam. It is the statistical basis for judging whether mail is "wanted and expected". See [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability). **Enhanced status codes**: the RFC 3463 three-part codes (for example, `5.1.1` means a bad destination mailbox) that let software parse SMTP replies to classify bounces. See [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes). **Envelope sender (MAIL FROM, Return-Path, 5321.MailFrom)**: the address given in the SMTP `MAIL FROM` command, where bounces are sent. It is separate from the visible From header. SPF is evaluated against this domain. See [SPF](https://emailmarketing.net/learn/authentication/spf) and [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp). ## F **False positive**: a legitimate message wrongly classified as spam. Providers weigh this cost against the cost of missing spam, and it is why a good engagement history can rescue borderline mail. **Feedback loop (FBL)**: a provider mechanism that reports recipients' spam complaints back to the sender (usually in ARF format), so that the sender can suppress complainers immediately. See [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). **FCrDNS (forward-confirmed reverse DNS)**: the PTR record of the sending IP address resolves to a hostname that resolves back to the same IP address. Most major providers treat it as a basic infrastructure requirement. See [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices). **Feedback-ID header**: Gmail's FBL mechanism. The sender supplies a header, and Gmail aggregates its identifiers into spam-rate statistics for each campaign in Postmaster Tools (without revealing individual complainers). See [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools). **From header (5322.From)**: the author address displayed to recipients, defined by RFC 5322. DMARC alignment is anchored on this domain. See [Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format). ## G **GDPR**: the EU's General Data Protection Regulation. For email marketing, it requires a lawful basis (usually explicit consent), respect for the rights of data subjects, and an easy way to withdraw consent. It is broader than an anti-spam law. See [compliance overview](https://emailmarketing.net/learn/compliance). **Google Postmaster Tools**: Google's free dashboard for senders. It shows domain and IP reputation, spam rate, authentication pass rates, and delivery errors for mail to Gmail. See [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools). **Greylisting**: a receiver technique that temporarily rejects mail from unknown sources and accepts it when it is retried. It works because much spam software does not retry. Senders see it as deferrals. See [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp). ## H **Hard bounce**: a permanent delivery failure (5.X.X), such as an address or domain that does not exist, or a policy rejection. Remove the address immediately and never send to it again. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **Honeypot**: a decoy. It is either a pristine spam-trap address planted to catch people who harvest addresses, or a hidden form field that only bots fill in, used to block signups by bots. See [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps). ## I **Inbox placement rate (IPR)**: the percentage of delivered mail that reaches the inbox rather than the spam folder, usually measured for each provider through seed testing. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **IP warming (warm-up)**: gradually increasing volume on a new IP address (or domain) so that receivers can build a reputation history. Suddenly sending full volume from a cold IP address triggers filtering. See [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up). ## L **List churn**: the rate at which addresses leave a list through unsubscribes, bounces and abandonment. Marketing databases degrade by roughly 22% per year, so hygiene is continuous work, not a one-off task. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **List hygiene**: the ongoing practice of removing invalid, bouncing, complaining and unengaged addresses, to keep healthy the metrics that providers score. See [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **List-Unsubscribe header**: the RFC 2369 header that advertises unsubscribe endpoints (mailto or HTTPS), which mail clients show as a built-in unsubscribe control. See [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe). ## M **Mailbox provider (MBP or ISP)**: the organization that runs recipients' mailboxes (Gmail, Yahoo, Microsoft, corporate servers). The terms "mailbox provider" and "ISP" are used interchangeably for the receiving side. **MTA, MSA, MDA, MUA**: the roles that handle mail. The Mail Transfer Agent relays mail between servers, the Mail Submission Agent accepts mail from clients, the Mail Delivery Agent files mail into the mailbox, and the Mail User Agent is the recipient's client. See [Email Architecture](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture). **MTA-STS**: a policy mechanism, published over HTTPS, by which a receiving domain requires authenticated TLS for inbound SMTP. It defeats STARTTLS downgrade attacks without DNSSEC. See [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts). **MX record**: the DNS record that names the servers receiving mail for a domain. It is checked during address validation, and a domain needs one (or an A record as fallback) to receive bounces. ## O **One-click unsubscribe**: defined by RFC 8058. A `List-Unsubscribe` HTTPS URI together with a `List-Unsubscribe-Post` header lets the recipient unsubscribe with a single POST request, without a landing page. It is mandatory for bulk senders under the 2024 requirements of Gmail and Yahoo. See [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe). **Open rate**: the percentage of delivered messages whose tracking pixel fired. Apple MPP and image prefetching inflate it, so treat it as approximate and give more weight to clicks and conversions. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **Opt-in and opt-out**: opt-in means the recipient explicitly asked for the mail (the consent model of CASL and GDPR). Opt-out means mail may be sent until the recipient unsubscribes (the CAN-SPAM model). See [Compliance](https://emailmarketing.net/learn/compliance). ## P **PECR**: the UK Privacy and Electronic Communications Regulations, consent-based rules for electronic marketing in the UK that apply alongside the UK GDPR. See [UK PECR](https://emailmarketing.net/learn/compliance/uk-pecr-email-marketing). **Postmaster**: the role responsible for a domain's mail system. `postmaster@` is a reserved address that must accept mail. Providers publish their sender requirements on "postmaster pages" (see, for example, [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements)). **Preference center**: a page where subscribers can change frequency, topics and channels instead of unsubscribing completely. It turns people who might have complained into subscribers who stay, at a lower frequency. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). ## Q **Quarantine**: in DMARC, the policy that asks receivers to treat failing mail with suspicion (typically by putting it in the spam folder) rather than reject it. More generally, a filter holding suspect mail. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc). ## R **Re-engagement (win-back) campaign**: a last-chance message to inactive subscribers, asking them to confirm they are still interested before a sunset policy removes them. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **Reverse DNS (PTR record)**: the DNS mapping from an IP address back to a hostname. Sending IP addresses need a PTR record that is not generic and that forward-confirms (see FCrDNS). Many providers reject mail from IP addresses without one. See [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices). ## S **Seed list**: a panel of monitored test mailboxes at different providers, used to measure where a given message lands (inbox, tab, spam folder, or missing). Seed results tend to look worse than reality, because seed mailboxes have no engagement history. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **Sender reputation**: the scores that receivers attach to your sending IP addresses and domains, computed from complaints, bounces, engagement, spam-trap hits, volume patterns and authentication. It decides whether mail reaches the inbox, is throttled or is blocked. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). **Shared IP**: a sending IP address whose reputation is shared by many senders. It is appropriate below the volume at which a dedicated IP makes sense, and the trade-off is exposure to how the other senders behave. See [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). **SMTP**: Simple Mail Transfer Protocol (RFC 5321), the transport for email between servers. Its reply codes are the raw material of bounce handling. See [SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp). **SNDS (Smart Network Data Services)**: Microsoft's sender dashboard, by IP address, for mail to its consumer domains. It shows volume, filter verdicts, complaint rate and trap hits, and is paired with JMRP, Microsoft's complaint feedback loop. See [Microsoft SNDS & JMRP](https://emailmarketing.net/learn/postmaster-tools/microsoft-snds-jmrp). **Soft bounce**: a temporary delivery failure (4.X.X), such as a full mailbox, an unavailable server or throttling. It is retried automatically. Suppress addresses that keep soft-bouncing. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **Spam trap**: an address that damages your reputation when you mail it. Pristine traps never belonged to a person, and can only be reached through bought or scraped lists. Recycled traps are abandoned real addresses turned into traps. Typo traps catch careless handling of signups. See [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps). **SpamAssassin**: a widely deployed open-source content filter that scores messages against sets of rules. Its scores appear in the headers of some receivers and in seed-test reports. See [Deliverability Testing Tools](https://emailmarketing.net/learn/reference/deliverability-testing-tools). **SPF (Sender Policy Framework)**: the RFC 7208 DNS record that lists the hosts authorized to send mail for a domain, evaluated against the envelope sender. It is limited to 10 DNS lookups, and forwarding breaks it. See [SPF](https://emailmarketing.net/learn/authentication/spf). **Spoofing**: forging a sender's identity (usually the From header) to impersonate a trusted party. SPF, DKIM and DMARC exist to counter it. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc). **Sunset policy**: rules that first reduce how often you mail addresses that stop engaging, then suppress them, before they decay into hard bounces or recycled spam traps (after about 12 months of inactivity). See [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). **Suppression list**: the do-not-mail list of addresses that unsubscribed, hard-bounced or complained. Suppression protects your reputation, so never bypass it. See [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring). ## T **Throttling**: a receiver limiting how much mail it accepts from a sender per unit of time, which shows up as deferrals. The term also covers rate limiting on the sender's side to stay under those limits. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **TLS-RPT**: a reporting channel (RFC 8460) through which receivers tell a domain about TLS negotiation failures for its inbound mail. It complements MTA-STS and DANE. See [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt). **Tracking pixel**: an invisible remote image whose download registers an "open." It is the mechanism behind open metrics, and proxies that fetch images make it unreliable. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). **Transactional email**: mail triggered by a recipient's own action (a receipt, a password reset, a notification). It is generally exempt from marketing consent rules and from marketing suppression, but not from deliverability concerns, so keep it separate from marketing streams. See [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation). ## U **Unsolicited commercial email (UCE)**: commercial mail sent without the recipient's permission. It is spam in the operational sense, and often in the legal sense. **Unsubscribe rate**: unsubscribes as a percentage of delivered mail (healthy: under about 0.3%). An unsubscribe is a much less costly negative signal than a complaint, so make unsubscribing easy. See [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). ## V **VMC (Verified Mark Certificate)**: a certificate that attests ownership of a logo (usually a trademarked one). Gmail and others require it to display a BIMI logo. See [BIMI](https://emailmarketing.net/learn/authentication/bimi). ## Related articles - [Deliverability Testing Tools](https://emailmarketing.net/learn/reference/deliverability-testing-tools), tools that put many of these concepts into practice - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) # Deliverability Testing and Diagnostic Tools > A practical catalog of free diagnostic tools — aboutmy.email, mail-tester, learndmarc, internet.nl, Google CheckMX, MXToolbox Email Health, check.spamhaus.org — what each tests, inputs, and where it fits in a workflow. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/deliverability-testing-tools When you set up a new sending configuration, or a delivery problem appears, free interactive tools can verify the setup and help diagnose the problem. They fall into two families: - **Message-based tools**: you send a real email to a generated address, and the tool analyzes what actually arrived. Examples are aboutmy.email, mail-tester.com and learndmarc.com. These test the whole live path: the IP address that actually connected, the DKIM signature actually applied, and the headers your platform actually produces. - **Domain and DNS-based tools**: you type a domain or an IP address, and the tool inspects published records and server behavior from the outside. Examples are internet.nl, Google CheckMX, MXToolbox Email Health and check.spamhaus.org. These test configuration, not a specific message. Use both. DNS-based tools confirm that the records are right. Message-based tools confirm that the mail your infrastructure actually sends authenticates and aligns. ## Quick reference | Tool | Input | Primary question it answers | |---|---|---| | [aboutmy.email](https://aboutmy.email/) | Send an email to a generated address | Does this message authenticate, align, and comply with the bulk-sender requirements of Gmail and Yahoo? (30+ checks) | | [mail-tester.com](https://www.mail-tester.com/) | Send an email to a generated address | How does a standard SpamAssassin install, with authentication and blocklist checks, score this message? (0–10) | | [learndmarc.com](https://www.learndmarc.com/) | Send an email to a generated address, or paste headers | Step by step: why do SPF, DKIM and DMARC pass or fail for this message? | | [internet.nl/test-mail](https://internet.nl/test-mail/) | Domain name | Does this mail domain meet modern open standards (IPv6, DNSSEC, SPF, DKIM, DMARC, STARTTLS, DANE, RPKI)? | | [Google CheckMX](https://toolbox.googleapps.com/apps/checkmx/) | Domain, with an optional DKIM selector | Are the MX, SPF, DKIM and DMARC records sound, as Google's own resolvers see them? | | [MXToolbox Email Health](https://mxtoolbox.com/emailhealth/) | Domain or email address | A broad health check: 100+ blocklists, tests of MX, SMTP and DNS, and results grouped as problems, warnings and passes | | [check.spamhaus.org](https://check.spamhaus.org/) | IP address, domain, or hash | Is this listed on a Spamhaus blocklist, why, and how do I get it delisted? | ## Message-based tools ### aboutmy.email (Word to the Wise) Built by Steve Atkins of Word to the Wise. Keep the page open (do not navigate away or refresh) and send an email to the one-time address it displays. Ideally, send a real campaign message from the real sending platform. You get a detailed report analyzing "authentication, size, structure and how well it complies with best practices." The tool is free. What it checks (30+ checks): - **Authentication, in depth**: not only whether SPF passed or failed, but the actual DNS lookup performed, the records found, the IP address checked, and the result. The same for DKIM, with the selector, public key and signature verification, and for DMARC, with alignment. BIMI is checked if configured. - **Compliance**: a dedicated section that checks the message against the bulk-sender requirements of Gmail and Yahoo (one-click unsubscribe with List-Unsubscribe, authentication, alignment, etc.). - **Headers and content**: analysis of the MIME structure, and warnings about headers. - **Images**: every image in the message, listed by host, with its file size, its native and rendered dimensions, and warnings when large images are scaled down in the mail client. Read a report in this order: **Authentication** first (fix anything red there before anything else), then **Compliance** (the requirements of Gmail and Yahoo are not suggestions), then the warnings about headers and content, then the "Good Practice" checklist. **When to use it**: this is the best single check before launch and after a change to a sending platform. Use it for a new IP address, domain or ESP, after changing DKIM keys or the From domain, or to confirm compliance with the sender requirements of [Gmail](https://emailmarketing.net/learn/providers/gmail-sender-requirements) and [Yahoo](https://emailmarketing.net/learn/providers/yahoo-sender-requirements). ### mail-tester.com Made by people associated with Mailpoet and AcyMailing, this is the classic tester that gives a "score out of 10". The page generates a random address (`xyz…@srv1.mail-tester.com`-style). Send your message to it and click "Then check your score." What it checks: - **SpamAssassin**: an unmodified SpamAssassin install scores the message. mail-tester reverses the sign so that a higher score is better, with 10/10 as the target. - **Authentication**: SPF, DKIM and DMARC evaluation of the received message. - **Blocklists**: the sending IP address and domain, checked against major DNSBLs. - **Content quality**: broken links, the ratio of images to text, HTML weight and validity issues, and whether an unsubscribe mechanism is present. It is free through the web interface, with a daily limit on free checks. Paid and API plans lift the limit. Results pages stay available at their URL for a period, so you can share them with a hosting provider or ESP. **Caveats**: the score is only an approximation. A standard SpamAssassin install is far simpler than the filtering at Gmail or Outlook, and a 10/10 does not guarantee inbox placement, because reputation and engagement dominate (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). Anything it flags is worth fixing, but do not chase the score as a goal. **When to use it**: a quick check of a combination of template and infrastructure, and a convenient first step when a customer reports mail going to spam. ### learndmarc.com (URIports) A visual tool for learning and diagnosis, sponsored by URIports. Send an email to the generated address at its server (`neo.learndmarc.com`), and it replays the validation process on screen, step by step, in real time: 1. **Connection**: the source IP address, the hostname from reverse DNS, and the envelope sender. 2. **SPF**: the lookup against the `MAIL FROM` domain, whether it passed, and whether SPF aligns with the From: domain. 3. **DKIM**: each signature found, with its selector, algorithm and verification result, and whether DKIM aligns. 4. **DMARC**: how the SPF and DKIM results and their alignment combine into the final DMARC verdict under the domain's published policy. It also offers a header analyzer (paste the raw message source instead of sending), a 10-question quiz with explanations, and results you can share, anonymize or print. It works best on a desktop. **When to use it**: this is the clearest tool for understanding and explaining an authentication failure. It is ideal when SPF passes but DMARC fails (an alignment problem), when debugging failures caused by forwarding, or when teaching a customer what [DMARC](https://emailmarketing.net/learn/authentication/dmarc) alignment means. It tests authentication only, with no checks of content, blocklists or placement. ## Domain and DNS-based tools ### internet.nl mail test Run by the Dutch Internet Standards Platform, "an initiative of the Internet community and the Dutch government." You enter the domain name of an email service. It tests adoption of modern open standards. Several of them matter even for domains with **no** mail service, for example publishing a null MX record, SPF and DMARC on domains that do not send: - **IPv6** reachability of name servers and mail servers - **DNSSEC** signing and validation of the domain and of the MX domains - **Authentication**: whether DMARC, DKIM and SPF records exist, their syntax, and how strict the policy is (it flags lax policies such as `p=none` or `~all`) - **Transport security**: the quality of the STARTTLS configuration, and **DANE** (TLSA records bound to the MX certificates) - **RPKI** route origin authorization for the IP addresses of the mail servers The output is an overall percentage score, with results for each section and subtest, a permalink you can share (useful for sending to a hosting provider), and a widget you can embed. **Caveats**: it measures adoption of standards, not deliverability as such. DNSSEC, DANE and RPKI are excellent hygiene and increasingly expected in Europe (and by some governments), but placement at Gmail or Outlook does not require them. A modest score can go with perfect inbox placement, so read the detail for each section, not the headline number. **When to use it**: infrastructure audits, security and compliance reviews, and checking STARTTLS and DANE after a change of MX or certificate. ### Google Admin Toolbox CheckMX Google's free DNS checker, at `toolbox.googleapps.com/apps/checkmx/`. You enter a domain name, and optionally a **DKIM selector**. It is aimed at Google Workspace administrators but works for any domain. It fetches and checks the MX records, SPF, DKIM (for the given selector) and DMARC as Google's resolvers see them, and flags common DNS problems: missing or duplicate records, too many SPF DNS lookups, syntax errors, and misconfigured priorities. **When to use it**: a fast second opinion on DNS records. It is particularly valuable because it shows how Google sees your records, and Google is the receiver that matters most for many senders. It is a good first check when Gmail in particular is rejecting mail or putting it in spam. ### MXToolbox Email Health An aggregated health report at `mxtoolbox.com/emailhealth/`. You enter a domain or an email address. It runs "hundreds of domain/email/network performance tests," grouped into five sections (blacklist, mail server, web server, DNS, and a summary of problems). Each section shows **Errors, Warnings and Passed**: - **Blocklists**: the domain and the IP addresses of its mail servers, checked against **100+ DNSBLs** (both IP and domain lists) - **Mail servers**: each MX record probed for SMTP connectivity, banner and greeting checks, an open-relay test, a reverse DNS (PTR) match, TLS support, and transaction time - **DNS**: 15+ tests against the authoritative name servers (SOA sanity, NS reachability, etc.), plus checks of the SPF and DMARC records Free users get **one Email Health Check every 24 hours**. Paid tiers add unlimited checks, and a monitor that runs 30+ tests again every few minutes, with alerts. Individual MXToolbox lookups (a single blocklist check, `spf:`, `dmarc:`, `smtp:` etc.) remain free and unlimited for occasional use. **Caveats**: with 100+ blocklists checked, expect noise, because many of the listed blocklists have almost no effect in practice. Weigh a listing by the reach of the list (Spamhaus matters far more than obscure lists), as explained in [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). **When to use it**: a broad first check in incidents where "our mail suddenly bounces everywhere", and periodic health checks of sending domains and MX hosts. ### check.spamhaus.org (IP & Domain Reputation Checker) Spamhaus's official free checker, and the only authoritative way to check and resolve Spamhaus listings, because lookups of Spamhaus zones through third parties can be out of date or blocked. You enter an IP address, a domain or a hash. It also detects your own client IP address when the page loads, and warns you immediately if that address is listed. You do not need an account to check. The delisting workflow involves verification steps. For a listed resource, it shows which dataset lists it (SBL, CSS, XBL, PBL, DBL…), **why** it was listed, what to fix so that the listing does not recur, and a guided removal request. CSS listings have a dedicated troubleshooting step that requires sending practices compliant with RFC 5321 and 5322 before removal. Removal is always free, and paid "delisting services" are scams. **When to use it**: immediately after any bounce that mentions Spamhaus (for example `554 … found in the Spamhaus blocklist. See https://check.spamhaus.org/`), and proactively when you bring new IP addresses into service (to find listings from previous users, and the PBL status of the range). For full detail on zones and return codes, see [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). ## Where each tool fits in a deliverability workflow | Stage | Tools | |---|---| | **Bringing new IP addresses or domains into service** | First check.spamhaus.org (inherited listings, PBL status), then Google CheckMX and internet.nl (records and standards correct), then aboutmy.email (a live message authenticates and aligns). Do all of this before [warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up) begins | | **Before launching a campaign or template** | mail-tester.com (content, and the score from a standard filter), aboutmy.email (compliance and the weight of the rendered message) | | **Authentication change (new DKIM key, SPF edit, DMARC policy move)** | learndmarc.com and aboutmy.email, to confirm both the pass and the alignment. Google CheckMX for record syntax | | **Sudden bounces or a block incident** | Read the SMTP response first. Then check.spamhaus.org if Spamhaus is mentioned, MXToolbox Email Health for a broad check, and learndmarc.com if the rejection mentions authentication | | **Periodic audit** | MXToolbox Email Health (within the free limit of 1 check per 24h) and internet.nl. Run aboutmy.email again after any platform change | None of these tools measures whether mail actually reaches the inbox or the spam folder at real mailbox providers, or your reputation there. For that, use data from the receivers, such as Google Postmaster Tools, Microsoft SNDS and feedback loops, together with your own engagement metrics (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). # DNS Blocklists and the Spamhaus Zones > How DNSBLs work, the Spamhaus blocklists (SBL/CSS/XBL/PBL/DBL/ZRD/AuthBL/HBL, combined as ZEN), why senders get listed, how delisting works, and Spamhaus's operational deliverability guidance. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/blocklists-and-spamhaus When a widely used blocklist lists your IP address or domain, receivers across the internet can refuse your mail at the same moment. Spamhaus is the most widely consumed reputation provider in email. Mailbox providers such as Comcast, RoadRunner and Sky use commercial spam filters and reputation data from providers like Cloudmark and Spamhaus. The largest freemail providers (Gmail, Hotmail and Outlook.com, and Verizon Media, the former Yahoo and AOL) rely mostly on filtering they built themselves on their own user data, and may or may not combine it with commercial data. A listing by a widely adopted reputation provider can therefore block delivery at thousands of receiving networks at once. There are hundreds of blocklists in the industry, but only a few have broad impact. Any comprehensive tool for checking blocklists (see [Deliverability Testing Tools](https://emailmarketing.net/learn/reference/deliverability-testing-tools)) will show your IP or domain listed somewhere, so how seriously to take a listing depends on who issued it. A Spamhaus SBL listing has enormous reach, while a listing on a defunct or obscure list can be ignored. ## How a DNSBL works A DNS-based blocklist (DNSBL) publishes its listing data as a DNS zone. The receiving mail server checks a connecting IP address (or a domain seen during the transaction) with an ordinary DNS `A` record query: - **IP lists**: reverse the octets of the IP address and append the zone. To check `192.0.2.99` against ZEN, query `99.2.0.192.zen.spamhaus.org`. - **Domain lists**: append the domain to the zone, for example `example.com.dbl.spamhaus.org`. If the IP address or domain is **not** listed, the query returns NXDOMAIN. If it **is** listed, the query returns one or more addresses in `127.0.0.0/8`, and the specific return code identifies which dataset listed it and why. A single ZEN query can return several answers in one response packet, one for each dataset the IP appears in. This is why querying ZEN is equivalent to querying SBL, CSS, XBL and PBL separately, and cheaper. Receivers use the answer at different stages: | SMTP stage | What is checked | Lists used | |---|---|---| | Initial connection | The connecting IP; the reverse DNS (rDNS) domain of the connecting IP | ZEN (SBL, CSS, XBL and PBL), DBL | | SMTP transaction | HELO string, `MAIL FROM` domain | DBL, ZRD | | Content inspection (after DATA) | Domains and URLs in headers and body, file hashes | DBL, ZRD, HBL | ## The Spamhaus zones | Zone | Type | Contents | |---|---|---| | `sbl.spamhaus.org` | IP | SBL: verified spam sources, spam operations, and infrastructure that supports spam (includes CSS) | | `xbl.spamhaus.org` | IP | XBL: exploited or compromised systems (hosts infected with malware, open proxies, botnet nodes) | | `pbl.spamhaus.org` | IP | PBL: a policy list of IP space that should not send mail directly to MX servers (dynamic or residential ranges, IoT devices) | | `zen.spamhaus.org` | IP | ZEN: SBL, CSS, XBL and PBL in a single query. The recommended IP list | | `dbl.spamhaus.org` | Domain | DBL: domains with a poor reputation (spam, phishing, malware, botnet command and control (C&C), abused legitimate domains) | | `zrd.spamhaus.org` | Domain | ZRD: Zero Reputation Domains, which are domains observed to have been registered within the last 24 hours | | `authbl` (DQS) | IP | AuthBL: IP addresses taking part in credential-stuffing or brute-force authentication attacks | | `hbl` (DQS) | Hash | HBL: SHA-256 and SHA-1 hashes of malware files, cryptowallets, and email addresses and URLs seen in spam | ### Return codes A query for a listed item returns one or more of these codes: | Return code | Zones | Meaning | |---|---|---| | `127.0.0.2` | sbl, zen | SBL listing (a spam source or operation investigated manually) | | `127.0.0.3` | sbl, zen | CSS listing (automated detection of Combined Spam Sources) | | `127.0.0.4` | xbl, zen | XBL listing (compromised host) | | `127.0.0.9` | sbl, zen | SBL DROP data (netblocks hijacked or leased to spammers; never route them) | | `127.0.0.10` | pbl, zen | PBL: a range designated by the ISP itself | | `127.0.0.11` | pbl, zen | PBL: a range designated by Spamhaus | | `127.0.0.20` | authbl | AuthBL listing | | `127.0.0.30` | sbl, zen | BCL (Botnet Controller List) | | `127.0.1.2` | dbl | Spam domain | | `127.0.1.4` | dbl | Phishing domain | | `127.0.1.5` | dbl | Malware domain | | `127.0.1.6` | dbl | Botnet C&C domain | | `127.0.1.102` | dbl | Abused legitimate site: a compromised legitimate site used for spam | | `127.0.1.103` | dbl | Abused legitimate site: a spammed redirector | | `127.0.1.104` | dbl | Abused legitimate site: phishing on a hacked site | | `127.0.1.105` | dbl | Abused legitimate site: malware on a hacked site | | `127.0.1.106` | dbl | Abused legitimate site: botnet C&C on a hacked site | | `127.0.1.255` | dbl | Error: an IP address was queried against the DBL (IP queries always return "listed", to flag misuse) | | `127.0.2.2` – `127.0.2.24` | zrd | Domain age in hours since first observation (2–24 h) | | `127.0.3.2` | hbl | Email address seen in spam | | `127.0.3.10` | hbl | Malware file hash | | `127.0.3.15` | hbl | Suspicious file hash | | `127.0.3.20` | hbl | Cryptowallet seen in spam | | `127.0.3.30` | hbl | URL seen in spam | | `127.255.255.250` | any | Error: DQS key disabled | | `127.255.255.251` | any | Error: DQS key illegally used | | `127.255.255.252` | any | Error: typing error in DNSBL name | Any answer in `127.255.255.0/24` is an **error signal, not a listing**. Treat it as "do not block." ### Usage terms Use of the public Spamhaus DNSBL mirrors is free for **low-volume, non-commercial** users under the DNSBL Fair Use Policy. Commercial and high-volume users must use the subscription Data Query Service (DQS). ZEN covers IP addresses only. It provides no protection against malicious domains, which is what DBL and ZRD are for. ## Why senders get listed For a legitimate sender, as opposed to a compromised host, listings almost always trace back to problems with data, not with content: - **Spamtrap hits**: the strongest signal of poor address acquisition or list hygiene (see the spamtrap taxonomy below). - **High complaint volumes** at receivers and through feedback loops. - **Sending to purchased, rented, harvested, appended or co-registration lists.** Spamhaus's position is aligned with that of the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG): "The practice of selling, buying or sending to lists of purchased email addresses – whether B2B, B2C or other categories, is in direct violation of M3AAWG core values." Consent is not transferable, so a purchased list can never carry consent. - **High unknown-user rates** (hard bounces): the signature of a stale or fabricated list. - **Bursty, erratic volume** that looks like an infected host. - **Compromised infrastructure**: a hacked form, an open relay, stolen SMTP credentials (leading to XBL, CSS or AuthBL listings). - **Sending directly to MX servers from dynamic or residential IP space** (leading to a PBL listing, which is not an accusation of spamming, only a policy statement about that IP range). - **Brand-new domains** that send immediately after registration (listed in ZRD for the first 24 hours, which is a reason to register domains well before you first use them). ## Delisting All checking and delisting goes through the **IP & Domain Reputation Checker at [check.spamhaus.org](https://check.spamhaus.org/)**. It is free, checking needs no account, and the tool automatically detects and evaluates your client IP when the page loads. It shows which dataset lists you and why, and walks you through troubleshooting and removal. Details for each list: - **PBL**: self-service removal for end users who legitimately run a mail server on the IP. Alternatively, route mail through your provider's smarthost. Ranges designated by the ISP (`127.0.0.10`) are policy statements by the network owner. - **XBL**: self-service, after you remediate the compromised device or malware. A new listing follows quickly if the infection persists. - **CSS** (`127.0.0.3`): automated listings that largely resolve themselves. Before you request removal, you must meet the sending best practices of RFC 5321 and RFC 5322 (valid rDNS, matching HELO, and so on). The checker includes a dedicated troubleshooting step for CSS. - **SBL** (`127.0.0.2`): investigated manually. Removal requires convincing a Spamhaus researcher that the issue is resolved. Investigations frequently demand **proof of consent** (see data collection below), and ISPs and reputation providers may also require you to ask your whole list for permission again. - **DBL**: listings expire automatically once the domain stops meeting the listing criteria. Manual removal goes through the checker ("using the form does not guarantee removal"). Approved removals propagate within minutes, or within up to 24 hours for some mirrors. **Delisting is always free.** Spamhaus: "Any offer from anyone to remove any Spamhaus listing for a fee is a scam." Blocks at receivers that reference Spamhaus (for example `554 The IP address of your mail server (…) was found in the Spamhaus blocklist. See https://check.spamhaus.org/`) clear on the receiver's own schedule after the listing is removed, typically 24–72 hours after the issue that triggered them stops. ## Spamhaus's deliverability guidance (Deliverability 101) Spamhaus's "Deliverability 101" eBook is written from the reputation provider's side of the fence. Its core claim matches the [foundations of email deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability): there is no shortcut, so consistently send correctly authenticated, carefully targeted emails to an engaged audience. The sections below cover what it adds. ### What feeds reputation (in Spamhaus's model) Reputation is made up of an unknown number of variables that ISPs and reputation providers do not reveal. The known components are: | Component | Notes | |---|---| | Spamtrap hits | They expose both illegitimate senders and legitimate senders with poor data hygiene | | Complaint volumes | Receivers weight complaint counts per IP. Thresholds are secret and vary between ISPs, and a good reputation buys slightly more forgiveness | | Engagement metrics | Clicks, opens, purchases. Opens and clicks are weaker evidence since Apple Mail Privacy Protection. Spamhaus itself, like many anti-spam appliances, opens spam and follows links that are not subscription links, so an open or a click is **not** proof of consent | | Management of bounces and invalid addresses | The unknown-user rate is a primary signature of spammers | | Consistent volumes in each mail stream | ISPs care more about botnet spam than about marketing mail, and sudden changes in volume look like infected hosts. "Bursty" streams degrade even a well-established reputation at the major freemail ISPs | There is a key asymmetry, by design and with no override: **it is much easier to drive reputation down than to repair it.** IP reputation has also become less central than domain and content reputation. With the 340 undecillion addresses of IPv6, criminals burn IP addresses freely, so filters rely on domains. Inbox placement is recalculated exceptionally quickly in response to how end users react, and treatment can change from one moment to the next. Allowlisting (formerly "whitelisting") by ISPs no longer exists. ### Looking legitimate: setup checklist Intentions matter far less than behavior. Spam filters cannot tell a well-meaning sender from a spammer if the behavioral basics are missing: - Authenticate everything, with SPF and DKIM at a minimum. Keep the SPF record **as narrow as possible**, because designating the whole internet as a permitted sender invites abuse. See [DMARC](https://emailmarketing.net/learn/authentication/dmarc) for alignment rules. - **Domain strategy for the customers of an email service provider (ESP)**, from best to worst: (1) delegate a subdomain of the brand's primary domain, for example `email.customerbrand.com`; (2) `customerbrand.espdomain.com`; (3) as a last resort, a cousin domain such as `customerbrand-email.com`. If a cousin domain cannot be avoided, it must clearly relate to the brand, because phishing has made users wary of look-alike domains. - Do not use anonymized WHOIS records on sending domains. Legitimate businesses have no reason to hide their identity, and registrars that switched to privacy by default after GDPR will usually unmask a record on request. - Limit the number of distinct sending domains, because the more unique domains send the same mail, the more flags it raises. Use the primary business domain or its subdomains. - Every domain that sends email should have working `abuse@` and `postmaster@` addresses and a working website. Link and tracking domains should redirect to the primary business site. - Where possible, use contiguous IP addresses on the same network, and do not use more IP addresses than you need. Hundreds of IP addresses scattered across networks is the definition of snowshoeing (see [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation)). - ESPs should publish an acceptable use policy (AUP) and terms of service (ToS) that are easy to find and enforced, and should watch SMTP logs for unexpected bounces, temporary failures (tempfails) and anomalies in mail streams. - Reputation is established during warm-up, so plan it. Choose highly engaged recipients for the first mailings, and grow volume based on the results of each previous send (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)). ### Address acquisition and consent records For every contact, record the following, and keep the record up to date: - The date and time of signup, **in UTC** - The channel through which the address was obtained - The IP address that submitted it If an IP or domain is blocklisted and manual intervention is needed, ISPs and reputation providers often **demand this proof of consent**. Without it, resolution takes longer or fails. The records also protect you against complaints under GDPR and similar laws. Rules for forms: opt-in checkboxes must be selected voluntarily (pre-checked boxes are dishonest, and illegal in some countries). Protect forms with CAPTCHA or reCAPTCHA. Since roughly August 2016, bot abuse of unsecured signup forms has been escalating. It poisons databases (including with malicious spamtrap submissions) and amounts to a denial-of-service (DoS) attack. Acquisition methods, ranked: | Method | Verdict | |---|---| | Confirmed opt-in (COI, or double opt-in) | The gold standard. A confirmation email carries a click-to-confirm link, and without a click no marketing mail is sent. It provides provable consent, a near-zero risk of spamtraps and higher engagement | | Single opt-in | Workable but risky: uncertain intent, submissions with typos, from bots or of throwaway addresses, spamtrap poisoning, higher complaint rates, and possible blocklisting | | Opt-out | Avoid at all costs. It guarantees high bounces, complaints, spamtrap hits, ISP blocks and blocklistings. Permission cannot be acquired after the fact | | Purchased or rented lists, harvesting, appending (e-pending), co-registration or affiliate lists | Never. Consent is not transferable, and the damage is severe and long-lasting | ### Frequency, engagement, and sunset policy Set the expected frequency in the confirmation or welcome message, and keep to it. Unexpected or erratic mail drives spam reports. Spamhaus gives this example of a sunset ladder: 1. The recipient has not opened in **more than 1 week**: move them from weekly to monthly mail. 2. They have not opened in **more than 1 month**: send a "do you wish to continue your subscription?" message with a confirmation link. 3. No response: add them to the suppression list and stop. Review engagement continuously, and segment out recipients who do not engage. The usual starting cutoff is one year of inactivity, tightened to six months and then three, depending on results. Sending in bulk to addresses that never consented is spam, and so is continually sending to addresses that have never been successfully delivered. The idea that ISPs and reputation vendors "tighten the rules" in the holiday season is a myth: nothing changes on the receiver side. Senders who reach deep into old or unengaged segments (or buy lists) for holiday revenue cause their own decline in reputation, with tempfails, deferrals, blocks and sometimes Spamhaus listings. ### Bounce handling **Hard bounce**: a permanent failure (5xx) that is not retried. If you get one, never send to that contact again: delete or suppress it. Codes that senders see frequently: | Code | Meaning | |---|---| | 550 | Non-existent email address (the vast majority of 550s mean "user unknown") | | 512 | DNS error: the recipient's domain does not exist in DNS | | 551 | User not local, or invalid address: relay denied | | 552 | Storage allocation exceeded (mailbox full, which some servers treat as permanent) | | 553 | Invalid mailbox name (malformed recipient address) | Most hard bounces in marketing are the direct result of poor data hygiene. Note that non-existent domains can later become spamtraps. **Soft bounce**: a temporary failure (4xx) that is retried. The sending system retries until the message is accepted or times out. The timeout is set on the sending side and varies by network: | Code | Meaning | |---|---| | 421 | Service unavailable or connection problem: too many simultaneous connections, a shortage of resources at the receiver, or a dip in reputation | | 450 | Mailbox unavailable: a corrupted or offline mailbox, or a refusal because of reputation or blocklisting | | 451 | Local error in processing | | 452 | Too many emails or recipients, or the server's storage limit was exceeded | Some ISPs respond to a dip in reputation with **tempfails** ("421 4.7.0 [TS01] Messages from x.x.x.x temporarily deferred due to user complaints"). Mail is deferred until either the flow stops or the reputation recovers. Do not automatically remove addresses hit by a tempfail from the list. Fix the problem with list quality instead. **ISP hard block**: a policy rejection of the whole stream, usually `554`, often with a URL to consult (for example, a Spamhaus reference). The causes are blocks on URLs or body content, missing authentication, a poor IP or domain reputation, or presence on a blocklist the receiver uses. Blocks typically clear after an arbitrary 24–72 hours once the trigger stops. Otherwise, resolve the root cause first, then open a ticket with the blocking network. **Some ISPs, notably Gmail, have no remediation channel at all.** Receivers generally escalate in this order: placement in the spam folder, then tempfails and throttling, then bounces, then hard blocks. ### Complaints and feedback loops Some causes of complaints are within your control: no real signup, expectations about frequency or content that were never set, too much mail or a sudden change in frequency, purchased lists, irrelevant content, and mailing after an unsubscribe. Remove an address immediately when it unsubscribes, whatever grace period the applicable law allows. Other causes are harder to control: recipients who simply do not remember signing up (mail them promptly after signup, because a first email weeks later is forgotten), typos in addresses collected at the point of sale, and frustrated users who report their whole inbox as spam. Reduce complaints by keeping the promise made at opt-in, offering a preference center with frequency options, never pre-checking boxes, never buying lists, and making unsubscribing trivial. Never require a login to unsubscribe, which is illegal in some places, and put the link where it is found faster than the spam button, for example at the top. The monitoring data sources are Outlook and Hotmail SNDS (mail volume, deferrals, complaint rates and trap hits per IP), Google Postmaster Tools (complaint volumes and domain reputation), and every available **feedback loop (FBL)**. Through an FBL, ISPs report user spam complaints back to the originating network in the Abuse Reporting Format (ARF), with personally identifiable information (PII) redacted. Process reports promptly and suppress complainants immediately. ### Spamtrap taxonomy Spamtraps prove a problem in data collection or hygiene, so fix the process, not the trap. Trap owners never reveal their traps. Traps are part of the secret of filtering, and bad actors who identify traps just suppress them without fixing anything. The types are: | Type | What it is | What hitting it proves | |---|---|---| | Classic or pristine | An address never given to any live user (often on wildcard domains, `*@example.com`) that starts receiving mail | A fabricated or generated list | | Seeded | Addresses deliberately scattered in places people would not look (for example, in web page source) | Scraping or harvesting, or buying from a scraper. It also catches failure to honor unsubscribes | | Typo domain | Traps at domains such as `yaaho.com`, `ynail.com`, `homail.com` | Typos at the point of entry. These domains receive real mail too, and are weighted accordingly. COI at collection prevents these hits | | Dead address | Once-valid addresses that an ISP turned off, hard-bounced for a period (often 12+ months), then silently reactivated as traps | Ignoring hard bounces, or stale lists | | Live | Addresses of real users whose unsolicited mail is used for blocking decisions | Sending unsolicited mail. Dangerous when the owner has connections | | Domain registration or role addresses (a subset of live traps) | `postmaster@`, `abuse@`, `admin@` and addresses published in WHOIS | Harvesting. These should almost never be on a marketing list | ### Legal context (consult counsel; there are email and data-protection laws in at least 77 countries) - **CAN-SPAM (US)**: federal. The Federal Trade Commission (FTC) has successfully sued violators. - **CASL (Canada)**: applies if mail goes to a Canadian domain or a Canadian user, or passes through Canada. - **GDPR (EU, in force 2018-05-25)**: covers residents of the EU and the EEA, and transfers of data out of them. Fines are severe, and consent records materially reduce exposure. - **CCPA (California, effective 2020-01-01)**: rights to know, to delete, to opt out of sale, and to non-discrimination. People under 16 need to give opt-in consent, and those under 13 need parental consent. # Email Abuse Taxonomy > The classification layer for the abuse cluster — one entry per abuse type with definition, victim, the detection signals an ESP sees, the typical actor (intentional customer vs compromised customer vs external), and which KB article owns the response. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/email-abuse-taxonomy When an abuse report reaches your desk, the first job is to classify it: **what kind of abuse is this, who is the victim, and who is the actor?** Those three answers decide which playbook you follow. Each entry below defines one abuse type, names its victim, lists the detection signals you can see from the ESP's side (not the receiver's), identifies the typical actor, and links to the guidance for the response. For triage priorities and the remediation loop itself, see [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk). ## The actor axis The same outbound symptom, spam pouring out of your IP addresses, has four very different causes, and each needs a different response. Getting the actor wrong is the most expensive mistake in triage: | Actor class | Description | Response posture | |---|---|---| | **Intentional customer** | The account holder is the abuser: they signed up to abuse, or drifted into it | Enforce: suspend or terminate. Fraudulent accounts get **no data retrieval and no tip-off** ([Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk)) | | **Compromised customer** | A legitimate account under an attacker's control (through credentials, an API key or a hacked content management system) | Recover: contain the abuse, return the account to its owner, and secure it against a new compromise ([Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts)) | | **Negligent customer (conduit)** | The customer is not sending abuse, but an unprotected asset of theirs (a form, a script, careless list buying) makes them a channel for it | Educate the customer and require controls. Escalate to enforcement if they refuse to fix the problem | | **External** | The attacker never touches a customer account. They abuse your brand, your signatures or third-party forms from outside | Monitor, report and take down. The ESP's own infrastructure may be the victim, not the source | What separates the first two is a **pattern of earlier valid use**, the test for telling compromised accounts from malicious ones in [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts#compromised-vs-malicious-accounts). Analyse the metrics carefully before you assume a mechanism: what looks like a compromise is often abuse of trial signups, and the reverse is also true. ## Master table | Abuse type | Primary victim | Key signals on the ESP's side | Typical actor | Guidance for the response | |---|---|---|---|---| | [Spam / UBE](#spam--ube) | Recipients, and the ESP's shared reputation | Spikes in complaints and feedback loop (FBL) reports, trap hits, blocklistings, bounce spikes | Intentional or negligent customer | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) · [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) | | [Phishing (incl. spear/BEC)](#phishing-including-spear-phishing-and-bec) | The impersonated brand and the defrauded recipients | Hostile URLs in content, takedown notices from trusted reporters or brands, hits on the phishing lists of DBL and SURBL | Intentional customer (fraudulent signup) or compromised customer | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) (P2) · [URL & Content Filtering](https://emailmarketing.net/learn/reference/url-and-content-filtering) | | [Brand spoofing / lookalike domains](#brand-spoofing-and-lookalike-domains) | The brand and its customers | DMARC reports showing unauthorized sources, and signup attempts with lookalike domains during vetting | External (or a fraudulent signup that uses the lookalike) | [Brand Protection](https://emailmarketing.net/learn/reference/brand-protection-domain-management) · [DMARC](https://emailmarketing.net/learn/authentication/dmarc) | | [Snowshoeing](#snowshoeing-ip-and-domain) | Filters and receivers, and the ESP's IP space | A customer requesting many IP addresses or domains, rotating identities, CSS listings | Intentional customer | [Spamhaus Deep Dive](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive) · [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) | | [List bombing](#list-bombing--subscription-bombing) | One targeted mailbox | Signup bursts to one address or domain across the whole platform, floods of confirmation mail | External, through negligent customers' forms | [Subscription Bombing](https://emailmarketing.net/learn/esp-operations/subscription-bombing) | | [Malware / ransomware distribution](#malware--ransomware-distribution) | Recipients' machines | Hits from attachment scanning, SURBL malware listings, urgent notices from trusted reporters | Compromised customer or fraudulent signup | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) (P2) · [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) | | [419 / advance-fee and fraud content](#419--advance-fee-and-other-fraud-content) | Recipients (financially) | Content heuristics, low volume with webmail-style sending, complaint text | Intentional customer (fraudulent signup) or compromised account ("stranded traveler") | [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) · [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) | | [Backscatter](#backscatter-generation) | The holders of forged addresses, and the ESP that bounces the mail | Outbound bounces to addresses you never sent to, listings of the Backscatterer type | Nobody: it is a misconfiguration, and an external spammer supplies the forged addresses | [Abuse Desk: backscatter](https://emailmarketing.net/learn/esp-operations/abuse-desk#backscatter) | | [DKIM replay](#dkim-replay) | The signing domain (the customer's or the ESP's) | Complaints or blocks for mail you have no record of sending, and one message ID seen at huge scale by receivers | External (needs only one signed message) | [DKIM Replay Attacks](https://emailmarketing.net/learn/authentication/dkim-replay) | | [Account takeover / compromised sending](#account-takeover--compromised-sending) | The customer, then everyone who shares the infrastructure | A break from the account's usual behavior: new location or user agent, sudden volume, new content or recipients | Compromised customer | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) | | [API-key abuse](#api-key-abuse) | The customer, and shared pools | Unusual sending through the API with no dashboard logins, intelligence about leaked keys, a new API integration just before a spike in trap hits or complaints | Compromised customer (leaked credential) | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) · [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) | | [Affiliate spam](#affiliate-spam) | Recipients, the advertiser's brand, and the ESP's reputation | Vetting answers (programs managed by third parties), content full of redirectors, complaint rates far above the customer's own streams | Intentional or negligent customer (through affiliates) | [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) · [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) | | [Cold email / consent-less outreach](#cold-email--consent-less-outreach) | Recipients, and the ESP's reputation | Bulk mail in small "personalized" batches, purchased B2B lists, volume split on purpose across accounts or domains | Intentional customer (often one who describes itself as legitimate) | [M3AAWG Position on Cold Email](https://emailmarketing.net/learn/reference/cold-email-position) | | [Harvesting / scraping](#harvesting--scraping) | Address owners, then whoever mails the list | Visible before the ESP sends: uploaded lists full of role accounts, traps and invalid addresses | External harvester, with an intentional or negligent customer as the buyer | [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) · [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps) | | [Open relay / proxy abuse](#open-relay--proxy-abuse) | The whole receiving ecosystem, and the relay operator | Traffic from third parties passing through customer infrastructure, SBL or XBL listings of customer hosts | External abuser exploiting a negligent customer's misconfiguration | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) · [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) | | [SMS / messaging ridealong](#sms--messaging-ridealong) | Message recipients on the other channel | Scripted abuse of features that send web messages to SMS or notifications, unusual volume for a single feature | External, through scripting, or a compromised account | [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) (material from the Web Messaging BCP) | ## Spam / UBE **Definition** (Spamhaus): **Unsolicited Bulk Email.** *Unsolicited* means the recipient has not granted verifiable permission. *Bulk* means the message is part of a larger collection of substantively identical messages. Both conditions must hold: "spam is an issue about consent, not content." Spam is the parent category. Most other types listed here are spam with an aggravating characteristic, such as deception, malware or fraud. - **Victim**: the recipients. Because ESPs are judged on their overall traffic, every other customer on shared IP addresses or domains is also a victim ([Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)). - **ESP signals**: spikes in the FBL complaint rate, [spam-trap hits](https://emailmarketing.net/learn/reference/spam-traps), rising rejections and deferrals at major receivers, [blocklistings](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus), and unusual bounce profiles when a list is imported. For thresholds and corrective actions, see [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks). - **Actor**: an intentional customer (bought lists, no consent) or a negligent customer (list hygiene that has decayed). Tell it apart from a compromise by comparing with the account's usual behavior. - **Response**: the remediation loop in [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk): validate the report, notify the customer citing the terms of service, remediate, suspend, terminate. Prevent it through [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting). For incidents driven by spam traps, see [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response). ## Phishing (including spear phishing and BEC) **Definition**: mail that impersonates a trusted party to steal credentials, payment data or money. **Spear phishing** targets specific individuals with researched pretexts. **Business email compromise (BEC)**, as the FBI's Internet Crime Complaint Center (IC3) describes it, is the sophisticated end: the attacker impersonates an employee, a vendor or an executive (through spoofing, lookalike domains or a mailbox that has actually been compromised) to trigger fraudulent transfers of funds. The Anti-Phishing Working Group (APWG) describes it as impersonating a trusted party to trick an employee into sending money or privileged assets. BEC often involves no malicious URL or attachment at all. It is pure social engineering, which content filters cannot catch. - **Victim**: two victims, the impersonated brand (damage to its reputation, and DMARC problems) and the defrauded recipient. - **ESP signals**: hostile or deceptive URLs in customer content (hits on the phishing list of SURBL, or on Spamhaus DBL and HBL; see [URL & Content Filtering](https://emailmarketing.net/learn/reference/url-and-content-filtering)), and takedown notices from brand-protection firms and trusted reporters. On the hosting side, look for phishing kits on customer sites: the Hosting Abuse BCP notes that phishing is almost always run through compromised end-user accounts with outdated scripts. Pure BEC rarely passes through an ESP in volume, because it is low-volume and targeted. Credential-phishing campaigns against your own customers, run to set up account takeovers, certainly do. - **Actor**: a fraudulent signup (intentional) or a compromised customer account or site. The actor is external when only your brand is imitated (see the next entry). - **Response**: P2 in the [abuse desk priority tiers](https://emailmarketing.net/learn/esp-operations/abuse-desk#complaint-priority-tiers-hosting-abuse-bcp), because malicious activity ranks above spam. Suspend the sending mechanism immediately, then decide whether the account is compromised or fraudulent. Phishing aimed at your customers to collect their ESP credentials feeds into [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). ## Brand spoofing and lookalike domains **Definition**: an external attacker sends mail as a brand without touching the brand's infrastructure. The attacker either spoofs the exact domain (a forged From address, which an enforced [DMARC](https://emailmarketing.net/learn/authentication/dmarc) policy defeats) or uses **cousin or lookalike domains** (typos, added terms such as "-login", other top-level domains). A lookalike domain authenticates perfectly as itself, and so passes DMARC without trouble. - **Victim**: the brand and its recipients. The ESP is also a victim when its own brand, or its customers' domains, are imitated to phish credentials. - **ESP signals**: DMARC aggregate reports from customers that show unauthorized sources ([DMARC Aggregate Reports](https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports)), signups during vetting that use lookalikes of known brands (a classic sign of a fraudulent signup; see [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting)), and hits from certificate transparency and domain registration monitoring. - **Actor**: external. In the variant an ESP sees, a fraudulent customer registers the lookalike domain and asks you to authenticate it. This is why [customer domain authentication](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication) checks belong in onboarding. - **Response**: [Brand Protection and Domain Management](https://emailmarketing.net/learn/reference/brand-protection-domain-management) covers the domain inventory, defensive registration, monitoring and the takedown paths. DMARC enforcement handles spoofing of the exact domain. ## Snowshoeing (IP and domain) **Definition** (Spamhaus): spreading spam thinly across **many IP addresses and domains** to dilute the reputation of each identity and stay under filter thresholds. It uses "ranges and domains with poor or frequently changing identification," and the spammer uses the IP addresses legitimately (they are not botnets). The domain variant rotates newly registered domains in the same way. - **Victim**: filters and receivers, which the spammer evades. The ESP is also a victim, because its IP space and its tools for delegating domains are consumed, and so are its other customers when CSS listings hit shared ranges. - **ESP signals**: during vetting, prospects who request an unusually large number of IP addresses or sending domains for their volume, anonymized WHOIS records, many previous ESPs, and any hint of changing infrastructure to evade a listing (an explicit warning sign in the [Vetting BCP](https://emailmarketing.net/learn/esp-operations/customer-vetting)). In operation, frequent domain changes, sending that stops and starts to spread metrics across platforms, and [Spamhaus CSS](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive#css--combined-spam-sources-127003) listings ("many frequently-changing domains is itself the signal"). - **Actor**: an intentional customer, by definition. Snowshoeing is a deliberate setup and never an accident. - **Response**: see the [Spamhaus Listings Deep Dive](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive) for how the listing works and how to get delisted. Terminate rather than remediate, because a snowshoe operation has no legitimate configuration to restore. Prevent it through vetting and a model of tiered rights, in which new accounts do not get large sets of IP addresses or domains. ## List bombing / subscription bombing **Definition**: a denial-of-service (DoS) attack against one mailbox. A script submits the victim's address to thousands of unprotected signup forms, and the flood of legitimate confirmation and welcome mail buries the inbox, often to hide notifications of fraud. - **Victim**: the owner of the targeted mailbox. Secondary victims are the form owners (their lists are poisoned and receive trap submissions) and the ESP (Spamhaus listed ESP sending IP addresses during the 2016 wave). - **ESP signals**: unusual signup rates to a single address or domain across many customers' forms on the platform, floods of confirmation messages to one address, and a sudden start with no gradual ramp. - **Actor**: an external attacker. Customers with unprotected forms are negligent conduits. - **Response**: [Subscription Bombing & Signup-Form Abuse](https://emailmarketing.net/learn/esp-operations/subscription-bombing) gives the full playbook: detection signatures, requirements for CAPTCHA and confirmed opt-in (COI), suppression of each targeted address during an attack, and coordination across the industry. ## Malware / ransomware distribution **Definition**: mail that delivers malicious payloads, either as attachments (droppers, documents with macros) or as links to sites that host exploits or downloads. This includes the delivery of ransomware and recruitment into botnets. - **Victim**: the recipients' machines and organizations. The ESP's reputation collapses quickly, because distributing malware triggers the harshest responses from receivers and blocklists. - **ESP signals**: hits from scanning outbound attachments for malware (the Web Messaging BCP says to restrict the types of files that can be uploaded and to scan them for malware), SURBL malware or Spamhaus HBL hits on linked domains, and urgent notices from trusted reporters and computer emergency response teams (CERTs). On the hosting side, look for malware placed on customer sites (P2 in the hosting tiers). - **Actor**: rarely a deliberate ESP customer, since mainstream ESP tools are a poor channel for malware (attachments are limited and content is inspected). Usually the actor is a compromised customer site or account, or a fraudulent signup abusing free-tier sending. - **Response**: P2 in [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk). Stop sending immediately, with no remediation window for the traffic itself. Then decide whether the account is compromised or fraudulent, as described in [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). For detection in content, see [URL & Content Filtering](https://emailmarketing.net/learn/reference/url-and-content-filtering). ## 419 / advance-fee and other fraud content **Definition**: fraud in which the content itself is the crime. Examples are advance-fee fraud (called "419", after the section of the Nigerian Criminal Code on fraud), which promises a large payoff for an upfront fee; lottery and inheritance scams; fake jobs and overpayment fraud; romance scams that develop over time; and the "stranded traveler" plea, sent from a hijacked account to its own contacts. - **Victim**: the recipients, financially. The volume is usually low compared with UBE. What makes this type serious is the harm each message can do. - **ESP signals**: content heuristics and long-lived filter signatures (these scams are decades old and their wording barely changes), complaint text that describes the scam, and low-volume accounts sending mail styled as personal messages to scattered recipients. For the stranded-traveler variant, look for an established account that suddenly mails its whole contact list. - **Actor**: an intentional fraudulent signup, or a compromised account for the customized variants. The [Compromised User ID BCP](https://emailmarketing.net/learn/esp-operations/compromised-accounts#containment-and-remediation-compromised-user-id-bcp) classes stranded-traveler scams as "permanent credential, customized exploit," which always need human intervention. - **Response**: triage in [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk). Fraud reports can also arrive through law enforcement, and those outrank spam in the queue. Fraudulent accounts are terminated without the courtesy steps. ## Backscatter generation **Definition**: misdirected bounces. A server accepts a message with a forged return address and then bounces it to that innocent address, instead of rejecting the message during the SMTP session. In volume, the bounces are themselves UBE, and the operator that sends them gets blocklisted. - **Victim**: the holders of the forged addresses (often the real users of a spoofed brand), then the ESP that generates the bounces, through blocklists focused on backscatter and through reputation damage. - **ESP signals**: outbound delivery status notifications (DSNs) or auto-replies to addresses you never delivered mail to, complaints about "bounces for mail I never sent", and listings on DNSBLs that target backscatter. - **Actor**: none in the usual sense. Backscatter is a **misconfiguration**: accepting mail and bouncing it later, autoresponders without safeguards, or challenge-response systems. The external spammer who forges your customers' addresses supplies the trigger but never touches your systems. - **Response**: [Abuse Desk: backscatter](https://emailmarketing.net/learn/esp-operations/abuse-desk#backscatter) describes the mitigations: reject during the SMTP session, Bounce Address Tag Validation (BATV), suppress bounces based on SPF, and clean the queue. For how bounces work, see [DSNs](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications). ## DKIM replay **Definition**: an attacker obtains one message with a legitimate DKIM signature (for example, through a free trial or a signup confirmation sent to a mailbox the attacker controls) and sends it again, unchanged, to millions of recipients. Every copy carries a valid signature, so the reputation of the `d=` domain is spent on mail that the domain never sent to those recipients. - **Victim**: the signing domain. That is the ESP itself when customers sign with domains the ESP shares among them, or otherwise the customer's own domain. The recipients are secondary victims of the spam. - **ESP signals**: the defining anomaly is **reputation damage with no matching sending records**. You receive complaints and blocks for messages, recipients or volumes that do not appear in your logs, see a single Message-ID at huge scale in receiver feedback, or see domain reputation collapse on a stream whose own metrics look clean. - **Actor**: external. The attacker only needs to receive one signed message, and a free-tier signup is enough. This is why replay is specifically an attack on ESPs with self-service trials. - **Response**: [DKIM Replay Attacks](https://emailmarketing.net/learn/authentication/dkim-replay) covers the mitigations and their tradeoffs: a short `x=`, separate selectors and keys for each stream, oversigning, and controls on trial accounts. Key hygiene is covered in [DKIM Key Rotation](https://emailmarketing.net/learn/authentication/dkim-key-rotation). Vetting trial signups limits the attacker's access to freshly signed mail ([Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting)). ## Account takeover / compromised sending **Definition**: a legitimate customer account that is fully or partly under unauthorized control (a "compromised user account" in the words of the Compromised User ID BCP). The attacker uses it to send spam, phishing or fraud through the reputation the customer has earned and through the ESP's infrastructure. - **Victim**: first the customer (its reputation, data and contacts), then every tenant that shares its IP addresses or domains, then the recipients. - **ESP signals**: a **break from the account's own usual behavior**. Examples are logins from new locations or from places too far apart to travel between, unfamiliar user agents, sudden changes in volume or in the set of recipients, new kinds of content, deleted sent mail, and changed forwarding or reply-to settings. Other signals are a surge of FBL complaints on an account with a clean history, and intelligence from credential dumps that names customer email addresses. - **Actor**: a compromised customer, by definition. The test for a pattern of earlier valid use separates this from abuse at registration. - **Response**: [Compromised Accounts & Outbound Abuse](https://emailmarketing.net/learn/esp-operations/compromised-accounts) covers the whole lifecycle: detection feeds, the mitigations for the four types of compromise, forcing users to authenticate again, and handling repeat compromises. Reports often arrive through the [abuse desk](https://emailmarketing.net/learn/esp-operations/abuse-desk). For how FBLs work, see [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). ## API-key abuse **Definition**: abusive sending through stolen or leaked API credentials rather than through an interactive login. The keys may have been committed to public repositories, taken from compromised customer servers, or phished. API-key abuse is a subtype of account takeover (ATO) with its own detection profile. It is listed separately because API traffic bypasses the login anomalies that most ATO detection relies on. This split reflects the practice of sending platforms (vendor security guidance on revoking leaked keys, and secret scanning of the kind GitHub offers), not a category formally defined by M3AAWG. - **Victim**: the customer that owns the key, and the shared infrastructure. - **ESP signals**: sending through the API with no matching activity in the dashboard, new source IP addresses or ASNs on the API path, notifications from secret scanning (keys leaked in public repositories), and a new or changed API integration just before a spike in trap hits or complaints. [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response#4-re-vetting-the-customer) lists that last signal explicitly as a reason to vet the customer again. Volume patterns unlike the integration's history are another signal. - **Actor**: a compromised customer (leaked credential). Distinguish this from an intentional customer who scripts abuse through their own key, which is ordinary spam sent over an API. - **Response**: [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). This applies the "temporary or permanent credential" model to machine credentials. Revoke the key immediately (a password reset is not enough, because the key survives password changes), issue replacement keys with limited scope, and audit what the key touched. To prevent it across the platform, give new accounts tiered rights, with API access restricted until tenure and reputation justify more ([Customer Vetting, fraud-prevention practices](https://emailmarketing.net/learn/esp-operations/customer-vetting#fraud-prevention-practices-hosting-abuse-bcp)), and enforce limits for each tenant to contain the damage ([Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture)). ## Affiliate spam **Definition**: spam sent by third-party affiliates who promote a customer's or an advertiser's offer for a commission. The advertiser may be entirely legitimate. The abuse comes from affiliates whose lists and methods nobody vetted. The Vetting BCP identifies this category as a historical source of abuse, and notes that programs a company runs itself are riskier than those run by reputable third-party networks. - **Victim**: the recipients (who never consented to the actual sender), the advertiser's brand, and the ESP if either the affiliate mail or the traffic to the promoted landing pages touches its infrastructure. "Spamvertising on network" has its own line in the hosting abuse tiers. - **ESP signals**: vetting answers that admit to affiliate programs, content full of redirectors and tracking chains that lead to third-party offers ([URL & Content Filtering](https://emailmarketing.net/learn/reference/url-and-content-filtering) covers redirectors), complaint and trap rates far above those of the same customer's streams to its own list, and Spamhaus DBL listings of the promoted domains even when your sending IP addresses stay clean. - **Actor**: an intentional customer (who knowingly buys traffic driven by spam) or a negligent customer (who runs a program without policing its affiliates). The affiliates themselves are outside the relationship with the ESP, and that gap in accountability is exactly what makes the category dangerous. - **Response**: [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) (extra scrutiny at onboarding, and questions about how the program is managed). [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) explains why affiliate lists produce complaint profiles close to those of purchased lists. Enforce through the standard abuse desk loop, and hold the customer answerable for its affiliates. ## Cold email / consent-less outreach **Definition** (M3AAWG, Nov 2025): unsolicited email from senders who are *otherwise legitimate and identifiable*, seeking a business relationship with recipients who have **no prior relationship, connection or consent**. It is sent with deceptive tactics to imitate one-to-one mail: small randomized batches, lookalike or throwaway domains, and technically valid authentication used as camouflage. M3AAWG's position is that cold email delivered deceptively **is spam**. M3AAWG's *Sender Best Common Practices* (Version 4.0, August 2026, section 4.5) summarizes the position more broadly: it describes cold email as abusive without the qualifier about deceptive delivery, and refers readers to the position paper for the full details. - **Victim**: the recipients, and the ESP. Cold email operations deliberately spread volume across accounts, subdomains and providers to avoid detection. They use up shared reputation and, at the account level, look much like snowshoeing. - **ESP signals**: many small "personalized" sends built on the same template, purchased or scraped B2B lists (role accounts, no evidence of opt-in), rapid creation of domains or subaccounts, integrations with sending tools marketed for "outbound sequences", and complaint rates that are modest in absolute terms but extreme for the volume. - **Actor**: an intentional customer, usually one who sincerely argues that the mail is legitimate. That is why the [M3AAWG position](https://emailmarketing.net/learn/reference/cold-email-position) exists: it gives abuse desks an industry consensus answer to "but it's not spam, it's sales outreach." - **Response**: [M3AAWG Position on Cold Email](https://emailmarketing.net/learn/reference/cold-email-position) sets out the argument about the definition and the detection indicators. Enforcement is driven by policy (a prohibition in the acceptable use policy, and screening during vetting) through [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) and the [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk). For why consent cannot be transferred, see [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods). ## Harvesting / scraping **Definition**: collecting email addresses without consent, by crawling websites, scraping platforms and breach dumps, or generating addresses from dictionaries, to build or sell lists. The abuse an ESP encounters comes later: a customer mailing a harvested list. - **Victim**: the address owners, then the customer who mails the list and the ESP. Harvested lists are full of [pristine spam traps](https://emailmarketing.net/learn/reference/spam-traps) (planted precisely to catch harvesters), invalid addresses and role accounts. - **ESP signals**: at list import, a high share of role accounts, implausible spreads of domains, and no opt-in metadata. At the first send, high hard-bounce rates together with pristine trap hits. That combination is the signature, since pristine traps point almost uniquely to harvested or purchased data. Another signal is a customer who cannot produce evidence of opt-in for addresses you spot-check (the [audit technique used in trap incidents](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response#investigating-opt-in-claims)). - **Actor**: the harvester is external. The actor the ESP has to deal with is the intentional or negligent customer who bought or scraped the list. - **Response**: [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) places harvesting at the bottom of the range of acquisition methods, and every acceptable use policy prohibits it. [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps) and [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) cover the incident that reveals it. CAN-SPAM increases the penalties for sending to harvested lists ([CAN-SPAM](https://emailmarketing.net/learn/compliance/can-spam)). ## Open relay / proxy abuse **Definition**: third parties route mail through infrastructure that should not relay it for them. The classic case is an SMTP server that accepts mail from anyone to anyone (an **open relay**). Modern equivalents are open proxies, hacked webmail or PHP mailer scripts, and misconfigured cloud instances that relay without authentication. - **Victim**: the whole receiving ecosystem, because the relay hides where the abuse came from, and the relay operator, whose IP addresses get listed. Spamhaus lists them on the SBL or XBL, and the PBL exists precisely because end-user IP space should not send mail directly to mail exchangers ([Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)). - **ESP signals**: this is mostly a category for hosting providers. Look for customer virtual or dedicated servers sending mail that never passed through the ESP's submission path, anomalies in traffic analysis during network self-scans, blocklistings of customer host IP addresses, and complaints that attribute mail to customer infrastructure the customer does not recognize. - **Actor**: an external abuser exploiting a negligent customer's misconfiguration or unpatched software. This is the core scenario of the Hosting Abuse BCP, where outdated content management systems and scripts are the main route to compromise. - **Response**: the baseline for preventing abuse at hosting providers in [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) (contractual requirements to patch, web application firewalls (WAFs), and a separate IPv6 address range for each customer so that blocks can be precise), the remediation loop in [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk), and how delisting works in the [Spamhaus Listings Deep Dive](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive). ## SMS / messaging ridealong **Definition**: abuse of messaging features other than email on platforms close to email, such as gateways from the web to SMS, e-card and invitation senders, "share this article" features, in-app notification and comment systems, and REST messaging APIs. The M3AAWG Web Messaging BCP treats these and webmail as one attack surface. Any feature that relays content supplied by a user to a recipient the user chooses will be scripted for spam once filtering on the email path makes it the cheaper channel. - **Victim**: the recipients on the other channel. SMS spam costs more and intrudes more per message than email, and carriers penalize the platform severely. The platform's relationships with carriers and aggregators play the role that blocklists play in email. - **ESP signals**: unusual volume for a single feature (messages sent, invitations issued) compared with the audited resource baselines that the Web Messaging BCP prescribes, patterns of registration abuse feeding the feature, identical payloads across many accounts, and short messages full of URLs. - **Actor**: external, through scripted signups, or compromised accounts. The actors are the same as for email abuse: the channel differs, but the playbook does not. - **Response**: [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts). The three layers of defense in the Web Messaging BCP (access to the user interface, content filtering and distribution controls) were written for exactly this surface. Apply rate limits to "almost all web services accepting or relaying user-generated content." Compliance regimes on the carrier side (for example, 10DLC registration in the US) are outside the email scope of this reference. The entry is here because the abuse arrives through the same accounts and forms that the email side polices. ## Using the taxonomy For a report that has not been classified yet, follow this sequence: 1. Identify the abuse type from the signals above. 2. Place it in the [abuse desk priority tiers](https://emailmarketing.net/learn/esp-operations/abuse-desk#complaint-priority-tiers-hosting-abuse-bcp). Child sexual abuse material (CSAM) and threats outrank everything, and malicious activity (phishing, malware) outranks spam. 3. Identify the actor class before you choose between recovery and enforcement. The courtesy steps you owe a compromised customer are exactly the steps you must deny a fraudulent one. 4. Hand the case to the guidance for that type. Several types often occur together: account takeover leading to phishing, harvesting leading to spam and then a trap incident, or a fraudulent signup leading to snowshoeing. Classify the case by the mechanism you must shut off, not by the content you observed. # M3AAWG Position on Cold Email (Nov 2025) > The industry-consensus stance — deceptive delivery of unsolicited "cold email" is an abusive practice; full definition, deceptive-tactic list, detection indicators, and the non-transferability of consent. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/cold-email-position If a customer argues that its cold outreach is sales, not spam, the industry's answer is clear: sending unsolicited email with deceptive delivery methods is abuse. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), whose members include the major mailbox providers, set out that position in a one-page statement. The statement is *M3AAWG Position on Cold Email*, November 2025, Version 1.0 (M3AAWG-154; reference URL m3aawg.org/M3AAWGPositionOnColdEmail). It is the industry's explicit position on "cold outreach", and it focuses on **deceptive practices used to deploy cold-email communications that mimic or appear to be one-to-one communications, but in reality are considered spam.** ## Definition > In email marketing terms, a "Cold Email" is an unsolicited email from otherwise legitimate, identifiable senders that tries to create a business relationship, a sale, a business opportunity, or other professional benefit from a **recipient who has no prior relationship, connection, or consent with the sender or business**. Note that the senders are described as "otherwise legitimate, identifiable". The position is not about criminal spam operations. What defines cold email is the absence of any prior relationship, connection or consent. ## Deceptive tactics the position targets To look personally related to the recipient and appear to be one-to-one messages, cold emails sent in bulk often use: - Authentication (SPF, DKIM and DMARC, technically compliant but used as camouflage) - Opt-out links - Personalization (first name, job title, company name, and so on) - Other content generated by AI Misleading delivery methods, used to avoid detection by spam filters: - Sending at random intervals - **Lookalike domains**, which resemble legitimate domains but are actually unrelated (M3AAWG's example: `paypal-security.com` for `paypal.com`) - Multiple sending accounts > **The practice of using or facilitating deceptive delivery methods to mask Cold Emailing is in direct violation of core M3AAWG values.** ## Detection indicators The reputation metrics that indicate a sender is sending cold email include, but are not limited to: | Indicator | Where to read more | |---|---| | Detection in spam traps | [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps) · [Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) | | Blocklisting | [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) | | High numbers of hard bounces for unknown users | [DSNs](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) | | High complaint rates | [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops) | ## Particularly egregious practices Any attempt to do the following "are particularly egregious and are not acceptable in any manner": - Get around limits on mail volume - Avoid spam filters - Hide sending domains - **Simulate subscriber engagement artificially** (for example, with tools that fake warm-up or engagement) - Use other tools or services that exploit loopholes at mailbox providers or cloud platforms ## Consent cannot be transferred between channels M3AAWG's position is that **the specific form of consent received to market to an individual is not transferable between marketing channels**. Its example: consent to be contacted or marketed to by telephone does not give the business consent to contact that person by cold email. ## The position > **M3AAWG's position is that using deceptive and misleading delivery methods to send unsolicited email (including Cold Email) is an abusive practice.** M3AAWG's *Sender Best Common Practices* (Version 4.0, August 2026, section 4.5) summarizes this position in one paragraph, and its wording is broader than the position paper. The summary says M3AAWG views cold email itself as abusive, without the qualifier about deceptive or misleading delivery methods. It then refers readers to the Position on Cold Email for the full details. If you read both, the position paper is the document the summary points to. ## What this means for an ESP - Cold email may be legal in some jurisdictions (for example, under the opt-out regime of CAN-SPAM; see [CAN-SPAM](https://emailmarketing.net/learn/compliance/can-spam)). But the industry body that includes the major mailbox providers classifies cold email delivered deceptively as **abuse**, not marketing. Being legal does not make mail deliverable or acceptable. - The list of detection indicators also works as a checklist for vetting and monitoring. Trap hits, blocklistings, bounces for unknown users and complaints, together on one customer's stream, are the fingerprint of cold email. - Customers who rotate domains, use lookalike domains, run farms of mailbox accounts, randomize their sending schedule or use services that simulate engagement ("warm-up" services) fall under the "particularly egregious" clause. - The position is **in addition to and inclusive of** all other M3AAWG best practice guidance. It builds explicitly on the *M3AAWG Position on Selling Email Address Lists* (m3aawg.org/SellingEmailLists) and the *M3AAWG Position on Email Appending* (m3aawg.org/AppendingPosition). Selling lists and appending email addresses were already condemned, and this position applies the same stance to the way cold outreach is delivered. ## Related articles - [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) - [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability) - [M3AAWG Senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) # OECD Anti-Spam Toolkit (2006) > The OECD's cross-border anti-spam policy framework: eight elements, the Council Recommendation on enforcement co-operation, and the BIAC/MAAWG ISP and email-marketing best practices. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/oecd-anti-spam-toolkit If you need to compare national anti-spam laws, or to understand how enforcement authorities in different countries work together, the Organisation for Economic Co-operation and Development (OECD) Anti-Spam Toolkit is the closest thing to an internationally agreed reference design for national anti-spam policy. The **Anti-Spam Toolkit of Recommended Policies and Measures** was produced by the **OECD Task Force on Spam**, which the OECD Council approved in 2004 and whose mandate ended in June 2006. The ICCP and CCP committees declassified the Toolkit on 29 March 2006. The OECD Council adopted the accompanying **Council Recommendation on Cross-Border Co-operation in the Enforcement of Laws Against Spam** on **13 April 2006**. The OECD then had 30 member countries, and the Recommendation also invites non-member economies to take account of it. The Toolkit is a **policy and enforcement framework**. It does not itself impose obligations on senders. It includes two industry best-practice documents as Annexes: one from BIAC and MAAWG for ISPs, and one from BIAC for email marketers. ## What still holds and what is dated The Toolkit predates mature SPF, DKIM and DMARC, the 2024 bulk-sender requirements from Gmail and Yahoo, mobile-first messaging, and modern reputation systems. Its **technical** sections (Element IV) refer to SPF, "DKIM/META", Sender-ID, greylisting, BATV and SES, and PTR checks. These are of historical interest, and current practice is covered in dedicated articles on each topic. What remains **directly useful today** is the framework for policy and cross-border enforcement: the checklist for designing legislation, the types of consent, the reasoning about who is liable, the model for enforcement co-operation, and the best-practice lists for ISPs and senders, which the M3AAWG documents later expanded. Use the Toolkit for the framework, and the linked references for current technical practice. ## The eight elements The Toolkit is organised around eight related elements of a comprehensive public-policy framework: | # | Element | Core proposition | |---|---|---| | I | **Regulatory approaches** | Clear, simple anti-spam legislation that sets out what is and is not allowed | | II | **Enforcement** | Empowered authorities, fast sanctions, cross-border co-operation | | III | **Industry-driven initiatives** | Self-regulation, codes of conduct, and acceptable use policies that work together with the law | | IV | **Technical measures** | Layered anti-spam tools. No single method is enough on its own | | V | **Education and awareness** | Educate both recipients and senders. Target users, groups and small and medium-sized enterprises (SMEs) | | VI | **Co-operative partnerships** | Public-private collaboration in design and enforcement | | VII | **Spam metrics** | Measure the effectiveness of policy and technical measures (the MAAWG Email Metrics Program is noted) | | VIII | **Global co-operation (Outreach)** | Extend the framework to non-OECD economies, with bilateral and multilateral aid | ## Element I: Regulatory design Legislation should aim to **preserve the benefits of electronic communication**, to **prohibit and sanction spamming as defined by national law**, and to **reduce the amount of spam** by targeting different stages of sending. The value of legislation depends on the certainty that sanctions will be applied. Four general legislative principles: - **Policy direction**: set out the main objectives early. They should underlie the whole strategy. - **Regulatory simplicity**: the legislation should be short and simple. - **Enforcement effectiveness**: pair the law with an effective system of sanctions, appropriate standards of proof, and authorities with resources. Poor enforcement makes good legislation useless. - **International linkages**: spam crosses borders, so plan for co-operation and information exchange with foreign authorities. ### Legislative best-practice checklist The Toolkit's table for the regulatory element is a useful design checklist for any jurisdiction that is drafting or comparing anti-spam law: | Issue | Recommended approach | |---|---| | **Services concerned (scope)** | Choose a technology-specific law (aimed at the media that cause problems today) or a technology-neutral one (flexible and future-proof). Real-time voice could be regulated separately. | | **Commercial purpose** | Decide whether the law covers only commercial and transactional messages, or also non-commercial ones (political, religious). Specific categories may be expressly excluded (for example, academic institutions writing to their alumni). | | **Consent** | Three approaches, often combined: **expressed** (active permission, which is opt-in); **inferred or implicit** (from conduct or an existing business relationship); **assumed** (presumed until withdrawn, which is opt-out). | | **Unsubscribe address** | Messages should carry a working opt-out. This implies a **valid return address**, and a **postal address** may also be required. Leaving these out, or failing to stop sending within the legal period, should be sanctionable. | | **Information about message origins** | Prohibit falsified or concealed headers and sender identification. Require the marketer behind the sender to be clearly identified. | | **Not bulk** | Email may be classified as spam only above a volume threshold, **typically 50–100 messages over 24 hours**, so that legitimate bulk mail such as newsletters is not caught. | | **Labelling** | The law may require a specific label for advertising or pornographic content. | | **Person authorising or benefiting** | Sanction not only the person who physically sends, but also whoever commissioned or authorised the sending or profited financially from it. That person is easier to identify, which helps enforcement. | | **Harvesting and dictionary attacks** | Add sanctions where address-harvesting software, harvested lists, or automatic address generation are used. | | **Illegal access** | Forbid the unauthorised use of protected computer resources (compromised machines used to send). | | **Misleading or fraudulent content** | Scams and phishing may be ordinary computer-related crimes. Anti-spam law may add bans on deceptive subject headings and work together with anti-fraud and consumer law. | | **Security threats (malware)** | Often made a crime by statute or through the **Council of Europe Convention on Cybercrime**. | | **Cross-border jurisdiction** | Cover messages sent to or from the jurisdiction, and messages commissioned from within it or benefiting someone within it. Give authorities the power to co-operate across borders. | The checklist maps onto the national regimes: [CAN-SPAM (US)](https://emailmarketing.net/learn/compliance/can-spam) follows the opt-out, assumed-consent model; [CASL (Canada)](https://emailmarketing.net/learn/compliance/casl) and [UK PECR](https://emailmarketing.net/learn/compliance/uk-pecr-email-marketing) follow the expressed, opt-in model. See also [EU ePrivacy & GDPR](https://emailmarketing.net/learn/compliance/eu-eprivacy-and-gdpr-email-marketing) and [Australia's Spam Act](https://emailmarketing.net/learn/compliance/australia-spam-act). ## Element II: Enforcement and the Council Recommendation The **Recommendation on Cross-Border Co-operation in the Enforcement of Laws Against Spam** (Annex I) is the core of the Toolkit, binding in spirit. It covers **serious violations only**: conduct that (a) causes or may cause injury, financial or otherwise, to a significant number of recipients, (b) affects particularly large numbers of recipients, or (c) causes substantial harm. The decision to assist always rests with the **Spam Enforcement Authority** that receives the request. Governments should improve their legislation to: 1. Establish a **domestic framework** of laws, enforcement authorities and practices. 2. Improve the authorities' **ability to co-operate** with foreign counterparts (share information, provide investigative assistance). 3. Improve **procedures** for co-operation, by prioritising requests and using common resources and networks. 4. Develop **co-operative models** between enforcement authorities and private-sector entities. The Recommendation has four operative parts: | Part | Obligation on member countries | |---|---| | **(a) Domestic framework** | Maintain effective laws and Spam Enforcement Authorities. Give those authorities the power to obtain evidence, investigate and act in a timely manner against violations committed from their territory or affecting it. Enable action against both **senders** and **those who profit** from the sending. Review frameworks periodically. Consider **redress for financial injury**. | | **(b) Ability to co-operate** | Provide ways to share information with foreign authorities on request, subject to safeguards. Enable investigative assistance (obtaining information, documents and records, and locating persons and things). **Designate a contact point** and register it with the OECD Secretariat, which keeps and publishes the list. | | **(c) Procedures** | Before requesting assistance, do preliminary investigation to confirm that a request is warranted. Prioritise requests. Use common resources (the OECD spam website, informal channels, existing enforcement networks). | | **(d) Private-sector co-operation** | Authorities, businesses, industry groups and consumer groups should co-operate on user education, referral of complaint data, and sharing of investigation tools, analysis and trend information. Encourage co-operation to locate and identify spammers, reduce inaccurate domain-registration data, and make the Internet more secure. | The OECD instructed its ICCP and CCP committees to monitor progress within three years. This model of designated contact points, prioritised mutual assistance and private-sector data sharing is the ancestor of today's practical escalation and referral channels, described in [Cross-Provider Escalation & Mitigation Channels](https://emailmarketing.net/learn/providers/escalation-and-mitigation-channels), and of abuse-report intake, described in [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk). ## Element III: Industry-driven initiatives Anti-spam law should work together with private-sector self-regulation. The Task Force welcomed the best-practice work of BIAC and MAAWG. It noted that in some jurisdictions such codes could be **formally registered with the national enforcement agency**, so that the authority can compel compliance where the industry association cannot. The actors and their duties: - **Providers of online services or goods**: respect customer privacy. Adopt clear company email policies and apply them consistently (for example, never ask for personal information, or ideally never put a clickable link in an email). Authenticate mail or use digital signatures. Prevent phishing with clear domain names and **defensive domain registration**, monitoring of look-alike sites, and control of "bounced" messages. Tell customers what mail the company will and will not send. - **Direct marketers**: adopt and implement a code of conduct for electronic marketing. Build closer relationships with ISPs to reduce false positives. Align codes with anti-spam law nationally and internationally. - **ISPs and network operators**: implement self-regulation. **Adopt and enforce Acceptable Use Policies (AUPs)** as contract terms whose breach allows suspension or termination. Inform subscribers about anti-spam and anti-virus filtering. ### BIAC and MAAWG best practices for ISPs and network operators (Annex II) Here "ISPs and network operators" means **any entity operating an SMTP server connected to the Internet**. Each practice applies only where national law does not contradict it: | # | Practice | |---|---| | 1 | Address **compromised end-user equipment**, with timely processes to manage it or stop it as a source of spam | | 2 | Use **industry-standard authentication** for email, for sources, or for both | | 3 | **Block potentially infecting attachments**. Where content is filtered, obtain the customer's prior agreement as the law requires | | 4 | **Actively monitor inbound and outbound volume** to detect unusual activity and its source, and respond | | 5 | Establish **inter-company processes** for reacting to other operators' incident reports, and **accept end-user complaints** | | 6 | **Communicate security policies and procedures** to subscribers | | 7 | Send **non-delivery notices (NDNs) only for messages originated by their own account holders**, which avoids [backscatter](https://emailmarketing.net/learn/bounce-handling/backscatter-and-batv) | | 8 | Ensure that **only their account holders use their mail submission servers** (submission authentication) | | 9 | Maintain **accurate WHOIS, DNS and IP registration records** (WHOIS, SWIP, RWHOIS), with role contacts (postal, phone, email) for resolving abuse | | 10 | Ensure that all public IP addresses have correct **forward and reverse DNS** and WHOIS or SWIP entries, and that private address space complies with **RFC 1918** | These practices are the direct precursors of the [M3AAWG Senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) and of the operational controls in [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices). [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) expands on role accounts and WHOIS hygiene, and [IPv6 Reverse DNS](https://emailmarketing.net/learn/operations/ipv6-reverse-dns) on PTR expectations. ### BIAC best practices for email marketing (Annex III) This is a voluntary code for marketers. Where national law is stricter, the law governs. It contains nine recommendations and a set of technical tips: | # | Recommendation | |---|---| | 1 | Respect the **consent requirements of the country from which the marketer operates**, unless the marketer knowingly or intentionally targets consumers in another country | | 2 | **Keep records of opt-in and opt-out requests** so that lists can be cleaned before broadcasts. Record proof of consent, including the date and time, the originating IP address, and the collection URL or medium, and provide it on request | | 3 | In all marketing mail (not transactional mail), provide an **obvious, clear and efficient opt-out by email or on the web**. Do not bury it. Confirm the opt-out without requiring further action from the consumer | | 4 | Every message must **clearly identify the sender**. The subject line and body must accurately reflect the content, origin and purpose, and the sender's identity should appear **above the fold** where possible. Avoid subject lines about "free offers" or "winning prizes", which trigger spam filters. Include the sender's main **postal address**. | | 5 | Provide a **link to the sender's privacy policy** | | 6 | Marketers, list brokers and list owners must **ensure that list addresses were obtained legally**. Review the broker's privacy policy and collection procedures, and obtain a contractual warranty that collection was legal | | 7 | Use **great discretion when marketing to children and young people**. Adult content (sexually explicit material, gaming and gambling, tobacco, alcohol, firearms) needs age-appropriate handling and, where applicable, the tag **"SEXUALLY EXPLICIT"** at the start of the subject line. Seek parental permission where required | | 8 | Have a **fair, effective, confidential and easy-to-use system for handling complaints** | | 9 | Disclose the addresses of existing consumers to third-party affiliates or within a family of companies **only if** they are used consistently with the purpose of collection, an easy opt-out exists, or consent was given. Be transparent about brand relationships | **Technical tips for electronic marketers** (Annex III): - All servers (inbound, outbound, websites) should have **reverse DNS (PTR)** entries. Forward and reverse lookups should match, and sending machines should **identify themselves with that name in HELO or EHLO**. - Publish **SPF records, domain-key records (the predecessor of DKIM), or both** for senders and for third-party sites associated with a mailing, and keep them current. - Give outbound mail servers **IP addresses distinct from the site's other servers**. - Keep **WHOIS records accurate and complete**. - Keep **role accounts (postmaster@, abuse@)** working and actively monitored for all sender domains, including sites referenced in the content. **Bounce handling** (Annex III): | Bounce type | Rule | |---|---| | **Hard (5xx)**: no such user, or mailbox unavailable | Promptly **suppress** the address across all lists once refusals reach **3 or more in 14 days**. If a 5xx indicates *spam blocking* rather than a bad address, the address may be reactivated once the block is removed. | | **Soft (4xx)**: transient failure | **Remove** the address when refusals exceed **5 in consecutive campaigns from a single list, or 5 in aggregate across several lists within 10 days**. | For modern, provider-specific handling, compare [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes), [List Hygiene & Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies) and [Suppression-List Architecture](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture). ## Elements IV–VIII (brief) - **IV Technical measures**: no single tool is enough. Layering at origination, on the backbone, at the gateway and at the recipient greatly reduces spam. Current practice is covered under [authentication](https://emailmarketing.net/learn/authentication/spf), [transport security](https://emailmarketing.net/learn/transport-security/mta-sts) and filtering. - **V Education and awareness**: governments run public campaigns. ISPs use their customer channels (website, portal, SMS, newsletters) to explain how to avoid spam, which filters exist, how to report abuse, and the **abuse-desk contact**. "The education of recipients is as important as the education of senders." - **VI Co-operative partnerships**: anti-spam strategy should be developed in partnership between the public and private sectors. ISPs and enforcement authorities should stay in contact to report spam cases and share network data. - **VII Spam metrics**: measure in order to evaluate national strategies. The Task Force welcomed and encouraged **MAAWG's Email Metrics Program**. - **VIII Global co-operation (Outreach)**: make the Toolkit and best practices available to non-OECD economies, and promote anti-spam activity abroad through bilateral and multilateral arrangements. A companion site (historically `www.oecd-antispam.org`) hosted updated information on national spam laws and the list of national enforcement contact points. ## Why this still matters for running an ESP Turn to the Toolkit when a question is about jurisdiction or crosses borders rather than being technical: which legislative model a target country follows, how enforcement authorities co-operate across borders, what an ISP's acceptable use policy and abuse obligations look like in policy terms, and how best practices for senders and marketers were written down before M3AAWG formalised them. For day-to-day deliverability, the specific provider requirements and authentication standards govern. The OECD framework governs the legal and inter-agency layer around them. # Routing Security and IP Hijacking > BGP/IP hijacking and the IPv4 transfer/leasing market as email-abuse vectors — how spammers acquire fresh "clean" IP space, the research quantifying transferred/leased-prefix abuse, Spamhaus's network-hijacking observations, and RPKI/ROA as the mitigation. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/routing-security-and-ip-hijacking If you acquire or vet IP address space for an email service provider (ESP), the history of that space matters as much as its current reputation. Email reputation is usually discussed at the level of IP addresses and domains. The layer beneath it, which decides who may announce an IP range into the global routing table, is also used for abuse. Spammers, bulletproof hosting providers and botnet operators need a constant supply of IPv4 space that has **not yet been "burned"** (listed on blocklists), because their sending burns reputation fast. With IPv4 addresses exhausted, three ways of getting fresh space have become channels for abuse: - **BGP or IP hijacking**: announcing address space you do not own; - the **IPv4 transfer market**: buying blocks, including blocks with a hidden history of abuse; - the **IPv4 leasing market**: renting blocks month by month, which hides the real user from WHOIS. The mitigation is **RPKI and Route Origin Authorizations (ROAs)**, which let a legitimate sender prove, and a receiver verify, that the routing of a range is authorized. For the checklist of what to inspect before you assign a leased or purchased block to customers, see [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence). For how the resulting listings appear and are removed, see [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) and [Spamhaus Listings Deep Dive](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive). ## Why hijacking is an email problem Spammers rotate IP addresses the way they rotate domains. An IP address that sends spam soon earns a poor reputation and gets listed, so the operator needs **fresh, clean IP addresses all the time**. Announcing IP space that legitimately belongs to someone else, or that has been abandoned, meets that need without any registry paperwork that links the abuse back to the operator. The stolen space is used for a burst of spam or for hosting malware, then released before or while it gets listed, and the cycle starts again. This is the network-level equivalent of [snowshoe spamming](https://emailmarketing.net/learn/ip-management/basic-ip-allocation), which spreads the load thinly across many IP addresses to stay under the thresholds applied to each one. The difference is that the IP addresses themselves are taken without permission. Spamhaus's DROP, EDROP and ASN-DROP datasets, and the SBL DROP return code (`127.0.0.9`, "hijacked/leased-to-spammers netblocks; never route"), exist specifically to flag this (see [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)). ## How criminals acquire IP ranges Spamhaus lists four ways to acquire ranges. Two are legitimate on paper and two are abusive: | Path | How it works | Where the abuse comes in | |---|---|---| | Direct assignment from a Regional Internet Registry (RIR) | Become a member of an RIR and receive an allocation | Legitimate, but slow, and space is increasingly scarce | | Assignment from an ISP | An upstream provider allocates space to a downstream customer | Legitimate, but bulletproof hosting providers take advantage of careless upstream providers | | **Hijacking abandoned ranges** | Impersonate the original owner of dormant space | Route space that nobody is watching | | **Temporarily stealing allocated ranges** | Announce part of someone's live space, then release it | "Route rotation": send spam, then vanish | ### Legacy space is the favourite target Ranges issued **before ARIN was created in 1997** ("legacy" allocations) are prime targets for hijacking. They make up roughly **35.9% of the entire IPv4 address space**. They were issued before modern registration practices, they often have no owner who pays for them or pays attention to them, and they **cannot be revoked for non-payment**. A block can therefore lie dormant and forgotten for years, until an attacker brings it back into use. ### The Chemstress case (147.50.0.0/16): how a hijack works Spamhaus documents a typical takeover of a dormant /16. It shows that a hijack is a **social engineering operation against the registry**, not only a technical trick with BGP: | Date | Step | |---|---| | 2011-08-19 | Register a look-alike domain using the name of the original ARIN contact | | 2011-12-12 | Persuade ARIN, through social engineering, to change the block's contact information to the attacker | | 2011-12-16 | Begin unauthorized BGP route announcements for the /16 | | 2012-06-10 | Change the company address to a mail-forwarding service | Once the registry record is falsified, the fraudulent route announcement looks authorized to any network that checks only WHOIS. ## Fighting abuse at the edge Spamhaus argues for blocking malicious traffic at the **routing layer, on edge routers** (through BGP), rather than waiting for detection at the application layer (SMTP or HTTP). It names these patterns of abuse: - **Rogue autonomous systems.** Bad actors run their own autonomous system (AS) and announce routes through BGP. Chains of compromised autonomous systems are common, and criminals exploit **"customer-of-a-customer"** relationships so that no single upstream provider feels accountable. - **Accepting routes without checking.** Upstream providers often pass on rogue routes for **months**, because of weak vetting and "automated processes set up to accept, almost blindly, whatever customers announce." - **Direct peering to stay invisible.** Criminal groups peer directly with a target provider and keep their networks off the global routing table, so that route monitors do not detect them. **Mitigations Spamhaus recommends for network operators:** - Deploy the **DROP, EDROP and ASN-DROP** lists on edge routers to deny connectivity to networks known to be criminal. - **Verify the routes your BGP customers announce.** Look into a customer's history of abuse and routing before you accept their routes, and watch for **route rotation**: announce, send spam, withdraw. - Adopt **BGP Flowspec (RFC 5575 / RFC 7674)** to push dynamic access control lists (ACLs) to edge devices in real time. For example, feed data from the **BCL** (Botnet Controller List) through Flowspec to blackhole botnet command and control servers, one IP address at a time. - Get the networking and anti-abuse teams to work together, since they usually sit in separate silos. For scale, Spamhaus reports that its DNSBLs protect ~**2.7 billion mailboxes**, that it was founded in 1998, and that it has ~**30 investigators across 9 countries**. The BCL list stays small but is growing. ## The IPv4 transfer market as an abuse channel When you buy a block on the secondary market, you may be buying a hidden history of abuse, or the seller may be a repeat abuser getting rid of burned space. Giotsas, Livadariu & Gigis (**PAM 2020**, "A first look at the misuse and abuse of the IPv4 Transfer Market") measured this across a decade of transfers (2009-10-12 to 2019-08-24). They combined IP blocklists, honeypot data, detection of prefix hijacking, and lists of AS reputation: | Finding | Value | |---|---| | Transferred routed prefixes with ≥1 blocklist report | **~40%** | | Routed prefixes not transferred with ≥1 blocklist report | **6%** | | Likelihood of blocklisting, transferred /24 sub-prefixes compared with those not transferred | **6× more likely** | | Transferred space overall, depending on the type of abuse | **4× to 25× more likely** to be blocklisted | | Transfers whose reported date or recipient organization **disagreed** with WHOIS and BGP routing | **>65%** | | Transferred prefixes covered by a ROA with an **inconsistent origin ASN** | **6%** | | Rate of blocklisted space for autonomous systems acting as **both buyer and seller**, compared with those in a single role | **2× higher** | The timing shows **deliberate evasion of filters**. Blocklist reports **peak within one year after** the transfer date, for every type of malicious activity (spam, phishing, malware, botnet command and control, prefix hijacking, unsolicited scans, illegal content). The abuse appears after the transfer even when the address space was in use and visible to scans **at least a month before** it. The imbalance remains after removing legitimate space belonging to cloud providers and very large networks (AWS, Google Cloud), whose infrastructure services are abused for short-lived malware virtual machines. **Repeat BGP hijackers and bulletproof hosting providers are over-represented** among market participants. The authors describe the numbers as a **lower bound**, because transactions that are not reported never appear in RIR databases. ## The IPv4 leasing market: a newer channel that WHOIS cannot see Leasing means renting a block for as little as one month, while the prefix stays registered to the lessor. It is less transparent than buying. Because the RIR processes no transfer, **the lessee's identity is never recorded in WHOIS**. The real user of the address block is hidden, and abuse complaints and vulnerability notifications do not reach them. Malicious actors use this to **rotate "clean" blocks quickly and discard used ones**, getting around IP blocklisting. Degen et al. (**TMA 2025**, University of Twente / CAIDA, "From Scarcity to Opportunity: Examining Abuse of the IPv4 Leasing Market") compared leased and non-leased prefixes over 82 days (Dec 2024 – Mar 2025) using FireHOL blocklists: | Finding | Value | |---|---| | Leased prefixes blocklisted (FireHOL Level 1) compared with non-leased prefixes, Feb 2025 snapshot | **2.89× more likely** (0.518% compared with a mean of 0.179%) | | The same comparison on the broader, full aggregated set of 253 blocklists | **1.84× more likely** (32.0% compared with 17.4%) | | Prevalence of anonymizers (VPNs and proxies) in leased space compared with non-leased space | **2.59× more prevalent** | | Increase in blocklisting in the `abuse` category **30 days** after the lease starts | **+60.2%** | | Increase in blocklisting in the `abuse` category **150 days** after the lease starts | up to **+269%** | | Increase in blocklisting in the `malware` category **150 days** after the lease starts | **+37.9%** | Listings of leased prefixes were **stable before the lease started, and then rose steadily** through the measurement period. That is the pattern of a block that stays clean until a lessee starts abusing it. The Level 1 figure (2.89×) is a conservative minimum, and the figure from the broad set of lists is an upper limit. **The size of the market (TMA 2025).** More than >**6,184 transfers** covering **30.2M addresses** took place in 2024. One broker alone reported **757 transfers worth US$60.7M**. IPv4 addresses are now used as collateral for loans: one company issued **US$206M** in notes secured by its IPv4 assets. Waiting times at the RIRs as of Feb 2025 were **498 days at RIPE NCC, 615 days at ARIN and 1,417 days at LACNIC**. This scarcity is what pushes operators to the secondary and leasing markets in the first place. Notably, **some brokers now offer RPKI management, prefix "parking" (announcing a prefix from the broker's own AS), IP reputation services and delisting as a service** as extras. These are legitimate uses of the same tools that abusers exploit. **What this means for operators.** A leased or transferred block is statistically more likely to be dirty than routed space chosen at random, and its history is harder to see. Checking reputation before you acquire a block is not optional: look at its blocklist history, its earlier SWIP and WHOIS records, and SenderScore and Talos (see [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence)). ## RPKI and ROAs: the mitigation **RPKI (Resource Public Key Infrastructure)** uses cryptography to bind IP prefixes to the AS numbers authorized to originate them, so networks can reject false route announcements. Origin validation is currently the **only** RPKI function in operational use. ### Route Origin Authorization (ROA) A ROA is a signed object, published by the legitimate holder of the resource, that contains three fields (RFC 6482): | Field | Meaning | |---|---| | **Prefix** | The IP address block being authorized | | **Origin AS number** | The single AS allowed to originate that prefix in BGP | | **maxLength** | The most specific prefix length the AS may announce | For example, a ROA for `192.0.1.0/24` with a **maxLength of /25** authorizes announcing that `/24` or its two adjacent `/25`s, but **nothing more specific**. Limiting maxLength blocks the classic hijack, in which the attacker announces a more specific sub-prefix (which BGP always prefers) to divert traffic. ### Route Origin Validation (ROV) states A router compares each BGP announcement with the set of **Validated ROA Payloads (VRPs)** and gives it one of three states: | State | Condition | Typical action | |---|---|---| | **Valid** | The prefix and origin AS are covered by ≥1 VRP, within maxLength | Accept | | **Invalid** | Wrong origin AS, or more specific than maxLength allows | Reject, or give the route lower preference | | **NotFound** (Unknown) | No VRP covers the prefix (no ROA is published) | Accept (fail open) | Space without a ROA ends up **NotFound**, not Invalid, so RPKI protects only the prefixes whose legitimate holder has published a ROA. That is the direct action for a sender who wants clean space: **publish ROAs for your sending ranges**. A hijacker's announcement of your space that is more specific or has the wrong origin is then marked **Invalid** and dropped by networks that enforce ROV, and a receiver's routing infrastructure treats your own announcements as authorized. It also protects you as a buyer. The PAM 2020 finding that **6% of transferred prefixes covered by a ROA had an inconsistent origin ASN** is exactly the kind of mismatch ROV brings to light. The RPKI documentation notes that the **vast majority of route hijacks are unintentional**, caused by typing mistakes in the origin or by route leaks. Broad ROA coverage makes both accidental and malicious wrong origins **easy to identify and reject**. ### Beyond origin validation - **BGPsec (RFC 8205)** validates the whole AS path, not just the origin, but its real-world deployment "may prove limited." - **ASPA (Autonomous System Provider Authorization)** is draft work on path validation, an emerging middle ground between ROV, which checks only the origin, and full BGPsec. ## Bottom line for an ESP 1. Fresh IP space is a commodity for spammers. Hijacking, buying and leasing are all ways to get it, and all three leave measurable traces on blocklists. 2. **Leased blocks are 1.84–2.89× and transferred blocks 4–25× more likely to be dirty** than routed space chosen at random, and leasing deliberately hides the operator from WHOIS. Vet a block before you assign it (see [IP-Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence)). 3. **Publish ROAs** for your sending prefixes. A hijack of your space then becomes Invalid at networks that enforce ROV, and it shows that the operation is well run. Before you acquire a block, check that its ROA and origin are consistent. 4. Spamhaus DROP, EDROP and ASN-DROP, and the BCL (optionally through BGP Flowspec), let you refuse traffic from networks known to be criminal at your own edge. # Sender Certification Programs: Validity Certification and the CSA > The two surviving commercial allowlist programs — Validity Sender Certification and the Certified Senders Alliance — with exact admission criteria, performance thresholds, costs structure, which receivers honor each, and an honest assessment of when certification pays off. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/sender-certification-programs If you are considering paying for sender certification, whether it helps depends on which mailbox providers you need to reach and on whether you send as a brand or as a platform. Formal third-party allowlisting is [largely historical](https://emailmarketing.net/learn/reference/glossary), but two commercial programs survive with real support from receivers. **Validity Sender Certification** is the former Return Path Certification. It is an allowlist of IP addresses, honored mainly by Microsoft, Yahoo and AOL, Comcast, and networks filtered by Cloudmark. The **Certified Senders Alliance (CSA)** is a German program of eco and DDV, and its allowlist is used by GMX and WEB.DE and most of the German-speaking mailbox market. The two programs target different senders. Validity certifies **brands on dedicated IP addresses and explicitly excludes ESPs**. The CSA certifies **sending platforms, including ESPs, at the infrastructure level**. **Neither program influences Gmail.** Gmail runs its own reputation systems and [largely ignores third-party signals](https://emailmarketing.net/learn/operations/reputation-monitoring). No certification, paid or otherwise, improves placement at Gmail. --- ## Validity Sender Certification Source: "Sender Certification Requirements" (Validity, © 2024, published for 2025; fetched July 2026). Certified IP addresses are placed on Validity's allowlist, mailbox provider partners are notified, and Validity starts monitoring the IP addresses 24×7. Validity claims relationships with "75+ global mailbox and security providers". The partners for which it states thresholds are Microsoft, Yahoo and AOL, Comcast, and Cloudmark. ### Application and pre-approval process 1. You subscribe, and Validity starts a comprehensive audit of the email program. 2. You complete the **Sender Certification Questionnaire** (typically within the first day). This unlocks the certification data feeds (complaint rates, spam trap hits, and sending volume for each IP address, from Validity's provider and filter partners) and starts the audit. 3. If the program meets the Business Model, Measurability and Infrastructure requirements, the account may get **preliminary activation** of Certified status **before the audit is complete**. This is the "pre-approved" state marketed at validity.com/sender-certification/get-pre-approved. The preliminary benefits last **up to 60 days** while the audit runs. 4. If the remediation the audit requires is not complete after the 60-day preliminary period, or if requirements are breached at any point during the subscription, the IP addresses are **suspended from the allowlist** (access to the data feeds continues). They are activated again once the corrections are made. Ongoing obligations: respond to any program notice within **3 days**, and start the required actions within **10 days**. Notify Validity in writing within **2 business days** if an IP address or domain is compromised, and enable it again only after Validity has reviewed the mitigation. ### Eligibility (business model) - The business can be verified through a public third-party source (a country registry, Dun & Bradstreet), has a physical address on record, has been **legally registered and operating for at least 1 year**, and does not use a registered agent that hides its ownership. - Every approved brand has a valid HTTPS website or landing pages, and has had them **for at least the past 6 months**. - **Dedicated IP addresses only.** Shared IP addresses are not eligible, and the applicant must have been the only entity on the IP addresses for **at least 60 days**. - Certified IP addresses may carry only **transactional and commercial email built from templates**. Corporate or 1:1 mail is not allowed, and neither is free-form content in messages (for example, text entered in a web form). **Excluded business categories** (cannot be certified): Email Service Providers (senders mailing on behalf of brands they do not own, such as ESPs, brand licensing, publishers and white-label services), agencies, third-party and affiliate mailers, lead generation, list rental providers, penny-bid auctions, illegal activities, and human trafficking. For an ESP, this means you cannot certify your own platform or your shared pools. Only customers on dedicated IP addresses who fully own their brand can enroll, each one individually. ### Volume minimums and IP limits - Each IP address must deliver **at least 100 messages to each of Microsoft and Yahoo in every rolling 30 days** (as measured in Validity's data). IP addresses without measurable, consistent volume are not reviewed. Once certified, such IP addresses are **suspended after 30 days and removed from the program after 90 days**. - An IP address may not target a single mailbox provider (with occasional exceptions, only with Validity's prior written approval). - The maximum number of certified IP addresses depends on the contracted annual volume: | Annual sending volume | Max IPs | | Annual sending volume | Max IPs | |---|---|---|---|---| | 1,200,000 | 2 | | 120,000,000 | 8 | | 3,000,000 | 2 | | 180,000,000 | 9 | | 7,500,000 | 3 | | 240,000,000 | 10 | | 12,000,000 | 4 | | 420,000,000 | 13 | | 36,000,000 | 5 | | 600,000,000 | 16 | | 60,000,000 | 6 | | 1,200,000,000 | 18 | | 90,000,000 | 7 | | More than 1,200,000,000 | 22 | ### Technical and program requirements (summary) - **Infrastructure**: no open relays. [Forward-confirmed reverse DNS (FCrDNS)](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). [SPF](https://emailmarketing.net/learn/authentication/spf) on all Return-Path domains, with no `+all` or `?all` and no `ptr` mechanism. All mail [DKIM](https://emailmarketing.net/learn/authentication/dkim)-signed, with keys of at least 1024 bits (2048 recommended) and **no `l=` tag** (use `x=` instead). [DMARC](https://emailmarketing.net/learn/authentication/dmarc) of at least `p=none` on the From domain, aligned, with a working `rua`. ARC recommended for forwarding. The role accounts `abuse@` and `postmaster@` on all sending and Return-Path domains. Proof of domain ownership through a Validity TXT token that must stay in DNS for as long as the membership lasts. Hard bounces removed from all future mailings. TLS recommended. - **Content**: clear branding. Accurate subject lines, without "RE:" or "FWD:". A physical mailing address in commercial and transactional mail. **No URL shorteners** (Bitly, TinyURL and similar). **No attachments of any kind.** No hidden content. A valid Message-ID. Headers that comply with RFC 5322. - **Unsubscribe**: [List-Unsubscribe (RFC 2369) covered by the DKIM signature, RFC 8058 one-click](https://emailmarketing.net/learn/list-management/list-unsubscribe), and a link in the body. Requests processed within **2 days**. Links that keep working for **at least 60 days** after sending. Requests made in other ways (by post, by phone, to abuse@) are also honored. - **Consent**: [double opt-in, or single opt-in with notification](https://emailmarketing.net/learn/list-management/consent-methods). Another legal basis, such as documented legitimate interest, needs written evidence. Prohibited: pre-selected opt-in, plain single opt-in without notification, harvesting, renting, buying or appending lists, and email prospecting. Co-registration requires separate unchecked sign-ups for each brand and consent that can be proven. Forward-to-a-friend requires a CAPTCHA on the form, one email and at most one follow-up, no external links, a personal comment of no more than 140 characters, and no more than 100 messages per user in 24 h. - **FBLs**: sign up for every available [feedback loop](https://emailmarketing.net/learn/list-management/complaint-feedback-loops). The mandatory minimum is Microsoft JMRP, the Comcast IP & Domain FBL, and the Yahoo FBL. ### Performance thresholds (exceeding any leads to partial or full suspension) **Microsoft SRD (Sender Reputation Data junk votes), cumulative over 30 days:** | Individual IP SRD volume | 0–4 | 5–10 | 11+ | |---|---|---|---| | Allowed SRD rate | not enforced | 5 junk votes | 45% | | Group SRD volume (all certified IPs) | 0–9 | 10–30 | 31–50 | 51+ | |---|---|---|---|---| | Allowed SRD rate | not enforced | 75% | 65% | 55% | Group enforcement applies when at least 2 IP addresses are certified. If the group threshold is exceeded, every IP address with at least 1 junk vote is suspended. **Complaint rates, averaged over 30 days across all sending volume** (enforced only above a minimum number of complaints): | Source | Threshold | Enforced above | |---|---|---| | Microsoft complaint rate | 0.2% | 200 complaints | | Yahoo and AOL inbox complaint rate | 0.2% | 200 complaints | | Comcast complaint rate | 0.3% | 100 complaints | | Cloudmark complaint rate | 1.0% | 100 complaints | **Spam traps, cumulative over 30 days:** | Trap class | Allowed hits | |---|---| | Critical spam traps | 3 | | Significant spam traps | 5 | | RP Trap Network | 100 | | Cloudmark traps | 100 | **Blocklists (current listings):** 1 listing on a critical blocklist, or 2 on significant blocklists, breaches the threshold. Repeated or excessive listings can lead to suspension or termination. --- ## Certified Senders Alliance (CSA) The CSA was founded in 2004 and is run by **eco** (Association of the Internet Industry) together with the **DDV** (German Dialogue Marketing Association). It **certifies IP platforms** (IPv4 only). The certified party is the company that operates and controls the sending platform, which describes an ESP exactly, the opposite of Validity's model. The CSA maintains a list of certified IP addresses that it distributes to participating mailbox and security providers, which build it into their filters. Those partners send back live compliance data, which certified companies see in the **Certification Monitor**. The contract documents (Criteria, Conditions of Participation, Rules of Procedure, Price List) are published at certified-senders.org/resources. German law applies, and the place of jurisdiction is Cologne. > About the documents: the older 2017 PDF URLs cited above now serve the **June 2026** editions of the Criteria and the Conditions of Participation (the older documents expired on 19 July 2026). The figures below are therefore current as of the June 2026 versions, fetched July 2026. ### Who can participate - The company **operates the technical platform** that controls the sending of bulk email, and is responsible for it. It generally needs **at least 3 months of sending history** on the infrastructure. - Certification covers **all IP addresses used for commercial bulk email**. Every IPv4 address and its FQDN must be uploaded to the Certification Monitor, and the declared IP addresses may be used only for commercial bulk email (not for internal corporate mail). - For ESPs and other platform providers, only IP addresses under the company's **sole control** can be certified, and certified outbound servers must be clearly separable from servers that are not certified. - Brands that run their own platform must fully control and monitor delivery on it. Otherwise they cannot be certified. - **Hosting providers are excluded** for servers that customers rent and use on their own. - The business model must not conflict with the ethical principles of eco and DDV (a separate ground for rejection). ### Certification process, fees, and contract 1. Return the signed individual offer and pay the **assessment fee** (set by the CSA Price List, and **not refunded** if certification fails). 2. Assessment: a reputation check of the declared IP addresses using the participating partners' data, and a review of documents (sample newsletters, the IP list). Errors that are repeatedly left uncorrected can lead to a deadline. If the deadline is missed, the CSA may charge a new assessment fee. 3. The decision is made by the **Complaints and Certification Committee (CCC)**, which has four members, two elected from eco and two from DDV. Certification requires a majority. After a rejection (because of doubts about compliance or an ethical conflict), the company **may apply again after 6 months**. 4. Monthly contributions (invoiced quarterly, pro-rated) start on approval. The price category depends on the **total annual revenue** of the company or of its parent company (from an annual revenue survey; a company that does not respond is placed in the highest category). The contract lasts 1 year, renews automatically, and has a **3-month notice period**. 5. Payment arrears of **more than 30 days** lead to temporary delisting of the IP addresses (reinstatement about 5 working days after payment). Arrears of **more than 60 days** lead to termination for good cause. After the contract ends, all references to the CSA must be removed within 4 weeks (6 months for print), with a **contractual penalty of €500 per week** after that. IP statuses on the certified list: **Active** (full benefits, plus monitoring and reporting), **Failed** (technical requirements not met; no benefits), **Delisted** (a sanction; no benefits, but monitoring continues), **Monitored** (during certification) and **Parked** (set by the company for unused IP addresses; listed, but sending is prohibited, which lets you prepare DNS in advance). For the duration of certification, the company must prove control of each IP address, either with a DNS TXT record on the server's FQDN in the form `CSA-certified-host=`, or with a WHOIS registrant organisation that matches the contracted company name. Outgoing servers need full FCrDNS (the PTR record gives the FQDN, and the FQDN's A record gives back the same IP address), the FQDN announced in HELO or EHLO, and hostnames that do not look like coded dial-up identifiers (`server-80-12-54125.example.org` fails). Missing verification or broken lookups result in the status "failed". ### Mandatory criteria (June 2026) **Trust & transparency:** a postal address and a digital contact that are easy to find on the website, accessible privacy information, and messages and SMTP dialogue that comply with the RFCs (currently RFC 6532, 2142, 2369, 5321, 5322, 7208, 6376, 8058). **Abuse prevention:** - A role account for abuse (preferably `abuse@org-domain.tld`) registered in the Certification Monitor. Respond to the **eco Complaints Office within 24 hours on business days**. - Platform providers must be able to enforce compliance for each customer (blocking, rate limiting, volume caps, caps on sending domains) and must protect customer accounts (for example, with 2FA). - Redirect and click-tracking links must be able to be deactivated **within 24 hours** of a notification of phishing or misuse. - The **`X-CSA-Complaints: csa-complaints@eco.de`** header, inserted and DKIM-signed on certified servers only, within 4 weeks of certification, and confirmed by a test mailing. - No open relay, no public proxy and no backscatter. Continuous monitoring. Delivery over **TLS** that reflects the current state of the art. **Authentication:** - SPF for the MAIL FROM domain, ending in **`-all` or `~all`**. - A valid DKIM signature on every email (RFC 6376). For ESPs, `d=` must be attributable to the customer's sending domain (an additional signature with the ESP's domain is allowed). The signature must cover at least **From, X-CSA-Complaints, Date, To**, and the **`l=` length parameter is prohibited**. - **Relaxed DKIM alignment** is required: the organizational domain of `d=` must match the domain in the header From (with an exception for ESPs only when the customer has no domain of its own). **List hygiene:** - The platform must be able to insert **List-Unsubscribe** (the RFC 2369 URL method with POST over HTTPS, which can be combined with **List-Unsubscribe-Post**, RFC 8058 one-click) and **List-Help** (a mailto: or HTTPS link; HTTP is not permitted) in every email. - Every advertising email must carry a working unsubscribe that requires **no login**. ESPs must give customers an easy unsubscribe feature using a link in the body (preference and selection pages are allowed). - Bounce handling as specified in RFC 5321, with an **MX record (or an A record as fallback) on the envelope-from domain**. Further delivery to mailboxes known not to exist must be prevented. **Performance thresholds (7-day windows):** | Indicator | Threshold | Basis | |---|---|---| | Spam complaint rate | At most **0.3%** per IP or per company | Complaints divided by emails reaching the inbox | | DKIM missing rate | At most **3.0%**, company average | Unsigned emails divided by total emails sent (data validated by partners) | | Hard bounce rate | At most **1.0%** per IP or per company | | | General reputation | No significant IP or DKIM reputation problems with participating providers (trap hits, content scanners, spam rates) | | **Recommended (not mandatory):** register for public FBLs and implement the **CFBL header (RFC 9477)**. Send multipart HTML and text. Publish DMARC with a `rua` that can be processed, and `p=reject` is recommended. Use **DANE (RFC 7671, with DNSSEC), with MTA-STS (RFC 8461) as the fallback** where DNSSEC is not feasible. Use DKIM with 2048-bit keys and SHA-256. Use double opt-in (the confirmation email must contain **no advertising**). State the mailing frequency at sign-up. Provide a working reply-to address. Use **separate IP addresses for newsletters and for transactional mail**. Avoid URL shorteners. Extend DKIM alignment to the MAIL FROM domain, and keep the domains in the List, Reply-To and Sender headers consistent. The CSA publishes a self-assessment **checklist** (certified-senders.org/csa-checklist) that turns these criteria into yes-or-no readiness questions. It is useful to go through it before paying the assessment fee. ### The CSA Email Directive: German legal baseline encoded as certification content The CSA's certification criteria refer to its "Email Marketing Directive", which summarizes German and EU law. This is what makes CSA certification legally meaningful in Germany. It matters even to senders who are not certified but mail German users (compare the double opt-in (DOI) expectation noted in [GMX and WEB.DE requirements](https://emailmarketing.net/learn/providers/gmx-web-de-postmaster)). **Permission (directive ch. 2)**, based on the General Data Protection Regulation (GDPR) and the ePrivacy Directive 2002/58/EC as implemented in the Act against Unfair Competition (UWG), the TMG and TTDSG (telemedia laws) and the Federal Data Protection Act (BDSG): - "Advertising" is interpreted broadly (newsletters, birthday greetings, market research, brand promotion, requests for donations). Transactional mail needs no consent, until any advertising element is added. From that point, the full consent rules apply. - Consent must be **transparent** (which company, which products, which channels, with no blanket consent; the Federal Court of Justice (BGH) found that consent naming about 8 companies can be valid, while the Higher Regional Court (OLG) of Frankfurt found 59 sponsors to be too many), **active** (no pre-checked boxes or opt-out constructions), **freely given**, and **documented** (the consent text, the place, and the timestamp and IP address of the sign-up and of the DOI confirmation click). - **Double opt-in is the de facto standard of evidence** (recognized by the BGH as proof that the request came from the address). The DOI confirmation email must contain **no advertising** (courts have objected even to logos in the footer). Sign-ups that are not confirmed should be deleted within **about 2 weeks**. - Consent has no legal expiry date, but the Regional Court (LG) of Munich I has treated consent **unused for about 1.5 years** as lapsed. - Withdrawing consent must be easier than giving it. Consent records are kept for **3 years after withdrawal** (the limitation period in §195 BGB) to defend against claims. - **The existing-customer exception in §7(3) UWG** (email advertising without consent) requires all four conditions: the address was obtained in connection with a completed sale, the advertising is only for the sender's own similar goods or services, a clear notice of the right to object is given when the address is collected and in every email, and the customer has not objected. - **B2B is not exempt.** German law requires opt-in for business-to-business (B2B) email advertising as well. The relaxed rule of presumed consent for B2B exists only for telephone marketing. **Legal notice, or Impressum (directive ch. 3)**, based on the E-Commerce Directive 2000/31/EC and the Telemedia Act: every commercial email needs a **complete legal notice, in full text, in the email itself** (not behind links). It includes the company name with its legal form, the full street address, the authorized representatives, the register court and number, an email address (a phone number is recommended), and the VAT ID where applicable. The sender's identity and the commercial nature of the message must be evident. Violations can be fined up to **€50,000**. ### Which receivers honor the CSA The participating mailbox providers (listed at certified-senders.org/participants, fetched July 2026) include the entire German-speaking consumer market (**GMX, WEB.DE, mail.com, 1&1, freenet, mail.de, T-Online, Arcor, Kabel Deutschland (Vodafone), unitymedia, Swisscom**) and international names: **Microsoft (Outlook.com, Office 365), Yahoo, AOL, Comcast, Orange, Seznam.cz, Fastmail** and various hosting companies. Security and filtering participants include **Cloudmark, Cisco Talos, abusix, Hornetsecurity, Open-Xchange, Halon, and Excello (virusfree)**. The weight given to certification varies. German providers treat it as a first-class signal: GMX and WEB.DE actively send bulk senders to the CSA and route complaint feedback through it, and they run no public FBL of their own. For the large international participants, it is one input among many, not a way around the filters. --- ## Is certification worth it? For an ESP operator, the costs and benefits look like this: - **Gmail: no.** Gmail takes part in neither program, and it ignores third-party certification and blocklists in favor of its own systems. If your problem is placement at Gmail, certification buys nothing. Fix the [fundamentals of engagement and spam rate](https://emailmarketing.net/learn/providers/gmail-sender-requirements) instead. - **Certification is a floor, not a boost.** The admission criteria of both programs are essentially the [M3AAWG senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) plus monitoring, and a sender who genuinely meets them usually already delivers well. The extra value is (a) the data feeds (Validity's feeds on traps, complaints and SRD, and the CSA Certification Monitor with partner data, which matters because complaint feedback from GMX and WEB.DE is not available any other way), (b) the benefit of the doubt during incidents and [warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up), and (c) a documented record of compliance. - **The CSA is worth evaluating for any ESP with meaningful volume in Germany, Austria and Switzerland (DACH).** It is the only program designed to certify platforms and ESPs. It is the de facto FBL and escalation channel for GMX and WEB.DE, and its criteria encode the German legal requirements (DOI, Impressum) that you must meet anyway to mail Germany safely. Costs grow with company revenue (the assessment fee plus monthly contributions). Take the compliance obligations seriously (a 24 h response to abuse reports, 24 h to deactivate links, thresholds over 7-day windows), because losing certification after taking part publicly is itself a reputation signal. - **Validity is a decision for each brand, not for the ESP.** ESPs are an excluded category. Only customers on dedicated IP addresses qualify, and they must own their brand, have at least 1 year of corporate history, have been alone on their IP addresses for at least 60 days, and send sustained volume to Microsoft and Yahoo. It suits high-volume B2C brands whose problems are at Microsoft (SRD and JMRP), Yahoo and AOL, Comcast, or regional ISPs filtered by Cloudmark. Its thresholds (0.2% complaints at Microsoft and Yahoo, 3 critical trap hits in 30 days, 1 critical blocklisting) are stricter than typical operating targets. Treat them as a service level you must keep, or expect suspension in the middle of the contract. - **Neither program replaces good consent.** Both prohibit purchased, rented and appended lists outright. Certification cannot clean up a bad acquisition practice, and both programs revoke certification faster than mailbox providers forgive. # Spam Traps: Types and What They Signal > Trap types (pristine, recycled, typo), how each gets onto a list, what hitting them signals about data quality, and how to respond. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/spam-traps Based on Word to the Wise's "What Spamtraps Tell Us" (Laura Atkins, March 2025), which updates her earlier "A Brief Guide to Spamtraps" (2011). Spam traps (spamtraps) are email addresses operated by blocklists, anti-spam organizations, and mailbox providers to detect poor sending practices. ISPs and reputation systems cite trap hits as justification for blocking senders. ## Trap types | Type | What it is | How it gets on a list | What a hit signals | |---|---|---|---| | **Pristine** | A fabricated address that has never existed, often at a domain that has never been used for email | Senders making up addresses, or buying them from a list seller | Non-permission-based sending practices (see [worst practices](https://emailmarketing.net/learn/industry-best-practices/wttw-email-best-practices#buying-lists)) | | **Recycled** | An address or domain that received legitimate mail at one point, was decommissioned, allowed to bounce for a minimum of **12 months**, then reopened as a trap | Poor bounce handling, or reactivation of an outdated contact database; frequent in purchased lists | Inadequate list hygiene / bounce processing | | **Typo** | A real misspelling of an address, typically on the **domain** portion; security/anti-spam organizations have bought common typo domains and turned them into monitoring addresses | A person mistypes their own address on a signup form | Sender is trying to be opt-in but is not verifying that captured data is correct | ## The key insight: traps are a signal, not the problem > Spamtraps are NOT the problem; they're a signal. Traps indicate underlying data-collection and data-maintenance issues. The critical corollary: **if your list processes allow spamtraps onto the list, it's likely you're also sending mail to actual people who don't want it** — which is the real reputation damage (see [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)). ## How to respond Do not try to hunt down and remove individual trap addresses — fix the root causes: - **Don't purchase lists.** - **Never reactivate old database addresses** (recycled-trap source). - **Implement address verification** on website signup forms (typo-trap source). - Maintain proper bounce handling so decommissioned addresses leave the list long before the 12-month recycling window ends. # Spamhaus Listings Deep Dive — SBL, CSS, PBL, DBL Policy and Delisting > Per-list detail on Spamhaus listing criteria, escalation policy, self-service vs investigated delisting, return/error codes, and how receivers should query the zones — beyond the zone overview in Blocklists & Spamhaus. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive When a shared IP address or a customer domain on your platform is listed by Spamhaus, you need to know that list's actual policy, how the listing can escalate, and the exact steps to get it removed. The sections below cover each list in turn. [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) covers how DNS blocklists (DNSBLs) work, the full tables of zones and return codes, and Spamhaus's guidance for senders. ## SBL — Spamhaus Blocklist (`127.0.0.2`) A research team working from open-source intelligence (OSINT) maintains the SBL by hand, and the database averages **30,000–40,000 listings**. The zone is **rebuilt and reloaded every 5 minutes, 24/7**, so both new listings and removals take effect quickly. ### What gets listed The SBL lists IP addresses "under the control of, used by, or made available for use by spammers and abusers in unsolicited bulk email or other types of Internet-based abuse": - **Snowshoe spam ranges**: "ranges and domains with poor or frequently changing identification." - **Spam hosting**: IP addresses that host websites advertised in spam, or resources used by spam and malware operations. The IP address does not need to send mail to be listed. - **Spam services**: bulletproof hosting ("explicit or tacit actions not to disconnect customers who spam"), spamware ("software whose main purpose is to aid in the sending of high volume unsolicited bulk email"), and address scrapers. - **Security threats**: command-and-control (C&C) servers for botnets, sites infected with malware, phishing pages, and ransomware infrastructure. **Informational listings** exist alongside blocking listings. Spamhaus describes them as "an early warning signal to indicate that the listed IP is displaying poor behavior. Informational listings are indicative, and do not result in IPs being blocked." Treat one as the last warning before a blocking SBL listing. ### Escalation policy When a network ignores its listings, Spamhaus extends the listing beyond the abusive IP addresses, to "that network's own infrastructure IP addresses, to extended ranges of that network, or even to that entire network." The triggers are: - ignoring SBL listings for long periods; - claiming to remove spammers who keep coming back (moving customers from one IP address to another); - providing bulletproof hosting; - persistent spam or security problems. For an ESP, this is the risk that threatens the whole business. Tolerating one bad customer can turn a listing of a single IP address into a listing of the company's own MX servers, its website, or its entire allocation. ### SBL delisting Only the **ISP or network responsible for the listed IP address** can ask for removal. End users and ESP customers cannot, and must go through their provider. The workflow: 1. Read the SBL listing page (linked from the checker) to understand the specific spam problem. 2. Fix it **permanently**. For a spammer customer, Spamhaus typically expects the provider to terminate or disconnect the server, clear the DNS entries served by the ISP's main DNS servers, clear PTR records, stop MX servers from accepting mail for the customer, and remove the SWIP and rWhois entries. In other words, fully deprovision the customer rather than only suspending its sending. 3. The ISP's abuse or security desk sends a removal request to the SBL Removals Team **that describes how the problem was solved**. An explanation is required, not just "please delist." No service level is published beyond "once the abuse issue has been terminated". Investigations may require proof of consent and re-permissioning of the list at fault (see [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)). Delisting is always free: "Any offer from anyone to remove any Spamhaus listing for a fee is a scam." ## CSS — Combined Spam Sources (`127.0.0.3`) CSS is the **automated** part of the SBL zone. It targets "IP addresses that are involved in sending low-reputation email", and it watches only SMTP traffic on port 25. It holds **2–4 million listings** at any time, with **300,000–400,000 new listings every 24 hours**. This is the list that a legitimate but careless ESP customer is most likely to hit. ### Detection and granularity Listings result from "multiple events and heuristics", which Spamhaus does not disclose. The triggers it names are: - **snowshoe operations**: static sources of spam spread thinly across IP addresses and domains, which other lists do not catch; - **compromised hosts**: insecure installations, misconfigured servers, breached accounts, and exploited content management systems (CMS); - **poor list hygiene**: unsolicited mail from senders who manage their subscribers badly. Granularity: **IPv4 /32; IPv6 /64** (following the assignment practice in RFC 4291). Listings of larger IPv6 blocks are aggregated if many /64s in a network misbehave, which is why ESPs that send over IPv6 must separate customers by /64 at a minimum. ### Common causes for ESP infrastructure - a HELO or EHLO name that is not a FQDN (`localhost.localdomain`, a bare `mail`); - missing rDNS, or rDNS that does not match forward DNS (the PTR record must give a hostname that resolves back to the same IP address); - no IP warm-up, so that cold IP addresses sending volume look like snowshoe senders (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)); - customer lists built with single opt-in or kept without hygiene, which hit traps ("use double opt-in to avoid spam traps"); - default settings of control panels (Plesk, cPanel, DirectAdmin) and load balancers that present generic identities, and wildcard DNS. ### CSS expiry and delisting **A listing normally expires automatically three days (72 h) after spam was last detected.** "In some cases of chronic abuse, the listings can last longer." Because expiry is automatic, the first decision is whether to wait for it or to remove the listing yourself. Self-removal is done through [check.spamhaus.org](https://check.spamhaus.org/): "Whatever caused the problem MUST be identified and corrected before removing an IP from CSS." The number of self-removals is **limited**, and the IP address is listed again immediately if the cause persists. Using up removals without fixing the root cause turns a 72-hour nuisance into a chronic listing. The checker's CSS flow checks the basics from RFC 5321 and 5322 (rDNS, HELO) before it allows removal. ## PBL — Policy Blocklist (`127.0.0.10` / `127.0.0.11`) The PBL is about **policy, not abuse**. It lists "end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server." A PBL listing does not accuse anyone of spamming. It contains **over 1.4 billion IPv4 addresses, roughly 40% of routable IPv4 space**, mostly ISP ranges for broadband and dial-up, plus some IPv6 CIDR blocks. The zone is rebuilt **every 15 minutes**. The data comes from two sources, told apart by the return code: | Code | Who listed the range | |---|---| | `127.0.0.10` | The ISP itself, through a PBL account (an authoritative statement about its own address space) | | `127.0.0.11` | Spamhaus research: end-user space with high concentrations of botnet zombies | ### Self-service removal The operator of a mail server on an IP address listed on the PBL can remove **a single IP address** through the Reputation Checker, if all of these are true: - the IP address is **static** (dynamic IP addresses should relay through the ISP's smarthost instead); - an outbound mail server actually runs on it; - forward (A) and reverse (PTR) DNS are configured correctly; - the IP address is assigned to the person or company asking for removal. Requests from freemail addresses (Gmail, Hotmail, Yahoo) are refused, and the request must come from an address on a domain that matches the mail server. Removal takes effect in **about 15 minutes**. Exclusions **expire after one year**, and they are **reversed immediately if spam is detected**. Removing many IP addresses one at a time gets the exclusions reversed and access revoked, so removals of several ranges must be done by the ISP that owns the space. This matters when an ESP acquires a range that sits inside a PBL block of an access network: ask the upstream provider to exclude the range in its PBL account, instead of removing IP addresses one by one. For end users behind the PBL, the right fix is not removal at all, but **authenticated submission on port 587 or 465** to their provider's smarthost. The PBL affects only delivery made directly to MX servers on port 25. ### ISP PBL accounts Networks manage their own address space with a PBL account. To be eligible, a network needs at least one IPv4 /24 or IPv6 /48 allocation, a primary domain that can be verified in IP-Whois, rWhois or rDNS, a working `abuse@` address, and a work email address on the primary domain (or a related one). An account contains **Master Ranges** (the full allocation), which in turn contain **PBL zone listings** (the parts actually listed). Changes take effect within 15 minutes. An ESP that runs its own allocation should hold a PBL account, if only to make sure its transactional and sending ranges are excluded, and to list any customer access space it operates. ## DBL — Domain Blocklist (`127.0.1.x`) The DBL lists domains only: "No IP addresses are listed in the DBL." It has more than about 80 mirrors worldwide. Listings are mostly automated, with manual intervention when needed, and **expire automatically once the domain no longer meets the listing criteria**. The full table of return codes is in [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). The key distinction is between codes `127.0.1.2–.6`, where the domain itself is bad (spam, phishing, malware, botnet C&C), and codes `127.0.1.102–.106`, for **abused-legit** domains, which are legitimate domains that were compromised and abused. ### Listing causes Spamhaus deliberately does not disclose its criteria ("We do not discuss the specific criteria we use"), but it states these principles of reputation: - **An unknown reputation counts as a poor one.** "Reputations are built over time, and building a good reputation takes longer than building a bad one." New sending domains start at a disadvantage (and see ZRD for the first 24 h). - **Anonymity harms reputation** (anonymized WHOIS records, hidden operators). - **Domain and IP reputations affect each other.** Clean hosting with correct rDNS matters to the domain. - **Snowshoe rotation of domains**: many domains that change often are in themselves the signal. "Legitimate mailers invest in durable, long-term infrastructure." - **SPF, DKIM and DMARC do not protect against listing.** Spammers authenticate too, and authentication records alone never justify delisting. - Spamhaus **does not scan websites**. Listings come from observed traffic: "when we see those signs it means for certain that the website or server is insecure, infected or compromised." ### Abused-legit (`127.0.1.102–.106`) These are compromised legitimate sites: an outdated CMS or plugins, weak credentials, or poor server security. Where possible, listings target **hostnames rather than the whole domain**, to avoid blocking the legitimate site. The removal steps Spamhaus prescribes are: take the site offline while you fix it, remove infected files, update the CMS and all plugins and extensions, audit server security, and change all passwords and turn on two-factor authentication (2FA). For an ESP, this is the family of codes to check when the domain of a customer's own website (used in links) is listed but the customer's mail practices look clean. ### Query mechanics receivers must respect - **Never query IP addresses against the DBL.** An IP query always returns a listing (`127.0.1.255`), by design, so that a misconfigured filter that rejects mail with links to IP literals fails visibly. - **Wildcarding**: the DBL lists domains at the registered-domain level, and every hostname or subdomain under a listed domain returns a listing (`www.bank.phish.example.tld` matches a listing of `example.tld`). Lookalike variations of the domain do not match. - Check at three stages: the rDNS domain of the connecting IP address at connection; the HELO and `MAIL FROM` domains before DATA; and URLs, header domains and contact addresses when the content is inspected. - Test points: `test.dbl.spamhaus.org` returns `127.0.1.2` (the operational test from RFC 5782), `dbltest.com.dbl.spamhaus.org` returns `127.0.1.2`, and anything not listed returns NXDOMAIN. - **Validate the range of the response**: only answers within `127.0.1.0/24` are DBL listings. This matters in China, where traffic manipulation by the Golden Shield can alter DNS answers. Any other value means the domain is not listed. (Spamhaus's mirrors in China serve the DBL for IP queries only, so users in China get domain answers from outside the country.) - The DBL works in RPZ ("DNS firewall") deployments and for filtering spam in blog comments. Microsoft Exchange has no built-in support for domain DNSBLs (third-party products are required). ### DBL delisting - **Automatic**: most listings expire on their own after the activity that triggered them stops. For a short-lived listing, fixing the cause and waiting is often the whole workflow. - **Manual**: use the form in the Reputation Checker. "Using the form does not guarantee removal," and people who ask for removal too often get blocked. Approved removals are processed immediately, within minutes at Spamhaus, but receivers' local copies may lag by **up to 24 hours** (contact Spamhaus if the domain is still listed 24 h after approval). - **Listing again is automatic** if the problem is detected again, so a delisting without a fix to the root cause does not last. - Delisting is always free. ### DBL guidance for URL shorteners / redirectors (ESP click-tracking domains behave identically) Spamhaus advises these services to check every destination domain against the DBL **before** creating a short link, and to check again later (after about 1 day and about 1 week). Reject destinations whose A records are on the SBL (and optionally the XBL). Never allow the destination URL to change after the link is created, and do not chain links through other shorteners. Suspend abusive links with a 404 or 410 response (not an interstitial page). Require a CAPTCHA or other bot prevention to create links, consider ZRD to filter out domains that were just registered, and run `abuse@` and `postmaster@` addresses and feedback loops for the service. An ESP whose shared click-tracking domain is listed on the DBL has usually ignored several of these at once. ## Querying the zones correctly (DNSBL usage FAQ) A receiver, including an ESP that filters its own inbound mail or mail on its platform, must follow these rules: - **Query only ZEN** for IP checks: "The subzones of Zen (SBL, XBL, PBL) should not be queried separately," and never combine ZEN queries with queries to the SBL, XBL or PBL. One ZEN answer already carries every code that applies. - **Do not apply DNSBLs to outbound mail**, "particularly PBL", because your own smarthost customers legitimately sit in PBL space. Policing outbound mail needs different tools (see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring)). - **Never query through public resolvers** (8.8.8.8, Cloudflare, Quad9, resolvers shared by ISP customers) unless the resolver supports EDNS Client Subnet (ECS). The originating network must be identifiable. Queries through anonymous resolvers get the answer `127.255.255.254`. Queries from large shared-hosting environments are refused. - **Treat error codes as "do not block"**: `127.255.255.254` (a query through an anonymous or public resolver), `127.255.255.255` (query volume exceeded) and `127.255.255.252` (a typo in the zone name). A filter that treats these as listings rejects all mail. - **Test** from the mail server's own network: `dig 2.0.0.127.zen.spamhaus.org +short` must return `127.0.0.x`, and `dig 1.0.0.127.zen.spamhaus.org +short` must return NXDOMAIN. The Blocklist Tester at `blt.spamhaus.com` checks the whole chain by sending test emails. - **Access tiers**: the free public mirrors are for small and medium non-commercial organizations within fair use. The DNSBL fair-use policy publishes no hard number, and commercial spam-filter services and ISPs must subscribe whatever their volume. The free **DQS** tier is limited to "not consistently exceed **100,000 queries per day**," for non-commercial use. Above that, use paid DQS or the rsync **Data Feed** (a local zone transfer, which requires running your own resolver). DQS also carries some datasets available only through it, such as ZRD, HBL and AuthBL. - **Do not automate lookups against check.spamhaus.org.** The web checker is for manual use, and automated use gets the querying IP address firewalled. ## Delisting workflow summary | List | Code | Who can delist | Mechanism | Timing | |---|---|---|---|---| | SBL | 127.0.0.2 | Only the responsible ISP or network | Fix the problem permanently, then the abuse desk writes to the SBL Removals Team to explain the fix. Proof of consent may be required | The zone reloads every 5 min once removal is approved. Investigation time varies | | CSS | 127.0.0.3 | Self-service (limited number of uses) | Fix the cause (rDNS, HELO, hygiene), then use the checker, or wait | Expires automatically about 72 h after the last detection. Listed again at once if not fixed | | XBL | 127.0.0.4 | Self-service | Remove the malware or fix the compromise, then use the checker | Listed again quickly if the infection persists | | PBL | 127.0.0.10/.11 | The holder of the IP address (single IP) or the ISP that owns the space (ranges) | The checker (static IP, a mail server, matching DNS, and a requester not using freemail). ISPs use their PBL account | About 15 min. The exclusion expires after 1 year and is reversed if spam is detected | | DBL | 127.0.1.x | Domain owner | Automatic expiry, or the checker form (no guarantee) | Immediate on approval. Receivers can lag by up to 24 h | All checks and requests start at the **[IP & Domain Reputation Checker](https://check.spamhaus.org/)**. It is free, needs no account for checking, and automatically evaluates the IP address you visit it from. The live tool is a JavaScript application behind bot protection, and nothing beyond its landing text could be captured ("Do you have problems sending email? … Relax, you're in the right place", from a Wayback snapshot dated 2026-07-09). Its behavior as described above comes from Spamhaus's official blocklist and FAQ pages. Removal from a Spamhaus zone does not immediately unblock delivery. Receivers refresh their copies on their own schedule (within minutes for users of DQS or ZEN, and up to 24 h for the slowest), and the damage to your reputation at each receiver fades separately. # URL Reputation and Content Fingerprinting > How modern content filters judge message bodies — URL/domain reputation lists (SURBL zones, query mechanics, redirector handling) and fuzzy hashing (rspamd shingles, near-duplicate campaign detection) — and what that means for senders' link domains and templates. Source: emailmarketing.net — https://emailmarketing.net/learn/reference/url-and-content-filtering A message can be fully authenticated and sent from a clean IP address and still be filtered because of what it contains. The reputation of IP addresses and sending domains ([blocklists](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)) judges who is sending. Content filters add two more checks that judge what is being sent: the reputation of every domain linked in the message body, and a fuzzy fingerprint of the message that is matched against spam campaigns seen before. Both checks work independently of the sender's own authentication and IP reputation. A message that links to a blocklisted domain, or whose fingerprint matches a known campaign, is filtered anyway. ## Part 1: URL and domain reputation (SURBL) SURBL is the model example of a **URI DNSBL**. Instead of listing sending IP addresses, it lists domains (and some IP addresses) that appear in the bodies of unsolicited or malicious mail. URIBL.com and the Spamhaus DBL and HBL (see [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)) work the same way. Spam filters extract every URL from a message, reduce each one to a domain, and query that domain against these zones. A match typically adds a heavy score or blocks the message outright. ### List zones and return values The public data is served as one combined zone with bitmasked values, **`multi.surbl.org`**, which brings together these datasets: | List | Meaning | Bit value (last octet) | |------|---------|------------------------| | DM | Disposable email domains | 4 | | PH | Phishing sites | 8 | | MW | Malware sites | 16 | | CT | Click-tracker domains | 32 | | ABUSE | General abuse or spam sites | 64 | | CR | Cracked (compromised legitimate) sites | 128 | - Responses are A records in the form **127.0.0.X**. A domain on several lists returns the sum of their bits. For example, **127.0.0.80 means MW plus ABUSE (16 plus 64)**. - **NXDOMAIN** means the domain is not listed, and an A record means it is listed. SURBL states that the A record is "the strongly preferred response for automated use." - The default **TTL is 60 seconds** on the live multi zone, and the data itself is updated roughly **every 30–40 seconds**. - A response of **127.0.0.1** is not a listing. It signals that the querier's access is blocked because of excessive volume on the public mirrors, and that the querier must sign up for SURBL's Sponsored Data Service. - Beyond its domain lists, SURBL also runs **HASHBL**, reputation queries based on hashes, in these categories: abuse, cracked, malware, phish, email, crypto, phone. - For filter operators, data is delivered as DNS (Private Query Service), rsync (recommended for high-volume mail filtering), RPZ (web filtering), a REST API, CSV, and RTF (real-time feeds in JSON). The very existence of the **CT (click tracker)** list matters: tracking and redirect domains are a listing category in their own right, not an edge case. ### How filters extract and query URLs (SURBL implementation guidelines) SURBL's published guidance to filter developers describes what production content filters actually do: 1. **Extract every URI** from the message, **fully resolving redirections to the final target domain**. In other words, filters are told to follow redirectors and shorteners to the destination and check that domain, not only the visible link. 2. Reduce URIs to domains or subdomains. With the wildcarded multi zone, subdomains of a listed domain match automatically, so filters do not need to normalize to the level of the registered domain. 3. **Do not resolve the extracted domains in DNS.** The domain string itself is the lookup key. 4. Query by prepending the domain to the zone (`domainundertest.com.multi.surbl.org`) and doing an A-record lookup. 5. **URLs with numeric IP addresses** (`http://10.20.30.40/`) are checked with the octets reversed, as DNSBLs do: `40.30.20.10.multi.surbl.org` (octets in base 10). 6. Keep a **local allowlist** of well-known, high-traffic domains (yahoo.com, w3.org, google.com) to avoid pointless queries. 7. **Check that answers fall within 127/8.** An answer outside 127.0.0.0/8 indicates a DNS resolver that uses wildcards or redirects and corrupts the results; run a local caching nameserver. SURBL explicitly prohibits two practices, because both cause false positives with shared hosting: do **not** use URI data from message bodies to check sender IP addresses, and do **not** resolve listed domains to IP addresses and blocklist those IP addresses. ### What this mechanism implies - Listing one domain affects **every message that links to it**, from every sender and on every IP address. For an ESP, a URI DNSBL listing of a shared domain is an incident that affects many customers. - Because filters resolve redirects, hiding a bad destination behind a shortener or your own redirect domain does not evade the check. Instead, it exposes **your redirect domain** to listing when the destinations behind it are abused. This is exactly what SURBL's CT list captures. - Because subdomains of a listed domain match under the wildcarded zone, a listing at the level of the registered domain takes down every customer subdomain beneath it. ## Part 2: content fingerprinting with fuzzy hashing (rspamd) Fuzzy hashing detects that a message is a **near-duplicate of spam reported before**, even after the spammer changes it. rspamd's `fuzzy_check` module and `fuzzy_storage` worker are a fully documented open implementation. Commercial fingerprinting systems, and shared hash networks such as Razor, Pyzor and DCC, follow the same principles. rspamd also provides a public shared fuzzy feed that many installations query by default, so a fingerprint learned anywhere can add to scores everywhere. ### How the fingerprint is built: shingles - The message text is split into words, then into **overlapping sequences of three words (trigrams)**, called "shingles." - Each shingle is hashed with **multiple hash functions (32 hashes per shingle)**, and the fingerprint of the message is the set of these hashes. (rspamd cites Broder's research on resemblance and shingling as its basis.) - Comparison is **probabilistic**. Similarity is computed from the number and positions of shingle hashes that match between the candidate message and the stored hashes, which gives a percentage match rather than exact equality. - Hash algorithms for text: `mumhash` (the current default, and recommended), `xxhash`, `fasthash`, `siphash` (legacy). Changing the algorithm invalidates all stored data. - **Images and attachments are matched exactly**, not fuzzily, using blake2b digests of their content. A single changed byte breaks the match. This is why image spam campaigns render their images again for each send, and why filters combine exact hashes with perceptual image hashing elsewhere. Key defaults in `fuzzy_check`: `min_bytes = 1k` (the minimum size of an attachment or image considered), `min_height/min_width = 32` px for images, `min_length = 0` (all text parts are checked), `text_multiplier = 4.0`, `timeout = 2s`, `retransmits = 1`. `mime_types` selects which attachment types (for example `application/*`) are hashed, and `short_text_direct_hash` hashes texts too short for shingling exactly. ### HTML-structure fuzzy hashing (rspamd v3.14+) Since v3.14.0, rspamd can also fingerprint the **structure of the DOM**, independently of the text. It uses tokens of the form `tagname[.class][@domain]` (for example `a.button@example.com`). Only the first CSS class is used, known tracking classes are filtered out, and link domains are normalized to eTLD+1. The combined hash is weighted as follows: structure shingles 50%, **call-to-action (CTA) domains 30%**, all link domains 15%, and counts of features (tags and links) 5%. To avoid matching generic templates, it requires at least `min_html_tags` (default 10; example configurations use 15), at least 2 links, and a DOM depth of at least 3. The weight on CTA domains targets phishing. A phishing message that perfectly clones a brand's template gets a structure similarity of ~0.9, but with different CTA domains the combined similarity collapses (the documented example: 0.9 structure similarity with mismatched CTA domains gives a combined 0.45). Conversely, a spam campaign that keeps its CTA domain while shuffling its copy still matches. ### Why mutations and token stuffing don't evade it The fingerprint is a large set of overlapping word-trigram hashes, compared probabilistically. As a result: - **Small edits** (swapped words, inserted names, reordered paragraphs) change only the shingles that overlap the edit. Most shingles still match, and similarity stays above the threshold. - **Token stuffing** (appending random words, hidden text, or strings meant to break hashes) adds shingles but does not remove the ones that match. It only dilutes the similarity ratio slightly, while the absolute number of known-bad shingles still matches. Defeating shingle matching requires rewriting essentially the whole body, and even then HTML-structure hashing (v3.14+) still matches the unchanged template and CTA domain. - Merge fields for each recipient, unsubscribe URLs and tracking tokens also leave most of the shared shingles intact. This is exactly why a campaign reported by its early recipients is recognized in the rest of the send. ### Weights, thresholds, and gradual scoring Stored hashes carry a **weight** that grows as sources (user reports, trap hits, honeypots) report the same fingerprint again. Scoring is deliberately gradual, not all or nothing: - Each flag or rule has a `max_score` (a threshold on hash weight). Below the threshold, the symbol scores 0. The score then rises from the threshold to **2× the threshold**, along a hyperbolic tangent curve: ≈50% of the metric weight at the threshold, and the full score at 2×. For example, with a report weight of 1 and a threshold of 20, a fingerprint needs ≥ 20 independent complaints before it scores at all. - Hashes are organized by numeric **flags** that map categories to symbols. The conventional layout: flag 1 is confirmed spam (`FUZZY_DENIED`, max_score 20), flag 2 is probable spam (`FUZZY_PROB`, max_score 10), and flag 3 is legitimate, allowlisted content (`FUZZY_WHITE`, max_score 2). Flag numbers must be unique across writable rules, and `skip_hashes` allowlists specific fingerprints. - Learning: `rspamc -f -w fuzzy_add ` (or `-S FUZZY_DENIED`) adds a hash, and `fuzzy_del` removes one. `read_only = true` makes a rule query-only, and an optional learning condition written in Lua can block learning or change its flag. On the operational side, the fuzzy_storage worker: - has a single-writer architecture, with an update queue synced to disk every `sync = 1min`; - stores data in SQLite (the default) or Redis; - lets hashes **expire** through `expire` (90d is the recommended initial value, so old fingerprints age out as campaigns die); - needs roughly 400k hashes per 100 MB of RAM (1.5M ≈ 500 MB); - accepts learning only from `allow_update` IP addresses; - supports optional Curve25519 transport encryption (`encrypted_only = true`), and master and slave replication (TCP 11335) with flag translation for each slave. ## Sender implications Together, the two mechanisms lead to concrete rules for anyone running an ESP or a sending program: - **Every domain in the body carries reputation**: link domains, image-hosting domains, redirect and click-tracking domains, and even domains that appear in plain text. Their reputation is evaluated separately from the From domain and the sending IP address. - **Customers who share a tracking domain share its fate.** A click-tracking or link-wrapping domain used across an ESP combines the reputation of every customer's destinations. One abusive customer can get it listed on a URI DNSBL (SURBL's CT category exists for exactly this), which filters every customer's mail at once. The mitigations are tracking subdomains for each customer on domains the customer owns (through a CNAME), proactive URI DNSBL monitoring of tracking domains, and screening destination URLs against SURBL, URIBL and the DBL at send time. - **Public shorteners do more harm than good.** Filters resolve them to the destination anyway, and the shortener's domain carries the accumulated reputation of everyone who has abused it. See [Content & Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability). - **Keeping link domains clean is an ongoing monitoring task**, not a one-time check. Query your tracking, image and landing domains against multi.surbl.org (and the Spamhaus DBL) as often as you check IP blocklists, and check the URLs of every outbound campaign before you send it. - **Fingerprinting makes complaints count against the rest of the send.** The first few thousand recipients who report a campaign create its fuzzy hash and add weight to it, and the rest of the same send then matches it. Sending in segments with pauses (to the most engaged recipients first, watching early complaint signals, then continuing) takes direct advantage of the scoring window between the threshold and 2× the threshold. - **Changing a template does not reset its content reputation.** Minor changes to the copy, rotating subject lines, or personalizing merge fields leave the shingle fingerprint (and the fingerprint of the HTML structure and CTA domains) intact. The only real reset is genuinely different content sent to an audience that wants it. Content reputation is a symptom of list quality, not a problem to solve by engineering the content. - **Consistent CTA domains cut both ways.** Keeping your links on your own stable domains with good reputation helps structure hashing tell you apart from phishing clones of your template. Scattering links across throwaway domains looks like evasion. ## Related articles - [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus), on how DNSBLs for IP addresses and domains work, including the Spamhaus DBL and HBL, the other major datasets of domain reputation - [Content & Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability), with the practical content rules (shorteners, images, links) that these mechanisms explain - [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring), on where URI DNSBL checks of tracking and link domains belong in a monitoring program # ESMTP Extensions for Senders — SIZE, PIPELINING, CHUNKING, DSN > What RFC 1870 SIZE, RFC 2920 PIPELINING, RFC 3030 CHUNKING/BINARYMIME, and RFC 3461 DSN (NOTIFY/RET/ENVID/ORCPT) do, and when each matters on an ESP's outbound path. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/esmtp-extensions If you run a sending MTA, four SMTP service extensions have a direct effect on your outbound throughput and on the quality of your bounce data: SIZE, PIPELINING, CHUNKING and DSN. Below is what each one does and when it matters. ESMTP extensions are negotiated for each session. The server lists keywords in its `EHLO` response, and the client may then use the matching commands and parameters. A sending MTA should parse the EHLO extension list on every connection and adapt to it. Other extensions are covered elsewhere: 8BITMIME (RFC 6152) and SMTPUTF8 in [MIME & Encoding](https://emailmarketing.net/learn/rfc/mime-and-encoding) and [SMTPUTF8 and EAI](https://emailmarketing.net/learn/rfc/smtputf8-eai), and STARTTLS in [transport security](https://emailmarketing.net/learn/transport-security/mta-sts). ## RFC 1870 — SIZE (message size declaration) - **EHLO keyword:** `SIZE`, with an optional numeric parameter giving the fixed maximum message size, in octets, that the server will accept. `SIZE 0` means there is no fixed maximum. `SIZE` with no number gives no information about a limit. - **MAIL parameter:** `MAIL FROM:<...> SIZE=nnn` (1–20 digits). The declared size is the number of octets the client will send after the `354`, **including CRLF pairs but excluding the terminating dot and the extra dots added by dot-stuffing**. In other words, it is the headers and body as sent. An estimate is fine, and estimates should err on the high side. - **Server replies:** `552` is permanent (the declared size exceeds the fixed maximum, so do not retry at that server). `452` is temporary (the server lacks resources right now, so retry later). The server may check the size at MAIL time or after DATA. It may accept a message larger than declared, and should not send a `552` after DATA unless the actual size exceeded the declared size. **When it matters:** declaring SIZE turns an oversized send into a cheap rejection before DATA, instead of transferring megabytes and receiving `552` after the final dot. At scale, that saves real bandwidth and queue time. Reading the advertised limit lets the MTA fail oversized messages locally with a clear bounce ("exceeds example.com's 26214400-octet limit"), and lets a platform enforce composition limits for each destination. Remember that the advertised limit applies to the **encoded** message, and base64 adds ~37% (see [MIME & Encoding](https://emailmarketing.net/learn/rfc/mime-and-encoding)). Distinguish the `552` from SIZE (the message is too big, a content problem) from the `552` "exceeded storage allocation" in RFC 5321 (the mailbox is full, a recipient problem). The enhanced status code tells them apart (`5.3.4` for the first, `5.2.2` for the second). ## RFC 2920 — PIPELINING (command batching) - **EHLO keyword:** `PIPELINING`, with no parameters. Never pipeline commands to a server that did not advertise it. - **What may be pipelined:** `RSET`, `MAIL FROM` and `RCPT TO` (and the obsolete SEND, SOML and SAML) may appear anywhere in a group. **`EHLO`, `DATA`, `VRFY`, `EXPN`, `TURN`, `QUIT` and `NOOP` may only be the last command in a group**, because their success or failure changes the session state. NOOP can be used as a synchronization point. - **Client obligations:** check **every** status in the group, matching replies to commands by counting them. You MUST NOT assume that DATA failed just because all the RCPT commands failed: read its reply. Without nonblocking I/O, the client must keep each group within the TCP window to avoid a deadlock. - **Server obligations:** reply in the order the commands were received. Buffer replies to commands that can be pipelined, but never to the commands that end a group. Send a positive `DATA` reply only if ≥1 valid RCPT was accepted. If the server replied 354 with no valid recipients, it must accept the message and discard it. Never flush the TCP input buffer. **When it matters:** without pipelining, a transaction costs one round trip per command (`MAIL`, each `RCPT`, then `DATA`, for a total of N+2 round-trip times, or RTTs). With pipelining, `MAIL FROM`, all the `RCPT TO` commands and `DATA` go out in one write, about 1 RTT before the content. Over a 100 ms transatlantic path, that is the difference between ~3–4 messages per second per connection and ~10+. Pipelining is the cheapest way for an outbound MTA to multiply its throughput before it adds connections, which [provider connection caps](https://emailmarketing.net/learn/providers/microsoft-sender-requirements) limit anyway. Almost all major receivers advertise it. One caution: some anti-spam layers treat "early talkers" (clients that send before the greeting banner, or pipeline without the extension being advertised) as bots. Negotiate strictly. ## RFC 3030 — CHUNKING (BDAT) and BINARYMIME - **EHLO keywords:** `CHUNKING` (which enables `BDAT`) and `BINARYMIME` (binary content with no transfer encoding, usable **only** together with CHUNKING). - **BDAT syntax:** `BDAT chunk-size [LAST]`. The exact number of octets follows immediately after the command's CRLF. There is no dot-stuffing and no scanning for a `.` terminator. The final chunk carries `LAST`, and it may be empty. The server MUST reply `250` to each successful chunk. - **Errors:** if a failure occurs during the transaction, the server MUST still read and discard the announced chunk octets before it replies `4xx` or `5xx`. After any `4xx` or `5xx` reply to a BDAT command, the client MUST NOT send further BDAT segments, and should send `RSET` to clear the transaction. - **Mixing rules:** `DATA` and `BDAT` MUST NOT be mixed in one transaction (`503`), although both may appear in different transactions of the same session. `BODY=BINARYMIME` on the MAIL command commits the transaction to BDAT, so `DATA` after it gets `503`. A receiver that accepts BINARYMIME must preserve every bit of every octet from then on. `text/*` content must still use CRLF line endings. **When it matters:** for typical marketing mail, rarely. The messages are small and already safe as 7-bit, and several large receivers do not advertise CHUNKING, so the DATA path must exist anyway. CHUNKING matters for very large messages (no scanning for the terminator, and exact accounting), for truly binary payloads that would otherwise grow by base64's ~37%, and in some modern submission paths where BDAT is the native framing. A note on interoperability: bugs in how filters and gateways handle BDAT have caused parsing discrepancies in the past (BDAT was a vector for SMTP smuggling at receivers), so some operators deliberately leave it off. Treat it as an optimization to enable for each destination, never as a requirement. ## RFC 3461 — DSN extension (NOTIFY / RET / ENVID / ORCPT) This extension is the SMTP side of delivery status notifications. It controls **when** DSNs are generated and carries correlation data through to them. [RFC 3464](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) defines the format of the bounce itself. - **EHLO keyword:** `DSN`, with no parameters. **Parameters for each recipient (`RCPT TO`):** | Parameter | Values and syntax | Meaning | |---|---|---| | `NOTIFY` | `NEVER` \| a comma-separated list of `SUCCESS`,`FAILURE`,`DELAY` | `NEVER` must appear alone, and means no DSN under any conditions. `SUCCESS`: a DSN on delivery. `FAILURE`: a DSN on failure. `DELAY`: the sender is willing to receive DSNs about delays. If the parameter is absent, the receiver's default applies, which in effect is `FAILURE` or `FAILURE,DELAY` | | `ORCPT` | `addr-type;xtext-address` (e.g. `rfc822;user+2Btag@example.com`), ≤500 characters | The original recipient as the sender specified it. It is passed on unchanged through forwarding, so the DSN's `Original-Recipient` field survives address rewrites. At submission it must match the RCPT TO address | **Parameters for each message (`MAIL FROM`):** | Parameter | Values and syntax | Meaning | |---|---|---| | `RET` | `FULL` \| `HDRS` | Whether failure DSNs return the whole message or only its headers (success DSNs return the headers at most). If absent, the receiver chooses | | `ENVID` | xtext, ≤100 characters (user agents are advised to use ≤38) | An opaque transaction ID from the sender, returned unchanged in the DSN's `Original-Envelope-Id` field. It links a bounce directly to its send, without parsing message headers | - **xtext encoding:** printable ASCII characters 33–126, except `+` and `=`, pass through unchanged. Every other character becomes `+HH` (uppercase hexadecimal). Values must be US-ASCII before encoding. - **Effect on command lines:** a conforming MTA must handle command lines of at least 1036 characters (512 for the base command, plus 530 for the ORCPT and NOTIFY parameters on RCPT). - **Server neutrality:** a server MUST NOT refuse a MAIL or RCPT command only because it carries valid DSN parameters. Malformed or duplicate parameters get `501`. - **Relay rules:** when the next hop supports DSN, ENVID, RET, NOTIFY and ORCPT MUST be passed on exactly (ORCPT with its case preserved, and a relay may add ORCPT if it is absent). When the next hop does **not** support DSN, the parameters MUST NOT be sent, and the relaying client makes up for it instead. With `NOTIFY=SUCCESS` and the message accepted, it MUST generate a "relayed" DSN. On failure (5xx), it generates a "failed" DSN unless `NOTIFY=NEVER` was set. With `NOTIFY=NEVER`, no DSN is ever sent. - **Mailing lists:** when a list redistributes a message, it MUST NOT carry the DSN parameters of the original submission. The list sets its own, with its own return path. Tracking of successful delivery therefore stops at the list: a submission with `NOTIFY=SUCCESS` gets its success DSN from the MTA that delivered it to the list. **When it matters for an ESP:** - **`NOTIFY=NEVER` is the most useful setting in practice.** RFC 3834 recommends it for auto-replies. It is equally useful for any traffic whose bounces you plan to detect another way, or do not want at all (for example, probe traffic). Where the receiver honors it, it stops non-delivery reports (NDRs) from being generated at the source. Do **not** use it on normal campaign mail, because you need failure DSNs for [bounce processing](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications). - **`ENVID`** links each bounce to its message even when the returned content has been stripped. It complements VERP: VERP still works with bounces that do not follow RFC-3464, and ENVID still works through forwarders that break VERP. It costs little, so set it. - **`RET=HDRS`** keeps failure DSNs small, which is polite and saves bandwidth when your messages are large. - **`NOTIFY=SUCCESS` is not a tool for tracking delivery** at scale. Most large mailbox providers ignore it or do not send success DSNs, and requesting a success notification for every recipient of millions of messages would create a traffic problem of its own. Rely on SMTP acceptance and engagement signals instead. ## Reading an EHLO response: a checklist for senders | Keyword seen | Sender action | |---|---| | `SIZE n` | Reject or bounce locally any message whose encoded size is > n, and declare `SIZE=` on MAIL | | `PIPELINING` | Send MAIL, the RCPT commands and DATA in one write, and check every reply by count | | `8BITMIME` | You may send `BODY=8BITMIME`. Otherwise, make sure the content uses quoted-printable (QP) or base64 encoding (never "just send 8-bit") | | `CHUNKING` | You may use BDAT, but keep DATA as a fallback | | `DSN` | Add ENVID and RET (and NOTIFY where appropriate), and expect bounces in the RFC 3464 format | | `SMTPUTF8` | Recipients with internationalized addresses (EAI) can be delivered on this hop. See [SMTPUTF8 and EAI](https://emailmarketing.net/learn/rfc/smtputf8-eai) | | `STARTTLS` | Negotiate TLS before sending mail (required by [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) policies) | ## Related articles - [RFC 5321 — SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the base protocol and its reply codes - [Delivery Status Notifications (RFC 3464)](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications), the DSN format these parameters control - [RFC 3834 — Auto-Replies](https://emailmarketing.net/learn/rfc/rfc3834-auto-replies), where `NOTIFY=NEVER` is recommended - [MIME & Encoding](https://emailmarketing.net/learn/rfc/mime-and-encoding), on the encoding choices that SIZE, 8BITMIME and BINARYMIME interact with # MIME & Transfer Encodings (RFC 2045/2046) > Deliverability-focused MIME digest: structure and headers, multipart/alternative ordering, quoted-printable and base64 rules and pitfalls, size inflation, and the malformed-MIME defects that trigger filtering. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/mime-and-encoding Every HTML campaign you send is a MIME message, and defects in its encoding or structure are a recurring cause of broken rendering and filter penalties. MIME extends the [RFC 5322 message format](https://emailmarketing.net/learn/rfc/rfc5322-message-format), which allows only ASCII text in lines, so that a message can carry several parts, non-ASCII text and binary data over transports that only guarantee 7-bit lines. RFC 2045 defines the framework and the encodings, and RFC 2046 defines the media types. ## The five MIME header fields (RFC 2045) | Field | Requirement | Notes | |---|---|---| | `MIME-Version: 1.0` | MUST be present, exactly as written, on every MIME message | Without it, receivers may treat the message as plain text from before MIME | | `Content-Type: type/subtype; parameter=value` | The subtype is mandatory. The names of the type, the subtype and the parameters are case-insensitive, and parameter values are case-sensitive unless defined otherwise | Default when absent: `text/plain; charset=us-ascii` | | `Content-Transfer-Encoding: mechanism` | One of `7bit` (the default), `8bit`, `binary`, `quoted-printable`, `base64`, or an extension | See below | | `Content-ID: ` | Optional; MUST be unique worldwide | Used to reference inline images (`cid:`) from HTML parts | | `Content-Description` | Optional, in US-ASCII (RFC 2047 for non-ASCII) | Rarely matters in practice | ## Content-Transfer-Encoding mechanisms | Mechanism | Constraint on the data | Actually transforms? | |---|---|---| | `7bit` | Lines of at most 998 octets between CRLFs; no octets above 127; no NULs | No. It declares that the data already conforms | | `8bit` | Lines of at most 998 octets; octets above 127 allowed; no NULs; CR and LF only as CRLF pairs | No. It requires the 8BITMIME SMTP extension from end to end | | `binary` | Any sequence of octets, with no limit on line length | No. It requires BINARYMIME and [CHUNKING](https://emailmarketing.net/learn/rfc/esmtp-extensions), and is essentially unused in Internet mail | | `quoted-printable` | The output is 7-bit, with lines of at most 76 characters | Yes | | `base64` | The output is 7-bit, with lines of at most 76 characters | Yes | **Restriction on composite types:** it is "EXPRESSLY FORBIDDEN" to use any encoding other than `7bit`, `8bit` or `binary` on `multipart/*` or `message/*` entities. Encoding applies only to leaf parts, never to a container, which prevents nested passes of encoding and decoding. RFC 6532 later relaxed this for `message/global` only (see [SMTPUTF8 and EAI](https://emailmarketing.net/learn/rfc/smtputf8-eai)). ### Quoted-printable rules (RFC 2045 §6.7) Quoted-printable (QP) is designed for data that is mostly ASCII text, so the encoded output stays largely readable by people. 1. Any octet may be represented as `=XX` with **uppercase** hexadecimal digits. Lowercase is not permitted when generating, although robust decoders accept it. 2. Octets 33–60 and 62–126 (printable ASCII except `=`) may appear literally. 3. TAB (9) and SPACE (32) may appear literally, but **MUST NOT be literal at the end of an encoded line**. Trailing whitespace must be written as `=09` or `=20`, because the transport may strip trailing spaces silently. 4. A hard line break in text is represented as a real CRLF. 5. Encoded lines MUST be at most **76 characters** long (not counting the trailing CRLF). Longer lines of content use a **soft line break**: an `=` as the last character, which the decoder deletes along with the CRLF that follows it. 6. When binary data is encoded in QP, CR and LF must be encoded as `=0D` and `=0A` (a binary CRLF becomes `=0D=0A`). QP for binary data is legal, but base64 is the right tool. In practice, QP inflates typical HTML in English or Western European languages only slightly (3 bytes for each encoded octet). For scripts where nearly every character is multi-byte UTF-8, such as Chinese, Japanese and Korean (CJK) or Cyrillic, QP approaches 3× inflation, and base64 (about 1.37×) is smaller. ### Base64 rules (RFC 2045 §6.8) - The alphabet has 65 characters: `A–Z` (0–25), `a–z` (26–51), `0–9` (52–61), `+` (62), `/` (63), and `=` for padding. - 3 input octets become 4 output characters. A final partial group is padded: 1 octet becomes 2 characters plus `==`, and 2 octets become 3 characters plus `=`. Any `=` marks the end of the data. - Encoded output MUST be in lines of at most **76 characters**. - Line breaks in text must be converted to CRLF **before** encoding (the canonical form), so a decoded text part uses CRLF line endings whatever platform composed it. - **Size inflation: 4/3 (about 33%), plus a CRLF every 76 characters, comes to about 37% in total.** Provider limits on message size (for example, Gmail's 25 MB) apply to the encoded message, so a "20 MB attachment" is about 27 MB on the wire. The size declared with the SIZE extension also includes this inflation (see [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions)). ### Choosing an encoding (sender guidance) - For HTML and plain-text parts in UTF-8, `quoted-printable` is the safe universal default. It survives 7-bit hops, keeps diffs and DKIM canonicalization predictable, and avoids depending on 8BITMIME negotiation. `8bit` is fine when your MTA verifies 8BITMIME support on every hop. Support is essentially universal today, but a hop that accepts only 7-bit data must then re-encode the message, which **breaks DKIM signatures**. Sign after the final encoding, or use QP so that no hop ever re-encodes. - For attachments and images, always use `base64`. - Never emit lines longer than 998 octets in any part. Long unwrapped HTML lines are a classic generator bug, and the soft wrapping of QP at 76 characters fixes this at no cost. ## Media types (RFC 2046) The discrete types are `text`, `image`, `audio`, `video` and `application`. The composite types are `multipart` and `message`. Unrecognized subtypes fall back as follows: text with a known charset is treated as `text/plain`, other discrete types as `application/octet-stream`, and an unknown `multipart/*` as `multipart/mixed`. ### Multipart syntax - The `boundary` parameter is **mandatory**. It is 1–70 characters long and must not end in a space. The allowed characters are digits, letters, `'()+_,-./:=?` and the space (but not as the last character). Because `/`, `=`, `?`, `:` and space can appear, the boundary value usually needs quotes in the Content-Type header. - The delimiter is a line that starts with `--boundary`, and the closing delimiter is `--boundary--`. The boundary **must not appear in any encapsulated part**. Generators should use boundaries with high entropy rather than checking the content. - Each body part consists of optional headers, a blank line and the body. Parts with no Content-Type default to `text/plain; charset=US-ASCII`, except inside `multipart/digest`, where the default is `message/rfc822`. - MIME readers ignore the preamble (before the first boundary) and the epilogue (after the closing delimiter). The preamble is occasionally used for a "this is a MIME message" note to legacy clients. ### Multipart subtypes that matter for senders | Subtype | Semantics | Deliverability notes | |---|---|---| | `multipart/mixed` | Independent parts, in order | A message with attachments | | `multipart/alternative` | The same information in alternative renditions. **Parts MUST be in increasing order of preference and faithfulness, with the best and richest version LAST.** Clients display "the last part of a type supported by the recipient system's local environment." | The classic structure is `text/plain` first and `text/html` last. In the reverse order, many clients show the plain-text part. A well-formed pair, where the plain part actually matches the HTML content, has long been a positive signal for spam filters, while an empty or boilerplate plain part is a mild negative | | `multipart/related` (RFC 2387, included for completeness) | HTML with inline `cid:` images | The standard structure for embedded images | | `multipart/digest` | Parts default to `message/rfc822` | Rare in the traffic of email service providers (ESPs) | | `multipart/parallel` | Order is not significant | Effectively unused | | `multipart/report` (RFC 6522) | Machine-readable reports | The container for [delivery status notifications (DSNs)](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) and for feedback loop (FBL) reports in the Abuse Reporting Format (ARF) | The canonical nesting for a campaign is `multipart/mixed( multipart/related( multipart/alternative( text/plain, text/html ), inline images ), attachments )`. Collapse the levels you do not need. ### `message/*` subtypes - `message/rfc822`: a full encapsulated message, used for forwards, FBL reports and the original messages returned in bounces. Its encoding is restricted to 7bit, 8bit or binary. - `message/partial`: fragmented delivery with reassembly (the parameters `id`, `number` starting at 1, and `total` on the last piece; 7bit only). It is obsolete in practice, and filters treat fragmentation as an evasion technique. Never use it. - `message/external-body`: a body by reference (access types FTP, ANON-FTP, TFTP, LOCAL-FILE and MAIL-SERVER). It is also effectively dead, and filters treat it as suspicious. ### text/plain and charsets The default charset is `US-ASCII`, which means ANSI X3.4-1986 specifically. Always declare `charset=` explicitly, and label content with the lowest common denominator that actually covers it. In modern practice, use `charset=utf-8` everywhere and the question is settled. ## Malformed-MIME defects that trigger filtering Spam filters score MIME conformance because sloppy generators correlate with spamware. SpamAssassin's `MIME_*` family of rules, and the equivalent rules in commercial filters, test exactly these defects. They are worth linting for in an ESP's message builder: | Defect | RFC rule violated | |---|---| | Missing `MIME-Version: 1.0` on a message with MIME structure | 2045 §4 MUST | | Missing or unmatched final `--boundary--` closing delimiter | 2046 §5.1.1 | | Boundary string that occurs inside the body of a part | 2046 §5.1.1 "must not appear inside any of the encapsulated parts" | | Raw 8-bit bytes in a part declared `7bit` or `quoted-printable`, or in headers | 2045 §2.7 and §6.7 | | Lines over 998 octets (unwrapped HTML) | 2045 §2.7; [5321 limit](https://emailmarketing.net/learn/rfc/rfc5321-smtp#size-limits-section-4531--minimums-implementations-must-handle) | | QP lines over 76 characters, lowercase `=xx` hex, literal trailing whitespace | 2045 §6.7 rules 3 and 5 | | Base64 with invalid characters or broken padding | 2045 §6.8 | | Content-Transfer-Encoding other than 7bit, 8bit or binary on a multipart | 2045 §6.4 | | Charset declared but content not valid in it (for example, a `us-ascii` label on an 8-bit body) | 2045 §5.2; 2046 §4.1 | | `multipart/alternative` with HTML before plain text, or HTML alone inside an alternative | 2046 §5.1.4 ordering | | Bare CR or LF (not in CRLF pairs) in transmitted data | 2045 §2.8; 5321 | | `message/partial` fragmentation | Filter evasion heuristic | None of these defects alone typically blocks delivery at the major providers, but their effect adds to reputation. Several of them (boundary bugs, encoding mismatches) also visibly corrupt rendering, which drives "report spam" clicks. ## Related articles - [RFC 5322 (Message Format)](https://emailmarketing.net/learn/rfc/rfc5322-message-format), the header framework MIME extends - [SMTPUTF8 and EAI](https://emailmarketing.net/learn/rfc/smtputf8-eai), on raw UTF-8 in headers and `message/global` - [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions), including CHUNKING and BINARYMIME - [Content and Design for Deliverability](https://emailmarketing.net/learn/operations/content-and-design-for-deliverability), on content signals beyond structure # RFC 3834 — Automatic Email Responses > The auto-responder rulebook: when not to respond, the Auto-Submitted header, null return-path and loop prevention, and how senders should emit and handle OOO/vacation replies. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc3834-auto-replies Every campaign you send triggers automatic replies such as out-of-office (OOO) notices, and every feature that answers mail automatically can start a mail loop. RFC 3834 is the rulebook for anything that answers mail automatically: vacation and OOO notices, bots that acknowledge tickets, and responders on file servers and mail servers. Two of its contributions matter every day to an email service provider (ESP). The first is the **`Auto-Submitted:` header**, the standard machine-readable marker that says "this was not written by a human". The second is the **discipline of loop prevention**, which stops auto-responders, [bounces](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) and bulk mail from feeding back into each other. An ESP sits on both sides. Its campaigns trigger thousands of OOO replies, and its own transactional and notification traffic must not take part in loops. ## Responder taxonomy | Type | Acts for | Example | |---|---|---| | Service Responder | An address whose whole purpose is to respond; senders expect the response | File retrieval, calendar booking | | Personal Responder | One recipient, following that user's configuration | UNIX `vacation`, OOO | | Group Responder | Many recipients, under uniform criteria | A server-wide notifier for viruses or quarantined mail | ## When a responder must NOT respond Responders "MUST NOT blindly send a response for every message received": - A responder **MUST NOT** respond when the response would go to a null address, that is, when the `MAIL FROM` or `Return-Path` of the subject message is `<>` (bounces and other notifications). This mirrors [RFC 5321's rule](https://emailmarketing.net/learn/rfc/rfc5321-smtp#null-reverse-path-mail-from) that notifications are sent with the null sender. - It **SHOULD NOT** respond to any message that carries `Auto-Submitted:` with a value other than `no`. Auto-replies never answer auto-replies. - It **MAY** refuse to respond to return paths with patterns typical of responders and mailing lists: local parts that match `owner-*`, `*-request`, `MAILER-DAEMON` and similar. - Personal and Group responders **SHOULD NOT** respond unless the recipient's address appears explicitly in a `To:`, `Cc:`, `Bcc:` or `Resent-*` field. This prevents responses to bulk mail sent as Bcc, and to much spam. - A responder **SHOULD NOT** respond to messages with the `Precedence:` values `list`, `junk` or `bulk`. This is a de facto rule that the RFC endorses; `Precedence` is not formally standardized. - **Rate limit:** send the same response to the same sender at most once within a period of several days, with **7 days RECOMMENDED as the default**. Send at most one response per incoming message. - Service responders SHOULD NOT answer badly malformed requests, and SHOULD NOT return large responses (more than a few kilobytes) without verifying that the requester authorized them. This defends against backscatter and amplification. ## Where the response goes - **To the `Return-Path`** after delivery, or to the SMTP `MAIL FROM` reverse path before delivery. It is "really the only [address] that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender." - Personal and Group responders **SHOULD NOT** use `Reply-To:`. `From:` has the same problems, and `Sender:` SHOULD NOT be used either. A Service Responder MAY use `From:`, or an address in the payload, if the specification of its service says so. - If `Return-Path` is missing, the delivery agent has a bug. Do not guess with heuristics. **What this means for an ESP:** OOO replies to your campaigns arrive at your **bounce address or Variable Envelope Return Path (VERP) address**, not at your `From:` or `Reply-To:` address. Your return-path processor must classify them (see below). The VERP encoding tells you which recipient is away, even when the body of the reply is useless. ## How a compliant response is built - **Envelope:** choose a `MAIL FROM` that makes loops unlikely. **`<>` MAY be used**, or a dedicated response address that never responds. `NOTIFY=NEVER` on RCPT is RECOMMENDED where the server supports the [Delivery Status Notification (DSN) extension](https://emailmarketing.net/learn/rfc/esmtp-extensions), because an auto-responder does not want bounces of its own responses. - **Header:** - `Auto-Submitted: auto-replied`. - `From:` reaches the human owner or maintainer. For personal responders, that is the recipient's name and a recognizable address. - `To:` is the single recipient of the response. - `Subject:` is a brief indication that this is an automatic response, followed by the original subject. The prefix `Auto: ` MAY be used (followed by an ASCII space, 0x20). - `In-Reply-To:` and `References:` SHOULD be set from the `Message-ID` of the subject message, as described in RFC 2822 §3.6.4. - `Date:` is the time the response was generated. - `Reply-To:` appears only if a reply is actually wanted, and points to where the reply is expected. - **Body:** brief, in `text/plain`. It SHOULD NOT include significant content, non-text parts or attachments from the subject message. This stops responders from rebroadcasting confidential or malicious content. ## The `Auto-Submitted:` header field The syntax is `Auto-Submitted: value [; parameters]`. The registered values are: | Value | Meaning | Rules | |---|---|---| | `no` | The message originated with a human | Optional; its absence roughly indicates human origin | | `auto-generated` | Sent by an automatic process **not** in direct response to another message (cron alerts, notifications, welcome mail) | MUST NOT be used on direct responses. MUST NOT label DSNs or message disposition notifications (MDNs), which are identified by their own MIME types | | `auto-replied` | Sent by an automatic process in direct response to another message | SHOULD be used on all auto-replies; MAY also appear on DSNs and MDNs | Extension keywords require IETF consensus. The field is the standard key for suppression: mail that carries `auto-generated` or `auto-replied` must never receive an automatic answer. ## Loop prevention, summarized Loops are prevented by defense in depth, and each layer is sufficient on its own: 1. Responses go to the Return-Path, and messages with a null return path never get responses. A responder that sends with `MAIL FROM:<>`, or from a response address that stays silent, can therefore never be answered by a compliant peer. 2. `Auto-Submitted: auto-replied` marks the response, so other responders stay silent. 3. Remembering each sender, and responding at most once per sender per 7 days, caps volume even against a peer that does not comply. 4. One response per incoming message, never more (the defense against "sorcerer's apprentice mode"). ## Guidance for senders (ESP operations) - **Sending automated mail:** every message your platform generates that is not a direct reply (welcome mail, alerts, digests and, arguably, bulk campaigns) can carry `Auto-Submitted: auto-generated`. Anything that answers a user's message carries `auto-replied`. This costs nothing, stops storms of OOO replies coming back at you, and labels your streams honestly for filters. Never put an `Auto-Submitted` value other than `no` on genuine human one-to-one (1:1) mail. - **Never auto-respond to `<>` or to `Auto-Submitted` mail** in any product feature (autoresponders, "thanks for your reply" flows, ticket bots). Doing so generates backscatter, and backscatter gets IP addresses [blocklisted](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus). - **Classifying inbound replies at the bounce address:** an OOO reply is not a bounce. Detect it by `Auto-Submitted: auto-replied`, by subject prefixes such as `Auto: ` or a localized "out of office", and by the absence of a `multipart/report` structure. Then **do not suppress the recipient**. An OOO reply proves that the mailbox exists and received the message, so treating it as a failure removes live subscribers. Microsoft Exchange marks OOO replies with `X-Auto-Response-Suppress` and `auto-replied`. Plenty of responders in the real world do not comply, so keep heuristics alongside the header check. - **Reply tracking features:** exclude messages with `Auto-Submitted != no` from "reply" engagement metrics, and do not let them trigger follow-up sequences. Counting OOO replies as engagement corrupts both analytics and sending logic. - **Expect spikes in OOO volume** after large business-to-business (B2B) sends, especially around holidays. They are normal and harmless. An auto-response loop between your system and a responder is not harmless, and the limits on your side (once per 7 days, once per message) are the guard against it. - **Precedence: bulk** on marketing mail is still a courtesy signal that some responders honor by staying silent. It is non-standard but harmless, and it reduces OOO noise. ## Related articles - [RFC 5321 (SMTP)](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the null reverse-path contract this builds on - [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications), the other kind of automatic mail, identified by format rather than by Auto-Submitted - [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions), including `NOTIFY=NEVER` - [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops) # RFC 5321 — SMTP: The Transport Protocol > Deliverability-focused digest of SMTP: session model, envelope vs. content, reply-code semantics, null sender, retry rules, size limits, and timeouts. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc5321-smtp Every time a receiving server accepts, defers or rejects your mail, it answers in the terms of one protocol. RFC 5321 defines how mail moves between hosts, and every bounce code, retry policy and envelope identity used in deliverability work comes from it. For the vocabulary around it (MTA, MSA, ADMD and so on), see [RFC 5598: Internet Mail Architecture](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture). For the message inside the envelope, see [RFC 5322: Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format). ## Session model An SMTP session is a lock-step dialog, one command at a time. Extensions such as PIPELINING relax this when both sides agree. | Step | Client sends | Server success reply | |---|---|---| | Connect | (TCP connection) | `220` greeting | | Identify | `EHLO client-hostname` (fallback `HELO`) | `250` and the list of extensions | | Envelope sender | `MAIL FROM:` | `250` | | Envelope recipient(s) | `RCPT TO:` (one per recipient, repeatable) | `250` (or `251` forwarded) | | Content | `DATA` | `354`, then the message, ended by `.`, then `250` | | End | `QUIT` | `221` | Other commands: `RSET` (abort the current transaction), `VRFY` and `EXPN` (address verification, widely disabled or answered with `252` to prevent address harvesting), `NOOP` and `HELP`. - A rejection at `MAIL FROM` or `RCPT TO` costs the receiver nothing for each message. A rejection after `DATA` means the receiver has already accepted the bytes. Many providers leave their final judgment (content filtering) to the reply after `DATA`, so a `5xx` after the final dot is a rejection for content or reputation, not an address problem. - The `EHLO` hostname is an identity signal. Receivers commonly check that it is a fully qualified domain name (FQDN) that resolves, and that it is consistent with the reverse DNS (rDNS) of the connecting IP address. RFC 5321 requires it to be the client's primary host name (or an address literal when there is none). ## Envelope vs. content The **envelope** is the addressing at the protocol level: one reverse-path (`MAIL FROM`) and one or more forward-paths (`RCPT TO`). The **content** is everything sent inside `DATA`: the header section and the body (governed by [RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format)). These consequences come up constantly in deliverability: - The address people see (the `From:` header) and the address bounces go to (`MAIL FROM`, recorded at delivery as `Return-Path:`) are independent. SPF authenticates the envelope `MAIL FROM`, and DMARC then tests whether it aligns with the header `From:` (see [DMARC](https://emailmarketing.net/learn/authentication/dmarc)). - Recipients in `RCPT TO` do not need to appear in `To:` or `Cc:`. This is how Bcc and list expansion work. - Relays MUST NOT modify the envelope addresses or the meaning of the message. They only add trace fields at the top (`Received:`, and the final delivery agent adds `Return-Path:`). ## Reply codes A reply code has three digits. The text after the code is for people, and the number is the contract. | First digit | Class | Sender behavior | |---|---|---| | `2yz` | Positive completion | The action succeeded; proceed | | `3yz` | Positive intermediate | Send more (only `354` in base SMTP) | | `4yz` | Transient negative | The failure may clear; **retry later, unchanged** | | `5yz` | Permanent negative | **Do not retry the same request**; bounce and suppress | The second digit gives the category: `x0z` syntax, `x2z` connections, `x5z` mail system status. Modern servers add RFC 3463 enhanced status codes (such as `5.7.1`) after the three-digit code for a finer diagnosis. Key codes: | Code | Meaning | |---|---| | `220` | Service ready (greeting) | | `221` | Closing channel (after QUIT) | | `250` | Requested action OK or completed | | `251` | User not local; will forward to `` | | `252` | Cannot VRFY user, but will accept and attempt delivery | | `354` | Start mail input; end with `.` | | `421` | Service not available, closing channel (also used for rate limiting and for deferrals like greylisting) | | `450` | Mailbox unavailable (temporary, for example busy or greylisted) | | `451` | Local error in processing; retry later | | `452` | Insufficient system storage, or too many recipients; retry | | `455` | Server unable to accommodate MAIL parameters now | | `500`–`504` | Syntax error, command not implemented, or bad parameters | | `550` | Mailbox unavailable (permanent: unknown user, or rejection for policy) | | `551` | User not local; try `` | | `552` | Exceeded storage allocation (message too big for the mailbox) | | `553` | Mailbox name not allowed (bad address syntax) | | `554` | Transaction failed (no valid recipients, or rejection for content or policy) | | `555` | MAIL FROM or RCPT TO parameters not recognized | In practice, receivers are free to use any code with any text. `4xx` deferrals ("try again later", "unusual rate of mail") are the standard soft signal that a provider is throttling you for reputation, and the text of a `550 5.7.x` reply carries the provider's actual reason. Always log the full reply text, not only the code. ## Null reverse-path (`MAIL FROM:<>`) - Delivery status notifications (bounces) and other notifications that the mail system generates MUST be sent with a **null reverse-path**, `MAIL FROM:<>`, so that a failed bounce can never generate another bounce (loop prevention). - Servers MUST accept `MAIL FROM:<>`. Rejecting the null sender breaks bounce handling and does not comply with the standard (although some spam filters score it). - A message received with a null reverse-path must never itself be answered with a DSN to that path. - In practice, any address you use in `MAIL FROM` must be able to receive mail, for bounce processing. The null sender is only for notifications, never for regular sending. ## Retry expectations (Section 4.5.4) - After a `4xx` or a connection failure, the sender queues the message and retries. The retry interval SHOULD be at least **30 minutes** for each destination (a strategy that shortens this when the first attempt failed in the middle of the connection is permitted). - The time before giving up generally needs to be **at least 4–5 days**. After that, a permanent failure notification goes to the reverse-path. - Retries MUST be tracked for each destination host or address, and exponential backoff is encouraged. Repeatedly hitting a host that is deferring you is itself a reputation signal. - On a `5xx`, the sender MUST NOT retry the same message to the same address, and generates a non-delivery notification instead. For list hygiene, suppress hard bounces immediately, and suppress soft bounces after repeated failures across the retry window. - If several MX hosts exist, the client tries them in order of preference (lowest MX value first) before deferring. ## Size limits (Section 4.5.3.1 — minimums implementations MUST handle) | Object | Minimum capacity | |---|---| | local-part | 64 octets | | domain | 255 octets | | path (`<...>` including punctuation) | 256 octets | | command line (including CRLF) | 512 octets | | reply line (including the code and CRLF) | 512 octets | | text line (including CRLF) | 1000 octets | | message content | at least 64K octets; no fixed ceiling, and the limit is advertised through the `SIZE` extension (RFC 1870) | Exceeding a receiver's declared limits draws a `552` (for the message) or a `500` (for a line or command). In modern practice, check the `SIZE=` value in the EHLO response before sending large messages. ## Timeouts (Section 4.5.3.2: minimum client-side waits) | Waiting for | Minimum timeout | |---|---| | Initial `220` greeting | 5 minutes | | `MAIL` reply | 5 minutes | | `RCPT` reply | 5 minutes | | `DATA` reply (`354`) | 2 minutes | | Each data block accepted | 3 minutes | | Reply to final `.` | **10 minutes** | | (Server side) inactivity | 5 minutes | The 10-minute wait at the end of data matters. Providers deliberately delay their verdict after DATA while they filter, and clients that hang up early cause duplicate deliveries: the server delivers the message, and the client retries it. ## Related articles - [RFC 5322: Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format), on what goes inside `DATA` - [RFC 5598: Internet Mail Architecture](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture), on who runs each hop - [DMARC](https://emailmarketing.net/learn/authentication/dmarc), on how envelope and header identities are authenticated and aligned # RFC 5322 — Internet Message Format > Deliverability-focused digest of the message format: required vs. optional headers, From/Date/Message-ID/Reply-To rules, line limits, and malformations that trigger filtering. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc5322-message-format Every message you send has to follow a strict format, and filters at the major providers reject or heavily penalize messages that break it. Getting the format right is therefore a baseline deliverability requirement. RFC 5322 defines that format: the content that travels inside the SMTP `DATA` command. The envelope around it is covered in [RFC 5321 (SMTP)](https://emailmarketing.net/learn/rfc/rfc5321-smtp). A message is a **header section**, made of fields of the form `Name: body CRLF`, followed by an optional **body**. One empty line separates the two. ## Line and length rules - Lines end with `CRLF`. A bare `CR` or a bare `LF` MUST NOT appear. This is a classic malformation introduced by naive scripts. - Each line MUST be at most **998** characters long (not counting the CRLF), and SHOULD be at most **78**. - A header field may be **folded** across lines: a `CRLF` followed by whitespace (a space or a tab) continues the same logical field. Unfolding reverses this. Non-ASCII bytes are not permitted in headers. Encoded words (RFC 2047) are used instead. ## Header field occurrence table (Section 3.6) | Field | Min | Max | Notes | |---|---|---|---| | `Date:` (orig-date) | 1 | 1 | **Required** | | `From:` | 1 | 1 | **Required**; a mailbox list | | `Sender:` | 0 | 1 | **MUST** appear if `From:` has more than 1 mailbox; a single mailbox | | `Reply-To:` | 0 | 1 | An address list | | `To:`, `Cc:`, `Bcc:` | 0 | 1 each | | | `Message-ID:` | 0 | 1 | **SHOULD** be present | | `In-Reply-To:`, `References:` | 0 | 1 each | SHOULD appear in replies | | `Subject:` | 0 | 1 | | | `Comments:`, `Keywords:` | 0 | unlimited | | | Trace (`Received:`, `Return-Path:`) | 0 | unlimited blocks | Added at the top in transit; never added by the author | | `Resent-*` | 0 | unlimited blocks | See below | | Optional and extension fields (`X-*`, `List-*`, …) | 0 | unlimited | Names must be unique unless specified otherwise | Only `Date:` and `From:` are mandatory. A duplicate of any field with a maximum of 1 (two `From:` headers, or two `Subject:` headers) makes the message malformed. A duplicate `From:` is also a known phishing evasion pattern, and filters punish it hard. ## The fields that matter most for deliverability ### `From:` This field names the **author or authors** of the message. It is the identity DMARC evaluates and the one users see. Its syntax is a `mailbox-list`, and the display name is optional: `"Ann Example" `. If more than one mailbox is listed, `Sender:` becomes mandatory. That field holds a single mailbox: the agent responsible for actually transmitting the message. When `Sender:` is absent, the `From:` address is implicitly the sender. Alignment between this domain and the domains authenticated by SPF and DKIM is the core of [DMARC](https://emailmarketing.net/learn/authentication/dmarc). ### `Date:` This field records when the author "pushed send", in `date-time` syntax: `day-of-week, DD Mon YYYY HH:MM:SS ±ZZZZ`. The year has 4 digits and the zone is a numeric offset; names such as `GMT` and `EST` are obsolete syntax. Dates that are far in the past or the future are a spam signal at several providers. ### `Message-ID:` The syntax is `` in angle brackets. Both sides are `dot-atom-text`, with no folding whitespace inside. The generator MUST guarantee **global uniqueness**, conventionally with a unique value followed by @ and your domain. Message-IDs that are missing, repeated across messages, or syntactically broken (no `@`, no angle brackets, not unique) are strong heuristics for bulk mail and spam. Always generate one at submission, with a domain you control. ### `Reply-To:` This field says where the author wants replies to go, in place of `From:`. Legitimate uses include role addresses and the handling of campaign replies. A `Reply-To:` domain that is very different from the `From:` domain is a common scam pattern and is scored accordingly. Keep the two consistent, or make the difference easy to explain. ### `In-Reply-To:` and `References:` These fields contain the `Message-ID` of the parent message, or several of them, and they build threads. When a sequence claims to be a reply (a "re:" in the subject with no real threading headers), the mismatch is detectable. ## Resent and trace fields - **`Resent-From:`, `Resent-Date:`, `Resent-To:` and the other resent fields** are added as a block at the top of the message, most recent first, when a user sends an existing message into the transport again (manual forwarding as a new message). Within a block, `Resent-From:` and `Resent-Date:` are mandatory. The original fields are never altered. - **`Received:`**: each MTA hop adds one at the top. Reading them from the bottom up reconstructs the delivery path. A forged or inconsistent chain of Received fields is a filtering signal. - **`Return-Path:`** is added at final delivery and records the envelope `MAIL FROM` (see [RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp)). Authors MUST NOT set trace fields themselves. ## Common malformations that trigger filtering | Malformation | Why it hurts | |---|---| | Missing `Date:` or `From:` | Violates the only two MUSTs; an instant heuristic hit | | Missing `Message-ID:` | Legitimate mail submission agents (MSAs) add one, so its absence correlates with spamware | | Duplicate `From:`, `Subject:` or `Date:` | Malformed, and a phishing evasion pattern | | Several mailboxes in `From:` without `Sender:` | Violates the specification | | Bare `LF` line endings, lines over 998 characters | Parsers disagree; some MTAs reject outright | | Raw 8-bit or UTF-8 bytes in headers without RFC 2047 encoding (or SMTPUTF8) | Rendering is undefined, and filters penalize it | | Malformed `Date:` (2-digit year, alphabetic zones, impossible values) | Obsolete syntax, and a fingerprint of bulk mailers | | Unmatched angle brackets or comments in address fields | Spoofers exploit the ways parsers disagree, so filters distrust it | | Missing or wrong separator between header and body | Body text is read as headers, or the reverse | | Empty or whitespace-only `Subject:` (allowed, but scored) | A bulk-mail heuristic | The safe rule is to generate messages with a real MIME library, never by concatenating strings, and to validate them with a linter before you increase volume. ## What RFC 5322 does not cover MIME (multipart bodies, attachments, HTML parts, content transfer encoding) is defined in RFC 2045–2049. Internationalized addresses and headers are RFC 6531 and RFC 6532 (SMTPUTF8). `List-Unsubscribe` and the other list headers are RFC 2369, RFC 2919 and RFC 8058. RFC 5322 is only the basic grammar of headers and body that those standards build on. ## Related articles - [RFC 5321 (SMTP)](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the envelope that carries this content - [RFC 5598 (Internet Mail Architecture)](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture), on which actor sets which header - [DMARC](https://emailmarketing.net/learn/authentication/dmarc), which authenticates the `From:` domain # RFC 5598 — Internet Mail Architecture > The vocabulary of email: MUA/MSA/MTA/MDA, ADMDs, actor roles, mediators vs. relays, and which actor sets which identity field. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc5598-email-architecture To diagnose a delivery problem, or to follow a discussion about one, you need exact names for the parts of the mail system. Statements such as "the MSA should add that header" or "forwarding breaks SPF because the mediator is a new originator" only make sense with these terms. RFC 5598 is the specification that defines them. It names the components, actors and administrative boundaries that the transport specification ([RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp)) and the format specification ([RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format)) assume. ## Two worlds - **MUA world (users)**: where messages are created and read. - **MHS (Message Handling Service)**: the store-and-forward network that accepts a message from an Author and delivers it to Recipients. The architecture has three store-and-forward layers: User **Mediators** at the top, **MHS Relays** in the middle, and packet switches at the bottom. ## Actor roles (who is responsible) | Role | Responsibility | |---|---| | **Author** | Creates the content and the recipient list | | **Originator** | Checks the message against standards and local policy, then submits it, and handles the duties that follow submission. It has "dual allegiance": it works for the Author but enforces the rules of its ADMD | | **Relay** | Routes, stores and forwards within the MHS, and adds trace information. It MUST NOT change envelope addresses or the meaning of the message | | **Gateway** | A hybrid of User and Relay that connects different kinds of mail service. It may translate content but must preserve the dialogue between Author and Recipient | | **Receiver** | Performs final delivery (or redirects the message). It may enforce policy immediately before or after delivery, which is where decisions to deliver to the inbox, file as spam or reject are made | | **Recipient** | Reads the message, and may reply or send message disposition notifications (MDNs) | | **Return Handler** (Bounce Handler) | A special recipient of the notifications the MHS generates (DSNs), reached through the return address the Originator supplied | ## Functional components | Component | Full name | Function | Key facts | |---|---|---|---| | **MUA** | Message User Agent | The mail client of the Author (aMUA) or of the Recipient (rMUA) | The aMUA creates and submits. The rMUA displays, replies and files | | **MSA** | Message Submission Agent | Accepts submission from the aMUA, and enforces ADMD policy and conformance to standards | Port **587** (SUBMISSION, RFC 4409 and 6409), authenticated, compared with port 25 for relay. Split into the aMSA (acts for the Author, and may add `Date:` and `Message-ID:` or fix headers) and the hMSA (acts for the MHS and takes responsibility) | | **MTA** | Message Transfer Agent | Relays the message one application-level hop over SMTP | Adds `Received:`. Does not change envelope addresses or editorial content (it may re-encode the MIME Content-Transfer-Encoding, CTE). Variants: Boundary (or Border) MTA, which crosses ADMDs, and Outbound, Inbound and Final MTAs | | **MDA** | Message Delivery Agent | Transfers responsibility from the MHS to the Recipient's environment | Split into the hMDA (facing SMTP) and the rMDA (applies actions at delivery time, for example filtering into folders). Writes `Return-Path:` | | **MS** | Message Store | Where messages rest | aMS (drafts, queue and sent mail) and rMS (received mail, accessed over IMAP or POP) | The standard flow runs **from the aMUA to the MSA, through one or more MTAs, to the MDA, the rMS and finally the rMUA.** ## ADMD: Administrative Management Domain An **ADMD** is a boundary of independent administrative authority. Inside it, one operator's policies apply for authentication, filtering, accountability and content handling. Everything that matters in deliverability happens **at the boundaries between ADMDs**, because that is where parties with no shared control must establish trust. This is what SPF, DKIM and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) authenticate: the sending ADMD to the receiving ADMD. There are three types. **Edge** ADMDs are organizations at the periphery that run their own mail. **Consumer** ADMDs are mailbox providers that serve end users, typically through web or IMAP access. **Transit** ADMDs are mail service providers and ESPs that relay mail and add value between Edge ADMDs. Edge ADMDs may exchange mail directly with each other. Transit ADMDs aggregate and filter mail, and take on responsibility for the reputation of their customers' mail. ## Mediators vs. relays: why forwarding is special A **Relay** moves the same message along. Responsibility and the envelope do not change. A **Mediator** receives a delivered message and **posts it again**. That creates a new transit through the MHS and a new responsibility, and the content may change, while the original Author's `From:` is preserved. Mediators sit between full relaying and full authorship, and they cause most of the edge cases in authentication. SPF breaks because the mediator's IP address is not in the SPF record of the Author's domain, and DKIM may break if the content changes. | Mediator type | What it does | Identity effects | |---|---|---| | **Alias** | Sends the message on to one or more new addresses. The message continues through the transfer service | Keeps the original `MailFrom` (return path), so bounces go to the original Originator. Only `RcptTo` changes. This is classic forwarding in the style of ".forward" | | **ReSender** (ReDirector) | Inserts a new Recipient into the original exchange | Keeps `From:`, adds `Resent-From:` (the mediator as author) and `Resent-Sender:`, and typically uses a new `MailFrom` | | **Mailing List** | Collects postings and redistributes them to members | A new `MailFrom` (the list's bounce address). Adds `List-Id:` (RFC 2919) and other list headers. Often modifies the subject or adds a footer, which breaks DKIM | | **Gateway** | Translates between different kinds of mail service | May rewrite content and addressing as needed, but must keep replies working | | **Boundary Filter** | A filter for abuse or policy at the edge of an ADMD, which may modify or quarantine messages | Acts as both a receiver and a re-injector | What this means for deliverability: a forwarder of the Alias type that preserves `MailFrom` breaks SPF at the next hop, unless it rewrites the sender (for example with SRS). A Mailing List that takes ownership of `MailFrom` passes SPF for its own domain, but it must not break alignment for the Author's domain. That need is the practical reason for ARC and for practices that preserve DKIM signatures. ## Identity fields: who sets what | Identity | Set by | Meaning | |---|---|---| | `RFC5321.HELO/EHLO` | SMTP client (MSA or MTA) | The host announcing itself for this hop | | `RFC5321.MailFrom` | Originator | The return address for notifications at the transfer level. It **need not** be the Author | | `RFC5321.RcptTo` | Author (or the Final MTA or MDA on redirect) | The envelope recipient, which may never appear in the headers | | `RFC5322.From` | Author | Who wrote the message (the DMARC identifier) | | `RFC5322.Sender` | Originator | Who submitted it. If it is absent, the `From:` mailbox is treated as the sender | | `RFC5322.Reply-To` | Author | Where replies should go | | `RFC5322.To/Cc/Bcc` | Author | The displayed recipients (Bcc recipients are not disclosed) | | `RFC5321.Received` | Each relay, mediator or receiver | A trace of hosts and IP addresses | | `RFC5321.Return-Path` | MDA | Records the `MailFrom` at delivery | | `RFC3461.ENVID` | Originator | An opaque tracking ID for one transit from posting to delivery (used to match DSNs) | | `RFC5321.ORCPT` | Originator | The original recipient address, which survives remapping. It is the only reliable way to match a DSN to a recipient | | `RFC2919.List-Id` | Mediator (list) | A globally unique list name that does not depend on any host | Three separate identities look like "the sender": `MailFrom`, `From:` and `Sender:`. Two different roles set them, and that is exactly why email authentication needed the concept of alignment ([DMARC](https://emailmarketing.net/learn/authentication/dmarc)). ## Ports and protocols quick reference | Port / protocol | Use | |---|---| | 25 / SMTP | Relay from MTA to MTA across ADMDs | | 587 / SUBMISSION | Submission from the aMUA to the MSA, authenticated (submission over implicit TLS on port 465 was added later, by RFC 8314) | | IMAP / POP | Access from the rMUA to the Message Store | | LMTP | Delivery from the MHS to the MDA without queuing | | ETRN / ODMR | Transfer from the MHS on request ("on-demand"), pulled by the receiving side | ## Related articles - [RFC 5321: SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the relay protocol these components use - [RFC 5322: Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format), the header fields each actor sets - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability), on how receiving ADMDs decide placement # RFC 6647 — Email Greylisting > How greylisting works (tuple mechanics, timing windows, reply codes), the IETF recommendations for greylisters, and what senders must do — same-IP retries, pool interactions — to pass it. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc6647-greylisting When your first attempt to deliver to an unfamiliar receiver is deferred with a temporary failure, greylisting is the most common reason. Your retry logic has to be designed with greylisting in mind, or the deferral can repeat indefinitely. Greylisting means **temporarily degrading service to unknown email clients as a defense against abuse**. It exploits the fact that much spam software sends once and never retries after a `4xx` temporary failure, while a compliant MTA queues the message and retries as [RFC 5321 §4.5.4](https://emailmarketing.net/learn/rfc/rfc5321-smtp#retry-expectations-section-454) requires. RFC 6647 documents the technique. It is a Standards Track applicability statement in the style of a BCP, published in 2012. ## How greylisting is applied (the five variants) The RFC classifies greylisting by the SMTP stage at which the decision is made, and by what is recorded: | Variant | What is recorded | Behavior toward unknown entries or entries under the minimum age | |---|---|---| | Connection-level | Source IP (or hostname) only | `421` and close, or `4yz` to all further commands, until the source reaches a minimum age (for example, 30 minutes) | | HELO/EHLO-level | Tuple (source IP, HELO/EHLO parameter) | `4yz` replies while the tuple is absent or under the minimum age | | MAIL-level | Tuple (source IP, RFC5321.MailFrom) | Same | | RCPT-level | Tuple of the recipient plus any combination of source IP, MailFrom and other recipients | Same | | DATA-level | Tuples that add RFC5322.From and To, the Subject, message digests or analysis of the body; applied at `DATA` or after the final `.` | Same. This is the most expensive form for both sides | The standard form, and the one the RFC recommends implementing, is the **triplet of IP address, RFC5321.MailFrom and the first RFC5321.RcptTo**. ## Reply codes "Per RFC 5321, the only two reasonable choices are `421` if the implementation wishes to terminate the connection immediately, and `450` otherwise." A greylisting deferral therefore looks exactly like any other soft failure, and nothing in the reply reliably identifies it as greylisting. Some receivers say "greylisted" in the text, so always log the full reply text. ## Timing parameters (Section 5 recommendations to greylisters) | Parameter | RFC recommendation | |---|---| | Retry-acceptance window | MUST be configurable; the default SHOULD be **1 minute to 24 hours**. A retry before the minimum delay gains the sender nothing, and a retry after the maximum finds that the record has expired | | Record lifetime after passing | A timeout for database entries MUST exist; the default SHOULD be **at least one week**. IP addresses with no recent traffic are then deleted and must qualify again | | After a successful retry | Allow **all further SMTP traffic from that IP address**, whatever the envelope information. Passing once allowlists the IP address, not only the tuple | Other MUST and SHOULD items for greylisters: - All inbound border MTAs of an administrative management domain (ADMD) listed in DNS SHOULD share a **common greylisting database and common policies**. Otherwise a sender that retries to a different MX starts the clock again, which makes the delay longer. - Greylisters MAY track CIDR blocks (for example, /24) or groupings by domain, so that clustered outbound server farms qualify as a unit. - Greylisters MUST provide a manual override (an exception list) for IP addresses and network blocks. - Greylisting SHOULD NOT be applied on the submission service for authenticated clients, or to any authenticated session. ## Exceptions / whitelisting (Section 2.7) Exception sets may name IP addresses, CIDR blocks, host names or domain names that are exempt from greylisting. Good candidates are hosts known to retry properly and hosts that rarely send. DNS-based allowlist services can serve as a shared source of exceptions. ## What senders must do On the client side, RFC 6647's position is that a client cannot know why a `4xx` reply came back ("greylisting could be in effect"). **A client therefore needs to be able to retry in order to be considered fully capable.** For an ESP, this has these operational consequences: 1. **Retry from the same IP address.** The tuple includes the source IP address. If your MTA retries a deferred message from a different IP address in the pool, the greylister sees a brand-new tuple and defers again, possibly forever as the retries cycle through the pool. Your queue and retry logic must pin a deferred message (or at least a deferred destination) to the IP address that made the first attempt. This is the key interaction between greylisting and sending from pools. 2. **Keep MailFrom stable across retries.** VERP and return paths unique to each message are fine, since the tuple is per message anyway. Rewriting the envelope sender between attempts, however, creates a new tuple. 3. **Time the first retry well.** The RFC 5321 SHOULD of ≥30 minutes sits comfortably inside the default acceptance window (1-minute-to-24-hour). A first retry in the 5–30 minute range clears most greylisters quickly. Retrying within seconds is wasted, because the entry is still under the minimum age, and it looks like hammering the server. 4. **Expect inconsistency between MX hosts.** Receivers that ignore the SHOULD on a shared database defer you separately at each MX, and a retry that lands on another MX host restarts the wait. This is a defect at the receiver, not yours. Patience is the fix, not rotating IP addresses. 5. **Plan for warm-up.** New IP addresses are by definition unknown everywhere, so the first sends from a fresh IP address to smaller receivers see higher deferral rates for the first hours. Allow for this in your throughput expectations for [IP warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up). It clears as the tuples age in. 6. **Know that address changes defeat aging.** Senders on DHCP or rotating addresses appear as new sources after every change. Conversely, NAT makes separate MTAs share one IP address, so a pass by one machine exempts the others. This is why receivers increasingly distrust greylisting on its own. 7. **Protect time-critical mail** such as password resets and other transactional mail. Greylisting can delay delivery on first contact by minutes to hours. The RFC's own security section warns of "unintentional and detrimental consequences for delivery of legitimate mail", particularly for time-critical applications. The mitigation is to send transactional mail from established IP addresses used consistently, which will already be aged in or on exception lists. ## Security considerations (Section 8) - Attackers who rotate the tuple parameters can bloat the greylisting database, a denial of service against the receiver. Implementations should define a failure policy for when the database is attacked or unavailable. - Greylisting slows abuse down but does not authenticate anyone: any botnet that retries passes it. Its value is that it cheaply filters out the share of abuse that does not retry. ## Related articles - [RFC 5321 — SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the retry obligations that greylisting relies on (≥30-minute retry interval, 4–5 day give-up) - [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes), for classifying `4xx` deferrals - [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up), on why fresh IP addresses see more deferrals # SMTPUTF8 / Internationalized Email (RFC 6530/6531/6532) > EAI digest: the SMTPUTF8 SMTP extension, UTF-8 headers, the no-downgrade rule, error codes, and what an ESP must decide about accepting and delivering internationalized addresses. Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/smtputf8-eai If your subscribers or customers use email addresses written in their own scripts, such as `用户@例え.jp`, you have to decide whether your platform accepts those addresses and whether it can deliver to them. The Email Address Internationalization (EAI) suite lets email addresses and headers carry raw UTF-8, so that an address like that is a working mailbox. RFC 6530 is the framework, RFC 6531 is the SMTP extension (`SMTPUTF8`), and RFC 6532 covers the changes to the message format. RFC 6533 covers internationalized [delivery status notifications (DSNs)](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications). The suite obsoletes the experimental RFCs 4952, 5336 and 5504. For an email service provider (ESP), the core question EAI raises is operational: **do you accept internationalized recipient addresses, and can you deliver to them from end to end?** ## Terminology (RFC 6530) - **All-ASCII address** versus **non-ASCII (i18n) address**: the second kind has at least one non-ASCII character in the local part, in the domain, or in both. - **Conventional message**: a message that strictly conforms to [RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format). **Internationalized message**: a message that uses the EAI extensions and therefore no longer conforms to RFC 5322. It exists only inside a channel where SMTPUTF8 has been negotiated. - Domains could already be internationalized through the A-labels (`xn--…` Punycode) of Internationalized Domain Names in Applications (IDNA, RFC 5890–5894), and that works without EAI. What EAI adds is UTF-8 in the **local part**, which has no ASCII-compatible encoding at all, plus native U-labels and UTF-8 header values on the wire. ## The pivotal design decision: no in-transit downgrade The experimental protocol paired each non-ASCII address with an ASCII alternative, and let relays downgrade the message along the way. The working group abandoned this approach because of interoperability failures, security concerns about unauthenticated pairing of addresses, and complexity. The rule in RFC 5321 that "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part" makes any rewriting of local parts in transit unsafe. The consequence (RFC 6530 §8): a relay holding a message that requires SMTPUTF8 **MUST either** negotiate the extension with the next hop **or reject or bounce the message**, so that the sender can make another plan. There is no partial delivery and no automatic fallback to ASCII. Downgrading, where it happens at all, happens only at the endpoints (at submission or at final delivery). ## The SMTP extension (RFC 6531) - **EHLO keyword:** `SMTPUTF8`, with no parameters. - **Request:** if the envelope or the message needs the capability, the client MUST add the `SMTPUTF8` parameter, which takes no value, to `MAIL FROM`. Example: `MAIL FROM:<用户@example.com> SMTPUTF8 BODY=8BITMIME`. - **What it unlocks:** UTF-8 in the local parts of MAIL and RCPT, U-label domains in the envelope and in trace fields, and the internationalized headers of RFC 6532 in the content. - **8BITMIME is mandatory:** servers that offer SMTPUTF8 MUST also support and announce 8BITMIME (RFC 6152). SMTPUTF8 is used with `BODY=8BITMIME` (or `BODY=BINARYMIME` where it is advertised), because UTF-8 headers are 8-bit data. - **Syntax:** `atext`, quoted-string text, esmtp-values and sub-domains are extended with `UTF8-non-ascii`. The structure of delimiters in addresses is unchanged. - **Trace fields:** a server that supports SMTPUTF8 and adds `Received:` to an SMTPUTF8 message SHOULD use the U-label form. The new `WITH` protocol values `UTF8SMTP(A/S/SA)` and `UTF8LMTP(A/S/SA)` record the negotiation. - **DSN:** a server that advertises both DSN and SMTPUTF8 MUST implement RFC 6533 (delivery status notifications that can carry UTF-8). - **VRFY and EXPN** gain an optional `SMTPUTF8` parameter, so that the server knows UTF-8 replies are safe. ### Relay and fallback rules, and error codes A client that supports SMTPUTF8 but cannot negotiate it with the next hop **MUST NOT transmit** an internationalized address, or a message with internationalized headers at any MIME level. A mail submission agent (MSA) may transform the message at submission. A relay SHOULD reject the message or generate a non-delivery notification (as described in RFC 3464 and RFC 6533). | Enhanced code | Meaning | Typical basic codes | |---|---|---| | `X.6.7` | Non-ASCII addresses are not permitted for that sender or recipient | 550, 553 | | `X.6.8` | A UTF-8 reply is required, but the client did not declare SMTPUTF8 support | 252, 550, 553 | | `X.6.9` | A message with UTF-8 headers cannot be transferred to one or more recipients, so the message is rejected | 550 | | `X.6.10` | Deprecated (a duplicate of X.6.8) | None | Rejection points: `553` at RCPT or `550` at MAIL where only ASCII is accepted, and `554` after DATA when recipients cannot accept internationalized headers. ## Message format changes (RFC 6532) - The format adds `UTF8-non-ascii` to `VCHAR`, `ctext`, `atext`, `qtext`, `text` and `dtext`. Raw UTF-8 therefore becomes legal in unstructured fields (Subject), address local parts, domains, comments and quoted strings. **Header field names remain ASCII-only.** - The line length limit of 998 becomes **998 octets** (a multi-byte character counts once for each of its octets). The recommended limit of 78 stays in characters, because it is about display width. - **Normalization:** NFC SHOULD be used; NFKC SHOULD NOT, because it can merge distinctions needed to spell names. RFC 6530 adds: support at least NFC on the receiving side, and never depend on senders to normalize. C0 control characters are prohibited, and U+0008 (backspace) is explicitly forbidden in mailbox names. - **Encoded words (RFC 2047) SHOULD NOT be generated** in an internationalized message. Write the UTF-8 directly. (Agents MAY convert encoded words to UTF-8 when quoting older material.) - **Message-ID:** UTF-8 is permitted, but keeping it ASCII is advised, for threading through `In-Reply-To:` and `References:` with parties that do not support EAI. - **The `message/global` media type:** an encapsulated message with UTF-8 header values, the EAI counterpart of `message/rfc822`. Unlike other `message/*` types, **any content transfer encoding is permitted** (relaxing RFC 2045 §6.4). 8bit or binary is recommended where allowed, and the message MUST get a 7-bit-safe encoding if it is handed to a 7-bit system. It is used in RFC 6533 DSNs to return internationalized originals. ## Deliverability and operational implications for an ESP 1. **The delivery path is all or nothing.** You can deliver to `user@例え.jp` (an A-label domain with an ASCII local part) with an ordinary stack. You can deliver to `用户@anything` **only** if every hop to the recipient's MX negotiates SMTPUTF8. If the MX does not offer it, the only compliant outcomes are rejection at submission or a bounce. 2. **Provider support is uneven.** Gmail and Outlook.com accept SMTPUTF8 for inbound mail, and Gmail advertises it for outbound mail. Many corporate gateways, smaller MTAs and downstream tools do not. An ESP that accepts EAI recipients needs to handle capability for each destination, and needs a clear bounce classification (`X.6.7` or `X.6.9`) when no path exists. 3. **Audit the whole stack, not only the MTA.** The security section of RFC 6531 is explicit: systems for logging, trouble tickets, suppression and tracking must store full UTF-8 addresses (or a defined mapping to ASCII), or data is silently lost. Add to that list the validation regexes of signup forms, deduplication (normalize with NFC before comparing), Variable Envelope Return Path (VERP) encoding, bounce parsers (expect the RFC 6533 `utf-8` address types) and the URL encoding of one-click unsubscribe links. 4. **In principle, authentication is unaffected.** [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) operate on domains, which have A-label forms. But apply the DKIM signature after any downgrade or transformation at an endpoint. Signed or encrypted content can never be upgraded or downgraded without breaking signatures (RFC 6530 names S/MIME and PGP explicitly). 5. **Risk from homographs and confusable characters:** internationalized From domains and local parts widen the room for phishing lookalikes (see [brand protection](https://emailmarketing.net/learn/reference/brand-protection-domain-management)). Receivers apply extra scrutiny to addresses that mix scripts. 6. **A defensible minimum position** for an ESP without full EAI support: accept internationalized domain names (IDNs) in A-label or U-label form (converting them to A-labels for SMTP), reject non-ASCII local parts at list import and in the API with a clear error, and document this. Accepting EAI addresses you cannot deliver to only manufactures bounces. ## Related articles - [RFC 5321 (SMTP)](https://emailmarketing.net/learn/rfc/rfc5321-smtp) - [RFC 5322 (Message Format)](https://emailmarketing.net/learn/rfc/rfc5322-message-format), the ASCII baseline that EAI extends - [MIME and Encoding](https://emailmarketing.net/learn/rfc/mime-and-encoding), including 8BITMIME and the encoding rules for `message/*` - [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions), the negotiation mechanism SMTPUTF8 relies on - [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications), a format that RFC 6533 extends for EAI # Two Worlds of Email Deliverability > Working with mailbox providers (wanted/expected email) versus working against them (gaming techniques) — why gaming fails and why sending less can earn more. Source: emailmarketing.net — https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability If your email is being filtered, you can either make it more wanted by recipients or try to get it past the filters with technical tricks. Those two approaches lead to two very different "worlds" of deliverability, and only the first one works over time. ## World 1: working with the mailbox providers Here your aim matches the providers' aim: mail that recipients **want** and **expect**, which is the mail providers are trying to deliver to the Inbox. Two conditions define that mail: - **Wanted:** it gives recipients something they value. - **Expected:** recipients recognize it, because they signed up or already have a business relationship with your brand. A provider cannot see into its users' minds, but it can observe their behaviour at scale, across tens of thousands of mailboxes, and that tells it more than asking would. Complaints and engagement carry the most weight: how many recipients mark a message as spam, how many open and read it, how many delete it unread, and how long they spend on it. Filtering algorithms turn those measurements into a verdict on whether your mail is wanted and expected. Behaviour is not the only input. Providers also examine **content**, where particular words or phrasing can push a message toward spam filtering, and **technical sending details** such as the number of connections you open, email authentication and warm-up schedules. Senders in this world send plainly and do not look for technical loopholes to "game" the system. Providers exist to deliver mail their users welcome, so in a program built on wanted and expected email the rest typically follows. Delivery problems still happen, and they are typically fixable. Open rates of **5% to 20% or higher** are common here, and the target is the **Inbox**. ## World 2: working against the mailbox providers Here senders try to trick spam filters into accepting or delivering mail that recipients neither want nor expect. Many senders arrive here without meaning to. Suppose your mail draws a lot of complaints or very little engagement, and providers have started filtering it. You have two possible responses: - **(A)** Look into the program itself: identify where the complaints or spam-trap hits come from and remove that cause, so recipients want and expect the mail more. That response keeps you in World 1. - **(B)** Leave the underlying cause in place and put all the effort into workarounds, such as spreading mail over many IP addresses so none attracts attention, rotating domain names, or sending the whole message as an image that content filters cannot read. That response takes you into World 2. World 2 is defined by the attempt to **game the system**. Plenty of poor deliverability advice circulates, so many senders choose this path in good faith. It fails because providers employ skilled, dedicated teams whose job is to spot the workarounds senders use against their filters and shut them down. **All gaming methods eventually stop working.** Every workaround named above is already well understood, and providers run countermeasures built to catch and penalize each one. Open rates around **0.1%** are typical in this world, and the standard "solution" to poor opens is to send more. Often the aim is no longer the Inbox at all, only the **Bulk or Spam folder**, as long as the mail is not refused outright. ## What makes email wanted and expected 1. **Permission is essential.** Mail that nobody asked for is unwanted by definition, so recipients must have invited you to write to them. 2. **What you send should match what people expect.** A subscriber who signed up for a "daily deal" and receives a daily advertisement with no deal in it is getting something other than what they wanted or expected. 3. **Volume should be reasonable and expected.** Sending five messages a day to people who were never told how often you would write means sending more than they expect, and probably more than they want. Tell subscribers how often to expect mail when they sign up. 4. **Permission cannot be hidden.** Consent tucked into terms and conditions that nobody reads still produces mail the recipient does not expect. A pre-checked checkbox has the same effect, since some people never notice it. 5. **The email must be identifiable.** A subscriber signed up for a particular brand. If the messages that arrive do not carry that brand, the subscriber sees mail from a sender they do not recognize and will probably regard it as unwanted and unexpected, however good the sign-up process was. 6. **Remove inactive subscribers.** Once a subscriber has gone a period of time without opening or clicking, stop mailing them. Someone who has ignored three emails a week for six months has in effect "emotionally unsubscribed". Dropping those addresses raises the share of your list that reads and wants your mail, so your sending as a whole becomes more wanted. Providers say openly that the purpose of their filters is to catch and block mail that recipients do not want or expect. ## Examples of gaming techniques (which do not really work) 1. **Using too many IP addresses (IP snowshoeing).** The sender spreads its volume thinly across many IP addresses, hoping each one sends too little to draw attention. Providers know the pattern and penalize senders who use more IP addresses than their volume justifies. GreenArrow recommends that each IP address send at least roughly 20,000 messages a day. 2. **Using too many domain names (domain snowshoeing).** The same trick applied to domains: spammers cycle through "disposable" domain names to shed a bad reputation and conceal who they are. Hard-core spammers go further, with methods that include taking over other senders' ESP accounts, DKIM replay attacks, sending through botnets and abusing open relays. Some of these are crimes. Measured against the goal of reaching the Inbox: - Filters are built specifically to detect IP and domain snowshoeing, so using either one can be enough on its own to move your mail to the Spam folder at many providers. - At best, snowshoeing gets mail into the **Spam folder**: some messages that would have been rejected outright are delivered to Spam instead. ## The two dimensions Two dimensions separate the worlds, and each is a scale with many positions between its ends: - **wanted and expected** at one end, **unwanted and unexpected** at the other - **not gaming** at one end, **gaming the system** at the other Progress means moving toward wanted and expected mail, and toward not gaming. The catch for a sender already in World 2 is that progress on **only one** dimension does not improve delivery. - Mail that becomes wanted and expected but still relies on gaming techniques is filtered for the gaming. - Mail that stops gaming but is still unwanted and unexpected is filtered for being unwanted. This change can even turn mail that used to reach the Spam folder into mail that is rejected entirely. The two have to improve **together**. ## Less is more: the economics that run against intuition Making mail more wanted and expected usually means sending **less** of it, and sending less can earn **more money**, because the smaller volume reaches the Inbox. GreenArrow illustrates this with a simplified, hypothetical example: - Mail in the Spam folder is opened 0.3% of the time, since about 95% of recipients never check Spam. - Mail in the Inbox is opened 10% of the time, 30× as often. - Every open is assumed to be equally likely to lead to the action that generates revenue. - The changes that make the mail wanted and expected cut volume by 5×, and they get it into the Inbox. Volume is 5 times lower while revenue per email is 30 times higher, so **total revenue rises 6×**. ## Making the changes Becoming more wanted and expected usually takes a close, thorough look at the whole email program. Let data drive it: change something, then watch what happens to complaint rates and engagement. Expect several rounds, because improving deliverability is an iterative process. Each campaign adds to your sending history, and that history points to the next improvement. The mailbox providers make the final decision to deliver to the Inbox, file in the Spam folder or reject, and these practices aim to make your mail the kind they choose to put in the Inbox. ## Related articles - [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) - [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability) - [Advanced IP Segmentation and Allocation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation) # DANE for SMTP (RFC 7672) > DNSSEC-authenticated TLS for SMTP — TLSA record placement and parameters, the sending-MTA validation algorithm, failure handling, and how DANE compares to MTA-STS. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/dane-smtp If your mail servers sit in DNSSEC-signed zones, you can tell every sending server exactly which TLS certificate or key your MX hosts must present, and stop attackers from stripping STARTTLS. DNS-Based Authentication of Named Entities (DANE), applied to SMTP in RFC 7672, does this with records published in DNSSEC-signed DNS. The secure existence of a TLSA record is enough on its own to tell sending mail transfer agents (MTAs) that TLS is available and mandatory for that server, which defeats STARTTLS stripping. The record data then authenticates the server without relying on public certificate authorities (CAs). DANE solves the same problem of downgrade and impersonation as [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts), but it anchors trust in DNSSEC instead of the Web PKI combined with trust on first use. The two can coexist; see the comparison at the end. ## Prerequisite: DNSSEC Everything depends on the DNSSEC validation status. RFC 7672 uses four states: | State | Meaning | Sender treatment | |---|---|---| | `secure` | Cryptographically validated | Usable for DANE | | `insecure` | Zone not signed with DNSSEC | No DANE; fall back to opportunistic TLS as it worked before DANE | | `bogus` | Validation failed | Treated as a lookup error | | `indeterminate` | Validation status cannot be determined | Treated as a lookup error | A hard rule: if any DNS query used to locate TLSA records fails (`bogus`, `indeterminate`, timeout, malformed reply, SERVFAIL, and so on), the SMTP client **MUST treat that server as unreachable and MUST NOT deliver through it**. Tampering with DNS therefore causes a deferral, not a silent downgrade. To publish DANE, the zones that contain the MX hostnames, their address records and the TLSA records must all be signed with DNSSEC and must validate. ## TLSA record placement TLSA records live at a name derived from the **MX host** (not from the mail domain), prefixed with the port and the protocol: ``` _25._tcp.mx.example.com. IN TLSA 3 1 1 ``` For a non-standard SMTP port, put the port number in `_._tcp`. ## TLSA parameters for SMTP A TLSA record has three parameter fields (certificate usage, selector and matching type), plus the association data. For SMTP, only two certificate usages apply: | Usage | Name | SMTP applicability | |---|---|---| | 0 | PKIX-TA | **Not applicable.** An attacker who can defeat DNSSEC could replace the record anyway, so PKIX adds no security. MTAs also lack a canonical trust store of public CAs for opportunistic use | | 1 | PKIX-EE | **Not applicable** (for the same reasons) | | 2 | DANE-TA | Trust anchor mode: the record designates a CA (often the operator's own), and the server must include that trust anchor certificate in the certificate chain of its TLS handshake | | 3 | DANE-EE | End-entity mode: the record matches the server's leaf certificate or key directly. **Primary recommendation** | Recommended combinations of parameters: | Combination | Reading | Notes | |---|---|---| | `3 1 1` (DANE-EE, SPKI, SHA2-256) | SHA-256 digest of the server's public key | Primary recommendation. The record survives certificate renewal as long as the key does not change | | `2 0 1` (DANE-TA, Cert, SHA2-256) | SHA-256 digest of the trust anchor certificate | Secondary. The selector Cert(0) is preferred over SPKI(1) because it preserves the constraints of the trust anchor (path length, name constraints). Through a CNAME, many servers under the same CA can share one TLSA resource record set (RRset) | Support for SHA2-256 is mandatory in all DANE implementations, so `1` (SHA2-256) as the matching type is safe everywhere. ### Name checks and certificate lifetime | | DANE-EE(3) | DANE-TA(2) | |---|---|---| | Certificate name check | **MUST NOT** be performed, because the TLSA match alone authenticates the server | **Required**: a reference identifier must match an RFC 6125 DNS-ID (or a CN-ID if there are no DNS-IDs). The reference identifiers are the TLSA base domain (primary), the original next-hop domain, and the domain after CNAME expansion if it is different. Wildcards are valid only as the entire first label | | Certificate expiration | Ignored: validity comes from the lifetime of the DNSSEC signature on the TLSA record | Checked as part of chain validation | SNI: the SMTP client **MUST send Server Name Indication (SNI) containing the TLSA base domain**. Servers must not require SNI from clients, and do not need to send SNI in their own hello if the default certificate matches the TLSA records. ## Sending MTA algorithm 1. **MX resolution.** Look up the MX records for the next-hop domain. If the MX RRset is `secure`, continue for each MX host. If it is `insecure`, opportunistic DANE falls back to regular TLS handling as before DANE, while a locally configured policy that makes DANE mandatory defers instead. The MTA is not required to prefer the MX host that offers more security; the normal order of MX preference applies. 2. **Address resolution.** Resolve the A and AAAA records for the MX host first, both to confirm that it is reachable and to learn the DNSSEC status of the chain of names. If the address records are `insecure`, skip the TLSA lookups (this avoids lookup errors on unsigned zones). CNAME handling determines the candidate TLSA base domains: a `secure` CNAME chain gives two candidates (the fully expanded name first, then the original name), and an `insecure` initial CNAME leaves only the original name. 3. **TLSA lookup.** Query `_25._tcp.` for each candidate. The first candidate that returns a `secure` TLSA RRset becomes the TLSA base domain. Follow CNAMEs in TLSA responses only while the whole chain stays `secure`. 4. **Apply the outcome:** | TLSA lookup outcome | Sender obligation | |---|---| | `secure` RRset with at least 1 usable record | TLS is **mandatory**, and authentication through TLSA matching is **required**. If authentication fails, do not deliver through this server; try the next MX or defer | | `secure` non-empty RRset, but all records unusable (unknown parameters, and so on) | TLS (encryption) is mandatory, but authentication is not required. If the TLS connection fails, move to the next server or defer | | `insecure` RRset, or authenticated denial of existence | No DANE: fall back to opportunistic TLS as before DANE (cleartext is acceptable if STARTTLS is unavailable) | | Any lookup error (`bogus`, `indeterminate`, SERVFAIL, timeout) | The server is unreachable; defer if no other servers remain | Delivery failures under DANE are deferrals (transient), never a downgrade to cleartext. They can be reported through the [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) result types `tlsa-invalid`, `dnssec-invalid` and `dane-required`. ## Operational guidance for publishers **When you rotate keys or certificates, always publish in advance:** 1. Publish two TLSA records: one that matches the current key or certificate, and one that matches the next. 2. Wait at least the TTL of the TLSA records, so that caches expire. 3. Switch the server to the new key or certificate. 4. Remove the old TLSA record once it is no longer needed. If you rotate the server key without publishing the new TLSA record in advance, strict senders defer all mail until DNS converges. - With `3 1 1` (an SPKI digest), routine certificate renewals that keep the same key need **no** change to the TLSA records. - DANE-TA(2) with CNAME centralization: point the `_25._tcp` name of each server at a shared central TLSA RRset. The CA operator publishes digests of new trust anchors there before servers adopt new keys. If one server's key is compromised, replace its CNAME with a direct DANE-EE(3) record until its certificate expires. - **No selective STARTTLS:** if a server advertises STARTTLS only to some clients (for example, after probes in the style of greylisting), senders that support DANE, for which cleartext is forbidden, can never complete the expected first transaction. Operators that publish TLSA records MUST NOT run selective STARTTLS. - Monitor the health of your own TLSA records and DNSSEC continuously. An expired DNSSEC signature makes your domain unreachable, not only unauthenticated, for senders that validate DANE. ## DANE vs MTA-STS | | DANE (RFC 7672) | [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) (RFC 8461) | |---|---|---| | Trust anchor | DNSSEC | Web PKI (CA certificates) and HTTPS | | Requires DNSSEC | Yes (signed MX, address and TLSA zones) | No | | First-contact protection | Yes: secure denial of existence is itself authenticated | No: trust on first use, so protection begins once a policy is cached | | Downgrade resistance | Strong (DNS tampering leads to deferral) | Weaker (an attacker can suppress discovery before the first cache) | | Granularity | Per MX host and port | Per mail domain (MX name patterns) | | Certificate model | Pinned key or certificate (DANE-EE), or private trust anchor (DANE-TA); no public CA needed | A CA-signed certificate with a matching subject alternative name (SAN) is required on every MX | | Failure mode | Defer (temporary failure) | Defer under `enforce`; deliver and report under `testing` | | Reporting | Through [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) (`policy-type: tlsa`) | Through [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) (`policy-type: sts`) | Precedence when both are published: RFC 8461 requires that senders implementing both **MUST NOT let a passing MTA-STS policy override a failing DANE validation**. DANE is the stronger mechanism, and MTA-STS extends coverage to senders and domains that cannot use DNSSEC. Publishing both is legitimate and increasingly common. A sender's daily results for each appear as separate policy entries in TLS-RPT reports. # MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) > How receiving domains publish an enforceable TLS policy via a DNS TXT record plus an HTTPS policy file, and how sending MTAs discover, cache, and apply it. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/mta-sts MTA-STS (RFC 8461) lets a receiving domain declare that it supports TLS for inbound SMTP and that sending MTAs should refuse to deliver to it over insecure channels. It closes the classic STARTTLS weakness: because STARTTLS is negotiated in cleartext, an active attacker can strip it (downgrade) or impersonate the MX. MTA-STS gives senders an out-of-band, cached policy to detect both. Unlike [DANE for SMTP](https://emailmarketing.net/learn/transport-security/dane-smtp), MTA-STS does **not** require DNSSEC. It leans on the Web PKI (CA-signed certificates) and HTTPS instead — easier to deploy, but weaker against attackers who can tamper with DNS on first contact (see Security model below). ## Roles - **Policy Domain** — the recipient domain publishing the policy (the RFC5321 mail domain, i.e. the part after `@`). - **Sending MTA** — discovers, caches, and applies the policy when delivering to that domain. ## Policy discovery: the DNS TXT record The presence (and version) of a policy is signaled by a TXT record at `_mta-sts.`: ``` _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" ``` | Field | Required | Value | |---|---|---| | `v` | yes | `STSv1` (only defined version) | | `id` | yes | 1–32 alphanumeric chars uniquely identifying this policy instance; senders compare it against their cached policy's id to detect updates | Processing rules: - Fields are semicolon-separated key/value pairs; unknown fields are ignored. - If multiple TXT records are returned, discard any not beginning with `v=STSv1;`. If more than one valid record remains, the result is ambiguous (misconfiguration). - Multiple character-strings in one record are treated as concatenated. - CNAMEs at `_mta-sts.` are followed normally (this enables delegation — see below). The TXT record only *announces* a policy and its version. The policy content itself lives at the HTTPS endpoint. ## Policy retrieval: the HTTPS well-known endpoint The policy is fetched with an HTTPS GET from a "Policy Host" formed by prepending the literal label `mta-sts` to the Policy Domain: ``` https://mta-sts.example.com/.well-known/mta-sts.txt ``` Fetch requirements: | Requirement | Rule | |---|---| | Certificate | Valid X.509 for the `mta-sts` DNS-ID (e.g. `mta-sts.example.com`), chained to a root CA trusted by the sender, non-expired; wildcard match only for the complete left-most label | | HTTP status | Must be 200; **redirects must not be followed** | | HTTP caching | Must not be used (freshness is governed by `max_age`, not HTTP cache headers) | | Content-Type | `text/plain` recommended; `charset=utf-8` or `charset=us-ascii` accepted | | Timeout | Suggested: 1 minute | | Max policy size | Suggested: 64 KB | | Failed-fetch rate limit | At most one attempt per 5 minutes per policy version id | ## Policy file format CRLF-separated `key: value` pairs: ``` version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net mx: backupmx.example.com max_age: 604800 ``` | Field | Required | Value | |---|---|---| | `version` | yes | `STSv1` | | `mode` | yes | `enforce` \| `testing` \| `none` | | `max_age` | yes | Cache lifetime in seconds, max `31557600` (1 year); expected to be weeks or greater | | `mx` | for enforce/testing (optional for none) | One pattern per `mx:` line; either a fully specified host (`mail.example.com`) or a wildcard for the left-most label only (`*.example.net`); IDNs must be Punycode A-labels | Parsing: unknown fields are ignored (extensibility); for duplicated non-repeatable fields (everything except `mx`), only the first occurrence counts. ### MX matching rules A candidate MX host is valid if its MX record name matches one of the `mx` patterns (RFC 6125 rules, wildcard restricted to the entire left-most label): | Pattern | Matches | Does not match | |---|---|---| | `*.example.com` | `mail.example.com` | `example.com`, `foo.bar.example.com` | | `example.com` | `example.com` | anything else | ## The three modes | Mode | Sender behavior | |---|---| | `enforce` | MUST NOT deliver to hosts that fail MX matching, fail certificate validation, or don't offer STARTTLS. Failing messages are treated as **transient** errors (retry), and the sender must re-check DNS for an updated policy before permanently failing a message | | `testing` | Deliver even on validation failure, but report failures via [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) if implemented. This is the safe on-ramp: exercise the full validation path and read reports before flipping to enforce | | `none` | Treat the domain as having no active policy; used for graceful opt-out | ## Sender-side requirements - MUST support TLS 1.2 or higher. - MUST support the TLS SNI extension. - The receiving MTA's certificate MUST be non-expired, MUST chain to a root CA trusted by the sender, and MUST contain a SAN DNS-ID matching the host per RFC 6125. Revocation MAY be checked (OCSP, CRLs). ## Caching and refresh - Cache a fetched policy for up to `max_age` seconds from the last fetch. - Before permanently failing a delivery under an `enforce` policy, check DNS for a newer policy (changed `id`) — the recipient may have fixed a broken policy. - SHOULD refresh proactively (e.g., a daily background fetch) rather than waiting for expiry — this shrinks the window in which an attacker can block discovery. - If the TXT record is found but the policy fetch fails **and no valid cached policy exists**: continue delivery as if MTA-STS were not implemented (fail open on first contact). - If no live policy is discoverable but a valid, unexpired cached policy exists: apply the cached policy (this is the core downgrade protection). ## Security model MTA-STS is **trust on first use**: until a sender has cached a policy, an attacker who can block DNS responses or the HTTPS fetch can make the domain appear policy-free. Once cached, the policy protects deliveries for `max_age` — hence the RFC's guidance that `max_age` SHOULD be "as long as is practical". DoS vector: an attacker who can modify a recipient domain's DNS can publish a malicious policy (long `max_age`, wrong `mx` constraints) that senders cache. Recovery relies on senders re-checking DNS before permanent failure. Contrast with DANE: DANE (DNSSEC-backed) is more downgrade-resistant; MTA-STS trades that for deployability (no DNSSEC needed). Per RFC 8461: senders implementing both **MUST NOT allow MTA-STS validation to override a failing DANE validation** — see [DANE for SMTP](https://emailmarketing.net/learn/transport-security/dane-smtp). ## Operational playbook **Deploying:** 1. Ensure every MX presents a valid CA-signed cert with matching SAN and offers STARTTLS. 2. Publish the policy file first, then the `_mta-sts` TXT record (senders seeing a new TXT id must not cache a stale policy). 3. Start with `mode: testing` and a modest `max_age`; enable [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) and watch reports. 4. Move to `mode: enforce` and lengthen `max_age` once reports are clean. **Updating (e.g. changing MX hosts):** update the HTTPS policy body **before** the TXT `id`. Keep old policies working for delivery during the transition window (up to the old `max_age`) or risk delays. **Removing MTA-STS gracefully:** 1. Publish a policy with `mode: none` and a small `max_age` (e.g., one day). 2. After previously cached policies have expired, remove the TXT record and the HTTPS endpoint. **Delegating to a provider:** CNAME `_mta-sts.` to the provider's TXT record, and point the `mta-sts.` host at the provider (CNAME/IP or reverse proxy). The catch: the policy endpoint's certificate must validate for **your** Policy Host name (`mta-sts.yourdomain.com`), not the provider's — the provider must provision a cert for your name. ## Why deliverability senders care MTA-STS is a *receiving-domain* control, but senders are on both sides of it: - As a **sending platform**, honoring recipient MTA-STS policies (and not delivering through failing paths) is increasingly expected of reputable infrastructure, and failures show up in the recipient's TLS-RPT data. - As a **domain owner**, publishing MTA-STS + [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) on your own domains is a trust signal consistent with the authentication posture mailbox providers now demand (see [DMARC](https://emailmarketing.net/learn/authentication/dmarc)) and protects mail you *receive* (including DMARC/TLS reports and reply traffic) from interception. # NIST SP 800-177r1 — Trustworthy Email (digest) > The US federal reference for email security — its numbered security recommendations across SPF, DKIM, DMARC, TLS, DANE/MTA-STS and S/MIME, the threat/mitigation matrix, and the federal-compliance context (BOD 18-01, FISMA, SP 800-52/800-53). Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/nist-sp-800-177 If your customers include US federal agencies, or organizations close to the US public sector, your email service will be measured against the federal government's email security guidance. That guidance is NIST Special Publication 800-177r1, Trustworthy Email (Rose, Nightingale, Garfinkel and Chandramouli; February 2019, 128 pp.). Its audience is enterprise email administrators. It applies to federal IT systems, as a companion to SP 800-45v2, *Guidelines on Electronic Mail Security*, and it is explicitly offered to non-government organizations for voluntary use. For an email service provider (ESP), it matters in two ways. It is the reference that customers in or near the US public sector will hold you to. It also packages SPF, DKIM, DMARC, TLS and DANE as one coherent set of recommendations, with the formal "Security Recommendation" numbers that procurement documents cite. **Some of its references are out of date.** The document cites DMARC as RFC 7489, which RFC 9989 has since obsoleted (see [DMARC Standard](https://emailmarketing.net/learn/authentication/dmarc-standard)). It describes ARC and REQUIRETLS as IETF work in progress; they have since been published as RFC 8617 and RFC 8689 (see [ARC](https://emailmarketing.net/learn/authentication/arc) and [SMTP TLS in Practice](https://emailmarketing.net/learn/transport-security/smtp-tls-practice)). It also states that MTA-STS had "no publicly available implementations" at the time of writing, although RFC 8461 was published at the same time and MTA-STS is now widely deployed. The recommendations remain the operative federal baseline. ## Federal requirements context - It is issued under the authority of FISMA (the Federal Information Security Modernization Act of 2014), and is consistent with OMB Circular A-130. - **DHS Binding Operational Directive BOD 18-01** (October 2017) requires domain-based authentication (SPF and DMARC, plus hardening of STARTTLS and HTTPS) for the domains of the federal executive branch. SP 800-177 presents itself as the guide to meeting BOD 18-01. It "does not extend those requirements", but gives guidance on best common practice. - Cryptographic parameters defer to NIST SP 800-57 (key management), SP 800-133 (key generation), SP 800-52 (TLS configuration) and FIPS-approved modules. - Appendix C provides a full **overlay of NIST SP 800-53 Rev. 4 controls onto email systems**. It maps the control baselines (Low, Moderate and High) to guidance specific to email for SPF, DKIM and DMARC, for SMTP over TLS, and for end-to-end (S/MIME) protection. Federal deployments must show these controls, and ESPs that serve agencies are asked for exactly this mapping in security questionnaires. ## Threats and mitigations matrix (Section 3) The document classifies threats to an email service as threats to integrity, confidentiality or availability: | Threat | Impact on purported sender | Mitigation | |---|---|---| | Email sent by an unauthorized MTA inside the enterprise (malware botnet) | Loss of reputation; valid mail blocked as spam or phishing | Domain-based authentication; digital signatures; block outbound port 25 for hosts that are not mail servers | | Spoofed or unregistered sending domain | Loss of reputation | SPF, DKIM and DMARC; digital signatures | | Forged sending address (phishing or spear phishing) | Loss of reputation; recipients disclose personally identifiable information (PII) | SPF, DKIM and DMARC; digital signatures; DNS-based blocklists (DNSBLs) | | Message modified in transit | Leak or alteration | TLS between servers; DKIM detects modification; end-to-end signatures | | Disclosure of content through traffic capture | Leak of PII | TLS on each hop; end-to-end encryption | | Disclosure of metadata | Privacy | TLS (with a noted limit: headers are still visible to MTAs) | | Unsolicited bulk email (UBE) | None, unless spoofed | A layered UBE pipeline (below) | | Denial of service (DoS or DDoS) on mail servers | Cannot send | Multiple servers and network segments, cloud providers, DNSBLs | | Malicious links or attachments | None | UBE techniques; "detonation chambers"; sanitization | The infrastructure recommendations here are to **block outbound port 25 except for authorized mail senders** (Rec 3-1), to avoid running MTAs on systems that are not part of the mail infrastructure, with internal hosts relaying through a trusted mail submission agent (MSA) instead (Rec 3-2), and to block inbound port 25 to unauthorized receivers (Rec 3-3). The document also warns about virtualization. Virtual machines that share NAT IP space with legitimate senders must be firewalled off port 25 or given separate NAT instances. ## The recommendation set The normative content of the document is its numbered Security Recommendations, condensed below. ### Section 4: authenticating the sending domain | Rec | Substance | |---|---| | 4-1 | Deploy SPF for every domain; **publish `v=spf1 -all` on every domain that sends no mail** (web-only or parked) to deny spoofers | | 4-2 | Deploy DNSSEC on all name servers and validate DNSSEC on all systems that receive email | | 4-3 | Federal: DKIM keys only with approved algorithms and key lengths. RSA with SHA-256 is approved; ed25519 (RFC 8463) was **not** approved for federal use at the time of writing (SHA-1 is disallowed for signatures) | | 4-4 | Protect DKIM private keys on the sending MTA (readable only by the MTA software); federal: FISMA control SC-12 | | 4-5 | **Each sending MTA gets its own private key and selector**, which limits the damage a compromised key can do | | 4-6 and 4-7 | Sign DKIM records with DNSSEC; validate DKIM queries with DNSSEC | | 4-8 | Mailing list software should verify the DKIM signatures of inbound mail and sign outbound mail again | | 4-9 | Broadcast and do-not-reply mail should carry S/MIME signatures | | 4-10 | **A unique DKIM key pair for each third party** that sends on the organization's behalf; publish a blank `p=` (or remove the resource record) to revoke it when the contract ends | | 4-11 (DMARC) | Domains that deploy SPF and DKIM should publish a DMARC record that signals the expected disposition | | 4-12 | Receivers should honor the DMARC policies of senders and send aggregate and failure reports | | 4-11 (S/MIME)* | Use S/MIME signatures for message authenticity and integrity | \* The published document numbers both the DMARC recommendation and the S/MIME recommendation "4-11". The summary in Section 4.8 lists the S/MIME one. Cite them by topic. The DKIM key parameters (Table 4-3) are RSA with SHA-256, at a recommended length of **2048 bits** and a recommended lifetime of **1–2 years**, and ed25519 at 256 bits, which is not approved for federal use. The key rotation procedure is: publish the new selector first, reconfigure the MTA, wait (the old key stays in DNS for about a week, for queued mail), and then delete the old resource record. Do not use web-based DKIM key generators for federal systems, because they expose the private key. On the order of deployment, the document advises publishing a `p=none` DMARC record with `rua` before you roll out SPF and DKIM, so that you get baseline visibility first. It calls `pct=` values other than 0 or 100 "not a wise strategy." For SPF change management, lower the TTL of the TXT record to about 300 seconds before editing it, and restore it (to about 3600 seconds) after you verify the change. Chains of SPF `include:` mechanisms are bounded by the limit of 10 DNS lookups. Do not `+` an include you do not control. To collect DMARC reports at a third party, the external report receiver must publish the authorization record `original-sender-domain._report._dmarc.mailto-domain`. Forwarding impact (Table 4-7): | Relay technique | Typical use | Breaks | |---|---|---| | Aliases | Forwarding, vanity addresses | SPF | | Re-sender | Forwarding from the mail client, or inline | SPF and DKIM | | Mailing lists | Re-posting with changes to the body | SPF and DKIM, which leads to DMARC rejection and to list unsubscribes | | Gateways | Unrestricted rewriting | SPF and DKIM | | Boundary filters | Spam and malware filters that modify content | DKIM | | Third parties | Email scanners, TIC providers | SPF and DMARC | The document's canonical forwarding failure is the Trusted Internet Connection (TIC) scanning loop. A cloud provider forwards mail to a scanner, and the scanner returns mail that now looks spoofed. ARC is the suggested mitigation. ### Section 5: transmission and content security | Rec | Substance | |---|---| | 5-1 | Use only TLS versions approved in NIST SP 800-52, with FIPS-approved cryptographic modules | | 5-2 | Servers that support TLS should advertise STARTTLS, and clients should attempt it whenever it is offered (the opportunistic floor; see [SMTP TLS in Practice](https://emailmarketing.net/learn/transport-security/smtp-tls-practice)) | | 5-3 | Receiving domains should implement **DANE, MTA-STS, or both** for every MX | | 5-4 | Federal DANE deployments: use **DANE-TA(2)**, where the certificate usage pins the certificate authority (CA) the agency chose, because federal use requires chain authentication to a known CA. Publish a **DANE-EE(3) record alongside it** for reliability. Both use selector SPKI(1) and matching type SHA2-256(1), that is, the TLSA parameters `3 1 1` and `2 1 1` | | 5-5 | Federal: S/MIME (with a certificate from a known CA) is preferred over OpenPGP for message confidentiality | The supporting analysis matches the guidance in [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) and [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts), and goes slightly further: - PKIX-TA(0) and PKIX-EE(1) should not be used for opportunistic DANE. - DANE-EE(3) needs no SNI or name check, because the trust comes from DNSSEC. - Publishing both `3 1 1` and `2 1 1` lets clients validate through either DANE or the CA system. Its comparison of DANE and MTA-STS (Table 5-3) sets out the differences. DANE uses TLSA records and MTA-STS uses TXT records. DANE requires DNSSEC on the client, and MTA-STS requires HTTPS. DANE can scope CAs and MTA-STS cannot. PKIX is not required with DANE and is required with MTA-STS. Self-signed certificates are acceptable only with DANE certificate usage 3. Failure reporting exists only in the MTA-STS ecosystem ([TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt), RFC 8460). On failure, DANE closes the connection, while the behavior of MTA-STS depends on the policy. When both are deployed, DANE takes precedence. The certificate profile for federal mail follows the FPKI "FPIX" profiles, with `KeyPurposeId` `id-kp-emailProtection (1.3.6.1.5.5.7.3.4)`. CA signature hashes are SHA-256 or SHA-512 only, and device certificates carry the DNS name or IP address in subjectAltName. ### Sections 6–7: UBE filtering and end-user access - For inbound and outbound filtering, the recommended **pipeline order is blocklist and allowlist checks, then domain-based authentication, then content filtering**, cheapest first. Dynamic DNSBLs are preferred over static local lists. Mail that passes SPF, DKIM and DMARC "should not automatically be assumed to not be UBE." - Rec 7-1: IMAP and POP3 clients must connect over TLS (RFC 8314). Cleartext TCP with password authentication is "strongly discouraged." - Rec 7-2: maintain a cryptographic key management system (CKMS) for keys related to email (federal: compliance with SP 800-57). - Rec 7-3: keys that encrypt stored mail must be different from the keys used in transmission. ## What an ESP should take from it 1. **The `-all` rule for domains that send no mail (4-1)** and **a unique DKIM key for each third party (4-10)** are the two recommendations aimed most directly at the relationship with an ESP. An agency customer that follows 800-177 will demand a dedicated key pair, not your shared signing key, and will null-route its parked domains. 2. **A key and selector for each MTA (4-5)** is stricter than common ESP practice, which is one key per customer domain. Expect it in federal security reviews. 3. **DANE-TA(2) with DANE-EE(3), using `2 1 1` and `3 1 1`,** is the concrete federal TLSA recipe if you host inbound mail for such customers. 4. The **SP 800-53 Appendix C overlay** is the document to point to when a customer close to government asks "how does your email service map to our control baseline." 5. DNSSEC runs through every recommendation (4-2, 4-6, 4-7, and as a prerequisite for DANE). Realistically, sending and bounce domains that serve federal customers need zones signed with DNSSEC. # SMTP Smuggling — End-of-DATA Discrepancy Spoofing > How mismatched end-of-DATA parsing between MTAs (bare . vs standard .) lets an attacker smuggle a second spoofed message that inherits the session's authenticated domain and passes SPF/DKIM/DMARC; the Dec 2023 SEC Consult disclosure and the receiver-side fixes. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/smtp-smuggling Even when your domain publishes SPF, DKIM and a DMARC policy of reject, a forged message using your domain can pass all three checks at a receiver whose mail server is vulnerable to SMTP smuggling. SMTP smuggling is a **spoofing** attack. It exploits the fact that two mail transfer agents (MTAs) in a mail path can disagree about where the DATA of a message ends. The base protocol ([RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp)) ends DATA with exactly `.`: a dot alone on a line, framed by CRLF. For decades, servers have also tolerated non-standard variants with a bare ``, such as `.`, `.` and `.`. This leniency dates from Sendmail, and Postfix, Exim and others copied it for interoperability. When the sending (outbound) server and the receiving (inbound) server tolerate different sets of these variants, an attacker can inject a crafted line-ending sequence into a message body. The receiver then believes DATA has ended partway through the message, and treats the bytes that follow as **new SMTP commands**. They form a second `MAIL FROM` / `RCPT TO` / `DATA` transaction, that is, a second, fully spoofed message "smuggled" inside one legitimate SMTP transaction. **SEC Consult disclosed the attack publicly on 18 December 2023.** It is one of the more serious email spoofing techniques of recent years because of what it defeats: it makes a forged message pass SPF, DKIM and DMARC. It is mainly a **vulnerability of receivers**, and the fix belongs in the inbound MTA. Senders and ESPs still need to understand it, because a vulnerable receiver silently undermines the DMARC protection that senders rely on to defend their domains. The attack does not weaken any authentication record you publish. It defeats the enforcement of those records at a vulnerable receiving server. ## The parsing discrepancy There are two roles and two ways to fail, and the attack needs one failure of each kind: | Role | Vulnerable behavior | Consequence | |---|---|---| | **Outbound or submission MTA** | Forwards a message body that contains a dot sequence with a bare ``, without normalizing it to `` or rejecting it | A message goes out on the wire carrying an embedded, non-standard end-of-DATA marker | | **Inbound or receiving MTA** | Accepts a non-standard sequence such as `.` as a **valid** end of DATA | The bytes after it are parsed as new SMTP commands instead of message content | Neither behavior can be exploited on its own. The outbound server must let the unusual sequence through onto the wire, and the receiving server must accept it as the end of DATA. An attacker who controls a lenient outbound service, or has a free or compromised account on one, and who targets a lenient inbound service, can exploit the gap between them. ### Anatomy of a smuggled transaction An authenticated attacker submits **one** message through the outbound service. The visible envelope and headers use the attacker's own legitimate, throwaway address, so the submission is authorized. Inside the DATA payload, the attacker plants: ``` ...legitimate-looking body... . ← smuggled end-of-DATA (receiver honors it) MAIL FROM: RCPT TO: DATA From: admin@victim-domain.example Subject: (spoofed message) ...attacker payload... . ← real end-of-DATA ``` The vulnerable outbound service sends all of this as the body of the first message, because it did not treat `.` as the end of DATA. The vulnerable inbound service reads the same bytes, but does treat `.` as the end of the first message. It then interprets `MAIL FROM` / `RCPT TO` / `DATA` as a brand-new transaction. The receiver has now accepted a second message whose `From:` is `admin@victim-domain.example`, delivered over the outbound provider's own trusted, authenticated connection. `BDAT` / `CHUNKING` ([RFC 3030](https://emailmarketing.net/learn/rfc/esmtp-extensions)) offers a related route. BDAT frames content with an explicit count of octets instead of scanning for `.`, so it allows command pipelining that the DATA path forbids. Faulty BDAT handling has been a separate smuggling route on the inbound side. This is the interoperability warning noted in the [CHUNKING section of the ESMTP extensions reference](https://emailmarketing.net/learn/rfc/esmtp-extensions#rfc-3030--chunking-bdat-and-binarymime). ## Why it bypasses SPF, DKIM, and DMARC The smuggled message is not authenticated in its own right. It inherits the authentication of the outer session. Each mechanism fails for a different reason: | Mechanism | Why the smuggled message passes | |---|---| | **[SPF](https://emailmarketing.net/learn/authentication/spf)** | SPF checks the **envelope MAIL FROM** against the connecting IP address. The smuggled transaction is delivered from the outbound provider's own IP address, which is legitimately in the provider's SPF record. The receiver sees a smuggled `MAIL FROM` from a domain that either passes on that IP address or is simply evaluated against trusted infrastructure. SPF never looks at the `From:` header at all. | | **[DKIM](https://emailmarketing.net/learn/authentication/dkim)** | The forged `From:` domain does not need a valid signature. The attacker signs with a domain they control (which verifies correctly), or relies on the receiver not enforcing alignment with the header domain. DKIM proves that some domain signed some headers, not that the `From:` domain authorized this message. | | **[DMARC](https://emailmarketing.net/learn/authentication/dmarc)** | DMARC requires SPF or DKIM to **pass and align** with the `From:` domain. The smuggled message achieves alignment because it comes from legitimate outbound infrastructure that the victim domain's records already approve, or that the receiver already trusts. The receiver evaluates it as though the provider sent it on behalf of the victim domain. | The result: `admin@outlook.com`, `admin@microsoft.com`, or any address at ~1.35 million domains hosted by GMX and Ionos could be spoofed with a passing DMARC result at a vulnerable receiver. A domain owner who has done everything right (SPF, DKIM, DMARC at `p=reject`) gets no protection at a receiver that ends DATA leniently, because the forgery never had to defeat the records. It arrived inside a trusted session. Compare this with [DKIM replay](https://emailmarketing.net/learn/authentication/dkim-replay). Replay resends a genuinely signed message unchanged, to spend a sender's reputation. Smuggling creates a new message that borrows the authentication of a session. Both defeat the simple reasoning that a message is trustworthy because DMARC passed, from opposite directions. ## The December 2023 disclosure: affected parties SEC Consult (Timo Longin) demonstrated the attack against major production infrastructure. The difference between the **outbound** role (failing to clean up the sequence) and the **inbound** role (accepting unusual sequences) matters, because a provider could be exploitable in one role, the other, or both. | Party | Role reported | Notes and status | |---|---|---| | **GMX / Ionos** (United Internet) | Outbound | Allowed smuggling from ~1.35 million hosted domains. Patched **10 Aug 2023**. | | **Microsoft Exchange Online** | Outbound | Allowed spoofing from millions of domains (for example `outlook.com`, `microsoft.com`). Patched **16 Oct 2023**. | | **Cisco Secure Email (Gateway / Cloud Gateway)** | Inbound | Accepted unusual sequences in the **default** configuration. Cisco at first declined to change the default, so operators had to apply the receiver-side workaround themselves. | | **Apple iCloud, Fastmail, Startmail, Runbox** | Outbound, inbound, or both (varies) | Listed among the affected services in the disclosure. | | **Postfix, Sendmail, Exim** | Inbound (and outbound leniency) | The MTA software itself. Coordinated fixes and workarounds followed. | **Disclosure timeline:** first discoveries in June 2023, notifications to vendors in late July 2023, patches from GMX (Aug) and Microsoft (Oct), and **public disclosure on 18 Dec 2023**. **CVEs** were assigned to the open-source MTAs: | CVE | Software | |---|---| | **CVE-2023-51764** | Postfix | | **CVE-2023-51765** | Sendmail | | **CVE-2023-51766** | Exim | ## Mitigations The lasting fix is **strict enforcement of the end of DATA at the receiver**: accept only `.`, and neutralize bare newlines before they can be read as the end of DATA. Cleaning up on the outbound side, by normalizing a bare `` to `` before sending, closes the other half. The large providers deployed exactly this on their servers. ### Postfix (receiver-side) Postfix's guidance (postfix.org/smtp-smuggling.html) offers a short-term workaround and a long-term fix. Parameter defaults depend on the Postfix release. **Long-term fix**: handling of bare newlines (Postfix 3.8.5 / 3.7.10 / 3.6.14 / 3.5.24 and later): ``` smtpd_forbid_bare_newline = normalize smtpd_forbid_bare_newline_exclusions = $mynetworks ``` `normalize` accepts a bare `` from the client but processes it as if `` had been sent, while still requiring the standard `.` to end DATA. This defeats `.` smuggling without breaking older clients. The stricter `reject` setting refuses any bare newline outright, but may reject some legitimate mail. The `$mynetworks` exclusion spares trusted internal senders, such as local scripts. Later Postfix releases moved the default toward enforcement. **Short-term workaround**: block the route through pipelining and CHUNKING: ``` smtpd_data_restrictions = reject_unauth_pipelining smtpd_discard_ehlo_keywords = chunking, silent-discard ``` or, on Postfix 3.8.1+: ``` smtpd_forbid_unauth_pipelining = yes smtpd_discard_ehlo_keywords = chunking, silent-discard ``` `smtpd_forbid_unauth_pipelining` is enabled by default in Postfix 3.9+. In 3.8.1 / 3.7.6 / 3.6.10 / 3.5.20 it shipped disabled, for compatibility. Discarding the `chunking` EHLO keyword withdraws BDAT, which removes the route through BDAT command pipelining. The cost is losing the benefits BDAT would otherwise give for throughput and large messages. ### Cisco Secure Email (receiver-side) Change how the listener handles non-standard line endings. The vulnerable **"Clean"** behavior rewrites a bare CR or LF into CRLF, and can create an exploitable sequence for the backend server. Switch it to **"Allow"**, which passes the bytes through unchanged, so a strict backend that requires `.` never sees a false end of DATA. The vulnerable value was the default and vendor support was lacking at first, so operators had to make this change themselves. ### General receiver checklist - Enforce `.` as the **only** end of DATA. Reject or normalize a bare `` or ``. - Forbid unauthenticated command pipelining. Treat `MAIL FROM`, `RCPT TO` or `DATA` appearing inside DATA as a sign of attack. - Withdraw `BDAT` and `CHUNKING` on untrusted inbound listeners, or audit them carefully. - Clean up outbound mail too. Normalize bare newlines so that your outbound path can never send the building block of a smuggling attack to a receiver further along. - Keep MTA software up to date (past the CVE-2023-5176x fixes). ## What it means for senders and ESPs - **You cannot fix this by changing your own DNS records.** No SPF, DKIM or DMARC configuration stops smuggling, because it defeats enforcement, not publication. `p=reject` is still worth having. It protects you at every receiver that is patched, which since 2023 covers the large majority of mailbox-provider volume. - **If you are an ESP running inbound MTAs** (intake of feedback loop reports, the `abuse@` and `postmaster@` role addresses, bounce processors, MX for customer domains), you are a receiver, and the receiver-side fix is yours: strict enforcement of the end of DATA, current MTA builds, and careful control of where BDAT is offered. See [abuse desk](https://emailmarketing.net/learn/esp-operations/abuse-desk) and [outbound monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) for where these listeners are. - **If you are an ESP running outbound MTAs**, make sure your submission path normalizes bare newlines. Otherwise a compromised or hostile customer could use your trusted IP addresses to smuggle spoofed mail from a third party's domain into a vulnerable receiver, which is exactly the abuse the large providers had to patch. This belongs with the hygiene of [customer domain authentication](https://emailmarketing.net/learn/esp-operations/customer-domain-authentication), and with the wider forms of spoofing abuse in the [email abuse taxonomy](https://emailmarketing.net/learn/reference/email-abuse-taxonomy). - **Understand the risk that remains in reporting.** A customer or brand you protect may see a report of a spoofed message that "passed DMARC", and the explanation may be a vulnerable receiver rather than a flaw in their setup. Being able to name SMTP smuggling, and point to the receiver-side fix, is the difference between a correct diagnosis and a long, fruitless search through the sender's DNS. ## Related articles - [DMARC (introduction)](https://emailmarketing.net/learn/authentication/dmarc), on the alignment logic that smuggling borrows to pass - [DKIM Replay](https://emailmarketing.net/learn/authentication/dkim-replay), the other major attack that defeats the assumption that a DMARC pass means a message can be trusted - [SMTP (RFC 5321)](https://emailmarketing.net/learn/rfc/rfc5321-smtp), which defines `.` as the end of DATA - [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions), on PIPELINING, CHUNKING and BDAT, which the workarounds restrict - [SPF](https://emailmarketing.net/learn/authentication/spf) and [DKIM](https://emailmarketing.net/learn/authentication/dkim), neither of which inspects the `From:` header on its own # SMTP TLS in Practice (STARTTLS, Implicit TLS, REQUIRETLS, version floors) > The sender-side TLS layer for mail — RFC 3207 STARTTLS mechanics, RFC 7435 opportunistic security, RFC 8314 implicit TLS on 465/587, RFC 8689 REQUIRETLS, and the RFC 8996 TLS 1.0/1.1 deprecation. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/smtp-tls-practice If you send mail or run a submission service, you need to know how TLS is actually negotiated, when your servers may fall back to cleartext, and which ports and TLS versions to offer. [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts), [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) and [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) are policies that receiving domains publish. Beneath them is the layer described here, seen from the sender's side. That layer covers how STARTTLS works on the wire, why mail uses opportunistic TLS by default (without authentication, and tolerating downgrades), which ports and TLS versions apply where, and how TLS can be made mandatory for a single message (REQUIRETLS) or through a minimum protocol version (the deprecation of TLS 1.0/1.1). ## STARTTLS mechanics (RFC 3207) STARTTLS upgrades a cleartext SMTP session to TLS on the same port (25 for relay between MTAs, 587 for submission). The sequence on the wire: 1. The client connects, the server greets it with `220`, and the client sends `EHLO`. 2. A server that supports TLS lists the `STARTTLS` keyword (with no parameters) in its EHLO response. 3. The client sends the command `STARTTLS` on its own (no parameters are allowed). 4. The server replies, and after a `220` both sides start the TLS handshake immediately. | Reply code | Meaning | |---|---| | `220` | Ready to start TLS. The client MUST begin TLS negotiation immediately | | `501` | Syntax error (parameters were supplied, and none are allowed) | | `454` | TLS not available for a temporary reason (the client can retry) | | `530` | "Must issue a STARTTLS command first": the server requires TLS before other commands | | `554` | The server refuses further SMTP commands because the security achieved is not sufficient | Rules after the handshake: - The SMTP session **returns to its initial state**, as if the 220 greeting had just been sent. The server MUST discard everything it learned from the client before TLS (for example, the EHLO argument), and the client MUST discard the list of server capabilities it received before TLS. - The client SHOULD send a new `EHLO`. The list of extensions the server advertises MAY differ from the one sent in cleartext. - The server MUST NOT advertise `STARTTLS` in its EHLO response after the handshake, and the client MUST NOT send STARTTLS when TLS is already active. - A publicly referenced SMTP server (an MX for a domain) MUST NOT require STARTTLS before it delivers mail locally. RFC 3207 forbids mandatory TLS on the public port 25 because not all senders support it. A receiving domain that wants mandatory TLS uses [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) or [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) instead, and a sender uses REQUIRETLS, described below. The security model has a weakness. Everything before the handshake, including the EHLO exchange and the STARTTLS advertisement itself, travels in cleartext and "may be modified by an active attacker." An attacker in the middle can simply remove the STARTTLS keyword, and the session continues in cleartext without any warning. This is the classic downgrade attack. RFC 3207's own answer is configuration. Both clients and servers "MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred," and clients should check that the domain name in the server certificate matches the host they meant to reach. In practice, almost no MTA does this for all destinations, because it would break delivery. That is why the policy mechanisms (MTA-STS, DANE, REQUIRETLS) exist. ## Why mail tolerates downgrade: opportunistic security (RFC 7435) RFC 7435 sets out the design thinking behind how MTAs behave by default. It reverses the usual view of security. Instead of treating cleartext as a failure, it treats cleartext as the **baseline** and any encryption as an improvement: "some protection most of the time" is better than a strict policy that blocks communication. The main principles: - **Encrypt whenever both sides support it, and authenticate when possible** through means that resist downgrade (DANE, keys cached on first use (TOFU), manual configuration). With each peer, the result may be authenticated and encrypted, encrypted without authentication, or cleartext, whichever is the best available. - **An explicit policy overrides opportunistic behavior.** Where an administrator, or a policy published by the recipient, makes security mandatory, the mandatory policy wins. Opportunistic security is the minimum, not the maximum. - **Do not misrepresent the protection.** Sessions that are encrypted but not authenticated must not be logged, or shown to users, as equal to authenticated encryption. - **Prefer forward secrecy (PFS)** wherever possible, so that recorded traffic cannot be decrypted if a key is compromised later. The terms it introduces, which the transport security guides on this site also use: | Term | Meaning | |---|---| | Unauthenticated, encrypted | TLS without checking the peer's identity. It defeats passive monitoring but not an active attacker in the middle (MITM). It is still strictly better than cleartext | | Authenticated, encrypted | The peer's identity is verified (by a certificate or DANE). It defeats both passive and active attacks | | TOFU | Trust on first use: accept a key without authentication the first time, cache it, and check that it stays the same afterward (the caching model of MTA-STS works in a similar way) | The trade-off is deliberate. Opportunistic TLS accepts the risk of downgrade because the main benefit of encryption is against pervasive passive monitoring, and active attacks at scale can be detected. Falling back to cleartext when the TLS handshake fails is acceptable for opportunistic sessions only, because the alternative, refusing delivery, punishes the wrong party. This is the default behavior of nearly every sending MTA today. It is also why an ESP's outbound TLS policy is normally to "offer and attempt TLS everywhere, and verify certificates only where a recipient policy (MTA-STS or DANE) or a local rule for that destination requires it." ## Submission and access: implicit TLS on 465 (RFC 8314) RFC 8314 ("Cleartext Considered Obsolete") covers the side of mail that users connect to: submission from a mail client to a submission server (MUA to MSA), and access to mailboxes. It moves the recommendation from STARTTLS to **implicit TLS**, where TLS is negotiated as soon as the connection opens, before any protocol exchange: | Protocol | Port | Service name | Mode | |---|---|---|---| | SMTP submission | **465** | `submissions` | Implicit TLS (now the recommended main option) | | SMTP submission | **587** | `submission` | STARTTLS (kept during the transition) | | IMAP | 993 | `imaps` | Implicit TLS | | POP3 | 995 | `pop3s` | Implicit TLS | What an ESP should know: - Port 465 was registered incorrectly in the past ("smtps", later given to another service), but it was so widely used for submission that RFC 8314 made the existing practice official and registered it with IANA as `submissions`. It is **not** for relay between MTAs: port 25 still uses STARTTLS only. - Implicit TLS is preferred to STARTTLS because it is simpler to implement and debug, and because it is immune to the STARTTLS command injection vulnerabilities, where commands pipelined before TLS leak into the session after TLS. - During the transition, "clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465". When both are configured properly, there is no significant difference in security. - Minimum versions: servers and mail clients **MUST support TLS 1.2 or later**. The default minimum requirement for confidentiality is negotiation of TLS 1.1 or later, which RFC 8996 (below) raises in practice. SSL 2.x, SSL 3.0 and TLS 1.0 should be discontinued "as soon as practicable." - Certificates: servers must keep valid certificates for all their service names (as RFC 7817 describes) and support Server Name Indication (SNI). Mail clients SHOULD NOT treat a session as confidential if the certificate does not validate. TLSA records signed with DNSSEC are an optional additional trust anchor. - When a provider stops accepting authentication in cleartext, the server "MUST NOT provide any indication over a cleartext channel of whether the user's authentication credentials were valid". This prevents attackers from discovering valid accounts over the insecure path. - It adds two clauses to the Received header: `tls` (the negotiated cipher suite) and `group` (the Diffie-Hellman group). They are useful when you audit the encryption of a delivery path. Why this matters to an ESP: the SMTP endpoints where your customers inject mail are submission services. The RFC 8314 baseline that customers' libraries increasingly expect is to offer 465 (implicit TLS) and 587 (STARTTLS), require TLS 1.2 or later, refuse authentication in cleartext, and present a valid certificate that supports SNI. ## Per-message mandatory TLS: REQUIRETLS (RFC 8689) REQUIRETLS is the sender's counterpart to the policies that recipients publish with MTA-STS and DANE. It lets the **originator of a message** require TLS for that specific message at every hop, and receive a bounce rather than have the message delivered in cleartext. It has two independent mechanisms that work in opposite directions. ### The REQUIRETLS SMTP extension (require TLS) - The server advertises `REQUIRETLS` in its EHLO response, and the client uses it as a parameter with no value on `MAIL FROM` (`MAIL FROM: REQUIRETLS`). - A client may forward a REQUIRETLS message to a server only when **all** of these are true: (1) the session is protected by TLS; (2) the MX lookup can be trusted, because it was signed with DNSSEC **or** the MX was validated by an MTA-STS policy; (3) the server's certificate chain verifies (through the Web PKI or DANE); (4) the next server's EHLO response after TLS advertises REQUIRETLS. - The sending MTA tries each MX host in turn until one meets every condition. If none does, the message MUST NOT be transmitted and MUST be bounced. - Relays MUST pass the REQUIRETLS parameter on. Intermediaries that send messages again as new messages should keep the requirement "to the extent feasible." How failures are reported, with enhanced status codes (see [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes)): | Code | Meaning | |---|---| | `5.7.30` | REQUIRETLS support required (the next hop does not support the extension) | | `5.7.10` | Encryption needed (a session protected by TLS could not be established) | Bounce handling: non-delivery reports for REQUIRETLS messages MUST themselves carry REQUIRETLS (unless they are redacted), and the server MUST behave as if `RET=HDRS` were set. The bounce contains only the headers, never the body, so the protected content cannot leak through the delivery status notification (DSN). Bounces with a null return path should not be discarded silently just because the next relay does not support REQUIRETLS. ### The `TLS-Required: No` header field (waive TLS) This header makes the opposite request. A message header (`TLS-Required: No`) tells MTAs that the sender explicitly prefers delivery even without TLS, and instructs clients to ignore a DANE or MTA-STS policy that fails for this message. It is meant for mail that must reach a misconfigured domain, for example a message telling the postmaster that their TLS is broken. Clients that handle it "SHOULD attempt to send the message regardless of the ability to negotiate STARTTLS", while still using encryption when it is available. Unlike the SMTP extension, the header survives passing through MTAs that do not implement RFC 8689. Limitations: REQUIRETLS provides transport security only. Messages remain readable in plaintext on every MTA along the path, and confidentiality from end to end still requires S/MIME or OpenPGP. Adoption among large mailbox providers is still limited. Use REQUIRETLS for streams that must be secure between parties that cooperate (see [Mandated & Regulatory Email](https://emailmarketing.net/learn/operations/mandated-and-regulatory-email)), not on general marketing traffic. ## Version floor: TLS 1.0 and 1.1 are deprecated (RFC 8996) RFC 8996 (March 2021, BCP 195) formally deprecates TLS 1.0, TLS 1.1 and DTLS 1.0. It moves RFC 2246 (TLS 1.0), RFC 4346 (TLS 1.1), RFC 4347 (DTLS 1.0), RFC 5469 (the DES and IDEA cipher suites) and RFC 7507 (Fallback SCSV) to Historic status. The normative rules: - "TLS 1.0 MUST NOT be used" and "TLS 1.1 MUST NOT be used". Negotiating either of them from any TLS version MUST NOT be permitted. - Clients MUST NOT send a ClientHello with `client_version` {03,01} (1.0) or {03,02} (1.1), and servers MUST NOT send a matching ServerHello. Any party that receives a Hello with those versions MUST respond with a `protocol_version` alert and close the connection. - Servers MUST still accept any `{03,XX}` version number at the record layer of a ClientHello (for interoperability), but MUST NOT negotiate the deprecated versions. The reasons: both versions tie the integrity of the handshake to SHA-1, which allows downgrade attacks at a cost of ~2^77 operations. They authenticate with SHA-1 or MD5||SHA-1 signatures, support no AEAD cipher suites, and require obsolete ciphers (for example, `TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA`). In operation, every extra version you support is a source of misconfiguration and maintenance work. The sentinel value in TLS 1.3's ServerHello.Random replaces the Fallback SCSV defense against downgrade. What this means for mail (the RFC itself applies to all protocols): the practical minimum for SMTP, submission, IMAP and POP is **TLS 1.2**, with TLS 1.3 preferred. [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) already requires senders to support TLS 1.2 or later. Major mailbox providers have progressively refused TLS ≤1.1 on submission, and increasingly score or refuse handshakes with old versions on port 25. An ESP whose servers still offer TLS 1.0/1.1 for outbound mail will see handshake failures, logged as deferrals or bounces, at strict receivers. Accepting very old versions on inbound connections is a compliance finding. Configure a minimum of TLS 1.2, modern AEAD cipher suites, key exchange with PFS, and TLS 1.3 enabled. ## Sender-side operational summary for an ESP | Layer | Default behavior | Stricter options | |---|---|---| | Outbound port 25 | Opportunistic STARTTLS everywhere; fall back to cleartext if the handshake fails (RFC 7435) | Honor the [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) and [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) policies of recipients (verify certificates, refuse insecure paths, defer rather than downgrade); mandatory TLS rules for the destinations of contracted partners; REQUIRETLS for messages that must never travel in cleartext | | TLS versions and ciphers | TLS 1.2 minimum, 1.3 preferred, AEAD and PFS (RFC 8996) | Never turn 1.0 or 1.1 back on to "fix" delivery to a very old receiver; that receiver is the exception | | Certificates (validation on outbound mail) | Not enforced for opportunistic sessions | MUST be enforced when an MTA-STS or DANE policy, or REQUIRETLS, applies | | Submission (for customers) | 465 with implicit TLS and 587 with STARTTLS, TLS 1.2 or later, a valid certificate with SNI, no authentication in cleartext (RFC 8314) | None | | Visibility | Log the negotiated version and cipher for each delivery; generate [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) reports for domains that ask for them; watch the encryption dashboard in Google Postmaster Tools | None | # SMTP TLS Reporting (TLS-RPT, RFC 8460) > The reporting channel for SMTP transport security — DNS record syntax, JSON report schema, the full failure result-type taxonomy, and how to use the reports operationally. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/tls-rpt If you are about to enforce TLS for mail sent to your domain, you need to know first whether any legitimate mail would fail. TLS reporting (TLS-RPT) tells you. Your domain publishes a DNS record that asks sending mail servers (MTAs) to report every day how TLS negotiation with your domain went: what succeeded, what failed, and why. TLS-RPT is defined in RFC 8460 and works alongside [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) and [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp). Those two mechanisms enforce TLS; TLS-RPT tells you whether enforcement would break real mail flow, or is already breaking it. It does for transport security what DMARC aggregate reports do for [authentication](https://emailmarketing.net/learn/authentication/dmarc). ## The DNS record The record is a TXT record at `_smtp._tls.`: ``` _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:reports@example.com" _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://reporting.example.com/v1/tlsrpt" ``` | Directive | Required | Value | |---|---|---| | `v` | yes | `TLSRPTv1` | | `rua` | yes | A comma-separated list of report destinations, using the `mailto:` or `https:` scheme | Several `rua` endpoints are allowed. A reporter may try all of them or choose one, and the report counts as delivered as soon as **any one** endpoint accepts it. ## Report generation and timing - **Period:** one full calendar day in UTC (00:00–24:00 UTC). - **Delivery delay:** reporters should add a random delay of 1–14,400 seconds, so that receivers are not hit by all reports at once. - **Retries:** if delivery fails, retry for up to 24 hours after the first attempt, preferably with exponential backoff. - **Exception for email reports:** when a report is delivered by email, the reporter must NOT apply MTA-STS or DANE failures to that delivery. Reports about broken TLS must still get through, without encryption if necessary. ## Delivery mechanisms ### By email (`mailto:`) | Aspect | Requirement | |---|---| | MIME structure | `multipart/report; report-type="tlsrpt"` | | Media type of the report part | `application/tlsrpt+json` (plain) or `application/tlsrpt+gzip` (compressed with gzip, with the extension `.json.gz`; gzip is recommended) | | Required headers | `TLS-Report-Domain:` (the domain the report is about) and `TLS-Report-Submitter:` (the reporting domain) | | DKIM | Report messages MUST carry a valid DKIM signature with the service type `s=tlsrpt`, and the `l=` (body length) tag MUST NOT be used. Receivers should ignore email reports that are not signed | | Subject | `Report Domain: Submitter: Report-ID: ` | ### By HTTPS (`https:`) - An HTTP POST of `application/tlsrpt+json` or `application/tlsrpt+gzip` to the endpoint. - Delivery succeeds when the response is HTTP 200 or 201. - Reporters MAY ignore HTTPS certificate validation errors when they post, because the reporting channel must not be blocked by the very problems it reports. ### Report filename convention ``` {sender}!{policy-domain}!{start-timestamp}!{end-timestamp}[!{unique-id}].{json|json.gz} ``` Example: `mail.sender.example.com!example.net!1470013207!1470186007!001.json.gz` ## Report content (JSON schema) Top-level fields: | Field | Meaning | |---|---| | `organization-name` | The reporting organization | | `date-range` | `start-datetime` / `end-datetime`, in RFC 3339 format, covering the UTC day | | `contact-info` | Email address of the party responsible for the report | | `report-id` | Unique report identifier | | `policies` | An array of result objects, one for each policy (it is an array even when there is only one policy) | Each entry in `policies` describes one policy the sender evaluated. A single day can include both an MTA-STS entry and a DANE entry for the same domain: ```json { "policy": { "policy-type": "sts" | "tlsa" | "no-policy-found", "policy-string": ["version: STSv1", "mode: testing", "..."], "policy-domain": "example.com", "mx-host": "*.mail.example.com" }, "summary": { "total-successful-session-count": 5326, "total-failure-session-count": 303 }, "failure-details": [ ... ] } ``` Each `failure-details` entry contains: | Field | Meaning | |---|---| | `result-type` | The type of failure (table below) | | `sending-mta-ip` | The reporter's sending IP address (IPv4 in dotted-decimal notation, or IPv6 as in RFC 5952) | | `receiving-mx-hostname` | The MX hostname the sender connected to | | `receiving-mx-helo` | Optional: the HELO or EHLO banner the sender saw | | `receiving-ip` | The destination IP address used | | `failed-session-count` | The number of sessions with this failure | | `additional-information` | Optional: a URI with more detail | | `failure-reason-code` | Optional: detail about the TLS error (for example, an X.509 or OpenSSL error string) | A single session can count toward more than one `result-type`, because the types do not exclude each other. ## Failure result types | result-type | Class | Meaning | |---|---|---| | `starttls-not-supported` | negotiation | The recipient's MX did not advertise STARTTLS | | `certificate-host-mismatch` | negotiation | The identity in the certificate (hostname or SAN) did not match | | `certificate-expired` | negotiation | The certificate is past the end of its validity period | | `certificate-not-trusted` | negotiation | An untrusted or unknown certificate authority, a violated name constraint, or an error in the chain | | `validation-failure` | general | A negotiation failure that fits no other type; see `failure-reason-code` for detail | | `tlsa-invalid` | DANE | An error validating the TLSA record; no valid member of the record set matched | | `dnssec-invalid` | DANE | DNSSEC validation failed; no validly signed records were returned | | `dane-required` | DANE | The sender requires DANE, but no valid TLSA records signed with DNSSEC exist | | `sts-policy-fetch-error` | MTA-STS | The policy could not be retrieved (for example, the policy host was unreachable) | | `sts-policy-invalid` | MTA-STS | The MTA-STS policy was retrieved but failed validation | | `sts-webpki-invalid` | MTA-STS | The MTA-STS policy host failed Web PKI (certificate) authentication | ## Using the reports TLS-RPT is how you reduce the risk of moving [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) from `testing` to `enforce`: 1. **Publish TLS-RPT first**, or at the same time as an MTA-STS policy in `testing` mode. Reports arrive from every major sender that implements RFC 8460: Google, Microsoft and other large platforms send them. 2. **Watch `total-failure-session-count` for each policy type.** MTA-STS failures in testing mode that are not zero represent mail that would have been deferred or lost under enforcement. 3. **Sort failures by result type:** - `certificate-*`: fix the certificates on the named `receiving-mx-hostname` (expired, wrong SAN, private certificate authority). - `starttls-not-supported`: an MX, often a backup MX or an old appliance, has TLS turned off. - `sts-policy-fetch-error` / `sts-webpki-invalid`: your HTTPS endpoint at `mta-sts.`, or its certificate, is broken. - `sts-policy-invalid`: the policy syntax is wrong, or an `mx` pattern does not cover a real MX. - `tlsa-*` / `dnssec-invalid`: TLSA records are out of date, or DNSSEC signing has a problem (see the [DANE guidance on key rotation](https://emailmarketing.net/learn/transport-security/dane-smtp)). 4. **Keep monitoring after you enforce.** An expired certificate on one MX now defers mail from strict senders without any other warning, and TLS-RPT is often the only signal from outside your systems. 5. If one organization reports failures for a long time while others report success, the cause is usually a problem on the network path of that sender (or interception), not your configuration. A note on internationalized domain names: they appear as Punycode A-labels in all records and reports, never as U-labels. # TLS for Mail: M3AAWG Baseline Recommendations (April 2026) > The industry TLS floor — opportunistic TLS everywhere with only TLS 1.2/1.3, encrypted intracompany traffic, encrypted user access (993/995/465/587/HTTPS), and TLS version/cipher logging feeding TLS-RPT. Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/tls-baseline If you run mail servers, a short list of measures protects your mail from eavesdropping, and you can put them in place relatively quickly. They are the base that [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts), [DANE for SMTP](https://emailmarketing.net/learn/transport-security/dane-smtp) and [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) build on. The measures come from *TLS for Mail: M3AAWG Baseline Recommendations* by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), updated in **April 2026** (first published in 2014; M3AAWG-155; reference URL m3aawg.org/TLSBaselineRecs2026). The document is deliberately brief and covers the "low-hanging fruit": three measures, plus a fourth on logging, that messaging providers can deploy against eavesdropping. It was motivated by the disclosures about global surveillance in the 2010s and by the ongoing pervasive monitoring of email traffic. It covers only measures that providers can deploy, not encryption by end users such as PGP, GPG or S/MIME. ## 1) Opportunistic TLS between providers, TLS 1.2 and 1.3 only - **Versions: use only TLS 1.2 and TLS 1.3.** In line with IETF RFC 8996, disable SSLv3, TLS 1.0 and TLS 1.1 because of their known security issues. The document says it again elsewhere: versions "such as 0.9, 1.0, or 1.1" are **obsolete and do not adequately protect data in transit**, and M3AAWG "specifically urges" supporting TLS 1.2–1.3 and nothing else. - Mail sent between MTAs without encryption is exposed both to unauthorized monitoring and to man-in-the-middle (MiTM) attacks. **Mandatory TLS based on a publicly trusted certificate** prevents both. However, TLS is not adopted everywhere, so forcing TLS is not feasible for general traffic. The answer is opportunistic TLS, with keys created for each session, which protects traffic on a best-effort basis (and can still be attacked by a man in the middle). - Many MTAs now support **DANE and MTA-STS**, which strengthen TLS session encryption further by protecting against downgrade and MiTM attacks. Consult your MTA's documentation to set up STARTTLS with recent versions and ciphers, and to disable obsolete ones properly. - **"M3AAWG strongly encourages all operators to enable Opportunistic TLS on all mail servers."** - Limitation: SMTP works **hop by hop**, and TLS works for each TCP connection, so opportunistic TLS protects each hop separately. If some hops in the delivery path use TLS and others do not, the protection is incomplete to the same extent. It is imperfect, but it protects at least some traffic from some passive attacks. - Verification: check what your servers offer with a testing tool for TLS over SMTP. The document names the **LuxSci SMTP TLS Checker** (luxsci.com/smtp-tls-checker) and **CheckTLS** (checktls.com/TestReceiver), both free for non-commercial use. ## 2) Encrypt intracompany network traffic The old assumption that internal traffic over dedicated links is secure "is no longer warranted", given how much pervasive network monitoring has been disclosed (the document cites **MUSCULAR (DS-200B)** and **Carnivore** in its footnotes). Encrypt **all traffic within your own network infrastructure**, with TLS or other cryptographic methods, in the same way that opportunistic TLS is applied to mail between MTAs over the internet. ## 3) Encrypt user credentials and access When users authenticate to read mail or submit messages, encrypt the exchange of credentials: | Access | Ports | |---|---| | IMAP with TLS, POP with TLS | **993** (IMAP), **995** (POP) | | IMAP or POP with STARTTLS | **143** (IMAP), **110** (POP) | | Mail submission with TLS | **465** | | Mail submission with STARTTLS | **587** | | Webmail | **HTTPS** | ## 4) Log TLS version and cipher data Both senders and receivers should log the **TLS version and cipher** of each TLS session, and may log data about failed connections, which "could be useful with TLSRPT reports" (see [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt)). Detailed data helps with diagnosis in the short term, and aggregated data shows trends. ## Caveats and scope - These are "fundamental steps rather than comprehensive encryption guidance". Other M3AAWG documents cover more advanced topics. Review your policies periodically. - Before you change existing configurations, understand how the changes affect users, **especially those with older client software**. Real data about your users should inform deployment decisions. ## RFCs cited | RFC | Subject | |---|---| | RFC 5246 | TLS 1.2 | | RFC 7258 | Pervasive Monitoring Is an Attack | | RFC 7672 | SMTP security via opportunistic DANE TLS | | RFC 8446 | TLS 1.3 | | RFC 8460 | SMTP TLS Reporting | | RFC 8461 | SMTP MTA Strict Transport Security (MTA-STS) | | RFC 8996

# emailmarketing.net — full text (English) > Every published emailmarketing.net knowledge base article in English. Published by the team behind Cakemail. Index: https://emailmarketing.net/llms.txt # ARC (Authenticated Received Chain) > RFC 8617 reference — the three ARC header fields, instance and chain-validation tags, sealing and validation rules, and how receivers use an intact chain to override DMARC failures caused by forwarding. Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/arc When mail passes through a forwarder or a mailing list, it can fail [DMARC](https://emailmarketing.net/learn/authentication/dmarc) at the final receiver even though the original sender authenticated it correctly. Forwarders and mailing lists routinely break [SPF](https://emailmarketing.net/learn/authentication/spf), because the sending IP address changes, and they often break [DKIM](https://emailmarketing.net/learn/authentication/dkim), because they add subject tags or footers or rewrite the body. This is the problem of **indirect mail flow**. ARC, defined in RFC 8617 (Experimental), addresses it. Each intermediary records the authentication results it saw when the message arrived, and seals them cryptographically, which builds a chain of custody that can be verified. The final receiver can then see that the message authenticated properly **before** the forwarder modified it, and may choose to override a DMARC failure. ARC reports what intermediaries saw. It is an additional signal, **not** a replacement for SPF, DKIM and DMARC, and it does not by itself make a message trustworthy. A spammer can seal their own spam, so the sealer's reputation matters. ## The ARC Set: three header fields per hop Each intermediary that takes part (an "ARC sealer") adds one **ARC Set** of three headers, all carrying the same instance number `i=`: | Header | Abbrev. | Contents | Signs | |---|---|---|---| | `ARC-Authentication-Results` | AAR | The SPF, DKIM and DMARC (and ARC) results this hop saw when it received the message, in the same format as the [Authentication-Results header](https://emailmarketing.net/learn/authentication/authentication-results-header). | (not a signature) | | `ARC-Message-Signature` | AMS | A signature like DKIM's (with the same tag syntax: `a=`, `b=`, `bh=`, `d=`, `s=`, `h=`, …) over the message **headers and body** as this hop passed it on. With it, the hop takes responsibility for any changes it made. It uses relaxed canonicalization, and must not sign existing ARC-Seal or Authentication-Results fields. | Headers and body | | `ARC-Seal` | AS | Seals the chain itself. It signs **only header fields** (not the body): all earlier ARC Sets plus this hop's AAR and AMS, in the order AAR, AMS, AS for each instance. It carries the `cv=` chain-validation verdict. | ARC headers only | ### Key tags | Tag | On | Values and rules | |---|---|---| | `i=` | all three | The instance number that ties a set together: **1–50**, increasing by 1 at each hop. Instance numbers must form a continuous sequence 1..N, with exactly one of each field for each instance. More than 50 sets, or a broken sequence, fails the chain. | | `cv=` | ARC-Seal | The chain validation status as this sealer saw it: `none` (no earlier chain existed, so this is the first hop), `pass` (the earlier chain validated) or `fail` (the earlier chain failed validation). | | `d=`, `s=`, `a=`, `b=`, `t=` | AMS, AS | As in DKIM: the sealing domain, the selector (the key is published at `._domainkey.`), the algorithm, the signature and the timestamp. | ## Chain validation (receiver algorithm) 1. Collect all ARC Sets. The chain **fails** if there are more than 50, or if the instance sequence 1..N is broken, duplicated or incomplete. 2. If the ARC-Seal with the highest instance has `cv=fail`, the chain **fails**. 3. Validate the **most recent AMS** signature (the latest custodian's snapshot of the message). Older AMS signatures may also be checked, to find the oldest point where the message still passed. 4. Validate **every ARC-Seal**, from the highest instance down. Each seal must verify over all the sets it covers. 5. If all checks pass, the chain status is **pass**. Otherwise it is **fail**. A failed or missing chain simply means that ARC gives no usable information. Judge the message on its ordinary SPF, DKIM and DMARC results. ## Sealing rules - A sealer records the results it saw in a new AAR, signs the message with an AMS, then seals it with an AS whose `cv=` reflects the state of the chain it found. - If the sealer found a **malformed or failed chain**, it must not extend the chain as valid. It seals with `cv=fail`, and the scope of the AS `b=` **MUST cover only the ARC Set created by the MTA that detected the failure** (not the broken earlier sets). - Sealers should seal only mail they actually handled and evaluated. Sealing is a statement of custody, backed by the reputation of the sealing domain. ## How receivers and DMARC evaluators use ARC - A DMARC evaluator **may, as local policy**, accept the authentication results in a validated ARC chain. If the message fails DMARC now, but the oldest AAR shows an aligned SPF or DKIM pass at the first hop and the receiver trusts every sealer in the chain, the receiver can deliver the message despite `p=reject` or `p=quarantine`. - This is exactly the `local_policy` or `mailing_list` override you see in [DMARC aggregate reports](https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports). RFC 8617 suggests recording, in the report's comment on the policy override, the chain validation status, each seal's `d=` and `s=`, and the originating IP address from the first ARC Set. - Trust in sealers is based on reputation and differs from one receiver to another. Large providers keep lists of forwarders and list operators whose seals they honor. An ARC pass from an unknown sealer, or one with a poor reputation, typically changes nothing. ## Deliverability takeaways - **Senders** cannot deploy ARC to fix their own deliverability. Intermediaries (forwarders, mailing lists, security gateways) implement it, and receivers honor it. What senders should do is publish solid SPF, DKIM and DMARC records, so that the AAR at the first hop records an aligned pass. - **Operators of forwarding services, mailing lists or filtering gateways** should seal with ARC (and preserve the original headers), so that DMARC enforcement further along the path does not destroy their traffic. - Under its sender guidelines, Gmail requires ARC headers on traffic from bulk forwarders. Microsoft, Google and other major providers both seal and honor ARC. ## Related articles - [DMARC](https://emailmarketing.net/learn/authentication/dmarc), the policy layer ARC helps preserve across hops - [Authentication-Results header](https://emailmarketing.net/learn/authentication/authentication-results-header), the format the AAR reuses - [DKIM](https://emailmarketing.net/learn/authentication/dkim), the signature method the AMS and AS build on # BIMI (Brand Indicators for Message Identification) > Implementing BIMI — DMARC enforcement prerequisites, the BIMI DNS record, SVG Tiny PS logo requirements, VMC/CMC certificates, and mailbox-provider support. Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/bimi If you want your brand's logo to appear next to your messages in recipients' inboxes, BIMI is how you ask for it. You publish the logo in DNS, and participating mailbox providers display it next to authenticated messages. Each mailbox provider decides independently whether to display the logo, and how. BIMI is not an authentication protocol itself. It is a **reward for full authentication**: a domain qualifies only once [DMARC](https://emailmarketing.net/learn/authentication/dmarc) is at enforcement. This is why BIMI is often the business reason that pays for a [DMARC enforcement rollout](https://emailmarketing.net/learn/authentication/dmarc-deployment). ## Prerequisites: DMARC at enforcement Before a BIMI record is honored, you need: - SPF, DKIM and DMARC deployed with proper alignment on the sending domain. - A DMARC policy at **enforcement on the Organizational Domain and its subdomains**: - `p=quarantine; sp=quarantine` or stronger, or - `p=reject; sp=reject`. - **Not permitted**: `p=none`, `sp=none`, or any `pct` value below 100. Mail must actually pass DMARC. The logo is displayed only on authenticated messages, and providers also make display depend on the reputation of the sending domain. ## The BIMI DNS record A TXT record published at the `default` selector under the `_bimi` label: ``` default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem" ``` | Tag | Meaning | Notes | |---|---|---| | `v` | Version | `BIMI1`. Must be first | | `l` | HTTPS URL of the SVG Tiny PS logo file | Required for the logo to be displayed | | `a` | HTTPS URL of the evidence document (a VMC or CMC certificate, in PEM format) | Optional in the specification, but required in practice by providers that demand certificates (e.g., Gmail) | A record with `l=` but no `a=` is a **self-asserted** BIMI record. Support for self-asserted records varies among mailbox providers (see the table below). Selectors other than `default` are possible, declared through a `BIMI-Selector` header on the message, to show a different logo for each mail stream. ## SVG logo requirements (SVG Tiny PS) The logo must conform to the **SVG Portable/Secure (SVG Tiny PS)** profile, which is based on W3C SVG Tiny 1.2: | Requirement | Value | |---|---| | `version` attribute on `