Spoofability verdict for sentinelone.com
No - sentinelone.com is not practically spoofable.
See the math
SentinelOne has built a genuinely hardened email authentication posture. This is what a security-conscious organisation looks like when it prioritises both protection and operational reality.
- DMARC p=reject (fully enforced): SentinelOne sends DMARC p=reject with no percentage carve-out—every message from sentinelone.com must pass SPF or DKIM alignment, or recipients discard it. This is the hardest possible stance and eliminates the 'open door' that p=none or p=quarantine policies leave.
- SPF -all hardfail with 40+ authorised IPs: The SPF record explicitly denies any server not on the whitelist (the -all flag). SentinelOne has carefully registered ~40 IP addresses and includes trusted third-party mailers (Google, Zendesk, Marketo, Salesforce, Atlassian), showing they've thought through legitimate sender sources.
- DKIM at 2 selectors (k2, google): SentinelOne is signing with at least two DKIM keys. Multiple selectors allow key rotation without dropping coverage and provide redundancy. The 'google' selector suggests Gmail integration.
- MTA-STS missing: MTA-STS enforces TLS in transit and prevents downgrade attacks. Its absence is a minor gap, but given the strong DMARC and SPF posture, it's not a dealbreaker for preventing spoofing—though it would harden the channel further.
What this means practically
An attacker cannot forge a convincing SentinelOne email to anyone running modern mail filters. Gmail, Outlook 365, Proofpoint, and other carriers will reject or hard-fail any message claiming to be from sentinelone.com unless it genuinely originates from one of the ~40 authorised IPs and passes DKIM or SPF alignment checks. Even internal or poorly-filtered recipients have low risk: the message would arrive unsigned or unsigned-plus-failed-SPF, a red flag in any mail client's authentication header.
Bottom line: SentinelOne has eliminated practical spoofability through defense-in-depth: DMARC reject, SPF hardfail, multi-selector DKIM, and granular IP whitelisting.
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 include:_spf.google.com include:mail.zendesk.com include:mktomail.com include:_spf.salesforce.com include:_spf.atlassian.net ip4:35.80.141.6/32 ip4:44.229.121.55/32 ip4:208.185.235.0/24 ip4:148.59.108.0/23 ip4:148.59.106.0/23 ip4:10.183.25.18/32 ip4:10.176.20.243/32 ip4:10.226.205.244/32 ip4:35.91.229.248/32 ip4:35.162.29.198 ip4:44.234.245.33/32 ip4:100.20.176.7/32 ip4:54.152.14.251/32 ip4:54.173.58.140/32 ip4:52.204.40.143/32 ip4:54.84.4.28/32 ip4:35.173.106.12/32 ip4:54.156.212.29/32 ip4:18.184.189.217/32 ip4:18.197.77.147/32 ip4:18.184.105.23/32 ip4:18.185.165.73/32 ip4:18.185.181.167/32 ip4:18.195.130.52/32 ip4:172.27.0.101 ip4:10.192.91.198 ip4:54.77.246.118/32 ip4:52.215.76.168/32 ip4:52.208.90.157/32 ip4:159.183.71.12/32 ip4:198.244.59.30/32 ip4:198.244.59.33/32 ip4:198.244.59.35/32 ip4:167.89.97.235 ip4:168.245.34.51 ip4:43.228.187.74/32 ip4:43.228.185.67/32 ip4:149.72.214.81/32 ip4:168.245.40.122/32 ip4:54.240.116.11/32 ip4:54.240.116.27/32 ip4:76.223.147.27/32 ip4:76.223.147.28/32 ip4:76.223.147.29/32 ip4:76.223.147.31/32 ip4:76.223.147.32/32 ip4:76.223.147.33/32 ip4:76.223.147.34/32 ip4:76.223.147.35/32 ip4:76.223.147.36/32 ip4:76.223.147.37/32 ip4:76.223.147.38/32 ip4:76.223.147.39/32 ip4:76.223.147.40/32 ip4:76.223.147.41/32 ip4:76.223.147.42/32 ip4:76.223.147.43/32 ip4:76.223.147.44/32 ip4:76.223.147.45/32 ip4:76.223.147.46/32 ip4:76.223.147.47/32 ip4:76.223.147.48/32 ip4:76.223.147.49/32 ip4:76.223.147.50/32 -all
Enforced
DKIM presence
found at 2 selectors
DKIM key found at selectors: google, k2.
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.