Spoofability verdict for substack.com
No - substack.com is not practically spoofable.
See the math
Substack has nailed the most important authentication step: a hard DMARC reject policy at 100% enforcement. This is the foundation that stops email spoofing in its tracks.
- DMARC p=reject at 100%: DMARC policy=reject on all outbound mail means receiving servers are instructed to refuse any message claiming to be from substack.com that fails authentication. No wiggle room; no softfails.
- SPF softfail (~all): SPF includes Google, Mailgun, and Zendesk (legitimate sending partners) but ends with softfail rather than hardfail. Softfail means 'this is unexpected' rather than 'reject it'. However, DMARC p=reject overrides this—SPF failures still cause DMARC to fail and the message gets rejected anyway.
- DKIM enforced (Google selector found): DKIM signing was detected on the google selector, providing cryptographic proof of origin. Combined with p=reject, this prevents forged copies of Substack mail from authenticating.
- MTA-STS mode=none: MTA-STS is not deployed. This is a post-delivery security measure that prevents attackers from downgrading TLS mid-transit. It's a smaller concern than DMARC/SPF/DKIM, but missing it leaves a gap in transport security.
What this means practically
An attacker cannot forge mail as substack.com in any inbox that respects DMARC—which is every major mailbox provider (Gmail, Outlook, Yahoo, etc.). Any spoofed message will fail DMARC authentication and be rejected or moved to spam. The softfail SPF is irrelevant here because DMARC alignment and enforcement make it moot. MTA-STS absence means in-flight interception is theoretically possible, but this is a rare attack and far less practical than domain spoofing.
Bottom line: Substack's p=reject DMARC policy at 100% makes it essentially impossible to spoof their domain; they've implemented the primary defense correctly.
What we measured
Enforced
DMARC policy
p=reject
DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 include:_spf.google.com include:mailgun.org include:mail.zendesk.com ~all
Enforced
DKIM presence
found at 1 selector
DKIM key found at selector: google.
Open
MTA-STS (transport)
mode=none
MTA-STS in mode=none (effectively disabled).
How to make it un-spoofable
- Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.