Spoofability verdict for calendly.com
Maybe - calendly.com is partially protected.
See the math
Calendly protects against some spoofing attempts but leaves meaningful gaps—a company this size has the infrastructure to do better.
- DMARC p=quarantine (partial strictness): Calendly's DMARC policy quarantines messages that fail authentication, which means spoofed emails are more likely to land in spam rather than inboxes. This is the middle ground between monitoring (p=none) and hard rejection (p=reject).
- SPF ~all (softfail): SPF includes multiple vendors (Google, Marketo) and uses a softfail (~all) rather than a hard fail (-all), meaning non-authorised senders get a warning flag but are not explicitly rejected. This is permissive by design, likely to avoid blocking legitimate mail.
- DKIM at 5 selectors with enforcement: Five active DKIM keys (k1, s1, s2, k2, google) with enforced signing means outbound Calendly mail carries cryptographic proof of origin. If a spoofed message claims to be from Calendly but lacks valid DKIM, it fails authentication.
- MTA-STS missing: MTA-STS forces other servers to encrypt connections when sending mail to Calendly's servers and prevents downgrade attacks. Its absence means an attacker could potentially intercept or downgrade a connection to deliver spoofed mail.
What this means practically
An attacker can create emails that appear to come from calendly.com by registering a lookalike domain or compromising a vendor in Calendly's SPF include chain. Because SPF uses softfail, such mail won't be hard-rejected by receiving servers; instead, receivers (Gmail, Outlook, etc.) will apply DMARC quarantine rules. This typically lands the mail in spam, but not reliably—some organisations and older mail systems may deliver it to inbox. The missing MTA-STS also means an attacker with network access could intercept mail in transit.
Bottom line: Calendly has the foundation (DMARC quarantine + DKIM signing) to stop most naive spoofing attempts, but switching SPF to hardfail and adding MTA-STS would close two practical attack vectors.
What we measured
Partial
DMARC policy
p=quarantine
DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:_spf.google.com include:mktomail.com ~allEnforced
DKIM presence
found at 5 selectors
DKIM key found at selectors: k1, google, s2, k2, s1.
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.
- 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.