Spoofability verdict for dropbox.com
Maybe - dropbox.com is partially protected.
See the math
Dropbox has invested in DMARC reject policy and SPF infrastructure, but left critical gaps that allow spoofing to slip through. The weak points aren't oversights—they're architecture choices that create practical risk.
- DMARC p=reject at 100%: Dropbox enforces reject-on-failure at 100% of traffic, meaning receiving systems should discard authentication-failed mail. This is the strongest DMARC posture available and blocks most naive spoofing.
- SPF softfail (~all): Despite the strong DMARC, SPF ends with softfail rather than hardfail. Softfail (tilde) means 'preference not to accept' but receivers treat it as advisory. This undermines the reject policy and is the visible weak point.
- DKIM: no selectors found: Probing 22 common DKIM selector patterns found nothing. Either Dropbox uses completely non-standard selector names or DKIM isn't deployed. This removes a second layer of signature-based verification.
- MTA-STS: missing: No MTA-STS policy detected. This leaves the connection between mail servers unencrypted and unverified, allowing man-in-the-middle interception of legitimate Dropbox mail in transit.
What this means practically
An attacker can send mail appearing to come from dropbox.com if they control an IP not in Dropbox's SPF list. Gmail and Microsoft 365 will often honour the DMARC reject policy, but smaller mail systems or legacy setups may accept the softfail and deliver the spoofed message to inboxes. The absence of DKIM means there's no cryptographic proof the email came from Dropbox's actual infrastructure. MTA-STS absence means an attacker on the network path can intercept real Dropbox mail and modify it before it reaches the recipient.
Bottom line: Dropbox has done the high-visibility work (DMARC reject) but left the implementation incomplete (softfail SPF, no DKIM, no MTA-STS), creating a false sense of security that doesn't hold up against determined or sophisticated spoofing attempts.
What we measured
Enforced
DMARC policy
p=reject
DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 ip4:45.58.64.0/20 ip4:185.45.8.0/22 ip4:162.125.0.0/16 ip4:199.47.216.0/22 ip4:108.160.160.0/20 ip4:205.189.0.0/24 ip4:160.34.15.16/28 ip4:52.5.134.202/32 ip4:205.220.162.87/32 ip4:205.220.174.83/32 ip4:167.89.98.146/32 ip4:167.89.89.46/32 ip4:167.89.96.134/32 ip4:159.183.109.97/32 ip4:149.72.220.85/32 ip4:159.183.15.144/32 ip4:159.183.2.51/32 ip4:159.183.2.58/32 ip6:2620:c6:8000::/48 include:amazonses.com include:_spf.google.com include:mail.zendesk.com include:mktomail.com include:rp.oracleemaildelivery.com exists:%{i}._spf.mta.salesforce.com ~allOpen
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
- 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.