wiredepth
Run a check

Spoofability verdict for duolingo.com

No - duolingo.com is not practically spoofable.

See the math

Duolingo has built a genuinely strong email authentication posture with the enforcement mechanisms that actually stop spoofing attacks. This is the straightforward win case: they're doing the work.

  • DMARC p=reject (enforced): DMARC is set to hard-reject (p=reject) with alignment enforced on both DKIM and SPF (adkim=r, aspf=r). This is the gold standard: receivers drop mail that fails authentication checks before it reaches inboxes. No softfail ambiguity.
  • SPF ~all (softfail): SPF uses softfail (~all) rather than hardfail (-all), which means non-authorised sources get a pass, not a rejection. However, because DMARC p=reject is in place, the softfail doesn't weaken the overall defence—the DMARC policy is what matters to most modern receivers.
  • DKIM at 4 selectors: Multiple DKIM selectors (google, k1, s2, s1) found across the domain. This distributes signing keys and allows key rotation without breaking authentication. Standard practice for large platforms.
  • MTA-STS mode=none: MTA-STS is not enabled (mode=none). This signal isn't critical for spoofing defence but leaves a small window: an attacker could downgrade the connection to plaintext SMTP. It's a lower-priority fix given the strong DMARC posture.

What this means practically

An attacker cannot practically send spoofed mail as Duolingo to major mailbox providers (Gmail, Microsoft 365, etc.). The DMARC p=reject policy with SPF and DKIM alignment means forged messages will be rejected before they reach user inboxes. The softfail SPF doesn't create a loophole because DMARC enforcement overrides it. The only tangible risk is an extremely narrow one: an attacker exploiting the absence of MTA-STS to downgrade the SMTP connection, but this is far less impactful than spoofing the From header.

Bottom line: Duolingo's DMARC p=reject with strict alignment is the protection that works; enable MTA-STS to close the last small gap, but don't let the perfect be the enemy of the genuinely secure.

What we measured

Enforced

DMARC policy

p=reject

inspect →

DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.

Partial

SPF posture

~all (softfail)

inspect →

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

v=spf1 ip4:100.25.59.11 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ip4:52.73.203.75 ip4:52.70.130.33 include:amazonses.com include:_spf.google.com include:_spf.salesforce.com include:mail.zendesk.com include:aspmx.pardot.com ~all

Enforced

DKIM presence

found at 4 selectors

inspect →

DKIM key found at selectors: google, k1, s2, s1.

Open

MTA-STS (transport)

mode=none

inspect →

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

How to make it un-spoofable

  1. Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
  2. Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.

Check another domain