wiredepth
Run a check

Spoofability verdict for joinmastodon.org

Maybe - joinmastodon.org is partially protected.

See the math

Mastodon has done the technical homework on DMARC and DKIM, but left the door ajar by softfailing SPF and skipping MTA-STS entirely. The result is a classic half-measure: inbound spoofing is harder, but still possible.

  • DMARC p=quarantine at 100%: Mastodon tells receivers to quarantine (not reject) mail that fails authentication. This is the second-strongest DMARC posture and actively prevents spoofed mail from reaching inboxes in practice.
  • SPF softfail (~all): A softfail means 'this *probably* isn't authorized but deliver it anyway.' Gmail, Outlook, and others treat softfails as a weak signal; attackers spoofing joinmastodon.org will often still land in inboxes because SPF doesn't block them.
  • DKIM at google selector: DKIM was found and enforced. Mail signed with Mastodon's key is cryptographically verified, which means forged mail *claiming* to be from Mastodon will fail DKIM.
  • MTA-STS missing: MTA-STS enforces encrypted transit between mail servers. Its absence doesn't enable direct spoofing, but it does allow an attacker on the network path to intercept or downgrade Mastodon's outbound mail.

What this means practically

An attacker can still send mail that appears to come from joinmastodon.org and reach recipient inboxes in practice. SPF's softfail policy means misaligned mail gets a shrug from most receivers rather than a block. However, the DMARC quarantine policy means that mail which fails *both* DKIM and SPF alignment will be moved to spam folders by strict implementations (Outlook, Gmail, Fastmail). A well-resourced attacker could still spoof with some success if they compromise a legitimate sender path (like HelpScout, which is listed in the SPF include) or send from an IP that passes a partial SPF check.

Bottom line: Mastodon is protected against low-effort spoofing but vulnerable to motivated attackers; upgrading SPF to a hard reject (~all to -all) and adding MTA-STS would close the remaining gaps.

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:_spf.google.com include:helpscoutemail.com ~all

Enforced

DKIM presence

found at 1 selector

inspect →

DKIM key found at selector: google.

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