Spoofability verdict for hilton.com
Maybe - hilton.com is partially protected.
See the math
Hilton has woven the right threads—DMARC quarantine, SPF hardfail, and multiple DKIM selectors—but left one critical gap wide open. This is the "partially protected" trap: strong email authentication that fails to address how that authentication is enforced at delivery.
- DMARC p=quarantine (partial strictness): Quarantine policy is the responsible middle ground: unauthenticated mail claiming to be from Hilton gets flagged for human review rather than silently accepted. However, pct, adkim, and aspf are unset, meaning Hilton isn't tuning when the policy applies—it relies on defaults.
- SPF hardfail with Outlook + Hilton includes: The -all hardfail mechanism blocks imposters: any mail server not explicitly listed (Outlook + four Hilton-owned SPF records) will be rejected. This is enforced at sender-side and prevents bulk spoofing from arbitrary mail servers.
- DKIM at 4 selectors (selector1, s1, s2, selector2): Multiple active DKIM signing keys give Hilton flexibility for key rotation and domain separation. The keys are discoverable and enforced—any forgery of Hilton's domain signature would fail verification.
- MTA-STS missing: MTA-STS enforces encrypted SMTP delivery to Hilton's mail servers. Without it, an attacker can intercept mail mid-flight even if SPF, DKIM, and DMARC are perfect—a man-in-the-middle can still relay spoofed messages.
What this means practically
An attacker cannot easily mass-mail from a random server using Hilton's domain (SPF blocks it) and cannot forge Hilton's signature (DKIM is signed). However, an attacker who can intercept network traffic en route to Hilton's mail server, or who gains control of a server already listed in Hilton's SPF includes (like a compromised Outlook tenant), can still inject forged mail. Receivers like Gmail and Outlook will quarantine a good fraction of spoofed attempts, but some will slip through to inboxes because there's no MTA-STS policy to force encrypted delivery at the last mile.
Bottom line: Hilton's authentication foundation is solid, but the missing MTA-STS creates an unnecessary window for network-level attacks and makes the investment in DMARC, SPF, and DKIM less useful than it could be.
What we measured
Partial
DMARC policy
p=quarantine
DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.
Enforced
SPF posture
-all (hardfail)
SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.
v=spf1 include:spf.protection.outlook.com include:_spf-a.hilton.com include:_spf-b.hilton.com include:_spf-c.hilton.com -all
Enforced
DKIM presence
found at 4 selectors
DKIM key found at selectors: s1, s2, selector2, selector1.
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.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.