The First Quarter of Permanent Rejections: Field Data from Q1 2026 Under Gmail Enforcement

April 2026 — Operational note. Q1 2026 was the first full calendar quarter under Gmail's permanent rejection regime. This note synthesises field data from managed PowerMTA infrastructure across the Cloud Server for Email fleet between January and March 2026, alongside publicly reported industry data, to document the SMTP rejection patterns that actually emerged, the remediation timelines that proved realistic, and the operational lessons that distinguish compliant senders from those who experienced quarter-level placement degradation.

The headline observation: enforcement has been less dramatic than the November 2025 announcements suggested for already-compliant senders, and more dramatic than expected for senders who had relied on Gmail's pre-November filtering as a soft consequence. The bifurcation defines Q1 2026. Compliant programmes experienced essentially zero change in delivery patterns. Marginally compliant programmes — those that had been passing Compliance Status but with edge-case alignment issues, intermittent DKIM signing, or inconsistent unsubscribe header injection — produced the bulk of the 5.7.x rejection volume.

Rejection Code Distribution Across Q1 2026

The accounting log data across managed PowerMTA infrastructure provided the cleanest view of which rejection codes actually mattered operationally during Q1 2026. Most published guidance treats the 5.7.x family as a flat list of possible codes; the field distribution is more skewed. Two codes account for two-thirds of all rejection volume; three more cover most of the remainder; the rest are operationally rare.

The distribution shape changed only marginally between January and March 2026. The 5.7.26 share started Q1 at approximately 38% and rose to 44% by the end of March, reflecting that authentication alignment problems are persistent rather than transient — once a configuration is wrong, it stays wrong until someone fixes it. By contrast, 5.7.28 (spam rate) showed more weekly variance: senders who crossed the 0.3% threshold drove brief spikes, then either recovered (after 7 consecutive days under threshold) or sustained the elevated state across multiple weeks.

Code-by-Code Operational Breakdown

Each 5.7.x code has a distinct remediation profile. The table below captures what each code actually meant in Q1 2026 operational contexts, distinguishing between the textbook description (often imprecise) and the operational reality.

Industry Context: The Pre-Enforcement Inbox Placement Collapse

The November 2025 enforcement escalation sits at the end of a longer trajectory worth contextualising. Industry-wide data tracking inbox placement rates across major ESPs documented the cumulative effect of the 2024-2025 enforcement period before Gmail's permanent rejection regime took effect. Senders mailing 1,000+ messages per month saw inbox placement collapse from approximately 49.98% in Q1 2024 to 27.63% in Q1 2025 — a 22.35 percentage point drop over the year that bracketed the original February 2024 sender requirements and the May 2025 Microsoft enforcement.

The platform-specific pattern reveals the underlying mechanism. Shared-IP ESPs (Mailgun, MailChimp, Amazon SES) experienced the largest declines because their architecture pools sender reputation across many customers — the worst-behaved sender on a shared IP drags placement for every other sender on the same IP. Dedicated infrastructure (managed PowerMTA, properly configured custom MTAs) had near-zero placement degradation across the same window because each sender's reputation is tied to their own IPs and domains rather than to a shared pool.

The Q1 2026 data continues this pattern. Compliant senders on dedicated infrastructure maintained essentially the same placement they had pre-November 2025. The senders who experienced material degradation are concentrated on shared ESPs where co-tenant compliance failures produced 5.7.x rejections that affected the shared infrastructure broadly.

The Q1 2026 Enforcement Timeline

Looking back across Q1 2026 month by month reveals the cadence at which Gmail's enforcement actually unfolded. Google's announcement framed the November 2025 transition as a single event; the operational experience was a three-stage ramp where rejection volume grew progressively through Q1 as Gmail's filtering systems applied stricter thresholds in each successive evaluation window.

Remediation Patterns: What Actually Worked

The remediation patterns that proved effective during Q1 2026 are not always the obvious ones. Three observations from the field stand out.

Observation 1: DMARC alignment audit is the highest-leverage pre-enforcement check

The 5.7.26 rejection class — 42% of total rejection volume — almost always traces to DMARC alignment problems that are invisible without aggregate report analysis. The pattern is consistent enough that "5.7.26 spike" is now operational shorthand for "audit your DMARC alignment now."

Senders operating with p=none policies typically did not realise their From: domain wasn't aligning until November's enforcement made it visible as rejections. The pre-enforcement remediation that consistently prevented 5.7.26: pull DMARC aggregate reports (free via Postmark, dmarcian, EasyDMARC, or Google's aggregate report parser), filter for any report with alignment failures, fix the underlying configuration before enforcement made it expensive to discover.

What produces alignment failures most often? Third-party marketing platforms, transactional services, or CRM systems sending mail through their own domain while displaying the customer's brand in the visible From: header. SPF passes — the third-party domain's record authorises the sending IP. DKIM passes — the third-party signs with their own key. But DMARC fails because neither aligns with the visible From: domain.

Remediation requires configuring each third-party service to authenticate as the customer's domain. Two paths: delegate subdomain DNS to them, or publish CNAME records that allow them to sign with the customer's DKIM key. Both work; the CNAME approach is operationally simpler because it doesn't require giving the third party authority over an entire subdomain.

Observation 2: PTR remediation is the slowest, so prioritise it first

The 5.7.25 rejection class — 9% of volume — had the longest median remediation time at 18 hours. The reason is structural. PTR records are controlled by the network provider that owns the IP block, not by the sender. Changing PTR requires opening a ticket, waiting for processing, and waiting for DNS propagation.

Network provider turnaround varies dramatically. Some respond within hours. Others within 1-2 business days. A small fraction require 3-5 business days for what should be a 5-minute change.

For dedicated infrastructure on CSE OÜ's managed PowerMTA, PTR records are configured during initial provisioning and verified against the HELO/EHLO hostname before any sending traffic flows. The check happens once, at the right time.

For senders on shared or budget hosting where PTR is misconfigured at deployment, the remediation work needs to start before the rest of the compliance stack — a perfect SPF, DKIM, and DMARC configuration still produces 5.7.25 rejections if PTR doesn't resolve correctly.

Observation 3: Spam rate enforcement is behavioural, not technical

The 5.7.28 rejection class — 7% of volume — differs from the others because the remediation is not a configuration change. Spam rate enforcement triggers when the sender's reported complaint rate exceeds 0.3%, and recovery requires seven consecutive days below the threshold. This is the most operationally painful class to handle because:

• The seven-day requirement creates a minimum recovery window that cannot be accelerated.
• Maintaining sub-0.3% during the recovery window often requires reducing volume to known-engaged segments, which means the affected programme operates at degraded throughput for the full week.
• The complaint rate is calculated daily by Gmail, so a single day above 0.3% during the recovery window resets the clock.
• The behavioural changes that drive recovery (list cleaning, segmentation, frequency reduction) often take 2-3 weeks to produce sustained complaint rate improvement.

For senders that had been operating at 0.10-0.25% complaint rates before November 2025 (the soft enforcement era), the 0.3% threshold felt distant. Q1 2026 demonstrated how thin that buffer actually was: a single problematic campaign, a stale segment, or an aggressive re-engagement attempt can push complaint rate from 0.20% to 0.35% in days. Once 5.7.28 starts appearing, the week-long recovery window is essentially mandatory regardless of how quickly the underlying behavioural cause is addressed.

Microsoft and Yahoo: The Convergence Pattern

Q1 2026 was also the first quarter in which the three major providers' enforcement patterns operated in genuine alignment. Microsoft began permanent rejections for non-compliant Outlook.com, Live, and Hotmail traffic in May 2025 with 550 5.7.15 codes. Yahoo aligned its enforcement with Gmail's earlier in 2025. The April 2026 vantage point is the first time the three providers' enforcement regimes have all been in place across an entire fiscal quarter.

The practical consequence: compliance fixes made for Gmail typically resolve rejections at Microsoft and Yahoo simultaneously, because the underlying technical baseline is shared. DMARC alignment that satisfies Gmail also satisfies Microsoft. PTR records that pass Gmail's check also pass Microsoft's. One-click unsubscribe headers that comply with Gmail's RFC 8058 requirement also satisfy Yahoo's similar requirement. The convergence simplifies operational work but raises the floor: a sender cannot specialise their compliance to one provider's policies because the policies are mostly the same.

Lessons for Q2 2026 Planning

Three operational priorities emerge from the Q1 2026 data that should shape Q2 2026 monitoring and remediation work.

Priority 1: Audit DMARC aggregate reports weekly, not monthly. The single highest-leverage operational practice that emerged from Q1 is regular alignment auditing. The 5.7.26 rejection volume was largely preventable; the senders who experienced it disproportionately were those who hadn't been pulling DMARC aggregate reports regularly. A weekly review using a free DMARC aggregator (Postmark DMARC Monitoring, dmarcian's free tier, or EasyDMARC's reporting) catches alignment drift within 7-14 days, well before it accumulates into the rejection volume that produces material delivery impact.

Priority 2: Monitor Compliance Status with daily logging. The Compliance Status panel in Postmaster Tools v2 (covered in detail in the March 2026 operational note on the Postmaster Tools v2 retirement) is a binary check that flips state when configuration drifts. Daily logging with alerts on any Pass-to-Fail transition catches configuration regressions within 24 hours rather than after rejections start accumulating. The cost is trivial; the benefit is the difference between catching a problem during a deploy and catching it after it has produced 24-72 hours of rejection volume.

Priority 3: Build MTA-side observability that doesn't depend on Postmaster Tools. The January 24, 2026 incident demonstrated that Postmaster Tools is downstream of Gmail's internal systems and shares their failure modes. The PowerMTA accounting log, ProtonMail's logs, Postfix's mail.log, and equivalents at other MTAs are independent observability layers that continue functioning when Postmaster Tools doesn't. Build dashboards and alerts on the MTA-side data as primary, with Postmaster Tools as secondary correlation. This is the operational discipline that distinguished CSE OÜ's managed infrastructure clients during the January incident from senders who relied solely on Postmaster Tools as their primary monitoring layer.

What to Expect Through Q2 2026

Google has not announced specific Q2 2026 changes to the enforcement regime. The pattern across the prior 18 months suggests continued tightening rather than relaxation. Specifically, three changes are plausible based on the trajectory: enforcement of the documented 0.1% recommended ceiling as a soft threshold (currently the threshold is documented as advisory; making it semi-enforced would shift more programmes into the warning zone), tighter alignment checking on subdomains versus parent domains (currently the alignment check is permissive about subdomain inheritance), and possibly the introduction of an engagement signal in the Compliance Status panel that has been hinted at but not yet implemented.

The conservative planning assumption: Q2 2026 will look like Q1 2026 with slightly tighter enforcement of the same rules. Programmes that came through Q1 stable will likely come through Q2 stable. Programmes that experienced Q1 rejection volume should treat Q2 as the window in which to complete remediation before any additional Q3 tightening surfaces.

Related operational notes covering the Q1 2026 enforcement context: Six Months Without Domain Reputation (March 2026), Gmail Bulk Sender Requirements: Enforcement Lessons, Why Inbox Placement Is a Lagging Indicator, Retry Pressure: The Silent Killer of SMTP Reputation at Scale, and the full operational notes series. For PowerMTA accounting log analysis specifically, see the PowerMTA technical FAQ.