Gmail Bulk Sender Requirements: Two Years In — Lessons from Enforcement

• April 2026
• Engineering Memo · External Release

Gmail announced its bulk sender requirements in October 2023 and began enforcement in February 2024, with full enforcement — hard rejection for non-compliant senders — beginning in June 2024. More than two years of enforcement have now produced sufficient data to assess which requirements matter most, which types of senders were most disrupted, and what infrastructure changes produce the fastest and most stable compliance outcomes.

This note synthesises the operational experience of managing infrastructure through the enforcement transition — not from Gmail's published documentation, but from the specific delivery patterns, SMTP error codes, and Postmaster Tools data observed across managed sending environments during the enforcement rollout and subsequent compliance normalisation period.

The Three Requirements That Produced the Most Disruption

Gmail's requirements cover authentication (SPF, DKIM, DMARC), unsubscribe compliance (one-click List-Unsubscribe), and spam rate management (below 0.10%). Of these, the enforcement disruption was not evenly distributed across the three categories. Most senders who experienced significant delivery impact in 2024 were affected by authentication gaps — specifically, DKIM signing failures or DMARC alignment failures — rather than by spam rate issues or missing unsubscribe headers.

The authentication enforcement was more disruptive than many senders anticipated because the 5.7.26 rejection code — "This message does not pass authentication checks (SPF and DKIM both do not pass)" — is a domain-level rejection that affects every message sent from the domain to Gmail addresses, not just a subset. Senders who had partial authentication (SPF passing but no DKIM, or DKIM from the ESP's domain rather than the sender's domain) found that what had been delivering normally for years suddenly began receiving 550 5.7.26 rejections systemically.

The DKIM-from-ESP-domain issue was particularly widespread. Many senders had delegated their email sending to an ESP (Mailchimp, HubSpot, Klaviyo) years earlier and had configured DKIM signing with the ESP's default configuration — which signs messages with the ESP's own domain (d=mcsv.net, d=hubspot.com) rather than the sender's domain. This had worked because DMARC was either not deployed or was at p=none on the sender's domain. When Gmail introduced the requirement for authenticated DKIM alignment in February 2024, these senders began receiving authentication rejections on all Gmail-destined traffic that had previously delivered normally.

The SMTP Error Codes That Appeared During Enforcement

The 2024 enforcement rollout introduced specific SMTP codes that were new or newly prominent in production accounting logs. Understanding these codes and the conditions that trigger them is essential for diagnosing ongoing compliance status.

421 4.7.26 — the pre-enforcement warning. This 4xx (temporary failure) code indicates that Gmail has detected an authentication issue with the sender's domain but is not yet permanently rejecting. It appeared in accounting logs beginning in the warning phase of enforcement (February–May 2024). Operators who saw this code and acted on it during the warning period avoided the hard rejection phase. Those who treated it as routine throttling (as 421 codes had historically been) found their mail permanently rejected when Gmail escalated to 550 5.7.26. The lesson: 421 4.7.26 is not a routine deferral — it is an enforcement warning with a finite grace period.

550 5.7.26 — the authentication enforcement rejection. This 5xx (permanent failure) code means Gmail is rejecting all mail from the domain due to authentication failure. It cannot be retried — the rejection applies until the authentication issue is corrected. The SMTP response message accompanying this code specifies what failed: "This message does not pass authentication checks (SPF and DKIM both do not pass). SPF check for [domain] does not pass with ip: [IP]. DKIM check failed." The response includes enough information to diagnose the specific failure, but requires reading the SMTP response text rather than just the code number.

550 5.7.515 — missing SPF or DKIM. A more specific rejection code indicating that either the SPF record or the DKIM key record is missing entirely from DNS for the sending domain. This appeared most commonly for new or recently migrated domains where authentication records had not been published before first send. The fix is DNS record publication — it is structurally simpler than a DKIM alignment issue, but requires the same 24–48 hour propagation before Gmail sees the new records.

Which Fixes Produced the Fastest Recovery

The fastest compliance recoveries — from receiving 550 5.7.26 to consistent 250 OK responses — occurred in environments where the root cause was a simple DNS configuration issue: missing DKIM selector record, incorrect SPF include, or DMARC not yet published. These fixes resolve after DNS propagation (24–48 hours) and produce immediate improvement in delivery rates once Gmail's resolvers see the corrected records.

Slower recoveries — taking 1–3 weeks rather than 1–2 days — occurred in environments where the authentication issue was structural: an ESP signing with its own domain that required CNAME delegation configuration and coordination with the ESP to activate, or a multi-source sending environment where the DMARC alignment fix required coordinating authentication configuration changes across 5–10 third-party services. The technical fix for each source was simple, but the coordination with multiple parties extended the total remediation timeline.

The slowest recoveries — 3–6 weeks — occurred in environments where the compliance issue was spam rate rather than authentication. Spam rate-driven rejections (550 5.7.350) require not just a technical fix but a list hygiene and sending practice change that must produce sustained complaint rate reduction before Gmail's reputation system registers the improvement. Technical fixes deploy in hours; list hygiene improvements demonstrate themselves over weeks of clean sending at reduced complaint rates.

State of Compliance in 2025–2026

Two years after enforcement began, the landscape has normalised. Most established sending organisations have completed the authentication and unsubscribe compliance work required. The enforcement codes still appear in accounting logs regularly, but now predominantly from: new senders who haven't yet configured authentication properly, recent infrastructure migrations where authentication records weren't updated before first send, and third-party service integrations added after the initial compliance work was done.

The ongoing monitoring requirement: DMARC aggregate reports reviewed weekly for any newly appearing sources with authentication failures, Postmaster Tools authentication section reviewed for pass rate trends, and accounting log checked for any 5.7.26 or 5.7.515 codes that indicate a newly failing sending source. The compliance work is never entirely done — each new service integration is a potential new authentication gap, and the monitoring cadence is what catches these gaps before they accumulate to volumes that affect reputation.

Yahoo's parallel requirements, announced at the same time as Gmail's, have had somewhat less visible enforcement impact — partly because Yahoo's FBL and SNDS tooling is less detailed than Gmail's Postmaster Tools, making enforcement codes less visible to senders, and partly because Yahoo has historically had more tolerance for authentication variation at the margin. That said, Yahoo's spam rate threshold (0.10%) is equally enforced and FBL data confirms that complaint-rate-driven rejections at Yahoo remain a significant source of deliverability problems for senders who have improved their Gmail compliance but not applied equivalent list hygiene improvements to their Yahoo-destined traffic.

The Infrastructure Configuration That Ensures Ongoing Compliance

Ongoing Gmail bulk sender compliance in 2025–2026 requires four specific configuration elements maintained continuously: DKIM signing with a 2048-bit RSA key published under the sending domain's DNS (not the ESP's domain), DMARC record at p=none or higher with RUA reporting to a monitored address, List-Unsubscribe and List-Unsubscribe-Post headers present in all bulk campaigns with functional endpoints, and a sustained spam rate below 0.08% as measured by Gmail Postmaster Tools.

For PowerMTA environments specifically: the dkim-signature configuration must use a key-file from a key pair where the public key is published under the sender's own domain's DNS; the header-list must include From: (ensuring the signed From: domain matches the d= tag for DMARC alignment); and List-Unsubscribe-Post header injection must be configured in MailWizz's campaign settings or added by the sending application for all bulk traffic injection paths.

The compliance verification before any new infrastructure deployment or ESP migration: send a test message from the new infrastructure to a Gmail address, retrieve the raw message, check Authentication-Results for dkim=pass with d=[your-domain] and spf=pass, verify the DMARC record evaluation shows pass, and confirm List-Unsubscribe and List-Unsubscribe-Post are present in the headers. This five-minute pre-send verification prevents the authentication failures that would otherwise appear as 550 5.7.26 codes during the first live campaign — precisely when catching them early before any volume has been affected is most valuable.

The Warning-Phase Lesson: Why Accounting Log Monitoring Is Non-Negotiable

The most consistent differentiator between senders who navigated the 2024 enforcement transition smoothly and those who experienced significant disruption was accounting log monitoring. Senders with daily accounting log review detected the 421 4.7.26 warning codes within 24–48 hours of their first appearance. Those without daily log review detected them only when the 550 5.7.26 permanent rejection began affecting delivery rates visibly in campaign performance metrics — by which point the grace period had expired and mail was already being hard-rejected.

The operational cost of discovering 421 4.7.26 during the warning phase versus 550 5.7.26 during the rejection phase is dramatically different. In the warning phase, the fix is the same (configure aligned DKIM, update DMARC record), but the impact is zero — mail is still delivering, just with warning codes that the operator can see and act on. In the rejection phase, the impact is 100% Gmail delivery failure until the fix is implemented and DNS propagates. For a programme where Gmail addresses represent 40% of the list, this means 40% of campaign sends are failing — a significant revenue and sender reputation impact that the warning phase would have prevented entirely.

The 421 4.7.26 lesson is broader than Gmail enforcement: it applies to any ISP that uses 4xx warning codes before escalating to 5xx rejection for policy violations. Yahoo's TS codes, Microsoft's pre-block throttling, and various ISP-specific warning mechanisms all follow the same pattern — a temporary failure that signals an emerging policy issue before it becomes permanent rejection. Operators who monitor accounting log 4xx codes at this granularity, distinguish enforcement warning codes from routine rate-limit deferrals, and respond to enforcement codes as P1 incidents rather than routine deferrals consistently avoid the disruptions that create the perception that "deliverability suddenly got worse" — when in fact the warning signals had been present for weeks before the disruption became visible.

What Changed for Senders Who Were Already Compliant

For senders who had correctly configured DKIM alignment, DMARC, and List-Unsubscribe before the 2024 requirements took effect, the enforcement transition was largely invisible. Their accounting logs continued showing 250 OK responses from Gmail at the same rate as before. Postmaster Tools showed no changes in authentication pass rates. The only observable difference: some messages that had previously been delivered to spam or promotions from Gmail addresses — messages from other senders using similar infrastructure that generated some co-mingled reputation signals in shared ESP environments — were now blocked before reaching any folder, slightly improving the signal quality in shared pool environments as non-compliant co-tenants' traffic was filtered before affecting pool reputation.

This observation reinforces the point about dedicated infrastructure: senders on dedicated IPs with correctly configured authentication experienced the enforcement transition as zero disruption. Senders on shared ESP infrastructure saw variable impact depending on the compliance state of their co-tenants, with some seeing delivery improvements as lower-quality co-tenant traffic was blocked and others seeing delivery degradation if their own compliance had gaps that the enforcement revealed.

The longer-term effect for compliant senders: the enforcement raised the baseline quality of bulk email reaching Gmail's infrastructure by blocking or penalising the most poorly-authenticated senders. This reduction in unauthenticated bulk email reaching Gmail's receiving infrastructure — and the corresponding reduction in complaint signals from low-quality senders — benefits the reputation baseline for all well-configured senders who remain. ISP reputation models compare each sender against the distribution of senders — as the lower end of that distribution is removed by enforcement, the relative reputation of well-configured senders improves marginally. This marginal improvement compounds over the 18 months since enforcement began into a measurable inbox placement benefit for senders who were already compliant and maintained their compliance discipline through the enforcement period and after.

Preparation for Future Gmail Requirement Updates

The 2024 requirements were not Gmail's last update to bulk sender expectations. Google has indicated publicly that additional requirements — around sender domain age, sender history, and message engagement thresholds — may be added in future updates. The organisations best positioned for any future requirement updates are those who have built the monitoring and maintenance infrastructure that detects compliance gaps early: daily Postmaster Tools review, weekly DMARC aggregate report analysis, real-time accounting log monitoring for new SMTP error codes, and quarterly authentication audits.

The specific preparation steps that make future requirement updates operationally manageable: maintain DMARC at p=reject (the highest enforcement level, which makes future authentication-related requirements irrelevant since the foundation is already as strong as possible); maintain List-Unsubscribe-Post at all times (not just during enforcement periods); keep spam rates below 0.05% (well below the 0.10% threshold, providing buffer for any threshold changes); and monitor Gmail's Sender Hub and postmaster.google.com announcements for early visibility into upcoming requirement changes before they enter enforcement.

The two-year lesson from the 2024 enforcement cycle is that preparation time is the most valuable resource for navigating requirement updates without disruption. Senders who were already DKIM-aligned before the 2024 announcement had months of warning to confirm their compliance. Senders who discovered they were non-compliant only when enforcement began had zero warning time. Building the monitoring infrastructure that provides early visibility into compliance gaps — and the operational discipline that maintains compliance continuously rather than reactively — is the investment that converts future requirement updates from potential crises into routine observations that require confirmation rather than emergency remediation.

Practical Verification Checklist for Current Gmail Compliance

For operators who want to verify their current Gmail bulk sender compliance status without relying on whether they have received enforcement error codes, the following verification checks confirm compliance status directly from the available data sources.

DKIM alignment verification: send a test message from your primary sending domain to a Gmail address you control. Retrieve the message and view the original message source. Find the Authentication-Results header in the received message. Confirm: (1) dkim=pass is shown; (2) the d= value in the DKIM-Signature header is your domain (e.g., d=yourdomain.com), not the ESP's domain; (3) the header-b field shows a valid signature. If dkim=fail or if d= shows an ESP domain rather than your domain, DKIM alignment is not configured correctly.

DMARC verification: query your DMARC record with dig TXT _dmarc.yourdomain.com. Confirm: (1) a record exists; (2) it contains v=DMARC1; (3) the p= value is set (p=none, p=quarantine, or p=reject). If no record is returned, DMARC is missing. Check the Authentication-Results header in the test message for "dmarc=pass" — if it shows dmarc=fail, there is an alignment problem between the DKIM or SPF and the From: domain that must be resolved.

List-Unsubscribe verification: check the headers of a recent campaign send (retrieved from a test recipient inbox). Confirm: (1) List-Unsubscribe header is present with both a mailto: and an https: URI; (2) List-Unsubscribe-Post header is present with value "List-Unsubscribe=One-Click"; (3) the https: endpoint responds to a test POST request with an HTTP 200 response. If any of these are missing or incorrect, the List-Unsubscribe compliance requirement is not met.

Spam rate verification: check Gmail Postmaster Tools spam rate for the past 30 days. The rate should be consistently below 0.08%. If any recent campaign produced a spike above 0.10%, identify the cause (specific list segment, new acquisition source, or content change) before the next send. A single above-threshold day is not necessarily an enforcement trigger, but sustained rates above 0.10% will trigger 550 5.7.350 rejections.

SPF verification: send the test message and check Authentication-Results for spf=pass. If spf=fail or spf=softfail, the sending IP is not covered by the SPF record for the From: domain. Also verify the SPF lookup count using an external SPF validator — if it exceeds 10, strict ISPs will report SPF failure even if the record syntactically covers the sending IPs, because the lookup limit is exceeded before reaching the relevant include.

Completing all five verifications before any significant campaign send — and re-verifying after any infrastructure change, new service integration, or DNS configuration update — is the preventive practice that ensures ongoing compliance without relying on reactive error code detection. The verification takes 20–30 minutes for a new environment and less than 10 minutes for a stable environment confirming previous configuration is still intact. This investment, made consistently before each campaign cycle, prevents the enforcement disruptions that cost hours to days of emergency remediation effort when discovered reactively during campaign sending.

The Gmail bulk sender requirements, now two years into enforcement, have successfully raised the baseline quality of authenticated bulk email at one of the largest email providers in the world. Senders who meet the requirements consistently deliver to Gmail recipients with the authentication, consent-mechanism compliance, and spam rate quality that Gmail considers acceptable for inbox delivery. Senders who maintain these standards proactively — rather than reactively responding to enforcement codes — operate with a stable compliance foundation that insulates them from the disruptions that future requirement updates will create for less-prepared senders. The requirements are not obstacles; they are the documented standards that define responsible bulk email sending in 2025 and 2026, and meeting them is both a technical requirement and a deliverability advantage relative to senders who continue to operate below the standards that the enforcement mechanism now enforces.

Two years of enforcement data confirm a consistent pattern: the senders who comply correctly outperform those who do not, not just in the narrow sense of avoiding Gmail delivery failures, but in the broader sense of domain reputation trajectory, inbox placement rate stability, and resilience to the ISP policy changes that are a permanent feature of the email deliverability landscape. Compliance is not the ceiling of deliverability performance — it is the floor from which further improvement is possible through the engagement, reputation, and infrastructure quality practices documented throughout this note series.