Four days ago Neil Kumaran posted on the Gmail Security & Trust blog. The post is short, two paragraphs of context and a bulleted list. The bulleted list is what matters. Starting in February 2024, anyone sending more than 5,000 emails per day to Gmail addresses will need to authenticate with SPF, DKIM, and DMARC, implement a one-click unsubscribe header, and stay below a 0.30% spam complaint rate. Yahoo posted essentially the same requirements the same week with a slightly different rollout calendar.
Most of the analysis I have read since the announcement misses the operational reality. The trade press is treating this as compliance theatre, a checkbox exercise for ESPs to assure their customers about. The technical blogs are walking through SPF syntax and DKIM key generation as if these were novel ideas in 2023. They are not. What is novel is the enforcement teeth, the calendar, and the second-order effects on the entire ecosystem of mail delivery.
We have been running PowerMTA-based infrastructure for senders since before any of this was on the horizon. We have customers who are going to be affected and customers who are not. The ones who are not affected fall into two camps: senders under the volume threshold, and senders who already do all of this correctly. The ones who are affected are everyone in between, which is the majority. The interesting question is not whether to comply. The interesting question is what compliance actually looks like when you take it seriously, and what happens when you do not.
This post is what we are telling our customers, and what we are doing internally to prepare. I am writing it the week of the announcement because the analysis available right now is largely wrong about what this means in practice. By March of next year there will be twenty good post-mortems published. By then it will be too late to use the information.
What Google and Yahoo actually said
The Gmail blog post is at blog.google/products/gmail/gmail-security-authentication-spam-protection. The Yahoo statement was posted to senders.yahooinc.com. I am linking these because half the third-party coverage I have read paraphrases the requirements in subtly wrong ways. The original text is short enough to read in five minutes and I recommend reading it before trusting any analysis. Including this one.
The requirements break into three buckets. The first is authentication. Bulk senders must publish SPF records that pass for the sending IPs, DKIM signatures that validate, and a DMARC policy with at least p=none alignment to either SPF or DKIM. None of this is technically new. SPF dates from 2003, DKIM from 2007, DMARC from 2012. What is new is the requirement to have all three working together as a precondition of delivery rather than as a reputation positive.
The second bucket is the unsubscribe mechanism. Bulk messages must include a List-Unsubscribe header that supports one-click unsubscribe per RFC 8058, plus a visible unsubscribe link in the message body. The receiving server can then process unsubscribes without the user clicking through to a webpage. Google has given senders until June 2024 to implement this part, six months after the February rollout of the authentication requirements.
The third bucket is reputation. Senders must keep their reported spam complaint rate below 0.30%. Google is saying anything above 0.10% will start hurting deliverability, and 0.30% is the hard ceiling at which mail will be rejected outright. This is the requirement that has the least precedent and the most teeth. SPF and DKIM are technical settings you can fix in a weekend. Spam complaint rate is a property of your audience, your content, and your list hygiene, accumulated over months of practice.
Why now
You can read the Gmail announcement two ways. The charitable reading is that Google is finally tired of bulk senders externalizing the cost of spam onto users and is using its market position to fix a coordination problem the industry has not been able to fix on its own. The cynical reading is that Google is consolidating delivery decisions through its own authentication framework in ways that will eventually disadvantage senders without expensive deliverability tooling. Both readings are partially true.
The thing both readings miss is that this was telegraphed for years. M3AAWG and the major mailbox providers have been publishing the same recommendations as best practices since at least 2018. Microsoft and Apple have been quieter than Google but moving in the same direction. The 2020 to 2022 period saw the major ESPs (SendGrid, Mailgun, Postmark) gradually tightening their own internal authentication requirements. The Google announcement formalizes what was already true at the operational level for any sender who has been paying attention.
What changed is the calendar. “Best practice that you should implement” became “requirement that determines whether your mail is delivered at all” with an enforcement date sixteen weeks away. For an operator running mature infrastructure with all three protocols correctly configured, the change is administrative. For an operator running infrastructure they inherited from a predecessor or set up five years ago and have not touched since, the change is existential. We have customers in both situations.
What this means for the operators we serve
The customer profile that comes to us is overwhelmingly one of two types. The first is a B2B operator running cold outreach across multiple subdomains, typically two to fifteen sending domains, each with a few hundred to a few thousand daily messages. The total volume per sending domain stays comfortably under the 5,000 threshold, but the aggregate operator-level volume is well above it. For this profile, the operative question is whether Google enforces per-domain or per-sender, and the answer is per-domain. The 5,000 limit applies to each individual domain in isolation.
This is operationally significant. An operator running fifteen subdomains at 1,000 messages each per day is sending 15,000 daily messages but is technically below the bulk sender threshold on every individual domain. Whether Google will eventually close this loophole is a separate question. For now, the cold outreach use case can continue with the same architecture as long as each domain has SPF, DKIM, and DMARC set up correctly. Most do not. We are spending the next four months remediating this across customer infrastructure.
The second profile is a B2C newsletter publisher or transactional sender. Single domain, single brand, daily volume typically 50,000 to several million. For this profile, the requirements apply directly and there is no architectural workaround. Authentication needs to be perfect, the unsubscribe mechanism needs to work reliably, and the spam complaint rate needs to be managed. Most of our customers in this profile already have authentication working. The unsubscribe and spam rate work is what is going to occupy the next six months.
The case I worry about most is the operator I have not heard from yet. The operator who set up their infrastructure in 2018, has not touched DKIM since, is signing with a 1024-bit key under a selector named “default”, and has no DMARC record at all. This operator will not learn about the requirement until their mail starts failing in February. By then their reputation will already be damaged. We are reaching out to dormant accounts proactively this month to catch this category before the calendar catches them.
The specific work happening between October and February
For senders who do not currently have working authentication, the sequence is unambiguous. Generate SPF records that include all current sending IPs and pass without exceeding the 10-lookup limit. Generate DKIM keys at 2048 bits with a selector name that includes the year for future rotation tracking. Publish DMARC at p=none with an aggregate report mailbox you actually read. Wait two weeks for receiver caches to settle and aggregate reports to start arriving. Read the reports. Identify any mail streams that are unauthenticated or misaligned. Fix them. Move to p=quarantine for a month. If complaint rates and bounce rates stay stable, move to p=reject.
This sequence takes ten to twelve weeks if done conservatively. Done aggressively in five weeks it can break things in production that take longer than that to recover from. The conservative path is appropriate for most senders. The aggressive path is appropriate when the deadline forces it, which it will for senders who start in December.
The unsubscribe header work is technically simpler but operationally trickier. Adding the List-Unsubscribe header is a two-line change in PowerMTA configuration or a checkbox in most ESPs. The hard part is the unsubscribe processing pipeline. RFC 8058 says the receiving server can fire a POST to your unsubscribe URL without any user interaction. Your endpoint must accept that POST, process the unsubscribe, return a 200 or 202, and never send to that recipient again. Two-day processing window. A surprising number of senders implement the header and forget the endpoint, or implement the endpoint and forget to actually suppress the recipient from future campaigns.
The spam complaint rate work is the hardest. There is no engineering fix. You build the rate down by sending mail that recipients want, removing recipients who do not engage, and never adding addresses you did not earn. For senders whose lists were partially purchased, partially scraped, or partially appended from data brokers, the answer is to clean ruthlessly between now and February. The remediation we do for customers in this situation typically removes 15% to 40% of the list. The deliverability improvement after is dramatic.
What about transactional mail
Transactional messages, defined as account notifications, password resets, order confirmations, and similar one-to-one messages tied to user action, are largely exempt from the unsubscribe requirement. They still need authentication. The Google announcement is ambiguous about the spam rate threshold for transactional, but the operational reality is that transactional senders almost always have spam rates below 0.10% naturally. If yours does not, you have a content problem masquerading as a transactional volume.
The interesting case is senders who blur the line. The “transactional” message that includes a marketing footer. The “transactional” daily summary that recipients did not actually request. The order confirmation that bundles three promotional offers below the receipt. These will be treated as marketing under the new rules. If they currently lack unsubscribe links and one-click headers, they need them by June. We have at least four customers in this category who are going to be unhappy when we tell them their “transactional” workflows are not.
The Yahoo difference
Yahoo’s announcement parallels Google’s but with two differences worth noting. First, the Yahoo enforcement rollout is described as “gradual through the first half of 2024” rather than the more explicit February enforcement Google announced. In practice this means Yahoo will be slower to bounce non-compliant mail but will eventually catch up to Google’s posture. Second, Yahoo’s spam rate threshold is stated less crisply. Yahoo says “low” complaint rates rather than the specific 0.10% target Google gives.
Operationally we treat both identically. Any sender prepared for Google compliance is prepared for Yahoo. The senders who would not pass Yahoo’s eventual enforcement are also senders who fail Google. We do not configure infrastructure for Yahoo specifically.
What we do configure for is the next provider to announce similar rules. Apple’s iCloud mail is the most likely candidate based on their privacy posture and their existing emphasis on authentication. Microsoft’s Outlook.com is the second most likely candidate based on their position in the market and the parallel they would draw from Google’s enforcement. If I had to bet, Microsoft makes a similar announcement within twelve to eighteen months. None of our customers will be caught flat-footed when it comes.
The second-order effects nobody is talking about
The trade press analysis stops at “implement SPF, DKIM, DMARC.” The actual interesting questions are second-order.
What happens to ESP economics when senders no longer need a major ESP for basic deliverability? For a decade, the value proposition of SendGrid, Mailgun, and similar was partly “we handle the authentication for you.” The Google announcement makes authentication a sender responsibility regardless of ESP. The implicit value of using SendGrid for SMTP becomes less obvious. We expect to see more senders move toward self-hosted MTAs after they realize they had to do the authentication work anyway.
What happens to deliverability monitoring tools? Google Postmaster Tools becomes essential for any bulk sender to track their compliance status and spam rate. The third-party tooling around Postmaster API data is going to explode. The interesting question is whether Google opens the Postmaster API in 2024 to support this, or keeps it scraping-only as it currently is. The Google product team is internally debating this. Watch for an API announcement in early 2024.
What happens to small senders who were freeloading on shared IP reputation through their ESPs? The new rules apply per-domain, but spam rate is calculated per-sending-domain. Senders on shared ESP IPs whose individual domain reputation was masked by aggregate IP reputation are going to discover their actual reputation when they get their own domain’s Postmaster Tools data. Some will be surprised in good ways. More will be surprised in bad ways.
What happens to the worst senders? The senders running pure spam operations have always been the canary. They had the most to lose from authentication enforcement and have been moving away from clean infrastructure since 2020. The Gmail enforcement will accelerate this. The legitimate gray-area senders, the ones doing cold outreach with thin authentication and aggressive lists, are going to be forced into one of two directions: clean up and become legitimate, or move further into the gray. Cold outreach as a business model will not disappear. It will get more expensive and more sophisticated.
What we are doing internally between now and February
We have eleven specific work items between today and January. I am not going to go into every one of them but here are the ones worth noting publicly.
We are auditing every customer DKIM key for size and rotation date. Any key smaller than 1024 bits goes to 2048. Any key older than two years gets rotated to a new selector. The work happens in coordination with each customer because key rotation requires the receiving cache to pick up the new public key before the signing switches over, and getting that wrong creates a 6-to-24 hour window where in-flight mail fails verification.
We are adding rua= and ruf= DMARC report mailboxes for every customer who does not have one. The aggregate reports are essential for the next four months because they will surface unauthenticated mail streams we did not know existed. We have already identified two customers who had a third-party tool sending on their behalf that we did not know about, only because the DMARC reports surfaced it.
We are implementing the List-Unsubscribe header processing pipeline for customers who do not have one. The hard part is the suppression list integration. PowerMTA has good support for the header itself, but the actual unsubscribe handling has to integrate with the customer’s audience database. We are templating this for the common cases and doing custom work for the rest.
We are testing one-click unsubscribe end-to-end against actual Gmail and Yahoo accounts. The RFC is unambiguous about the technical implementation, but the actual receivers have edge cases. Yahoo, specifically, will fire the POST from an IP range we have to allowlist. We discovered this last week and several customer endpoints needed adjustment.
What to do if you are reading this and unsure where you stand
The honest answer is to check three things in the next forty-eight hours.
Pull your current DMARC record. If you do not have one, you have months of work ahead of you and should start today. If you have p=none, check whether the aggregate reports actually go to a mailbox you read. Most do not.
Pull your DKIM keys and check their size. Anything under 1024 bits gets rejected by major receivers already. Anything at 1024 bits is going to start getting questioned in 2024. Plan a rotation to 2048 if you have not already.
Check your spam complaint rate at Postmaster Tools. If you are not signed up for Postmaster Tools yet, sign up today, then come back in a week when data has populated. If your complaint rate is above 0.10%, you have work to do. If it is above 0.30%, you have urgent work to do.
If any of these checks comes back wrong, you do not have until February. You have until October 2023, today, to start the remediation work. The receiver caches and reputation systems do not move at the speed of the enforcement deadline. They move on their own schedule.
We are taking on new customers through January for migration work specifically tied to February compliance. The intake is via the contact page. The conversation will be specific to your sending profile and your current authentication state. We will not tell you to switch ESPs or buy a managed service unless that genuinely is the right answer. Most of the time the right answer is to fix the infrastructure you have.
The February deadline is real. The work between now and then is real. The infrastructure decisions you make in the next sixteen weeks will determine whether your mail gets delivered in March.