The two inbox providers that matter publish what they require of a bulk sender, and it is worth reading before adding a single brace to a template. Google’s sender guidelines, in force since 1 February 2024, start with the threshold:
Starting February 1, 2024, email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section.
The requirements are authentication, a complaint rate and an unsubscribe:
Set up SPF and DKIM email authentication for your domain
Set up DMARC email authentication for your sending domain
Keep spam rates reported in Postmaster Tools below 0.30%
Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link
Microsoft drew the same line at the same number. Its post for high volume senders, published
on 2 April 2025 and updated on 29 April, sets the threshold at more than 5,000 emails per day,
requires SPF, DKIM and DMARC with at least p=none aligned to one of the two, and says what
happens otherwise: non-compliant messages are routed to Junk first, and may eventually be
rejected. Enforcement began on 5 May 2025.
Read both pages end to end and you will not find the word synonym, or similar, or identical. The only sentences about content are about honesty:
Message headers and message content should be accurate, and not misleading or deceptive
Don’t use HTML and CSS to hide content in your messages. Hiding content might cause messages to be marked as spam
So the question “how much spintax is too much” cannot be answered from the rulebook, because the rulebook does not mention it. It can be narrowed to the one thing spinning measurably changes: how many of your recipients receive the same message. That number, and what it costs to move it, are below.
One email, five hundred sends
The email is the shape every outreach guide teaches: a subject line, an opener that names the company, a value line, a proof line, a call to action, and a signature block with two links. It has 24 places where a synonym group can be switched on, three options each, in the order a copywriter would add them, subject and opener first. The recipients are 500 pairs of first name and company, a plausible day for one sending domain, taken here as the example, and a tenth of the threshold above. The engine is the open @spintax/core; the whole experiment is one file, linked at the end.
Two sends count as identical when they are the same text, subject line included, once the name and the company are taken out, the comparison this experiment uses; what a real filter compares is not published.
| Live groups of three | Messages on paper | Distinct messages among 500 sends | Sends whose text someone else also got |
|---|---|---|---|
| 0 | 1 | 1 | 500 |
| 2 | 9 | 9 | 500 |
| 4 | 81 | 81 | 498 |
| 6 | 729 | 371 | 231 |
| 8 | 6,561 | 483 | 32 |
| 10 | 59,049 | 500 | 0 |
The last column is the one nobody quotes. The first two groups sit in the subject line, so at two groups every body is still identical and only the subject varies. Four groups of three, the low end of the usual advice, give 81 messages, and 498 of the 500 recipients hold one that someone else also got. Six groups still leave 231 of them sharing. The count is not luck: for C messages and N sends the expected number of distinct messages is approximately C times one minus e to the power of minus N over C, the formula the product’s own cold email page derives for 20,000 sends, and at 500 it predicts 362, 481 and 498 for the last three rows against 371, 483 and 500 measured.
The group count your volume needs
Turn the same arithmetic around and it says how many groups a sending volume needs before the expected number of identical pairs drops below one:
| Sends per day | Groups of three | Messages on paper |
|---|---|---|
| 200 | 10 | 59,049 |
| 500 | 11 | 177,147 |
| 2,000 | 14 | 4,782,969 |
| 5,000 | 15 | 14,348,907 |
Against that table the standard advice looks different. Three to five groups is what most vendor guides recommend, and the product page linked above reads that as a ceiling on where word swapping stays safe rather than as a recommendation. Five groups of three is 243 messages. At 200 sends a day that is about 82 pairs of recipients holding an identical message; at 500 a day, about 513. The advice is right about the copy and wrong about the arithmetic, and the gap between ten groups and five is the whole problem: the volume wants twice the variation the prose can carry.
The way to close the gap without a thesaurus is to vary something other than words. A permutation of four items taken two to three at a time is 36 outcomes from one edit, about three groups’ worth, and it changes order and length rather than vocabulary; a conditional changes what a sentence says based on a field in the row. Both are on the product page with the arithmetic worked, and neither runs inside a sending tool, which parses flat braces and nothing else. You render first and send the rendered text.
What spinning never touches
Now the other measurement, which shows one reason synonyms may matter less than the part of a message that never changes. Take every send and count how much of each message is text that appears in 95% or more of the other sends.
| Live groups of three | Share of each message identical across 95% of sends |
|---|---|
| 0 | 100.0% |
| 8 | 68.4% |
| 24 | 7.5% |
At 24 groups, every sentence spun, 7.5% of each message is still identical across almost every send. That 7.5% is the signature block: the sender’s name, the company, and the two links, the booking page and the unsubscribe. The unsubscribe link the requirements demand sits in that block; the rest of what they demand, authentication and the complaint rate, sits on the domain. What the filters weigh beyond that is not published; what is published concerns the part no synonym touches.
Spinning, then, is insurance against one specific thing, a text fingerprint, and it is worth exactly what that fingerprint is worth to a filter whose weights nobody outside Google and Microsoft knows. That is not an argument against it. It is the reason to stop adding groups once the first table is satisfied, because past that point the cost side starts.
What it costs
The cost is the copy. Two things go wrong as groups multiply, and only one of them can be caught by a machine.
The first is a word landing twice in a short span because two neighbouring groups happened to pick it. The n8n node for spintax ships a lint for exactly this, a six word window, function words excluded, and its language neutral half is re-implemented in the measurement file. On this email it finds nothing up to four groups, and from eight groups on it flags 6.6% of renders: the opener’s “is growing the team” three words before the value line’s “growing teams”. Each flagged render is a message with a repetition that can make it sound mechanical, which is the one impression the whole exercise exists to avoid, and 6.6% of 500 is 33 recipients a day.
The second cannot be caught. Here is the same email, seed 7, with all 24 groups live:
We work with companies at your stage cut ramp-up time.
Every option in every group was fine on its own. “We help teams like yours cut onboarding time” is a sentence; “We work with companies at your stage cut ramp-up time” is not, because after “we work with” the next verb needs “to” in front of it, the template author did not notice, and this lint cannot, since agreement between two slots is not a rule it checks. The fix is a habit rather than a tool: fork the smallest span that differs, and read twenty renders, not one. The product page lists both under “before you send”.
Where the line runs
| Groups of three | What it does at 500 sends a day |
|---|---|
| 0 to 3 | one message, or a handful; the fingerprint is intact and the copy is yours |
| 4 to 6 | 81 to 729 messages; at six, 231 of 500 recipients still share one with someone |
| 10 to 11 | fewer than one identical pair expected at 11; the measured run at 10 had none |
| more than the table needs | nothing further for the fingerprint, more repeated words, more sentences no option set can carry |
| any group whose options are not interchangeable in the sentence | a broken email at some seed, however few groups there are |
Too much spintax is more groups than your daily volume needs, or one group whose options do not agree with the words around them. Too little is fewer than the table, if a shared message is what you are guarding against; whether it matters to a filter is not something this article can measure. The vendor rule of three to five is neither: it is the right amount of prose and half of the eleven groups that 500 sends a day need.
Where it breaks
Everything measured here is text. None of it is deliverability. What Gmail or Outlook do with 500 identical messages from an authenticated domain with a low complaint rate is not published, and the vendor numbers in circulation, inbox placement rising after spintax was added to subject lines, are the vendors’ own measurements on their own customers. This article does not add to them and does not repeat them as findings.
The lint catches repeated words and bad joins, and misses grammar between slots by design. The birthday arithmetic assumes the engine draws uniformly, which the measured columns confirm within a few messages, and it says nothing about whether a filter compares whole messages, sentences, or the 7.5% that 95% of sends share. The same shingle arithmetic on web pages, where the reader of the pool is Google rather than a spam filter, is in the scaled content abuse article.
Where the manual path runs out
For one template and a spreadsheet of 500 rows, the file linked here renders the pool, counts the identical messages and flags the repeated words in about a second, and reading twenty of the renders by hand is ten minutes:
npm install @spintax/core@0.6.1
node measure.mjsThe file is measure.mjs. It stops being enough when the template changes weekly, the list arrives from a CRM, and the sends go out from a tool that only understands braces. That is the cold email bridge on spintax.net: rows in, a rendered subject and body per row out, with the seed fixed per recipient, the lint run on every render and the uniqueness of the pool measured before anything reaches the sending tool. The engine underneath is the package this article measured with. When the channel is a contact form rather than mail, and a person has to press Send on every page, the same engine runs in a browser extension.