Spoofability verdict for theatlantic.com
No - theatlantic.com is not practically spoofable.
See the math
The Atlantic has built a straightforward, well-executed email authentication posture that closes off the most practical spoofing routes.
- DMARC policy=reject (enforced): Any email claiming to be from @theatlantic.com that fails DMARC checks will be rejected outright by receiving mail servers. This is the strongest possible DMARC stance and prevents attackers from bypassing authentication altogether.
- SPF hardfail (-all): SPF explicitly denies mail from any IP not on The Atlantic's whitelist (Google, Zendesk, Mailgun), with no softfail escape hatch. Combined with DMARC policy=reject, this stops attackers from using arbitrary sending infrastructure.
- DKIM at 5 selectors (google, s2, s1, protonmail, protonmail2): Multiple active DKIM signing keys detected, showing The Atlantic rotates keys across different senders (Google workspace, Proton, and internal selectors). This redundancy doesn't weaken security—it just means legitimate mail can come from different systems.
- MTA-STS missing: MTA-STS (which forces encrypted connections during mail transit) is not configured. This is a gap in defense-in-depth, but doesn't meaningfully weaken The Atlantic's anti-spoofing posture since DMARC reject already stops impersonation at the inbox level.
What this means practically
An attacker cannot realistically send email from @theatlantic.com and have it reach inboxes. SPF's hardfail blocks any unauthorized sender IP. If that somehow passes, DMARC's policy=reject will catch the failure and the receiving mail server will reject the message. This combination is enforced across the board—no exceptions or percentage-based bypasses. MTA-STS absence means an attacker *could* theoretically intercept mail in transit via a downgrade attack, but they still cannot impersonate The Atlantic to end users.
Bottom line: The Atlantic is not practically spoofable; their authentication stack works and is deployed at full strength.
What we measured
Enforced
DMARC policy
p=reject
DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.
Enforced
SPF posture
-all (hardfail)
SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.
v=spf1 ip4:129.33.240.133 ip4:208.95.135.43 include:_spf.google.com include:mail.zendesk.com include:mailgun.org -all
Enforced
DKIM presence
found at 5 selectors
DKIM key found at selectors: google, s2, s1, protonmail2, protonmail.
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 an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.