For most of the newsletter era, the trust contract was implicit: a reader paying for your writing assumed a person wrote it. On July 21, 2026, Substack made that assumption checkable. It shipped a "Scan for AI text" button, powered by the detector Pangram, that lets any reader run a post or note over 100 words through an AI-detection model and see an estimate of how much of the text looks machine-written. This is not a ban — AI-assisted writing is still allowed — but it changes the game from "nobody can tell" to "anyone can check," and on a platform whose whole product is voice-first writing that readers pay for, that is a bigger shift than it looks. This guide is the deep-dive for newsletter writers: exactly how the scanner works and what it reads, the controls writers actually hold (a pre-publish self-scan, a "how I make this" disclosure statement, a per-post opt-out, and a way to report false positives), the accuracy reality that makes the score an estimate rather than a verdict, why detection lands harder on a paid newsletter than on a throwaway feed post, what actually gets flagged versus what sails through, and the durable response — disclose your process, keep a genuinely human voice, and stop staking your whole business on one channel's authenticity score. It closes on where an AI content engine honestly fits a post-detector newsletter workflow, and where it does not.
For most of the newsletter era the trust contract was implicit. A reader who subscribed to your writing — and often paid for it — assumed a person sat down and wrote it. That assumption was never verifiable; you either trusted the byline or you did not. On July 21, 2026, Substack made it checkable. The platform rolled out a "Scan for AI text" feature, built with the AI-text detector Pangram, that lets any reader run a post or note through a detection model and see an estimate of how much of the writing looks AI-generated. Substack framed the move around a simple line: people should know what they are getting. It is deliberately not a ban — AI-assisted writing is still allowed — and the company was upfront that there are limits to what Pangram can detect, so the output is a probability, not a verdict.
The reason this matters more than a generic "platform adds AI label" story is what Substack is. It is a voice-first product where readers pay for a specific person's writing, and where the entire value proposition is that the words are that person's. A one-tap "was this AI?" button on that kind of product does something a label on a video feed does not: it turns the implicit trust contract into a thing a reader can test in real time. This guide walks the whole picture for a newsletter writer — how the scan works, what you control, how accurate it really is, what actually gets flagged, and the response that survives the next tightening of the rules. For the news-event version with the launch specifics, see the Substack AI-detector report; this is the practitioner's deep-dive.
The mechanics are narrow and worth getting exactly right, because a lot of secondhand summaries blur them. A reader viewing a post or note sees an option to scan it for AI text; running that scan returns an assessment of how much of the writing looks machine-generated. The scan only works on text longer than 100 words — short notes and one-liners are below the threshold — and it applies only to content published on or after the July 21, 2026 launch. Your back catalog is not retroactively scannable, so this is a forward-looking system, not an audit of everything you have ever written. At launch it runs on web and iOS, with Android support described as coming later. Treat all of this as a snapshot of the launch state; Substack has signaled it may add more AI-related features, so specifics will move.
The detector reads text, and only text. It says nothing about the images, embedded video, or design in your newsletter, and it cannot see whether you used AI to research, outline, or edit — only whether the words on the page pattern-match to AI-generated writing. That boundary is the single most useful thing to internalize. The scan is a judgment about one artifact (the prose) using one method (statistical detection), and it is blind to the rest of how a modern newsletter is actually made. A writer whose value is reporting, a distinctive argument, or a personal relationship with an audience has a lot of trust that lives entirely outside the thing the scanner measures. This is the same limit that runs through the broader AI content authenticity strategy: detection scores one layer, and trust is built across many.
Substack did not hand readers a weapon and leave writers defenseless — most of the switches sit with the writer. You can scan your own draft before publishing to see exactly what a reader would see, which turns the scanner from a surprise into a pre-flight check. You can add a statement — a persistent "how I make this" note about whether and how you use AI — that surfaces alongside a scan, so your process is disclosed on your terms rather than inferred. On the publish screen you can run the scan, open the report, and disable detection for that specific post or note, after which readers will not see a Pangram analysis on it. And if a scan of your own work is wrong, you can report and remove the mistaken result. The net effect is a labeling and disclosure system where the writer sets the defaults, not an enforcement crackdown that happens to you.
Every claim about this feature rests on one question: how good is the detector? The honest answer is "good, not infallible," and both halves matter. Pangram reports very high accuracy — over 99% in its own and some third-party evaluations, with an extremely low false-positive rate on genuine human text, and it has been evaluated by outside researchers. That is a genuinely strong record as detectors go, and it is why Substack chose it. But independent reporting, including an Atlantic investigation, has found that no AI detector, Pangram included, is perfect, and detection accuracy falls on shorter passages. Substack itself concedes the limits and calls the result an estimate. So the number a reader sees is a well-calibrated probability, not a courtroom finding.
For a real human writer, the risk that actually bites is the false positive: your genuinely handwritten piece getting a high AI-likelihood score. It is rare on a strong detector, but "rare" is not "never," and a distinctive, tightly-edited, or unusual-register piece is exactly the kind of writing that can confuse a statistical model trained on the average. This is why the two writer-side tools — the pre-publish self-scan and the report-a-mistake path — are not afterthoughts; they are the recourse for the case where the machine is wrong about you. The wrong lesson to draw is "detectors are broken, ignore them." The right one is "the score is a signal with a known error rate, so build a process that does not depend on winning a coin-flip on any single scan."
It is tempting to file this alongside every other platform AI-labeling story, but a newsletter is a different animal from a scroll feed, and the detector hits it differently for three reasons. First, the reader relationship is direct and often paid — someone chose you, subscribed, and may be handing over money specifically for your take, so the gap between "you wrote this" and "a model did" is a live trust question, not a passing curiosity. Second, the product is the prose itself; unlike a video or a carousel where writing is one element, a newsletter is mostly words, so the thing the detector scores is the thing you sell. Third, newsletters are long-form, which is exactly where detectors are most accurate — the sub-100-word escape hatch that protects a quick note does nothing for a 1,200-word essay.
Add those up and the exposure of a text-first newsletter to a text detector is close to maximal: paid trust, prose-as-product, and long-form length all point the same way. That is not a reason to panic, but it is a reason to treat this as a structural shift rather than a feature you can ignore until it affects you. It is the same lesson that ran through why generic AI content stopped working, now with a scanner attached: the era where undisclosed, voice-flattened AI text could pass unnoticed in a paid newsletter is closing, and the writers who adjust early keep the trust the ones who do not will spend the next year defending.
The most common misconception is that the scanner flags "AI use." It does not. It flags text that statistically reads as machine-generated, which is a narrower and more specific thing. Prose that gets a high score tends to share the tells detectors and readers both react to: even, rhythmically flat sentences, hedged and generic phrasing, rule-of-three filler, the tidy-but-anonymous structure a model produces when nobody pushed it toward a real voice. That is the profile of undisclosed, lightly-edited AI copy passed off as personal writing — which is precisely the thing Substack's co-founder argued against in the "against Claudefishing" post that announced the launch. If that is your draft, a light polish will not save it; the structure is still the model's.
What sails through is writing that is genuinely yours, regardless of how it started. A piece you drafted with a model and then actually rewrote — reordering the argument, cutting the padding, adding the specific detail, the contrarian opinion, the lived anecdote a model would never invent — reads differently to a detector because it is different at the level the detector measures. The practical craft of removing the machine signature is its own subject, covered in how to make AI content not look like AI, and the honest framing there applies here: the goal is not to fool a scanner. Humanizer tools that exist to do exactly that — rewrite AI text to slip past detectors, like Ryne AI — treat the symptom and miss the point, because a reader who churns on flat AI copy churns whether or not it passed a scan. The durable version of "passing detection" is writing that deserves to pass because a person meaningfully made it theirs.
Strip away the mechanics and the strategy is three moves, none of them about beating the scanner. They are the moves that were smart before the detector shipped and are now simply non-optional.
Use the "how I make this" statement, and mean it. A short, honest note — "I draft with AI help, then rewrite and fact-check every piece myself," or "this is written by hand, AI is only used for research" — converts the whole dynamic from something a reader discovers by scanning into something you told them. Disclosure is cheap, it is increasingly the expectation across platforms rather than a differentiator, and it removes the one thing that actually breaks trust: the feeling of being deceived. A reader who knows you use AI and likes your work is not a problem; a reader who feels tricked is a cancellation. Getting ahead of the scan with a clear statement is the highest-leverage thing on this list.
If you use AI to draft, treat the output as a first draft that has a machine signature you have to remove — not a finished piece you lightly proof. That means editing at the level of structure and voice: reordering the argument the way you would actually make it, cutting the generic connective tissue, replacing the model's safe abstractions with your specific examples and opinions. This is the same discipline the whole shift toward AI as editor and director rather than drafter points at. It is also, not coincidentally, what makes the writing better — the detector is a crude proxy for "did a person with a point of view actually shape this," and shaping it is the work either way.
The structural mistake is letting a single text-first newsletter be your entire distribution, because then one platform's authenticity score — and one false positive — can move your whole business. The fix is the boring, durable one: run your newsletter as one disclosed, well-voiced channel inside a broader presence, and own more of the relationship than any one platform controls. Publish to an email list you own as well as to Substack, so a policy change or a bad scan cannot cut you off from the audience you built. And extend the same ideas into formats a text detector cannot even read — short video, carousels, images — so your reach does not live or die on how one scanner reads your prose. This is the same platform-risk logic behind choosing an honest Substack alternative or complement: the newsletter is a channel, not the whole company.
Here is the specific problem a post-detector newsletter creates, stated as production economics. Detection rewards writing a person genuinely shaped, and readers reward the same thing — so your scarce, valuable hours should go into voice, argument, and the specific detail only you have. What they should not go into is the mechanical front half of every issue: staring at a blank page, restating what a source said, reformatting the same idea for a blog, an email, and five social posts. Kompozy is a content generation and multi-platform publishing engine, and the useful way to use it around a newsletter is to move your effort off that mechanical half and onto the half that earns trust. Feed it your raw material — a podcast episode, a talk, a long voice memo, a rough outline — and it drafts a structured Email Newsletter and a Blog Article you then rewrite in your own voice before publishing. It is a drafting and repurposing accelerator, explicitly not a "post what the model wrote" button, which is the exact posture the scanner rewards.
Two design choices make it fit the disclosure-and-voice strategy rather than fight it. A Persona Brief governs every generation — your positioning, your register, and a banned-word list that strips the generic AI-tell phrasing detectors and readers both react to — so the draft you start editing is already pointed at your voice instead of the flat model average, which means your editing pass is finishing a voice, not excavating one from sludge. And because Kompozy generates the whole spread from one source, the repurposing that would otherwise eat your week — turning the finished issue into Clipped Shorts from a companion video, Carousel Posts, Quote Graphics, and native Text Posts — stops competing for the hours you need for the writing itself. The same source, the same disclosed process, fanned to eight social platforms plus blog and email from one queue, with a per-post review gate before anything ships.
Keep the honesty here, because overpromising is its own tell. Kompozy will not write your newsletter for you, and if you publish its draft unedited you will deserve the high AI score you get — that is not a limitation to hide, it is the entire point. What it removes is the blank-page tax and the reformatting tax, so the finite time you have for a newsletter goes into the part a detector cannot fake and a reader will not forgive you for skipping: making the words genuinely yours. Pair that with a clear "how I make this" statement on Substack, and you are running the durable version of this — disclosed process, real voice, and a presence spread across output types a text scanner cannot read so no single channel's number decides your reach. That is the resilient shape this whole shift is pushing newsletter writers toward, and it is the workflow the engine is built to run.
Substack made the newsletter trust contract checkable, and it is not going back. The "Scan for AI text" button reads long-form prose, on a paid, voice-first product, at exactly the length detectors are most confident about — so a text-first newsletter carries close to maximum exposure to it. But the tool bans nothing; it exposes undisclosed, flattened AI text passed off as personal writing, and it hands writers the controls to disclose, pre-scan, and appeal. The score is an estimate with a real error rate, so the answer is never to game it. It is to disclose your process, edit AI drafts into writing a person genuinely made, and stop betting the business on one channel's number. Do that and the scanner is a non-event — because the thing it is looking for was never in your work in the first place.
Substack added a "Scan for AI text" feature, powered by the detector Pangram, that lets a reader check a post or note and see an estimate of how much of the writing looks AI-generated. It works on text longer than 100 words, applies only to content published on or after July 21, 2026 (older posts are not retroactively scannable), and launched on web and iOS with Android to follow. Substack calls the result an estimate and openly acknowledges there are limits to what Pangram can detect, so it is a probability, not a verdict.
No. The feature is a transparency and disclosure layer, not a prohibition — AI-assisted writing is still permitted. Substack's guiding line is that readers should know what they are getting. Writers can add a statement describing whether and how they use AI, scan their own drafts before publishing, and disable detection on a specific post. The tool is designed to surface undisclosed, passed-off-as-human AI text, not to police everyone who used a model to help draft.
Yes, per post. On the publish screen you can run the scan, open the report to see what a reader would see, and disable detection for that individual post or note — after which readers will not see a Pangram analysis on it. You can also pre-scan a draft, add a persistent "how I make this" AI-use statement, and report and remove a scan of your own work that you believe is a false positive. The writer holds most of the switches.
It is good but not infallible, which is exactly why the score is framed as an estimate. Pangram reports very high accuracy and a very low false-positive rate in its own and third-party evaluations, but independent reporting has found that no detector — Pangram included — is perfect, and accuracy drops on short passages. For a real human writer, the practical risk is a false positive on a distinctive or heavily-edited piece, which is why the pre-publish self-scan and the report-a-mistake path matter.
It depends on how much you actually change. A light polish over a model's draft often still reads as machine-written to a detector, because the underlying structure and phrasing are the model's. Genuinely rewriting in your own voice — reordering, cutting, adding specific detail and opinion a model would not produce — is what shifts both a reader's and a detector's read. But chasing the detector is the wrong goal: the durable move is to disclose your process and make the work genuinely yours, not to reverse-engineer a passing score.
Three things. Add a clear "how I make this" statement so your process is disclosed up front rather than discovered by a scan. Use AI as a drafting and repurposing aid but edit into your own voice before publishing, so the piece reads as you to both readers and detectors. And stop betting your whole business on one text-first channel — run a newsletter as one disclosed, well-voiced channel inside a wider, multi-format presence, so no single platform's authenticity score can decide your reach.
On July 21, 2026, Substack added a Pangram-powered "Scan for AI text" button that lets any reader check a post or note over 100 words — published from that date on — for AI-written text and see an estimate of how much looks machine-generated. It is disclosure, not a ban: writers can pre-scan drafts, add a "how I make this" AI statement, disable detection per post, and report false positives. Because the score is an estimate with real limits, the durable response for newsletter writers is a disclosed process and a genuinely human-edited voice — not gaming the scanner.
Get started → · ← All guides · Compare Kompozy vs other tools