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ź
Top comments (0)