wiredepth
Run a check

Spoofability verdict for binance.com

Maybe - binance.com is partially protected.

See the math

Binance has set up the core email authentication signals but left the door open at the foundation. DMARC quarantine + SPF hardfail is a solid framework—but MTA-STS is missing entirely, and DKIM coverage appears limited to Google's infrastructure.

  • DMARC policy=quarantine: Quarantine catches unauthenticated mail and pushes it to spam rather than bouncing it. This is the right call for a global platform with legitimate complex sending infrastructure.
  • SPF hardfail (-all): SPF is enforced with v=spf1 include:_spf.google.com -all, meaning any IP not explicitly approved by Google's SPF records will hard-fail. This prevents trivial spoofing from unrelated infrastructure.
  • DKIM Google selector only: DKIM was found at the Google selector only (probed 22 common selectors). This suggests Binance uses Google Workspace for sending but hasn't diversified DKIM coverage across other email providers or internal infrastructure.
  • MTA-STS mode=none: MTA-STS is not enforced (mode=none). This protocol prevents downgrade attacks on the transmission layer—without it, an attacker can intercept and redirect Binance mail even if SPF and DKIM pass the initial check.

What this means practically

An attacker cannot easily spoof from binance.com using commodity phishing infrastructure, thanks to SPF hardfail. However, if the attacker controls infrastructure that passes Google's SPF records (or compromises a Google Workspace account), they can send mail that DKIM-verifies. Because MTA-STS is absent, an attacker positioned on the network path can downgrade the connection and intercept Binance mail in transit. Recipients using Gmail or Outlook will likely catch most spoofed mail in spam due to DMARC quarantine, but recipients on older or misconfigured mail servers may see spoofed mail in the inbox.

Bottom line: Binance has deployed DMARC quarantine and SPF hardfail correctly, but the absence of MTA-STS and reliance on a single DKIM provider represents a measurable security gap for a global financial brand.

What we measured

Partial

DMARC policy

p=quarantine

inspect →

DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.

Enforced

SPF posture

-all (hardfail)

inspect →

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

v=spf1 include:_spf.google.com -all

Enforced

DKIM presence

found at 1 selector

inspect →

DKIM key found at selector: google.

Open

MTA-STS (transport)

mode=none

inspect →

MTA-STS in mode=none (effectively disabled).

How to make it un-spoofable

  1. Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.
  2. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain