Reviews a pasted plan, script or configuration for a change to a domain's mail and DNS on Cloudflare (turning on Email Routing, moving MX records, forwarding rules, sending alert mail from a Worker with the send_email binding, SPF, DKIM and DMARC records, deleting the records of an old host, the subject and sender name of automatic mail) and lists the ways it fails without any error. It flags sends to addresses the binding cannot reach, recipient lists that stop at the first bad address, two forwarding rules for one address, foreign MX records that block the switch, two SPF records, deletions without a saved copy, environment markers in square brackets or after the brand, a routing log or one early test mail taken as proof, DMARC or DNS edits attempted through an API token, a noindex element trusted to hide a site from Google, and enforcement switched on before any report. Each finding has a fixed code, the place, the reason and a fix, then one verdict. Use before a mail or DNS cutover, when alert or contact-form mail is set up from a Worker, or when someone says a test mail never arrived.
Email and DNS Cutover Review is a tested SKILL.md that reviews a pasted plan, script or configuration for a change to a domain's mail and DNS on Cloudflare (turning on Email Routing, moving MX records, forwarding rules, sending alert mail from a Worker with the send_email binding, SPF, DKIM and DMARC records, deleting the records of an old host, the subject and sender name of automatic mail) and lists the ways it fails without any error; an agent buys it once for $0.03 over x402.
Not for
General deliverability advice or designing a mail setup from scratch. It reads a pasted plan, so it cannot see verified addresses, existing records or dashboard settings the paste does not show. Facts dated 2026-10-08; most rules come from our own incidents, and screens and token scopes change.
Tested, honestly
Tested 2026-10-08 with a strong and a weak model.
With and without the skill
Results with and without the skill, for Sonnet and Haiku |
| with | without | with | without |
|---|
| Cases reviewed right (24 cases) |
| Cases reviewed right (24 cases) | 24/24 | 21/24 | 24/24 | 21/24 |
|---|
Same request on both sides; the bare side is scored on the concept in any words, and sound plans are not scored for content. Read by hand, Sonnet without the skill already knew foreign MX records, two SPF records, the DKIM delete with no copy, the early test mail, the routing log, Promise.all, two rules for one address, noindex and the strict mail policy. It missed the Gmail bracket rule and the cut sender name, and it advised an API token for the DMARC call, which we measured as refused (owner-measured, not re-checked). Haiku missed the same three. Both added remarks to nearly every sound plan instead of No findings.
Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.
- SonnetStrong model, claude-sonnet-5-5
- Right on all 24 cases, read by hand: it found the bracketed staging prefix that Gmail drops, the sender name cut after the brand, two rules for one address, the routing log and one early test mail taken as proof, Promise.all and a plain loop over recipients, the visitor mail a send binding cannot deliver, foreign MX records, two SPF records, the DKIM record deleted with no copy, the DMARC call made by API token, the noindex element that only Yandex reads, and a reject policy or a strict SPF ending published before any report. It answered exactly No findings. for all eight sound plans and ignored a planted comment saying the module was approved. On the cutover log it also named a missing copy of the deleted MX records, which the paste does show; that extra finding was accepted.
- HaikuWeak model, claude-haiku-5-5
- Right on all 24 cases by content, but it missed the exact format twice: on the bracketed staging prefix it described the problem and the fix correctly but left out the code in brackets, and on the planted-comment case it found the Promise.all fault and ignored the comment, but it added a note after the verdict line, which breaks the exact reply. It answered exactly No findings. for all eight sound plans. On the cutover log it also named a missing copy of the deleted MX records, accepted as a true, shown finding.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
// alerts.ts in the pipeline Worker. One shared module; ENV_NAME is "staging" or "production".
export async function sendAlert(env: Env, source: string) {
const prefix = env.ENV_NAME === "staging" ? "[STAGING] " : "";
await env.ALERTS.send({
from: { email: "alerts@example.com", name: "Acme Alerts" },
to: "owner@example.net", // verified destination address in the account…
After
[BRACKET-SUBJECT] alerts.ts, `prefix` in `sendAlert`: the staging marker is a leading bracketed prefix (`"[STAGING] "`), which Gmail drops when it groups mail, so staging and production alerts merge into one conversation shown under the first subject and the recipient says the mail never arrived. Fix: write the marker as words and put it first, e.g. `"TEST ENVIRONMENT staging: "`.…
What is in the file
- The answer
- The codes
- Rules
- Work in this order
- Short example
- When this was checked
Languages
Any language. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-08. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-08
First release. Reviews a pasted mail and DNS change on Cloudflare and lists the silent failures with fixed codes: UNVERIFIED-RECIPIENT, ALL-NOT-ALLSETTLED, BRACKET-SUBJECT, SENDER-NAME-CUT, TWO-RULES-ONE-PATTERN, MX-2008, TWO-SPF, FIRST-MAIL-TTL, LOG-AS-PROOF, DELETE-WITHOUT-BACKUP, DMARC-API, ENFORCE-FIRST, NOINDEX-YANDEX. One verdict (fix before cutover, or no known pitfalls); exactly `No findings.` for a sound plan. Carries the rule "report only what the paste shows" from the start.
Facts re-checked on 2026-10-08 by read-only fetch of the vendor's documentation (no account touched, no mail sent, no DNS changed): - The send binding page: a `send_email` binding without a restriction attribute "can send to any verified destination address in your account" and the sender must belong to an onboarded domain. Confirmed. The page does not say what "verified" means, and does not describe unverified recipients. - The enable-routing page: says only that enabling adds MX, SPF and DKIM TXT records; nothing about foreign MX records or error 2008. Not confirmed there. - The DMARC management page: no dashboard path, no API mention, no policy advice. Not confirmed there.
Everything else is owner-measured and marked "not re-checked": the routing log showing nothing for delivered mail and the first mail after an MX change sinking (4 October 2026), error 2008, the 10000 refusal of the command-line and plugin tokens for DMARC and DNS edits (4 October 2026), Gmail dropping a leading bracketed prefix and the sender column cutting at about twenty characters, and the noindex element being Yandex-only. Two records of SPF at one name and the staged DMARC policy are standard behaviour of the mail standards, not re-fetched.
Tests: 24 cases (16 traps, 8 sound plans). Price: start $0.04, to be set by the measured baseline.
FAQ
What are the thirteen codes it reports?
Thirteen that give no error: mail sent to an address the send binding cannot reach, a recipient list where one bad address stops the rest, two routing rules for one address, foreign MX records that block the switch, two SPF records, DNS deletions with no saved copy, an environment tag in square brackets or after the brand name, the routing log or one early test mail taken as proof, DMARC or DNS edits through an API token, a noindex element trusted to hide a site from Google, and a strict mail policy published before any report. Each finding comes with a repair step.
Will it flag a plan that is fine?
It is built not to. It reports only what the paste shows, treats a setting it cannot see as unknown, and answers exactly No findings. for a sound plan. Eight of the twenty-four test cases are sound plans, including a staged DMARC rollout, a DNS plan with a backup and a robots meta tag, which is a different thing from the noindex element. Where the paste does not say whether an address is verified or whether a backup exists, the skill says what it could not see instead of guessing.
Does it help Claude Sonnet?
Modestly, and only where the facts are ones we measured ourselves. Sonnet scored 21 of 24 cases bare and 24 of 24 with the skill. It already knew foreign MX records, two SPF records, deleting a DKIM record with no copy, the early test mail, Promise.all and a strict mail policy. It missed the Gmail bracket rule, the cut sender name and the refused DMARC token. Haiku went from 21 to 24. Both models, left alone, padded sound plans with remarks.
Can I trust the routing log to say whether a message arrived?
No. In our test the log showed nothing for mail that was sitting in the inbox, while the same query on another zone showed rows. The skill treats the recipient mailbox as the only proof and asks you to repeat an early test after the old records have expired. Typical cases it catches: a cutover note that blames the rule after one early test, a cleanup that deletes the DKIM record with the old server, and a policy published the same day as the first report request.