Spoofability verdict for visa.com
Maybe - visa.com is partially protected.
See the math
Visa has invested in email authentication—DMARC quarantine, DKIM signing, and a long SPF allowlist—but left a critical gap that undermines the whole effort: they're not enforcing strict policy alignment or adding transport-layer protection.
- DMARC p=quarantine (partial alignment): Quarantine is a sensible middle ground that catches failures without risking delivery of legitimate mail. However, Visa hasn't set adkim or aspf to 'strict', so a spoofed email can pass DMARC if *either* SPF or DKIM alignment succeeds—not both.
- SPF with ~all softfail (not -all hardfail): The SPF record lists 22 authorised sender IPs and uses ~all (softfail) rather than -all (hardfail). Softfail tells receivers 'this is probably wrong, but deliver it anyway'—which most do. An attacker sending from an unauthorised IP will still land in inboxes at many providers.
- DKIM at 2 selectors (s1, s2): Visa signs mail with DKIM, which is good. Finding only two selectors suggests they're using a simple key rotation pattern rather than frequent selector cycling, but the signatures themselves will still validate.
- MTA-STS missing: MTA-STS enforces encrypted connections to mail servers and prevents downgrade attacks. Visa hasn't published one, so an attacker can intercept mail in transit or force unencrypted delivery without detection.
What this means practically
An attacker can send an email claiming to be from visa.com that will pass through many mail systems. If they forge a From: header and ensure the email arrives from one of Visa's own IP ranges (or tricks SPF validation), it will pass DMARC quarantine and likely reach the inbox—especially at organisations with lenient junk filtering. Even without IP spoofing, the softfail SPF policy means many receivers won't reject spoofed mail outright. The absence of MTA-STS also leaves the connection between mail servers undefended against interception.
Bottom line: Visa's defences are partial: they signal intent but haven't closed the door, leaving room for convincing phishing and impersonation attacks that will slip past many recipients' filters.
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:198.241.162.0/24 ip4:198.241.168.0/24 ip4:198.241.159.0/24 ip4:72.46.234.0/24 ip4:66.185.181.0/24 ip4:198.241.174.0/24 ip4:74.116.91.0/24 ip4:198.80.42.3 ip4:69.20.125.232 ip4:198.241.175.106 ip4:216.251.253.98 ip4:67.208.216.61 ip4:198.247.174.175 ip4:67.220.120.24 ip4:66.185.186.2 ip4:198.241.171.12 ip4:204.75.142.27 ip4:66.165.175.189 ip4:67.192.139.34 ip4:67.192.157.83 ip4:174.143.100.191 ip4:198.241.158.43 ip4:198.241.207.0/24 ip4:198.241.206.0/24 exists:%{i}.spf.hc3429-92.iphmx.com exists:%{i}.spf.hc5864-50.iphmx.com ~allEnforced
DKIM presence
found at 2 selectors
DKIM key found at selectors: s2, 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
- 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.