wiredepth
Run a check

Spoofability verdict for wellsfargo.com

Maybe - wellsfargo.com is partially protected.

See the math

Wells Fargo has a strong DMARC reject policy in place, which is the right move for a financial institution. But the gaps elsewhere—no DKIM records found, no MTA-STS, and a soft-fail SPF—leave room for a determined attacker to craft plausible spoofed messages.

  • DMARC policy=reject (enforced): DMARC reject tells receiving mail servers to discard messages that fail authentication, which is the gold standard. For a bank, this is the right posture.
  • SPF ~all (soft-fail): Soft-fail SPF means unauthenticated messages get a 'maybe suspicious' label, not a hard block. Combined with weak DKIM, receivers treat these warnings loosely.
  • DKIM: no selectors found: No DKIM signature records detected after probing 22 common selectors. This means messages lack cryptographic proof of origin, leaving DMARC with only SPF to work with.
  • MTA-STS: missing: No MTA-STS policy means there's no encryption requirement for inbound SMTP connections, allowing downgrade attacks where an attacker intercepts unencrypted mail.

What this means practically

An attacker can spoof a Wells Fargo domain if they control a mail server that passes the soft-fail SPF check (which is loose). Without DKIM, there's no cryptographic tie to the real Wells Fargo infrastructure. Mail servers and users will see warnings, but many will still deliver or display the message as plausible. A targeted phishing campaign impersonating Wells Fargo alerts, statements, or fraud notices would likely get through to inboxes at smaller organizations or older systems.

Context for Wells Fargo

Banks are expected to run tight authentication. Wells Fargo's DMARC reject is correct, but DKIM and MTA-STS are table stakes for a financial institution handling customer trust. The soft-fail SPF is a particular vulnerability in this category—it's too permissive for an organization of this scale and sensitivity.

Bottom line: Wells Fargo has half the story right (DMARC reject) but is missing critical pieces (DKIM, MTA-STS) that would make spoofing genuinely difficult for attackers.

What we measured

Enforced

DMARC policy

p=reject

inspect →

DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.

Partial

SPF posture

~all (softfail)

inspect →

SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.

v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~all

Open

DKIM presence

no key found at common selectors

inspect →

No DKIM key found at any of the 22 common selectors. (Your domain may publish a DKIM key at a less-common selector - this is a heuristic, not exhaustive.)

Open

MTA-STS (transport)

missing

inspect →

No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.

How to make it un-spoofable

  1. Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
  2. Confirm DKIM is configured. We didn't find a key at the common selectors; if you do publish DKIM, the selector you use isn't in our probe list - that's fine, but worth verifying with your mail provider.
  3. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain