wiredepth
Run a check

Spoofability verdict for intel.com

Yes - intel.com is spoofable today.

See the math

Intel publishes SPF and SPF alone, with no DMARC enforcement and no DKIM signing. This creates a dangerous gap: SPF can stop direct mail server impersonation, but doesn't protect against display-name and header spoofing—attacks that often land in inboxes anyway.

  • DMARC at p=none: No enforcement policy means Intel's domains don't actively reject unauthenticated mail. Receivers get a permission slip to accept forged Intel email. This is the core spoofability lever.
  • SPF with hardfail (-all): SPF is correctly set to reject mail from unlisted servers (v=spf1 include:_spf.intel.com -all). This stops direct server impersonation but cannot authenticate message content or prevent header rewriting.
  • DKIM absent (0 selectors found): No DKIM keys discovered across 22 common selector patterns. DKIM would cryptographically sign message body and headers, closing the spoofing gap that SPF leaves open.
  • MTA-STS missing: MTA-STS enforces encrypted delivery but doesn't authenticate the sender. Secondary to DMARC and DKIM for spoofability, but worth having anyway.

What this means practically

An attacker can send mail with an intel.com return address and display name that passes SPF (by spoofing the display name and headers while keeping the SMTP server legitimate, or by using open relays) and lands in most inboxes. Because DMARC is not enforced and DKIM is absent, there's no strong signal telling Gmail, Outlook, or corporate filters that the email is fraudulent. This is particularly risky for Intel executives: a spoofed "from: [email protected]" with forged payment instructions will often reach end-users without quarantine or warning.

Bottom line: Intel's SPF alone cannot prevent display-name spoofing; add DKIM signing and enable DMARC enforcement (p=reject) to close the attack surface.

What we measured

Open

DMARC policy

p=none

inspect →

DMARC at p=none. Receivers are told NOT to act on auth failures; spoofed mail will not be blocked.

Enforced

SPF posture

-all (hardfail)

inspect →

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

v=spf1 include:_spf.intel.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. Publish a DMARC record. Start at p=none with a rua= report destination to gather data, then progress to p=quarantine and p=reject.
  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