wiredepth
Run a check

Spoofability verdict for amd.com

Maybe - amd.com is partially protected.

See the math

AMD has layered multiple email authentication mechanisms, but none are operating at full strength—a common state for large tech companies managing complex sender ecosystems.

  • DMARC policy=quarantine: Quarantine is the middle ground between permissive (p=none) and strict (p=reject). It tells receiving systems to isolate emails that fail authentication checks, blocking them from inboxes without hard rejection. This is effective against casual impersonation.
  • SPF softfail (~all): Softfail means 'if you see mail from something not in my SPF list, it *probably* didn't come from me, but accept it anyway.' Receivers treat it as a hint, not a block. It adds no enforcement at all—a sender not in the list can still land in inboxes.
  • DKIM enforced at 3 selectors: DKIM cryptographically signs emails. AMD is actively using at least three selector keys (default, mandrill, selector1), which suggests legitimate multi-vendor sending (Mandrill is Mailchimp's transactional service). This protects against signature forgery if the key is legitimate.
  • MTA-STS missing: MTA-STS forces downstream servers to encrypt their final hop to AMD's mail servers. Without it, an attacker can intercept the last mile of email routing and inject spoofed messages directly. This is a real gap.

What this means practically

An attacker can send mail that appears to come from @amd.com in two ways: (1) spoof the From header if they control an unauthentic SPF-listed IP—softfail won't stop them. (2) Intercept inbound connections and inject mail directly into AMD's receiving servers, since MTA-STS isn't enforced. DMARC quarantine and DKIM will catch many of these, but Outlook and Gmail may still deliver some to the inbox if the attacker crafts the message carefully. The lack of MTA-STS is the biggest practical vulnerability here.

Bottom line: AMD is mid-way protected: quarantine + DKIM stops casual spoofers, but the softfail SPF and missing MTA-STS leave real doors open for determined attackers.

What we measured

Partial

DMARC policy

p=quarantine

inspect →

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

Partial

SPF posture

~all (softfail)

inspect →

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

v=spf1 include:amd.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:oktamail.amd.com include:_spf.salesforce.com include:mktomail.com ~all

Enforced

DKIM presence

found at 3 selectors

inspect →

DKIM key found at selectors: default, mandrill, selector1.

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. Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.
  2. Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
  3. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain