Spoofability verdict for treasury.gov
Maybe - treasury.gov is partially protected.
See the math
US Treasury has deployed DMARC p=reject, which is the right call for a high-value target, but it's undone by a redirect in SPF that bypasses core protections and a complete absence of DKIM signing.
- DMARC p=reject (enforced): The reject policy tells receiving mail servers to discard unauthenticated messages claiming to be from treasury.gov. This is the strongest posture and shows intent to defend against spoofing.
- SPF redirect to _spfnew.treasury.gov (partial): SPF uses a redirect mechanism instead of a direct -all hardfail. Redirects are weaker and create a chain of trust that attackers can sometimes exploit; a -all qualifier would be stronger and more readable.
- DKIM: no selectors found (open): Despite probing 22 common selector names, no DKIM records exist. DKIM cryptographically signs outbound mail; without it, SPF and DMARC alone cannot authenticate mail that's already been forwarded or relayed.
- MTA-STS: missing (open): MTA-STS enforces encrypted transit of mail between servers and prevents downgrade attacks. It's missing here, but is less critical than DKIM when DMARC p=reject is already in place.
What this means practically
An attacker can send mail that passes SPF (by spoofing a subdomain or intercepting the redirect) but will fail DMARC authentication at the final hop because there is no DKIM signature to fall back on. Gmail, Outlook, and other major receivers honour DMARC p=reject, so spoofed mail will be rejected outright—which is the intended outcome. However, smaller or misconfigured mail systems, older appliances, or internal forwarding chains may not enforce DMARC strictly, and without DKIM those messages become vulnerable. Treasury's legitimate mail is protected; the risk is primarily to downstream trust.
Context for US Treasury
US Treasury is a high-value target for spoofing (financial fraud, compliance requests, social engineering). The p=reject policy reflects appropriate risk awareness, but the configuration suggests DKIM was either overlooked or not prioritized. This is correctable and worth escalating internally.
Bottom line: Treasury.gov is defended at the DMARC level but has left a gap by omitting DKIM and using SPF redirect instead of a hardfail—a setup that works for major receivers but leaves edge cases exposed.
What we measured
Enforced
DMARC policy
p=reject
DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.
Partial
SPF posture
?all (neutral)
SPF record present but has no terminal mechanism. Behaviour at receivers is unspecified.
v=spf1 redirect=_spfnew.treasury.gov
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
- 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.