wiredepth
Run a check

Spoofability verdict for dell.com

No - dell.com is not practically spoofable.

See the math

Dell has built a straightforward, effective email defence that makes spoofing dell.com impractical: a hard-reject DMARC policy backed by working SPF and DKIM signatures.

  • DMARC policy=reject: Dell enforces a hard reject policy, meaning recipients will reject unsigned or misaligned mail claiming to be from dell.com. This is the strongest DMARC stance and blocks most spoofing attempts at the receiver end.
  • SPF softfail (~all): SPF is configured with a softfail qualifier rather than hard fail, and includes a third-party hosted SPF provider (Proofpoint). This means mail from unauthorised sources will be flagged but not automatically rejected—however, combined with DMARC reject, enforcement is still strong in practice.
  • DKIM at 3 selectors (k2, s2, s1): Dell publishes DKIM signing keys and rotates them across multiple selectors, meaning legitimate mail can be cryptographically verified even if an attacker spoons the sender domain.
  • MTA-STS missing: MTA-STS adds encryption guarantees in transit but doesn't prevent spoofing; its absence here is a minor gap in transport security but doesn't weaken the spoofing defence.

What this means practically

An attacker cannot usably spoof dell.com. The DMARC reject policy means Gmail, Microsoft 365, and other major receivers will reject unsigned mail or mail with misaligned SPF/DKIM—it will land in spam or bounce. Even if an attacker guesses one of Dell's DKIM selectors, the cryptographic signature will fail. Legitimate spoofing (e.g. pretending to be from a Dell subdomain or circumventing alignment checks) is technically possible but requires network-level access or social engineering, not just domain impersonation.

Bottom line: Dell's defences are built correctly and will stop the vast majority of commodity spoofing attacks.

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

Enforced

DKIM presence

found at 3 selectors

inspect →

DKIM key found at selectors: s2, k2, s1.

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. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain