Spoofability verdict for spotify.com
No - spotify.com is not practically spoofable.
See the math
Spotify has built a straightforward, effective defense against email spoofing: a hard reject on all non-authenticated mail, backed up by multiple DKIM selectors and tight SPF controls.
- DMARC policy=reject (100%): Spotify enforces authentication on all outbound mail with no exceptions. Any email claiming to come from spotify.com that fails SPF or DKIM will be rejected outright by receiving mail servers.
- SPF with softfail (~all): SPF uses a softfail, not a hard fail. This is common for large organisations with many legitimate senders (Google, Mailchimp, Salesforce, Hubspot). Softfail means non-matching IPs are discouraged but not blocked, which is reasonable given their sender complexity.
- DKIM at 5 selectors (k1, s2, google, s1, mandrill): Multiple DKIM selectors mean multiple signing keys are in use—likely one per sending platform (Google Workspace, Mandrill, Salesforce, etc.). This provides key rotation redundancy and makes wholesale spoofing much harder.
- MTA-STS absent: MTA-STS adds transport-layer encryption enforcement but is still optional and gaining adoption. Its absence is not a weakness for spoofability, only for in-transit interception.
What this means practically
An attacker cannot realistically spoof Spotify mail. DMARC reject at 100% means any forged email will be rejected at the receiving mail server before a user even sees it. SPF and DKIM work together: SPF checks the sending IP; DKIM cryptographically verifies the email signature. An attacker would need to either own one of Spotify's authorized IPs (very hard), or forge DKIM signatures (cryptographically unfeasible without stealing private keys). Real-world outcome: gmail.com, outlook.com, and enterprise mail systems will refuse these emails and never deliver them to inboxes.
Bottom line: Spotify's strict DMARC reject policy backed by SPF and multiple DKIM selectors makes this domain effectively unspoofable in practice.
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:80.76.146.172 ip4:80.76.146.173 include:_spf.google.com include:servers.mcsv.net include:_spf.salesforce.com include:_spf.netigate.se include:21894833.spf06.hubspotemail.net ~all
Enforced
DKIM presence
found at 5 selectors
DKIM key found at selectors: google, mandrill, s2, 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
- Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.