Can you spoof a security vendor? We scanned 40

We checked the email authentication of 40 security companies — password managers, VPNs, identity providers, application-security scanners, and the recon firms that map everyone else's attack surface. The good news: as a group they are better than average. 33 of 40 enforce DMARC, meaning a forged message using their domain gets quarantined or rejected. The awkward news: seven of them can still be spoofed, including two companies whose entire business is scanning the internet for exposure — and nine in ten skip SMTP transport security entirely.

None of this is a hack. It is all published in DNS, readable by anyone in seconds.

The headline numbers

Across the 40 domains:

• 95% publish DMARC (38/40), and 82.5% enforce it at p=quarantine or p=reject (33/40).
• 40% are at full p=reject (16/40) — the strongest setting. Another 42.5% sit at p=quarantine (17/40), one step short.
• 17.5% are spoofable — 5 at p=none (monitoring only, no protection) and 2 with no DMARC at all (7/40).
• 37.5% have no DKIM signature we could detect (15/40).
• Only 10% publish MTA-STS, and the same 10% publish TLS-RPT (4/40 each) — the records that force and report encrypted SMTP delivery.

So the DMARC story is strong and the transport-security story is almost non-existent.

The spoofable seven

These seven left their domain at p=none or with no DMARC, so a phishing email forging their "From:" address is delivered without interference:

censys.io · shodan.io · keeperpasswordmanager.com · truffle-security.com · torproject.org · tunnelbear.com · zerotier.com

The two that stand out: Shodan and Censys are the internet-scanning services security teams use to find exposed infrastructure — and their own domains carry no DMARC enforcement. Keeper is a password manager, and TruffleSecurity builds a secrets-scanner; both are exactly the brands an attacker would want to impersonate in a credential-phishing email.

To be fair, p=none is a legitimate first step — you publish it, collect aggregate reports for a few weeks, then move to quarantine and reject. The point is not that any of these is "insecure" today; it is that a security vendor staying at p=none is leaving the easiest, most-impersonated attack open longer than you'd expect.

The ones doing it right

Credit where it's due. Sixteen are at full p=reject, including bitwarden.com, okta.com, yubico.com, gitguardian.com, tailscale.com, mullvad.net, dashlane.com and duo.com. And four go further and publish MTA-STS to force encrypted delivery: hardenize.com, signal.org, tutanota.com and yubico.com — YubiKey being the only vendor in the set that does both. That's the full stack: enforce DMARC, and require TLS in transit.

The transport-security blind spot

The most consistent gap is not DMARC — it's what happens to mail in transit. MTA-STS tells senders "only deliver to me over TLS, and only to these hosts"; TLS-RPT reports when that fails. Both are cheap DNS + policy files. Yet 36 of 40 security vendors — 90% — publish neither. A group that sells encryption and endpoint protection has, almost universally, not closed the downgrade-to-plaintext path on its own inbound mail.

DKIM is patchier than you'd think

DKIM signs the message body so a receiver can prove it wasn't altered and really came from you. We could not detect a DKIM signature on 15 of the 40 (37.5%) — including a few of the VPN and privacy brands. DKIM detection from the outside is imperfect (selectors vary and aren't always discoverable), so treat this as a floor, not a verdict — but it's a bigger gap than a security-vendor cohort should have.

Check your own domain

The whole point is that this is checkable from the outside in seconds — which means an attacker has already looked, and so has your next enterprise customer's security review. See where any domain stands:

Check a domain's DMARC →

The full per-domain ranking for this cohort — every vendor's SPF, DKIM, DMARC and MTA-STS side by side — is on the security-vendors leaderboard. If your own domain is on it and the row isn't clean, the fix is usually an afternoon: move DMARC off p=none, and publish an MTA-STS policy.