Spoofability verdict for threads.net
Yes - threads.net is spoofable today.
See the math
Threads has chosen not to deploy any of the four standard email authentication layers. This leaves threads.net wide open to anyone sending mail that claims to come from Threads.
- DMARC: missing: No DMARC record published. Without this, receivers have no instruction on what to do with mail that fails SPF or DKIM—most will accept it anyway.
- SPF: ~all (softfail): SPF is present but uses a softfail (~all) instead of a hardfail (-all), meaning failed SPF checks generate a warning, not a rejection. Receivers typically ignore softfails.
- DKIM: none found: No DKIM selectors detected across 22 common probes. Threads is not cryptographically signing outbound mail, so recipients cannot verify authenticity at all.
- MTA-STS: missing: No MTA-STS policy. This doesn't affect spoofing directly, but its absence means inbound mail routing to threads.net cannot be protected against man-in-the-middle downgrade attacks.
What this means practically
An attacker can send mail from any address @threads.net, and most mail servers will accept it. The SPF softfail will not stop delivery; DKIM is absent entirely; and DMARC provides no enforcement instruction. Depending on the receiving mail provider's heuristics, spoofed Threads mail may land in inboxes or spam folders, but nothing here prevents it from being delivered. Phishing campaigns impersonating Threads support or security alerts are practical threats.
Bottom line: Threads has deployed none of the standard email authentication controls—this is a complete absence of spoofing defense, not a partial one.
What we measured
Open
DMARC policy
missing
No DMARC record found. Receivers have no policy to apply.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 a ~all
Open
DKIM presence
no key found at common selectors
No DKIM key found at any of the 22 common selectors. (Your domain may publish a DKIM key at a less-common selector - this is a heuristic, not exhaustive.)
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Publish a DMARC record. Start at p=none with a rua= report destination to gather data, then progress to p=quarantine and p=reject.
- Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
- Confirm DKIM is configured. We didn't find a key at the common selectors; if you do publish DKIM, the selector you use isn't in our probe list - that's fine, but worth verifying with your mail provider.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.