wiredepth
Run a check

Spoofability verdict for slack.com

No - slack.com is not practically spoofable.

See the math

Slack has built an unusually robust authentication posture: DMARC reject enforcement at 100% rules out email impersonation at the edge, and SPF's hard-fail mechanism backs it up with zero ambiguity.

  • DMARC policy=reject (100%): DMARC reject at full percentage is the gold standard. Any mail claiming to come from slack.com that fails DMARC checks is outright rejected by compliant receivers, not soft-failed or delivered. This is the single most important line of defense.
  • SPF hardfail (-all): SPF uses explicit -all (hardfail), meaning any IP not explicitly listed in the include chain (Qualtrics, Zendesk, _spfextra.slack.com) is rejected. This eliminates the ambiguity that makes spoofing easier at other organizations.
  • DKIM: no selectors found: Zero DKIM selectors were discoverable via probing (tested 22 common patterns). This could mean Slack doesn't use DKIM at all, or selectors aren't following standard naming. It's a gap, but DMARC reject makes DKIM redundant for defense.
  • MTA-STS: mode=none: MTA-STS (which secures mail transport between servers) is not deployed. Relevant mainly for stopping in-transit interception between mail servers, not email spoofing. Not a priority given DMARC's strength.

What this means practically

An attacker cannot practically spoof mail from slack.com. DMARC reject is enforced at 100%, meaning Gmail, Microsoft 365, and other major providers will reject any message failing authentication checks—not defer it, not spam-folder it, reject it outright. The SPF hardfail prevents even accidental open-relay exploitation. An attacker would need to compromise Slack's own infrastructure or one of the explicitly authorized senders (Qualtrics, Zendesk, _spfextra.slack.com) to succeed.

Bottom line: Slack's DMARC reject policy is fortress-grade; spoofing slack.com addresses is not a viable attack path.

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 include:_spf.qualtrics.com include:mail.zendesk.com include:_spfextra.slack.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)

mode=none

inspect →

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

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