Newsletter deliverability for B2B professional services (2024–2025 sender rules)

What is email deliverability under the 2024–2025 sender rules?

Short answer: Deliverability is the percentage of sent messages that reach the inbox after authentication, alignment, complaint, and unsubscribe checks pass. Under the current regime, authentication failure — not IP reputation — is the primary rejection cause.

The distinction between “delivery” and “deliverability” matters. An SMTP server accepting a message is not the same as that message reaching the inbox. Before February 2024, most rejections were IP-reputation based. Under the current regime, they are authentication-based.

The enforcement progression: Google/Yahoo announced requirements in October 2023; enforcement began February 1, 2024; Gmail started rejecting a percentage of non-compliant traffic in April 2024; the one-click unsubscribe deadline was June 2024; Microsoft Outlook.com enforcement began May 5, 2025, with SMTP reject code 550 5.7.515. The 550 5.7.515 error — “Access denied, sending domain does not meet the required authentication level” — is the signal that Microsoft is now actively blocking, not just junk-routing.

What does the 5,000-messages-per-day threshold actually mean?

Short answer: The threshold is per primary domain — not per subdomain — and tripping it even once permanently classifies the sender as bulk. An HR-payroll firm sending a benefits newsletter to a client with 6,000 employees hits both Google and Microsoft thresholds in a single send.

The Google Workspace Admin Help FAQ states it directly: “A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period. Messages sent from the same primary domain count toward the 5,000 limit.” And: “Senders who meet the above criteria at least once are permanently considered bulk senders.”

Two words: “primary domain” and “permanently.” A firm sending 2,000 messages from mail.firm.com and 3,100 from app.firm.com has crossed 5,000 on the primary domain firm.com. Splitting traffic across subdomains does not work. Yahoo's Marcel Becker was explicit: “The number is not 5,000, or 6,000, or 4,000. If you send 4,999 messages, you still have to follow the requirements.” Once tripped — even once — the sender is permanently classified as bulk.

Microsoft mirrors Google: the Outlook policies page requires DMARC “at least p=none” with SPF or DKIM alignment, and recommends p=reject. An HR-payroll firm sending a benefits newsletter to a client with 6,000 employees hits both thresholds in a single send.

What authentication does a B2B services firm need in place?

Short answer: SPF, DKIM, and DMARC — all three published, all three aligned with the visible From domain. Anything less and Gmail spam-folders by default.

SPF (Sender Policy Framework, RFC 7208), DKIM (DomainKeys Identified Mail, RFC 6376), and DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) are all required. SPF is a DNS TXT record listing the IPs and services authorized to send on behalf of your domain:

DKIM is a cryptographic signature added to outgoing messages. The d= domain in the DKIM header must align with the domain in the visible From: address. A firm using a third-party ESP should verify that the ESP is signing with the firm's own domain, not the ESP's shared domain.

DMARC is the policy record that ties SPF and DKIM together:

DMARC pass requires that SPF or DKIM (or both) pass AND that the authenticated domain aligns with the visible From domain. ARC (Authenticated Received Chain, RFC 8617) handles authentication for forwarded mail — relevant for firms whose newsletters pass through compliance archiving systems that break the original DKIM signature.

How does DMARC progress from p=none to p=reject?

Short answer: Start at p=none with a reporting address for two to four weeks. Move to p=quarantine; pct=25, ramp weekly to 100, then advance to p=reject. Minimum six to twelve weeks; large enterprises take nine to eighteen months.

The rua= address receives aggregate XML reports from receiving mail servers showing which messages passed and failed. Read these before advancing to p=quarantine. Moving to quarantine without reading aggregate reports risks quarantining legitimate mail from services the firm forgot it authorized.

The pct= tag controls what percentage of failing messages are subject to the policy. Ramp to 50, 75, 100 over subsequent weeks. Once pct=100 is stable at quarantine, move to p=reject.

BIMI (Brand Indicators for Message Identification) — the feature that displays a brand logo in Gmail's sender field — requires p=quarantine or stricter plus a Verified Mark Certificate (VMC), which costs approximately $1,500 per year. For most B2B professional services firms with client lists under 20,000, the BIMI reputational lift is marginal relative to the VMC cost.

What are the spam-rate thresholds — and what happens when you cross them?

Short answer: Google's target is below 0.10% spam complaints. Hitting 0.30% makes the sender “ineligible for mitigation” — recovery requires seven consecutive days under threshold. One spam complaint per 1,000 sends is the working ceiling.

The Google Workspace Admin Help is specific: “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.” Google Postmaster Tools — the free dashboard for registered senders — surfaces domain reputation, IP reputation, spam rate, and authentication status. Any firm sending over 500 messages per day to Gmail should register and monitor it.

Validity's Sender Score — a 0–100 reputation index — marks ≥80 as healthy. The primary input is spam complaint rate, but bounce rate, sending consistency, and list hygiene also factor in.

The math on small lists: a 2,000-person list that generates 3 spam complaints is at 0.15% — above target. A 500-person list hits 0.10% with a single complaint. Small lists are more sensitive to individual complaint events, not immune to them.

How does RFC 8058 one-click unsubscribe work, and what gets it wrong?

Short answer: Two headers are required — List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The endpoint must accept POST, return 2xx, and remove the recipient with no confirmation page. GET-triggered processing and confirmation walls are the most common failure modes.

RFC 8058 (IETF, 2017) defines one-click unsubscribe. Two headers are required: List-Unsubscribe with an HTTPS URL in angle brackets (RFC 2369), and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The endpoint must accept POST, return 2xx, and remove the recipient — no confirmation page, no GET-triggered processing.

What gets it wrong: using GET instead of POST (prefetchers trigger GET; POST is the correct mechanism); placing a confirmation page between the POST and removal; using a URL that expires before CAN-SPAM's required 30-day minimum lifetime; or including only List-Unsubscribe without the List-Unsubscribe-Post companion. Gmail's enforcement table flags “Unsubscribe requests aren't honored within 48 hours” as a violation that removes delivery support.

The body-level unsubscribe link is separate from the header mechanism. Both are required.

How quickly do you have to honor an unsubscribe?

Short answer: Gmail and Yahoo require 48 hours. CAN-SPAM gives 10 business days. FINRA/SEC requires three to six years of archival. Honor the shortest live obligation — 48 hours — and archive separately.

Honor the shortest live obligation: 48 hours for any list that includes Gmail or Yahoo addresses. The FTC CAN-SPAM Compliance Guide states: “You must honor a recipient's opt-out request within 10 business days.” Gmail and Yahoo's 48-hour requirement is more restrictive. The 48-hour clock wins.

The FINRA and SEC archival obligation governs retention of the send record — message content, recipient, timestamp — not active subscriber status. Removing a subscriber from the send list does not delete the archived send records. Two separate systems: the suppression list (active, updated within 48 hours) and the compliance archive (retained three to six years, held in Bloomberg Vault, Smarsh, or equivalent). This “three-clock conflict” — Gmail/Yahoo 48 hours, CAN-SPAM 10 business days, FINRA 3–6-year archive — applies to the same subscriber action. Honor the shortest; archive separately.

Why did Apple Mail Privacy Protection break list-hygiene rules based on opens?

Short answer: Apple MPP pre-fetches email images — including tracking pixels — before the user reads the message. Approximately 46% of email opens are now Apple pre-fetch events. A suppression rule based on “no opens in 90 days” now removes active Apple Mail readers while retaining genuine ghosts on non-Apple clients.

Apple Mail Privacy Protection (MPP), introduced with iOS 15 in September 2021, pre-fetches email images — including tracking pixels — before the user reads the message. According to Pushwoosh, approximately 46% of email opens are now Apple pre-fetch events, not human reads.

A suppression rule that removes subscribers with “no opens in 90 days” now suppresses active Apple Mail readers (pre-fetches register as opens) while keeping genuine ghosts on non-Apple clients (non-opens are recorded accurately). The suppression list inverts.

Inbox placement and MPP correction are the denominator of open-rate measurement; deliverability rules determine which sends are even counted — see /newsletter-performance for MPP-corrected benchmarks.

The replacement hygiene signals: click activity in the last 90 days, direct reply events, and soft-bounce trend. Litmus's 2025 State of Email recommends click-or-reply-confirmed engagement over opens for all suppression decisions.

What does a deliverability-ready newsletter actually contain?

Short answer: SPF, DKIM, DMARC aligned; both List-Unsubscribe headers; a visible body unsubscribe link; a valid postal address; real text (not text-in-images); TLS on SMTP; and valid forward and reverse DNS PTR records on the sending IP.

A deliverability-ready newsletter requires: SPF, DKIM, and DMARC published and aligned; both List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers present; a visible unsubscribe link in the message body; a valid physical postal address (FTC CAN-SPAM); real text rather than text-in-images; TLS on the SMTP connection; and valid forward and reverse DNS PTR records on the sending IP.

Google's sender guidelines state: “Use a TLS connection for transmitting email.” The FAQ enforcement table lists “Domain doesn't have valid forward and reverse DNS records” as a condition producing “Temporary or permanent failure codes, or spam foldering.” A shared ESP handles TLS and PTR for most firms; a firm running its own SMTP infrastructure is responsible for both.

The message content also matters. Google references RFC 5322 (Internet Message Format) as the standard for message structure. A properly formatted message has a valid Message-ID, a Date header, and a From address whose display name matches the sending domain. Text-in-images — using an image to display newsletter text — is an original spam signal and continues to trigger filtering.

How do industry consent rules stack on top of CAN-SPAM?

Short answer: CAN-SPAM is the federal floor. SEC Rule 17a-4, FINRA Rule 4511, ABA Rule 7.3, state DOI rules, HIPAA, and CCPA/CPRA build upward from it. The strictest rule wins — firms do not average competing obligations.

CAN-SPAM is the federal floor: identification of the message as an advertisement, a valid physical postal address, a working opt-out mechanism, a 10-business-day honor window, and the opt-out mechanism must remain live for 30 days after the send. Industry rules build upward from that floor.

SEC Rule 17a-4 and FINRA Rule 4511 require three-to-six-year archival of customer communications. ABA Rule 7.3 governs lawyer solicitation. State DOI rules govern insurance agency communications. HIPAA cross-cuts health-adjacent messaging for HR-payroll firms. CCPA, CPRA, Colorado Privacy Act, and Virginia CDPA add opt-out and data-deletion rights that intersect with subscriber-list management.

The strictest rule wins. A California financial advisory firm is simultaneously subject to CAN-SPAM, SEC Marketing Rule 206(4)-1, and CCPA/CPRA. The firm honors whichever imposes the shortest deadline and most restrictive consent requirement — it does not average them.

The consent rules that govern list-building and acquisition are addressed in full at /newsletter-strategy.

What is the recovery path after a deliverability incident?

Short answer: Pause the affected list. Fix the underlying cause. Warm IP and domain back over 14–30 days. Run seven consecutive days under 0.30% spam rate. Most incidents are alignment regressions, not content-quality drops.

Common incident types: (1) An ESP migration where the new platform signs DKIM with the ESP's domain — DMARC alignment breaks immediately; (2) A subdomain change that invalidates the SPF record — the new sending IP is not in the include: chain; (3) A list-purchase event that introduces unengaged addresses and drives complaint rates above threshold.

There is no shortcut for reputation recovery. Volume must be reduced; re-engagement must be demonstrated through clicks and replies. Sending a re-engagement campaign to an already-complained-against list at full volume makes the incident worse. Microsoft's 550 5.7.515 code confirms SMTP-layer rejection; the fix is authentication, not content.

What do SMTP reject codes mean, and which ones indicate authentication failure?

Short answer: 421 codes are temporary rejections (retry); 550 codes are permanent. Authentication failure codes are 550-5.7.26 (Gmail DMARC fail), 421-4.7.32 (Gmail transient), and 550 5.7.515 (Microsoft authentication level insufficient). These are authentication failures, not content failures.

SMTP status codes follow the structure: first digit (2=success, 4=transient failure, 5=permanent failure), second digit (category), third digit (specific condition). The codes below represent the authentication-failure signals relevant to the 2024–2025 enforcement regime:

A 421 code means the receiving server is temporarily refusing the message but the sender can retry. A 550 is permanent — retrying the same message to the same server will produce the same result until the authentication configuration is corrected. Most aggregator content on deliverability predates the Microsoft enforcement; the 550 5.7.515 code is the newest addition to the enforcement landscape.