DEV Community: Kacper

I turned a 30-second security check into an app you can connect to Claude or ChatGPT

Kacper — Mon, 24 Aug 2026 08:43:33 +0000

Last week I checked the email security of eight automation agencies and seven of them could be spoofed. The check itself is two DNS lookups and takes about thirty seconds, which raises an obvious question: if it's that cheap, why does almost nobody run it?

Because it's thirty seconds you have to remember to spend, on a thing that produces no visible symptom when it's broken. Nobody wakes up thinking "I should verify my SPF record today."

So I moved the check to where the questions already get asked. It's now an MCP server you can connect to Claude or ChatGPT, and then just ask.

What it does

Connect it, then type something like "can people spoof email from stripe.com?" and the assistant runs the actual DNS lookups and comes back with a graded report:

## Email security report: example.com
**Grade: D — effectively spoofable**

| Check | Result |
|---|---|
| MX | 10 mx01.example-host.com. |
| SPF | v=spf1 include:_spf.google.com ~all |
| DMARC | v=DMARC1; p=none |
| DKIM | selectors: google |

### Problems (1), most severe first
- **[MEDIUM]** DMARC is p=none — monitoring mode. Receivers check
  alignment and then do nothing on failure; a forged invoice from this
  domain lands like real mail.
  - Fix: after ~2 clean weeks of reports, move to p=quarantine.

There's a second tool that compares up to five domains side by side, which is uncomfortable in a useful way if you run it on yourself and your competitors.

Connecting it

It's authless — it reads public DNS and stores nothing, so there's no signup, no key, no OAuth.

Claude: Settings → Connectors → Add custom connector, and paste:

https://deliverability-doctor.deliverability-doctor.workers.dev/mcp

ChatGPT: same URL as a custom MCP connector.

Then ask it about any domain in plain language.

The three findings it's actually looking for

No SPF at all. Anyone can send as you, today. One of the eight agencies I scanned was in this state on a Google-hosted domain.

More than one SPF record. This is the one that surprises people. Per RFC 7208, a receiver that finds two v=spf1 records is required to return permerror — and most treat permerror as no SPF at all. So the company that carefully added a second record for their new mailing tool didn't add protection, they deleted it. It happens constantly and it's invisible unless you look.

p=none DMARC. The sneaky one, because it looks handled. It's monitoring mode: receivers check alignment, then do nothing on failure. Six of my eight had it. A p=none with no rua= address is the worst version — not enforcing, and not collecting the reports that would tell you spoofing is happening.

Building it, briefly

Two things I'd do again.

I used DNS-over-HTTPS rather than Node's dns module. That decision looked like fussiness at the time; it meant the same analyzer file ran unchanged locally and then on Cloudflare Workers when I deployed, because Workers has no dns module. Choosing the more portable primitive early cost nothing and saved a rewrite.

And I tested the analyzer against domains whose answers I already knew before wiring up any protocol. That caught two real bugs. gmail.com was being flagged for a missing all mechanism — but its SPF ends in redirect=, which validly replaces all, so the tool was wrong and Google was right. And a domain that doesn't exist was being graded F — spoofable today, which is nonsense: NXDOMAIN means there's no domain to spoof. Both were fixed before the server ran once. Neither would have been caught by testing against domains I hadn't already characterised.

Honest limits

DKIM detection probes seven common selectors, so a custom selector reads as "not found" — that's why it never counts against the grade. The tool sees DNS only: it can't tell you whether your mail actually lands in inboxes, only whether receivers have been told who's allowed to send. And a grade of A means the authentication records are right, not that your sending reputation is good.

If you'd rather not connect anything, the free version is still two commands:

nslookup -type=TXT yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

Run those before you connect anything of mine, or anyone else's.

And if the check finds problems you would rather hand to someone: I do a one-page written version - your domain, exactly what is wrong, the exact records to paste, within 24h - for $39: https://niekonieczny.gumroad.com/l/spoofcheck. The free tool above is the same diagnosis; the $39 is for having it explained and turned into a to-do list.

— Kacper Konieczny, Łódź

I checked the email security of 8 automation agencies. 7 were spoofable.

Kacper — Sat, 22 Aug 2026 22:03:16 +0000

I was cold-emailing automation agencies last week, looking for subcontract work. Before I contact any company I run one check on their domain — SPF and DMARC, straight from public DNS, about thirty seconds each. It started as a way to find something genuine to open with. It turned into an uncomfortable little dataset.

Eight agencies. US, Canada, Australia, UK. All of them sell automation, integration or AI services — companies whose entire pitch is that they will wire your systems up properly.

Seven of the eight can be spoofed.

Agency	SPF	DMARC	Spoofable?
A	strict	p=none	effectively yes
B	soft	p=none, no reporting	yes, and they'd never find out
C	soft	p=none	effectively yes
D	missing	missing	completely
E	strict	p=none	effectively yes
F	strict	p=none	effectively yes
G	ok	p=none	effectively yes
H	strict	p=quarantine	no

No names. I emailed every one of them their own result privately, for free, before writing any of this, and one of them is only in the table because they wrote back and told me to get lost, which is fair enough.

Company D is the one that bothers me. A working consultancy with real clients, on a Google-hosted domain, with no SPF record at all. Anyone on the internet can send mail as them today.

p=none is the trap

p=none is the one worth understanding, because it looks like the responsible option and isn't. It's monitoring mode. Receiving servers check whether the mail aligns, and then — on failure — do nothing. A forged invoice from billing@your-agency.com arrives with exactly the same standing as your real mail. Six of my eight had it, which means six of them have almost certainly ticked "DMARC" off a list at some point and moved on.

The version with no rua= is worse than useless, because now you're not enforcing and not collecting the reports that would tell you it's happening.

Check yours

nslookup -type=TXT yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

If the first one returns nothing containing v=spf1, anyone can send as you, and that is a today problem rather than a roadmap problem. If you have SPF but no DMARC, you've told receivers who is allowed to send but not what to do about anyone who isn't. If you have p=none with a rua= address, you're in a reasonable place — read a couple of weeks of reports, confirm your real senders pass, then move to p=quarantine. If you have p=none with no reporting, add the reporting address first; you can't tighten safely without knowing what you'd break.

One more thing worth knowing: if you have more than one v=spf1 record on the same domain, that isn't extra protection, it's a permanent error. Per RFC 7208 a receiver seeing two SPF records is required to return permerror, and most treat that as "no SPF at all". It happens constantly when a company adds a second sending tool and pastes in a second record rather than merging into the first.

The whole fix is two DNS records and no budget. It is genuinely boring. That's why nobody does it.

Disclosure

I sell this — a written deliverability audit, 48 hours, $99: https://niekonieczny.gumroad.com/l/vscjt. The two commands above are the free version and for a lot of you they are the entire answer. Run them before you pay anyone, including me.

If you want to know how I work before you'd trust me with anything: I published the two bugs my own acceptance tests caught in my own product before launch — https://dev.to/kacper_35e1f61a8f41c3886b/my-own-acceptance-tests-caught-2-real-bugs-in-my-product-before-a-single-customer-saw-it-598b

— Kacper Konieczny, Łódź

My own acceptance tests caught 2 real bugs in my product — before a single customer saw it

Kacper — Fri, 21 Aug 2026 15:01:25 +0000

I sell a small pack of n8n workflows built around one idea: automation should ship with its own acceptance tests, and sends should stay disabled until those tests pass. Before listing it, I did the only honest thing you can do with a claim like that — I ran my own tests against my own product on a live n8n instance. They failed. Twice. This is the story, because both bugs are ones your workflows probably have too.

Bug 1: `require('crypto')` doesn't exist where you think it does

My intake workflow deduplicates submissions with a hash key. Locally-authored, looked clean, "obviously worked." On a stock n8n install it died instantly:

Module 'crypto' is disallowed

n8n's Code node sandboxes away Node builtins by default. If your dedupe, signing, or ID logic uses require('crypto'), it works on your tweaked dev instance and breaks on your client's stock one. Fix: a pure-JS hash (I used double FNV-1a — dedupe keys don't need cryptographic strength) or enabling builtin access consciously via env config — as a documented decision, not an accident.

Bug 2: your env-var read is a silent crash on stock installs

Every "armed/disarmed" gate in the pack reads an env var: delivery stays OFF until AF_DELIVERY_URL exists. Except on default installs, N8N_BLOCK_ENV_ACCESS_IN_NODE makes $env access THROW — so my fail-safe gate was actually a fail-crash gate. The fix is boring and important:

let url = '';
try { url = $env.AF_DELIVERY_URL || ''; } catch (e) { url = ''; }

Fail-safe now means: on any stock install, the workflow imports, runs, and refuses to send — instead of erroring out and teaching the buyer your stuff is broken.

Why this is a sales pitch (honestly)

Both bugs share a shape: they're invisible until the workflow runs somewhere you didn't build it. A demo can't catch them. A screenshot can't catch them. Only acceptance tests executed on a clean instance can — which is why every workflow I ship has its criteria written on the canvas in a sticky note, and a checklist the buyer runs before trusting anything.

The tests cost me an evening and two embarrassing bugs. They also mean the thing I sell is the thing I verified — and that discipline is the actual product.

(The full acceptance-first pack is at https://niekonieczny.gumroad.com/l/imbsml — and the error handler alone at https://niekonieczny.gumroad.com/l/uwxmpx.)