Spoofability verdict for mayoclinic.org
Yes - mayoclinic.org is spoofable today.
See the math
Mayo Clinic's email authentication setup relies on SPF's blocking mechanisms but neglects the DMARC policy that would tell mail receivers how to handle failures. This is the healthcare equivalent of putting a "no entry" sign on the door but leaving the reception desk unmanned.
- DMARC policy=none (100% coverage): DMARC is set to observe-only mode, meaning failed authentication attempts are logged but not rejected. Receivers like Gmail and Outlook have no instruction to quarantine or reject spoofed mail.
- SPF hardfail (-all): SPF is correctly configured with a strict -all terminator that rejects unapproved senders, covering Mayo's direct infrastructure and two relay networks (mayo.edu and msgfe_mcmo.mayo.edu).
- DKIM: no selectors found: Despite probing 22 common selector patterns, no DKIM signing keys were discovered. This means signatures cannot be validated even if a message passed SPF.
- MTA-STS: missing: No MTA-STS policy in place. This leaves SMTP connections vulnerable to downgrade attacks and man-in-the-middle tampering during the handshake.
What this means practically
An attacker can send mail that appears to come from mayoclinic.org by spoofing the sender address in the From header. SPF will block the mail if sent directly from an unapproved server, but if the attacker routes through a compromised relay or uses a lookalike domain (mayo-clinic.org), SPF no longer applies. Because DMARC is set to p=none, even legitimate SPF failures won't trigger automatic rejection—instead the mail lands in the inbox with a weak "authentication-results" header. Lack of DKIM means no cryptographic fallback exists. Healthcare recipients, already alert to phishing targeting sensitive records and appointment data, face heightened risk here.
Context for Mayo Clinic
Healthcare organisations face intense phishing pressure around appointment scheduling, billing, and patient data access. Mayo Clinic's brand is frequently impersonated. DMARC p=none is more concerning in healthcare than in education because there is no legitimate sender complexity justifying the weak posture—Mayo has a tightly controlled email ecosystem.
Bottom line: Mayo Clinic's SPF is strong, but DMARC's observe-only stance and missing DKIM defeat the purpose—authenticated mail is only effective if failed authentication is enforced.
What we measured
Open
DMARC policy
p=none
DMARC at p=none. Receivers are told NOT to act on auth failures; spoofed mail will not be blocked.
Enforced
SPF posture
-all (hardfail)
SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.
v=spf1 mx include:_spf.mayo.edu include:_spf_msgfe_mcmo.mayo.edu -all
Open
DKIM presence
no key found at common selectors
No DKIM key found at any of the 22 common selectors. (Your domain may publish a DKIM key at a less-common selector - this is a heuristic, not exhaustive.)
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Publish a DMARC record. Start at p=none with a rua= report destination to gather data, then progress to p=quarantine and p=reject.
- Confirm DKIM is configured. We didn't find a key at the common selectors; if you do publish DKIM, the selector you use isn't in our probe list - that's fine, but worth verifying with your mail provider.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.