A missing `1`, a leading hyphen, `xxx` prefix, or Microsoft Word smart-quotes — and your entire email security policy is silently ignored by every mail server on earth.
1. Microsoft Word smart quotes silently break email security
The admin drafted their SPF record in Microsoft Word, which converted their plain ASCII quote `"` into typographic smart-quotes (bytes `\226\128\156` / `\226\128\157`) and the hyphen before `all` into an en-dash (bytes `\226\128\147`). DNS parsers expect strict ASCII. Every mail server silently discards this record. Their email security is broken because a word processor tried to be smart.
2. Smart-quote byte corruption mangled through a non-UTF-8 system
Another Word/TextEdit victim, but worse. The SPF record is wrapped in corrupted multi-byte sequences (`\195\162\226\130\172\197\147`) representing smart-quotes that were copied into a non-UTF-8 system and mangled before being pasted into DNS. Broken twice over. Their email security is completely nullified.
3. Missing the `1` in `v=spf1` — the entire record is ignored
The SPF record reads `v=spf ip4:213.171.216.0/24...` — they missed the `1` from `spf1`. Because the version string is not specifically `spf1`, every mail server on earth will silently ignore this record entirely. One character. Completely invisible to the domain owner. Their outbound email is unprotected.
4. Leading hyphen invalidates the entire SPF policy
The SPF record starts with `-v=spf1` — a leading hyphen that instantly invalidates the entire policy. Almost certainly a copy-paste that included a preceding `-` from a bullet list or command-line argument. Every mail server ignores this. Their email is unprotected.
-v=spf1 a ip4:91.194.188.143 include:spf.protection.outlook.com ~all
The SPF record reads `xxxv=spf1 include:spf.protection.outlook.com...`. The `xxx` prefix means no mail server will recognise this as a valid SPF record. How `xxx` got there remains one of DNS archaeology's great unsolved mysteries.
6. HTML entity escaping loop destroys a GlobalSign verification token
A broken CMS backend repeatedly re-encoded the GlobalSign token. The original token was quoted. The system escaped `"` to `"`, then escaped the `&` to `&` — six times over. The result `_globalsign-domain-verification="GWm3N1...` is completely unrecognisable to GlobalSign's verification system.
7. Zero-Width Spaces corrupt Google verification — at an SEO agency
Zero-Width Space characters (UTF-8 bytes `\226\128\139`) are hidden inside the Google site verification token, causing it to silently fail. The delicious irony: this is a professional SEO agency whose website cannot pass Google's own domain verification. Their Google Search Console has presumably been inaccessible for years.
8. Zero-Width Space double-mangled through a non-UTF-8 system
A Zero-Width Space was copied, pasted into a non-UTF-8 system which mangled the bytes into replacement characters, and then that corrupted string was pasted into DNS. The bytes `\195\162\226\130\172\226\128\185` are a zero-width space encoded twice over. Broken on two separate occasions by two separate systems.
Another SPF record with a leading hyphen: `-v=spf1 a ip4:213...`. The leading dash makes the version string unrecognisable to every mail server on earth. This domain has no functional SPF protection and is fully vulnerable to email spoofing. This is the second example of this exact mistake we have catalogued in the .co.uk zone.
-v=spf1 a ip4:213.171.216.0/24 include:spf.protection.outlook.com ~all