2026 Email Deliverability Review: 9 Changes to Fix Before 2027

Nine changes reached email senders in 2026, and most of them need an edit before 2027. Google retired Postmaster Tools v1 and its reputation scores. DMARC was republished as RFC 9989, which adds three tags and drops pct. DKIM2 is heading for 2027. Gmail now judges a domain and its subdomains together, and Comcast has started moving its mailboxes onto Yahoo's filters.

Matthew Vernhout of Email Industries walked through all nine at the Unspam.email webinar 2026 Deliverability Review and 2027 Outlook on October 8, 2026, with Michaela Barriga of Email Industries moderating. This recap covers each change, the slides from the session, the exact DMARC record edits and the ten questions the audience asked. For a dated list of every 2026 change, including the ones the session skipped, see our email deliverability news roundup.

Press play to load this video from YouTube (Google). See our cookie policy.

The nine changes at a glance

Every change below has its own section, with the slide shown during the session where one exists.

ChangeWhat happened in 2026What to do before 2027
Postmaster Tools v1 retiredReputation scores, exports and the v1 API are goneMove dashboards and scripts to the v2 API
Validity HeatwaveA blocklist for synthetic domain warmingAsk your warming vendor how its tool engages
DMARCbis tags addedRFC 9989 adds np, psd and tAdd np=reject and psd=n
DMARCbis tags removedpct, ri, rf and the size limit are goneDelete them from your record
DKIM2A draft standard that FastMail already signs withAsk your platform for its DKIM2 roadmap
Gmail political sendersA verified sender program through Campaign VerifyUS political committees only
Gmail AI InboxGemini sorts, prioritizes and summarizes mailSend real text and alt text, not just images
Subdomains and root domainGmail evaluates them togetherOne suppression list for every team
Comcast to YahooComcast mailboxes move to Yahoo's filteringTreat comcast.net like Yahoo and watch bounces

Google Postmaster Tools v1 is gone, and the reputation scores went with it

Google Postmaster Tools v1 no longer works: its dashboards, its High, Medium, Low and Bad reputation ratings, its exports and its API are all switched off. Spam Resource reported that the interface was being removed account by account from August 20, 2026, and Matthew placed the last of the switch-off around October. Postmaster Tools v2 has no reputation score to replace them.

Matthew's view, from conversations with people at Google, is that the scores had not been accurate for a long time. Postmaster Tools v1 was about 15 years old and had been left unmaintained well before it was retired. That is why v1 and v2 showed different spam complaint numbers for the same domain: v2 had the complete data feeds, so v2 was already the source of truth.

Webinar slide comparing Google Postmaster Tools v1 and v2. Sunsetting v1: legacy reputation dashboards and the High, Medium, Low and Bad IP rating buckets are permanently retired, historical data pipelines have sunset, and manual CSV and UI exports are superseded by API queries. Operating in v2: compliance tracking with RFC 8058 one-click unsubscribe pass rates, real-time SPF and DKIM alignment diagnostics, and behavioral signals as the main drivers of spam-folder placement.

Three things change for senders:

  • Anything that read v1 data has to be rebuilt. Accounts moved to v2 on their own, but scripts and vendor integrations did not. The v2 API has a new data structure and needs OAuth access to the Postmaster account.
  • Postmaster Tools v2 reports compliance, not reputation. It shows one-click unsubscribe pass rates, SPF and DKIM alignment failures, and user-reported spam. Our Postmaster Tools v2 guide covers each view.
  • The data covers personal Gmail only. Postmaster Tools measures mail to gmail.com and googlemail.com addresses, never Google Workspace mailboxes. A consumer brand gets rich data, while a B2B sender with little personal Gmail volume often gets too little for a reliable reading.

Matthew asked everyone to use the feedback button inside Postmaster Tools v2 to request a reputation indicator. His reasoning: Google adds what enough senders ask for.

Validity's Heatwave blocklist lists domains warmed by fake engagement

Heatwave is a domain blocklist that Validity launched on September 3, 2026, aimed at cold email sent from domains warmed up with synthetic engagement. A synthetic warming tool sends mail between accounts it controls, then opens it, replies to it and moves it out of spam automatically, so that a new domain looks trusted. Validity's announcement names Spamhaus, SURBL, Comcast and Proofpoint among the organizations using or evaluating the list. Matthew put its size at about 1.1 million domains at launch, a number that is still growing.

Webinar slide on the Validity Heatwave blocklist launch. Heatwave is a blocklist for high-velocity spam bursts, aggressive acquisition tactics and sudden sending spikes. It reviews whether a sending domain is associated with synthetic reputation warming or unsolicited outreach, and lists domains at several levels: synthetic warming only, graduated to real cold outreach, and pre-warming.

Heatwave grades a domain rather than simply listing it. Matthew described four states:

  1. Not listed.
  2. Pre-warming: the domain is being warmed and has not sent anything else yet.
  3. Synthetic warming observed: warming traffic and nothing else.
  4. Graduated: the domain was warmed synthetically and now sends real outreach.

A domain that never used a warming tool can be delisted through Heatwave's escalation path. Read the listing description first, because it says which behavior was observed. A sender who does use a warming tool should ask the vendor directly whether its engagement pattern is abusive, because the tools are what Heatwave targets.

DMARCbis adds three tags: np, psd and t

DMARCbis is the revised DMARC standard, published as RFC 9989 in May 2026, and it adds three tags to the DMARC record: np, psd and t. Matthew described it as DMARC version two, although a DMARCbis record still starts with v=DMARC1.

  • np sets the policy for subdomains that do not exist. The old workaround was a wildcard SPF or DKIM record declaring that a name sends no mail. np=reject tells receivers to reject mail from any subdomain of yours that has no DNS records at all, which is where spoofers go first.
  • psd says where your organization begins. DMARC used to find a domain's organizational domain through the Public Suffix List, a volunteer-run file that struggles to keep up with new top-level domains. RFC 9989 replaces that lookup with a walk up the DNS tree, and psd=n on your own root domain tells receivers it is the organizational domain for itself and everything below it. psd=y is for registries that operate a public suffix, not for brands.
  • t=y is a test mode. A receiver applies one level less than the published policy, so p=reject; t=y is handled as quarantine and p=quarantine; t=y as none. Matthew suggested it for the step from none to quarantine, so the reports show what would happen before any mail is affected.

Matthew added a point that matters more than any tag: turn aggregate reporting on. Many companies that come to Email Industries published p=none years ago with no rua address. That record meets the Google and Yahoo requirement, but it tells the domain owner nothing. Matthew's own personal domains, each with a single user, are spoofed regularly. Across the domains we test, only 48% publish a DMARC policy and 52% of domains still have none, according to the Unspam.email Email Deliverability Benchmark.

DMARCbis removes pct, ri, rf and the report size limit

RFC 9989 removed the pct, ri and rf tags and made the ! size limit on a report address obsolete syntax that reporters ignore. All four can be deleted from a DMARC record today.

The pct tag caused the most confusion. It asked receivers to apply the policy to a percentage of failing mail, and Matthew's point was that nobody could compute it: What is 50% of an unknown number? Some receivers sampled every other message, and many treated the tag as all or nothing. The most common value, pct=100, was the default anyway and did nothing.

One case is more than cosmetic. A record with p=reject; pct=25 rejected a quarter of failing mail under the old standard and rejects all of it at a receiver that follows RFC 9989. Google, Yahoo and Microsoft had not publicly committed to RFC 9989 semantics by September 2026, so both readings are live at once. Our RFC 9989 guide has the detail. A sender who ramped enforcement with pct should use t=y for the same purpose now.

The size limit is the !10m on the end of an address such as rua=mailto:drua@example.net!10m, which asked for reports no larger than 10 MB. Matthew rarely saw it used, and aggregate reports are small anyway. RFC 9989 keeps the syntax only so old records still parse.

A DMARCbis record update is three deletions and two additions

The record on Matthew's slide came from a real customer, with only the domain changed. This is the legacy version:

v=DMARC1; p=reject; pct=100; ri=86400; fo=1; rua=mailto:drua@example.net!10m; ruf=mailto:druf@example.net

This is the same record updated for DMARCbis:

v=DMARC1; p=reject; np=reject; psd=n; fo=1; rua=mailto:drua@example.net; ruf=mailto:druf@example.net

Webinar slide titled Changes to the DMARC record. The legacy DMARC record reads v=DMARC1; p=reject; pct=100; ri=86400; fo=1; rua=mailto:drua@example.net!10m; ruf=mailto:druf@example.net, with pct=100 and the !10m size limit marked in red. The updated DMARCbis record reads v=DMARC1; p=reject; np=reject; psd=n; fo=1; rua=mailto:drua@example.net; ruf=mailto:druf@example.net, with np=reject and psd=n highlighted.

The update deletes pct=100, ri=86400 and the !10m size limit, and adds np=reject and psd=n. It is safe to publish today. A receiver still on RFC 7489 ignores np and psd, because both standards tell receivers to ignore tags they do not know. The deleted values were defaults or are ignored anyway.

The question the audience asked most was when to make this change, and Matthew's answer was now. The Unspam.email DMARC checker flags pct, ri and rf in a live record, and the DMARC record generator writes a record with an np policy.

DKIM2 fixes replay and mailing lists, and it is a 2027 project

DKIM2 is the next version of DKIM, still an IETF draft rather than an RFC, and it fixes two problems the original DKIM has had for years. Matthew expects it to matter in 2027.

  • DKIM2 stops replay. Under DKIM today, an attacker can take a signed message, change the parts the signature does not cover, and resend it in bulk with DKIM still passing. Senders fought this by oversigning headers. DKIM2 records each hop a message takes, so a copy replayed to other recipients no longer validates as the original.
  • DKIM2 survives mailing lists. A discussion list that adds a footer or edits the subject breaks a DKIM signature today. Under DKIM2, each system that changes a message records what it changed, and the final receiver can work backward to confirm the original was intact. Matthew called it chain of custody.

DKIM2 also makes room for stronger keys, including post-quantum algorithms. On key length Matthew was blunt: 512-bit keys should never be used, 1024-bit keys are on the way out, and 2048-bit is the size to ask your platform for. Our guide to DKIM key length explains the trade-off.

Senders who use an email platform have almost nothing to change in DNS in the short term. Platforms will run a DKIM2 signer beside the DKIM1 signer with your existing key, and a CNAME that points your DKIM record at your platform lets the platform update keys later without your involvement. FastMail is the largest mailbox provider signing with DKIM2 today and checking it on inbound mail, but most outbound senders do not sign yet. Matthew's practical advice was to ask your email platform for its DKIM2 roadmap on your next call or renewal, because platforms build what enough customers ask for. Our DKIM2 and DMARCbis guide covers the draft in depth.

Gmail's political sender program is verification, not a free pass

Gmail opened a Verified Sender Program for US political committees on September 8, 2026, built on Campaign Verify, the vetting service already used for political text messages and calls. It follows an earlier Google pilot for political mail that few campaigns joined.

A committee registered with the Federal Election Commission can enroll once it verifies its sending domain through Campaign Verify, signs with DKIM, publishes SPF, registers in Postmaster Tools and keeps its spam rate below 0.3% over a 14-day average. Enrolled mail still goes to spam when a recipient reports it, blocks the sender or filters it. Matthew stressed that the program is Google learning who a political sender is, not an exemption from its policies.

Several Email Industries clients have registered, and Matthew has not seen a measurable effect yet. Nothing changes for any other sender.

Gmail's AI Inbox reads your text, so an image-only email has nothing to summarize

Gmail now uses Gemini to sort, prioritize and summarize mail, and a summary can only describe the text a message contains. Google announced the Gemini-era Gmail on January 8, 2026, and the AI Inbox view that ranks what deserves attention is still limited to subscribers.

Matthew made four points about mail in the AI Inbox:

  • Every Gmail tab is the inbox. Primary, Promotions, Social, Updates and Forums are all the inbox, and someone reading Gmail in Outlook or Thunderbird never sees the tabs. Engineering a move from Promotions to Primary works only briefly before the mail gets reclassified.
  • Priority is learned from engagement. The AI Inbox decides what is urgent from how each person treats your mail, so marketing that a subscriber never opens drops down that subscriber's list.
  • Image-only email summarizes badly. With no live text, the model has to read the images or guess. HTML text and descriptive alt text give it something to work with, and it is worth checking whether the summary says what you meant.
  • Structured data gets surfaced. Gmail already lifts a two-factor code to the top of a message with a copy button. Schema markup for a sale lets the same systems show the offer more prominently.

How the summaries read a message, and what a sender controls in them, is covered in our guide to AI summaries in the inbox.

Gmail now judges your subdomains and root domain together

Gmail checks its sender requirements across a domain and its subdomains together, and the compliance status page in Postmaster Tools v2 reports them that way. The page checks eight requirements: SPF and DKIM authentication, From header alignment, DMARC authentication, encryption, user-reported spam rate, DNS records, one-click unsubscribe, and honoring unsubscribes.

Webinar slide on the Gmail Sender Enforcement Dashboard. Left: metrics are tracked over rolling evaluation periods and apply to subdomains and apex domains; large senders need PTR and FQDN server configuration plus DKIM, DMARC and SPF; a spam complaint rate below 0.3% prevents domain-level throttling; one-click list-unsubscribe is mandatory for commercial mail. Right: a Postmaster Tools compliance status table showing Compliant for SPF and DKIM authentication, From header alignment, DMARC authentication, encryption, user-reported spam rate, DNS records, one-click unsubscribe and honor unsubscribe.

Matthew's warning was that a compliant subdomain no longer protects a root domain that is not compliant. The common case is marketing sent from a subdomain with a working one-click unsubscribe, while transactional mail goes out from the root domain to people who already unsubscribed. When those recipients complain about the transactional mail, the whole domain pays. The same thing happens when a second division mails its own list and the two lists overlap. Email Industries sees it, in Matthew's words, "time and time again."

The fix is organizational rather than technical: one suppression list shared by every team and platform that sends under the domain. Across the emails we test, only 14% of senders pass the one-click List-Unsubscribe check, so for most programs the header itself is the first thing to fix. Our List-Unsubscribe header guide shows the headers Gmail expects.

Comcast mail is moving to Yahoo's filters

Comcast is migrating its consumer mailboxes to Yahoo, so mail to comcast.net addresses will increasingly be filtered by Yahoo's rules. Xfinity's migration page says the addresses stay @comcast.net, and the comcast.net MX records still point at Comcast for now. AT&T's consumer domains, such as att.net, already went the same way.

Webinar slide on the Yahoo and Comcast migration impact. Infrastructure consolidation: Comcast and Xfinity are migrating consumer mailboxes and spam filtering to Yahoo's platform, while Comcast still maintains the original MX records. Operational adjustments: complaint monitoring for Comcast addresses should consolidate in Yahoo Sender Hub, senders must stay under Yahoo's 0.3% maximum spam complaint rate, and bounce rules should process Yahoo's 554 and 553 permanent failure codes.

The migration cuts both ways for senders:

  • Yahoo problems will follow you to Comcast. A sender with poor delivery at Yahoo should expect the same at comcast.net as mailboxes move.
  • What works at Yahoo will work at Comcast. The 0.3% complaint ceiling, the authentication rules and Yahoo's bounce codes apply, and most platforms already process those bounces.
  • The transition will be rough. Matthew expects elevated bounces, new blocks and a shift in where complaints come from while mailboxes move.
  • Yahoo Sender Hub is worth registering for. Verify your domains through DNS, and then watch delivered volume and complaint rates. Yahoo told Matthew that more data is coming.

Our guide to fixing deliverability at Yahoo covers the rules that now apply to a growing share of US consumer mail. Matthew also mentioned a proposed standard for engagement reporting, draft-brotman-aggregate-performance-reporting, that would tell senders how many messages reached the inbox and how recipients engaged. By his account, only Comcast sends those reports today, and he held it back from the slides because it may not survive the migration.

The 2027 deliverability plan has four steps

Matthew closed the session with a four-step plan for 2027, and each step maps to one of the changes above.

Webinar slide titled 2027 Strategic Deliverability Plan, with four steps. Audit DNS for DMARCbis: remove deprecated pct tags, configure np=reject for dormant subdomains, and verify strict tree-walk alignment. Upgrade to the Postmaster Tools v2 API: automate daily data ingestion for RFC 8058 unsubscribe pass rates and authentication diagnostics. Enforce a sub-0.1% complaint threshold: tighten sunset policies to 60 days of inactivity to insulate lists from Validity Heatwave triggers. Re-calibrate Yahoo and Comcast sending: unify bounce handling and adjust sending queues to Yahoo's throughput caps.

  1. Audit DNS for DMARCbis. Remove the retired tags, add np=reject and confirm your alignment. Then review SPF, DKIM and DMARC every six months.
  2. Move to the Postmaster Tools v2 API. Rebuild anything that read v1 data, and pull unsubscribe pass rates and authentication diagnostics on a schedule.
  3. Keep complaints below 0.1%, and never above 0.3%. If complaints or bounces rise, tighten your sunset policy. If you use an automated warming service, check whether Heatwave lists your domains.
  4. Recalibrate for Yahoo and Comcast. Handle Yahoo's bounce codes the same way everywhere, and watch Comcast bounces closely while mailboxes migrate.

The 60-day sunset window on the slide is a starting point for a program that already has problems, not a rule. Matthew's answer on sunset policy in the Q&A below gives the range he actually uses.

Questions from the live Q&A

The audience sent ten questions during the session. These are Matthew's answers, condensed.

When should you update a DMARC record for DMARCbis?

Update it now. Matthew recommends a DNS review meeting every six months to confirm that SPF is current, DKIM keys are the right ones and DMARC enforcement still fits. A domain that has sat at p=none for five years with the work done is ready for quarantine. If your next review is in January, add DMARCbis to it.

Does Gmail filter .edu domains differently?

No. Matthew does not believe Gmail treats a domain differently because of its top-level domain. Gmail judges past performance, so more mail in spam usually means recipients no longer want it or find it relevant. Content decides the tab: a campus bookstore sale with prices and discounts reads as promotional and lands in Promotions.

Why does Postmaster Tools show one-click unsubscribe errors when it is implemented?

The error usually means mail is still reaching someone who already unsubscribed. Gmail expects an unsubscribe to take effect within 48 hours, and the usual causes are several lists or platforms that do not share suppressions, or transactional mail sent through a different platform to people who opted out. DMARC aggregate reports show every platform sending as your domain, which is how to find the stream nobody accounted for. In Matthew's experience, it is almost always a third-party platform the team did not realize was sending.

Is transactional email exempt from Gmail's unsubscribe rules?

No. Spam filters cannot tell transactional mail from marketing; they see a message with content. If transactional mail draws complaints or unsubscribe attempts, it probably carries promotional content, or recipients report it as spam because it has no unsubscribe link. Canada makes the line explicit: Canadian law has commercial and noncommercial messages and nothing in between, so a transactional message with an ad in it is commercial.

Is there such a thing as too much transactional email?

Yes, when the recipient has opted out of marketing. Michaela's example was a single purchase that produced five emails, from the order confirmation to a review request. Matthew's view is that a review request can count as commercial, because the brand benefits from the review. After someone unsubscribes, send strictly transactional mail such as the shipping notification, and drop the cross-sell.

How long should a sunset policy be?

It depends on how often you send. For a daily sender, Matthew suggests about 30 days without engagement, which gives a subscriber 30 chances to respond. For a monthly sender, two years can be reasonable. Website visits, logins, app use and a paid subscription all count as engagement, and a paying subscriber should keep receiving mail. Sixty days is the aggressive starting point he uses when a program has delivery problems, 120 days is more realistic for most brands, and the window can widen again once the problems are fixed.

Will BIMI logos show for Comcast users?

Yes. Once a Comcast user's mailbox has moved to the Yahoo web or mobile app, Matthew expects Yahoo's BIMI display to apply. A sender with BIMI in place should start to see the logo there.

Do DKIM or DMARC records need to change on a long-standing Google Workspace domain?

DMARC does and DKIM does not, for now. DMARCbis changes the tags, so review your record and remove or add tags as needed; a DMARC vendor managing your record should handle the upgrade. For DKIM, providers will sign with DKIM2 using your existing key, and Matthew does not expect DNS changes until DKIM2 becomes a formal standard. If your DKIM record is a CNAME to your provider, the provider can update it later with little effort on your side.

Does landing in spam hurt engagement?

Yes. Most people rarely open their spam folder, so mail that lands there gets little engagement, and the lack of engagement keeps it there. It also produces no complaints, because a recipient cannot report as spam a message that is already in spam. A program with almost no complaints and poor results should check where its mail is landing.

Under Canada's Anti-Spam Legislation (CASL), a purely transactional message such as an e-receipt does not need consent, but it still needs the other required elements, including an unsubscribe. The unsubscribe then applies to future commercial email. Personal messages and ongoing business correspondence are exempt entirely. Matthew had not seen a case brought for a missing unsubscribe in transactional mail, but he cited two recent ones for mailing people who had unsubscribed: a $500,000 undertaking and $200,000 from a job board. By his count, $700,000 was collected in six weeks, so a suppression list that does not carry forward is a real liability for anyone mailing Canada.

Test the changes before your next campaign

Every change above shows up in the headers and authentication results of a real message. Send one to the Unspam.email spam checker before your next campaign: it reports SPF, DKIM and DMARC results, the List-Unsubscribe headers and a spam score in one test. For a program that needs hands-on help, the Unspam.email deliverability consultants work with senders on audits and fixes.

The Unspam.email webinar page has the details of this session and of the ones that follow. The previous one, with Matthew Vernhout and Lawrence Heslin, is recapped in Inbox for the Holidays.

About the speakers

Matthew Vernhout is an email advisor at Email Industries, based in Toronto. He presented the session and answered the audience's questions.

Michaela Barriga works in marketing at Email Industries and moderated the session.

The webinar was organized by Unspam.email with Email Industries.

Frequently asked questions

What changed in email deliverability in 2026?

Google retired Postmaster Tools v1 and its IP and domain reputation scores, so Postmaster Tools v2 and its API are the only source of Gmail data. DMARC was republished as RFC 9989 (DMARCbis), which adds the np, psd and t tags and removes pct, ri and rf. Validity launched the Heatwave blocklist against synthetic domain warming, Gmail opened a verified sender program for US political committees, Gmail's compliance checks now cover a domain and its subdomains together, and Comcast began moving its consumer mailboxes onto Yahoo's filtering.

Should I update my DMARC record for DMARCbis now?

Yes. Matthew Vernhout of Email Industries advised doing it now rather than waiting for mailbox providers. Remove pct, ri, rf and any size limit such as !10m on a rua address, and then add np=reject for subdomains that do not exist and psd=n on your organizational domain. Receivers that still follow RFC 7489 ignore the new tags, so the update does not break anything.

Is Google Postmaster Tools v1 still available?

No. Google removed v1 access account by account from August 2026, and the High, Medium, Low and Bad reputation ratings went with it. Postmaster Tools v2 reports compliance instead: authentication, alignment, user-reported spam and one-click unsubscribe pass rates. Any script that read v1 data has to be rebuilt on the v2 API, which needs OAuth access to the account.

What is the Heatwave blocklist?

Heatwave is a domain blocklist that Validity launched on September 3, 2026, for domains warmed up with synthetic engagement, where a tool sends mail between accounts it controls and opens, replies to and rescues it from spam automatically. It launched with about 1.1 million domains and grades them as pre-warming, synthetic warming observed or graduated to real outreach.

How long should an email sunset policy be?

It depends on how often you send. Matthew Vernhout suggests about 30 days without engagement for a daily sender and up to two years for a monthly sender, counting website visits, logins and app use as engagement too. Sixty days is an aggressive starting point for a program with delivery problems, and 120 days is more realistic for most brands. Paying subscribers stay on the list as long as they can unsubscribe.

See where your campaign actually lands.

Start a free spam test Inbox placement test