Spoofability verdict for uber.com
Maybe - uber.com is partially protected.
See the math
Uber sits at the threshold: they've made good choices on DMARC and DKIM enforcement, but a softfail SPF policy and missing MTA-STS leave room for attackers to slip through if they're patient or precise.
- DMARC p=quarantine (partial): Quarantine policy means Uber is actively telling receivers to isolate mail that fails authentication checks. This is stronger than p=none but not as strict as p=reject. Aligns with travel industry norms where legitimate third-party senders (partner integrations, payment systems) need breathing room.
- SPF ~all (softfail): Softfail is a warning, not a block. Mail that fails SPF checks still reaches inboxes; it's just flagged lower-priority by some receivers. The include chains (vali.email and mailgun.org) show legitimate third-party dependency, but the softfail undermines enforcement—an attacker can spoof Uber's domain if they don't mind a soft penalty.
- DKIM at 6 selectors (enforced): Multiple selector coverage (google, mandrill, k1, k2, s1, s2) means Uber signs from multiple email platforms. DKIM is per-selector and per-domain, so an attacker must forge signatures correctly—a legitimate technical bar that catches most opportunistic spoofing attempts.
- MTA-STS missing: MTA-STS encrypts mail in transit and validates server certificates. Absence leaves Uber's inbound connection open to downgrade and man-in-the-middle attacks, allowing attackers to intercept or inject mail into Uber's infrastructure rather than just spoofing outbound mail.
What this means practically
An attacker can register a lookalike domain (e.g., uber.com.fake, uber-security.com) or compromise a third-party sender in Uber's SPF chain and send mail that appears to originate from Uber. The softfail SPF means Gmail, Outlook, and others won't hard-reject it; they'll apply reputational scoring instead. If the attacker also forges a valid DKIM signature (requiring access to one of Uber's six known signing keys), they can bypass both SPF and DMARC quarantine, landing in inboxes as a "warn, don't block" case. Uber's missing MTA-STS also means inbound mail isn't forced over TLS, creating a secondary vulnerability for attackers aiming to compromise Uber's own email infrastructure or intercept sensitive inbound customer mail.
Context for Uber
Travel and rideshare platforms legitimately rely on third-party integrations (payment processors, notification services, support ticketing). The softfail SPF and multi-selector DKIM setup reflects that operational reality. However, Uber's scale and the sensitivity of ride, payment, and account data make the missing MTA-STS and softfail policy notably risky; a bank or payment processor in a similar posture would warrant stronger urgency.
Bottom line: Uber's DMARC and DKIM layering creates real friction for attackers, but the softfail SPF and absent MTA-STS leave two doors open for sophisticated spoofing or infrastructure-level compromise.
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 include:uber.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:mailgun.org ~allEnforced
DKIM presence
found at 6 selectors
DKIM key found at selectors: google, mandrill, s1, k1, s2, 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
- 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.