Spoofability verdict for cloudflare.com
No - cloudflare.com is not practically spoofable.
See the math
Cloudflare has set up a strong, belt-and-suspenders email authentication posture: DMARC reject with 100% enforcement and a hardfailing SPF record with no exceptions. This is how a technology vendor should do it.
- DMARC policy=reject at 100%: Any email claiming to come from cloudflare.com that fails DMARC authentication (either SPF or DKIM) will be rejected by compliant receivers. No percentage carve-out; no soft-fail escape hatch.
- SPF -all (hardfail) with 7 IP ranges: SPF explicitly rejects any sender IP not explicitly listed. Cloudflare authorizes only their own networks (199.15.212.0/22, 173.245.48.0/20) and specific trusted vendors (Google, Mailchimp, Mandrill, Zendesk, Salesforce). The -all terminator means anything else bounces.
- DKIM at 3 active selectors (mandrill, k1, s1): DKIM adds cryptographic signature verification on top of SPF. Multiple selectors provide flexibility for key rotation without breaking email flow. Attacker cannot forge a valid DKIM signature without the private key.
- MTA-STS missing: MTA-STS would enforce TLS for inbound mail delivery, preventing downgrade attacks on the SMTP connection itself. Its absence is a minor gap but does not significantly affect spoofability given the strength of DMARC and SPF.
What this means practically
An attacker cannot practically impersonate cloudflare.com. Spoofed emails claiming to come from this domain will fail SPF (wrong source IP), fail DKIM (no private key), and therefore fail DMARC, triggering outright rejection at any competent mail server. Even phishing emails that manually set a fake From: header will not pass authentication checks; they will be rejected or flagged as suspicious.
Bottom line: Cloudflare has built a fortress around their email identity, with no practical spoofability surface.
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:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all
Enforced
DKIM presence
found at 3 selectors
DKIM key found at selectors: mandrill, k1, s1.
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.