Spoofability verdict for robinhood.com
Maybe - robinhood.com is partially protected.
See the math
Robinhood has built meaningful email authentication foundations—but left a critical gap that weakens them. This is the trap of partial enforcement: good signals that don't quite work together.
- DMARC p=quarantine (partial alignment): Robinhood enforces a quarantine policy, which tells receivers to isolate unauthenticated mail rather than deliver it. However, alignment is set to 'relaxed' (adkim=r, aspf=r), meaning a mail can pass DMARC even if sent from a subdomain—this narrows the real-world protection.
- SPF ~all (softfail): SPF uses a softfail qualifier (~all) instead of hardfail (-all). This tells receivers 'mail from unlisted IPs might still be legitimate'—essentially an advisory rather than a rule. Attackers spoofing robinhood.com will often pass SPF checks at permissive receivers.
- DKIM enforced (4 selectors found): Robinhood has DKIM keys deployed across multiple selectors (google, mandrill, s1, s2), indicating mature multi-vendor signing. If a mail is properly signed, DKIM cryptographically proves origin—the strongest single signal here.
- MTA-STS missing: MTA-STS encrypts mail in transit between servers and flags certificate mismatches. Its absence means an attacker can intercept or redirect Robinhood's outbound mail in flight without detection.
What this means practically
An attacker can convincingly spoof robinhood.com mail because SPF's softfail (~all) won't block spoofed mail at many receivers—Gmail, Outlook, and others often let softfail mail through to the inbox if DMARC quarantine isn't enforced at the receiver end. The attacker avoids DKIM by sending unsolicited mail that never reaches Robinhood's signing pipeline. In practice: phishing mail claiming to be from Robinhood support or account alerts will reach many inboxes, and receivers will see no clear authentication failure. Robinhood's own legitimate mail (signed via DKIM) stays protected, but the door is open for external abuse.
Context for Robinhood
Robinhood is a financial services company handling customer accounts and sensitive transactions. Unlike universities or content platforms, there's no operational reason for softfail SPF or absent MTA-STS here—these are gaps in an otherwise competent posture.
Bottom line: Robinhood has built strong DKIM signing but undermined it with a soft SPF policy and no transport encryption—a configuration that deters lazy attackers but won't stop a determined phishing campaign.
What we measured
Partial
DMARC policy
p=quarantine
DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 ip4:152.70.150.118 a:outbound.email.robinhood.com include:mail.zendesk.com include:amazonses.com include:_spf.google.com include:spf.mandrillapp.com include:mg-spf.greenhouse.io include:aristotle.com exists:%{i}._spf.mta.salesforce.com ~allEnforced
DKIM presence
found at 4 selectors
DKIM key found at selectors: google, mandrill, s1, s2.
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.
- 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.