wiredepth
Run a check

Spoofability verdict for usps.com

No - usps.com is not practically spoofable.

See the math

USPS has deployed a textbook email authentication posture: DMARC with reject policy backed by an SPF hardfail. This is the gold standard for government agencies and high-risk targets.

  • DMARC p=reject: Tells receiving mail servers to reject any message claiming to be from usps.com that fails DMARC alignment. This is the strongest DMARC policy and means non-compliant senders are blocked, not diverted to spam.
  • SPF -all (hardfail): Declares that only IPs in the 56.0.0.0/16 block are authorised to send mail from usps.com; everything else is rejected outright. The -all mechanism prevents soft-fail workarounds.
  • DKIM selectors: none found: DKIM signing wasn't detected, but it's redundant here because SPF and DMARC already enforce sender authentication at a strict level. Not a weakness.
  • MTA-STS: missing: MTA-STS encrypts transit between mail servers and prevents downgrade attacks. Its absence doesn't enable spoofing directly, but adds a small additional risk in-flight.

What this means practically

An attacker cannot send a message that will be accepted as genuinely from usps.com. Mail servers processing SPF will reject non-compliant senders at the protocol level. Even if an attacker bypassed SPF, DMARC reject policy would block delivery. Gmail, Microsoft 365, and other major platforms will refuse these messages outright—they won't land in spam or be flagged as suspicious; they will be rejected before a user ever sees them.

Bottom line: USPS has implemented email authentication correctly and comprehensively; spoofing usps.com is not a practical threat.

What we measured

Enforced

DMARC policy

p=reject

inspect →

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

Enforced

SPF posture

-all (hardfail)

inspect →

SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.

v=spf1 ip4:56.0.0.0/16 -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. 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.
  2. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain