Spoofability verdict for asana.com
Maybe - asana.com is partially protected.
See the math
Asana has built most of the technical foundations to stop email spoofing, but left the door just slightly ajar by not tightening their DMARC policy to enforcement.
- DMARC policy=quarantine (partial strictness): Quarantine is the middle ground: suspicious mail gets diverted to junk, but legitimate mail may still land in spam folders or disappear. Asana hasn't moved to p=reject, which would be harder enforcement. The unset adkim and aspf flags mean alignment checking isn't strictly configured.
- SPF hardfail (-all) with enforced strictness: Asana's SPF is tight. The -all hard-fail means any mail claiming to come from asana.com but sent from an unlisted server will be rejected outright. They've registered their approved senders: Google, Amazon SES, Sparkpost, Marketo, and Greenhouse.
- DKIM signature detected (google selector): DKIM signing is present and cryptographically verified. Mail signed with Asana's Google selector can be proven authentic. Only one selector found in the common set, suggesting limited vendor diversity or consolidation.
- MTA-STS mode=enforce: Asana enforces encrypted delivery and validates TLS certificates on inbound connections. This prevents downgrade attacks and eavesdropping on the wire, but doesn't directly prevent spoofing of the From address.
What this means practically
An attacker can still send mail that appears to come from an asana.com address if they control their own mail server. The message will fail SPF checks (good), but many mail receivers—including Gmail and Outlook—will still deliver it, either to the inbox or spam folder, depending on receiver policy. The lack of a strict DMARC reject means Asana is relying on downstream receivers to enforce the quarantine instruction; not all do. A spoofed email might land in the recipient's spam folder, or worse, slip through if the receiver is lenient or misconfigured.
Bottom line: Asana is well-defended but not maximally so; upgrading DMARC to p=reject would close the remaining gap and ensure spoofed mail is rejected at the perimeter, not gambled on downstream spam filters.
What we measured
Partial
DMARC policy
p=quarantine
DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.
Enforced
SPF posture
-all (hardfail)
SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.
v=spf1 include:_spf.google.com include:amazonses.com exists:%{i}._spf.sparkpostmail.com include:mktomail.com include:mg-spf.greenhouse.io -allEnforced
DKIM presence
found at 1 selector
DKIM key found at selector: google.
Enforced
MTA-STS (transport)
mode=enforce
MTA-STS in enforce mode. Mail in transit cannot be downgraded by an attacker.
How to make it un-spoofable
- Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.