Why AI-Written Cold Emails Are Starting to Land in Spam (The Actual Detection Mechanism, Not the Myth)

No primary documentation from Google, Yahoo, or Microsoft describes detecting AI authorship as a spam signal. Not one line, in any published sender guideline, about identifying whether a language model wrote your email.

What they document instead: who is sending (SPF, DKIM, DMARC), how much they're sending (bulk-sender volume thresholds), and how recipients react (complaint rates, engagement). SpamAssassin, the open-source classifier running behind a large share of the world's mail servers, scores token frequency: how often a phrase showed up in known spam before. And none of that requires knowing whether a human or a model typed the sentence.

So why do AI-drafted cold emails keep landing in spam? Because the shortcuts that make AI drafting fast, identical openers across a batch, template-shaped personalization, volume that spikes overnight, are exactly the patterns those systems were built to catch. The filter isn't reading your email and concluding a robot wrote it. It's counting.

The myth, and where it comes from

Search "why do AI cold emails go to spam" and you hit a wall of near-identical claims: spam filters run natural language models that recognize the statistical fingerprint of machine-written text. Perplexity. Burstiness. But some pieces cite a specific number, over half of spam is AI-generated now, as if that settles the mechanism question.

But it doesn't settle anything. Almost none of those pieces link to a Google, Yahoo, or Microsoft document. The claim spreads because it's intuitive: AI writing sounds a certain way, spam filters are AI-powered, so of course they catch each other. Neither half of that logic matches what the providers actually publish.

This piece checks each proposed mechanism against what the providers themselves document. Where the documentation is silent, that gets stated as plainly as where it speaks.

What Google, Yahoo, and Microsoft actually document

Three organizations run most of the world's inboxes. All three publish sender guidelines, and none of them are shy about disclosing what they score, down to compliance-checklist detail. Read all three back to back and a pattern shows up fast: every documented signal is about identity, volume, or reaction. Not content origin.

Authentication as identity, not content judgment

Google's email sender guidelines require SPF or DKIM, at minimum, from every sender. Bulk senders, defined as anyone sending more than 5,000 messages a day to Gmail addresses, need both plus a published DMARC policy. Yahoo's sender best practices mirror this almost exactly: SPF or DKIM for everyone, both plus a DMARC record at p=none or stricter once you cross into bulk territory. Microsoft brought Outlook into the same regime for high-volume senders starting in 2025, rejecting non-compliant mail outright with a 550 5.7.15 bounce instead of routing it to spam.

But none of this reads your email. Authentication answers one question: is this domain who it claims to be? It has nothing to say about whether the words inside were typed by a person or produced by a model.

Both Google and Yahoo also require one-click unsubscribe (RFC 8058) on bulk mail, honored within 48 hours. And that requirement sits in the same bucket as authentication: it's about giving the recipient a fast exit, not about judging what the message says. A perfectly written, highly relevant email from a domain without a working unsubscribe link still fails this check.

Volume and the bulk-sender threshold

The 5,000-message threshold isn't arbitrary. It's the line where Google's guidelines assume you've moved from individual sending to bulk sending, and the compliance bar rises accordingly. Cross it and Google wants your spam rate, as reported in Postmaster Tools, under 0.10% as a target and never above 0.30%. Yahoo publishes the same 0.3% ceiling.

Here's where AI drafting actually creates risk, but not the risk people assume. Writing 300 personalized emails used to take a human most of a day. A model collapses that to minutes. Teams that can suddenly produce ten times the volume often start sending ten times the volume, before their domain has the reputation or warmup history to support it. So that's a volume-and-reputation problem. The AI didn't trip a content filter. It just made it cheap to trip a rate limit.

Complaint and engagement feedback

Both Gmail and Yahoo run feedback loops: Yahoo's Complaint Feedback Loop, Gmail's own user-report learning system, plus bounce and inactive-recipient tracking. Recipients marking your mail as spam, in volume, degrades your sender reputation regardless of how the email got written. And a boring, well-targeted, obviously human email that annoys enough people gets the same treatment as a slick AI-drafted one that annoys the same number of people.

What's conspicuously absent

Read the source documents from all three providers end to end and one thing stands out: none of them mention AI-generated content, language models, or text-origin detection as a scored signal. Not a footnote, not a "coming soon." So that absence is worth stating directly, because it's the single fact this whole piece rests on, and it's easy to read past.

The real content-side mechanism: statistical pattern scoring, not authorship

Authentication and volume explain a lot. But not everything. Some of what gets flagged really is about the words in the message, just not the way the myth describes it.

Token-frequency scoring: the Bayesian layer

SpamAssassin ships with a Bayesian classifier, and its own documentation explains the mechanism in almost comically plain terms. Feed it 200 known spam messages and 200 known legitimate ones, and it starts scoring new mail based on how often specific words and short phrases showed up in each pile. The project's own worked example: train it on a hundred messages containing "penis enlargement," and the 101st message with those words gets flagged hard.

That's the whole mechanism. Word and phrase frequency, learned from a training set, applied to new mail. There's no model asking whether this reads like it was written by an LLM. There's a lookup table asking whether it has seen this exact phrase in spam before, and how often.

The classifier can't do any of this cold, either. SpamAssassin's own documentation is specific about the threshold: it needs at least 200 known spam messages and 200 known legitimate ones before it will score a single new email. And once it's trained, the tokens themselves get stored as hashes, not plain text. It's tracking statistics about word patterns, not building any kind of profile of who wrote what.

An AI-drafted batch trips this constantly, for a boring reason. Unconstrained AI drafting reuses the same sentence openers, the same transitions, the same call-to-action phrasing, across every email in the batch. That's precisely the kind of repetition a Bayesian classifier learns to flag, whether the repeated phrase came from a model or from a human copying the same template five hundred times.

Fuzzy-checksum bulk detection: DCC, Razor, and Pyzor

This is the piece that actually explains why swapping in a first name doesn't save an AI batch. The Distributed Checksum Clearinghouse, DCC, is a network of mail servers that share fuzzy checksums of the mail passing through them. Fuzzy is the operative word. DCC's own documentation confirms the checksums "ignore many personalizations and hash busters." A message sent to 500 people, each copy carrying a different first name and company dropped into an identical skeleton, still produces the same fuzzy checksum 500 times. So the network sees five hundred near-identical messages and flags the pattern as bulk, no matter what got swapped into the blanks.

Razor and Pyzor work on the same principle: distributed hash networks built to see through exactly the kind of surface variation a mail-merge produces, whether the merge came from AI or a spreadsheet. But none of these systems care who or what wrote the underlying template. They care that the template is the same 500 times.

The nuance: what Google's real machine learning is actually for

Google does run real machine learning on email text, and pretending otherwise would just make this piece's story cleaner than it should be. The relevant system is RETVec, short for Resilient and Efficient Text Vectorizer, a Google Research project with a public paper and an open-source repository.

Here's what RETVec's own documentation says it does: makes text classifiers resistant to character-level adversarial manipulation. Typos, homoglyphs (swapping a Cyrillic character for a similar-looking Latin one), leetspeak, invisible characters, the tricks spammers have used for two decades to sneak "fr33 v14gra" past a filter looking for the literal word "viagra." The arXiv paper is explicit about this framing. Nowhere in the paper, the GitHub repository, or the lead researcher's own publication page does the system get described as detecting AI-generated text or classifying who wrote a message.

Press coverage widely reports RETVec was deployed into Gmail's spam classifier, citing a 38% improvement in spam detection and a 19.4% drop in false positives. I couldn't independently confirm those figures or the Gmail deployment itself against Google's own primary blog post; the article's body text wasn't retrievable through a direct fetch, and neither the arXiv paper nor the GitHub repository states a Gmail deployment in its own text. Treat the deployment claim as widely reported, not primary-confirmed. What is confirmed, straight from Google's own paper and code: RETVec fights obfuscation. But it doesn't fight AI authorship. Detecting "fr33 w1nn3r" is a solved, documented problem. Detecting "an LLM wrote this paragraph" is a different, and as far as any primary source shows, unbuilt capability.

Can AI-generated text even be detected? What the closest real evidence shows

One piece of research gets close enough to the myth that it's worth engaging head-on instead of waving off. Researchers from Columbia University and the University of Chicago, working with Barracuda Networks, built a detector and ran it against a corpus of spam and malicious email spanning February 2022 through April 2025. Their trick: emails sent before ChatGPT's public release in November 2022 were almost certainly human-written, which gave them a clean baseline to calibrate three separate LLM-detection methods against. The paper was accepted to the 2025 ACM Internet Measurement Conference.

Their finding: by April 2025, 51% of spam emails were AI-generated. That's a real number, from real researchers, using a real, if retrospective, detection methodology. So authorship detection is possible. But it just isn't documented as something Gmail, Yahoo, or Outlook run live, at send time, on your specific email, as a classification signal.

And the study's second finding cuts against the myth even harder. AI-generated spam in their dataset showed fewer grammatical errors and more formal language than human-written spam, not the stilted, robotic tell people assume gives AI writing away. If anything, AI drafting made spam read more convincingly human, not less. The folk theory that filters catch AI text because it "sounds like AI" has the direction backwards.

Why the myth persists

Two plain reasons, neither requiring bad faith from anyone repeating the claim. First, the symptom looks identical from the sender's side. An AI-drafted batch full of repeated openers and identical structure gets flagged for the same reasons a human-written mail-merge blast would. But "AI did this" is a diagnosis that feels right and happens to be wrong.

Second, it's the more comfortable story. "The algorithm is targeting AI" externalizes the problem onto a system nobody can inspect. "My batch had almost no structural variance across 500 emails" is a QC failure the sender has to own. So only one of those two stories lets you avoid changing anything about how you write.

What actually triggers these signals when AI writes your cold email

None of the mechanisms above care about AI specifically. But AI drafting, used carelessly, walks straight into all three of them.

Phrase repetition

Left unconstrained, AI drafting defaults to the same handful of sentence openers, transitions, and CTA phrasing across an entire batch, because that's what "write me 500 personalized cold emails" produces when nobody checks the output. That's exactly what token-frequency scoring is built to catch. And it would catch the same pattern from a human running one template, too.

Template-shaped personalization

Dropping a first name and company into an otherwise identical skeleton is exactly the pattern fuzzy-checksum systems exist to see through. AI makes this fast enough to do at scale without anyone noticing they're doing it. Tell a model to "personalize" 500 emails and, left unchecked, it will do the minimum that satisfies the instruction: swap two or three tokens into a fixed shape. The output looks personalized to a human skimming a sample of five. But it looks identical to a system checksumming all five hundred.

Burst volume from unauthenticated domains

AI drafting collapses the time cost of writing a batch. That tempts teams to scale send volume faster than their domain's authentication and warmup can support, tripping the same bulk-sender thresholds documented above. The AI didn't cause this directly. It just removed the natural rate limit that used to come from a human only being able to type so fast. A domain that's been sending 50 emails a day for two months, then suddenly sends 3,000 in an afternoon because drafting got cheap, looks like a burst to every system watching volume, regardless of how good the copy is.

The fix: structural variance as pre-send QC

None of this requires abandoning AI drafting. It requires treating the output the way you'd treat any bulk-produced content: check it before it ships.

What "structural variance" means in practice

Concretely: real variation in sentence length and opening structure across the batch, rotation across message skeletons that are actually different rather than one skeleton with swapped tokens, and personalization anchored to something specific to the recipient, a detail from their public activity, not a merge field. A first name isn't personalization. It's a variable.

Building the pre-send QC check

Before a batch sends, run three checks against a sample:

• Diff the generated emails against each other for repeated openers and phrases.
• Confirm personalization references something recipient-specific, not just name and company.
• Cap how many emails in the batch share a structural skeleton.

That's a checklist a GTM engineer runs on the output. Not a prompting trick you paste into a chat window and hope for.

Where this sits relative to authentication and warmup

Structural variance fixes a content-layer problem. It doesn't substitute for SPF, DKIM, and DMARC, and it doesn't substitute for a warmed domain sending at a sane volume. Those solve different documented mechanisms: authentication solves identity, volume pacing solves burst detection, structural variance solves phrase-repetition and template detection. Skip one and the other two don't cover for it. So all three have to hold at once.

Verifying before you find out the hard way

The cheapest way to catch these signals is before a real batch goes out, not after open rates fall off a cliff. Seed-list testing, sending to a set of test inboxes across Gmail, Yahoo, and Outlook and checking where the mail actually lands, along with content-side deliverability checks, surfaces phrase-repetition and template-detection problems before they cost a domain its reputation.

Run it in this order. Authenticate the domain first (SPF, DKIM, DMARC) and confirm it passes with a header check, not just a "looks configured" glance. Warm the domain at a sane volume before the real batch, not the day of. Then, and only then, send the actual drafted batch to the seed list and check placement across providers. If mail lands in spam at that stage with authentication and warmup already solid, the content is the variable left, and that's when the phrase-repetition and template checks from the section above earn their keep.

Neither step is complicated. Both take less time than writing the batch in the first place, and considerably less than rebuilding sender reputation after a domain gets burned. Reputation is slow to build and fast to lose. Skipping the fifteen-minute check because the batch "looks fine" is how a domain ends up burned for a launch that mattered.