Your Email Domain Is Public Information, and Attackers Check It Before You Do
The business office manager at a Critical Access Hospital gets an email from the billing coordinator at the CAH forty miles down the highway. The two of them have worked together on shared patients for years. The message references a transfer that actually happened, asks her to confirm updated remittance details, and comes from the exact domain her colleague has always used. She replies.
Nothing was hacked. Not her mail system, not theirs. The attacker simply looked up the neighboring hospital's DNS records, saw that nothing there instructed receiving mail servers to reject unauthorized mail claiming to be from that domain, and sent a message with the From address set to whatever they wanted.
This is the part of your security posture that is published, publicly queryable, and evaluated by attackers before they ever send anything. It costs nothing to check and, for most organizations, nothing to fix. A meaningful number of rural facilities have never looked.
What Is Actually Published About You
Three DNS records determine whether a receiving mail server can tell your legitimate mail from someone wearing your name.
SPF (Sender Policy Framework) is a TXT record listing which servers are authorized to send on your behalf. DKIM (DomainKeys Identified Mail) publishes a public key so receiving servers can verify a cryptographic signature on your outbound messages. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that tells receiving servers what to do when a message fails those checks, and where to send reports about it.
You can read all three for any domain in the world, including your own, from a workstation right now:
Resolve-DnsName -Name yourdomain.org -Type TXT
Resolve-DnsName -Name _dmarc.yourdomain.org -Type TXT
Resolve-DnsName -Name selector1._domainkey.yourdomain.org -Type CNAME
The first returns your SPF record among other TXT records. The second returns your DMARC policy, if you have one. The third checks a DKIM selector, and selector1 is the common Microsoft 365 default. Google Workspace typically uses a selector named google. There is no way to enumerate DKIM selectors, which is why checking DKIM requires either knowing your selector or guessing from a list of common ones.
If the DMARC query comes back empty, you have no DMARC policy. That is the single most common finding, and it means a receiving mail server has no instruction from you about what to do with mail that fails authentication. The practical default is to deliver it anyway.
Four Places This Goes Wrong Quietly
Publishing the records is not the same as the records working. Four failure modes account for most of what turns up in real environments.
The SPF ten lookup limit. Every include, a, mx, ptr, and redirect mechanism in your SPF record consumes a DNS lookup, and the specification caps that at ten. Exceed it and the record returns a permanent error, which most receivers treat as no SPF at all. This happens gradually. You add Microsoft 365, then your patient reminder service, then a survey vendor, then your payroll platform, and one day you are at eleven. Nothing breaks visibly. Your SPF just stops counting.
The soft fail default. An SPF record ending in ~all is a soft fail, which tells receivers that unauthorized senders should be treated with suspicion but not rejected. A record ending in -all is a hard fail. Most templated records ship with ~all and stay there permanently. Soft fail is the right starting point while you are still discovering senders. It is not a finishing point.
DKIM signing the wrong domain. In Exchange Online, mail from a custom domain is not signed with that custom domain until you publish the two CNAME records and enable signing for the domain in the Microsoft Defender portal. Before that, messages carry a signature from your onmicrosoft.com domain instead. The mail is signed, so a casual check looks fine, but the signature does not align with the From domain, which means it does not produce a DKIM pass for DMARC purposes. Google Workspace has the same trap, signing with a gappssmtp.com default until you generate and publish a key for your own domain. Verify alignment, not just the presence of a signature.
DMARC parked at p=none. A policy of p=none asks receivers to report on failures and deliver the mail anyway. It is a monitoring posture, and it is the correct first step, because it lets you find the legitimate senders you forgot about before you start blocking things. But a domain sitting at p=none is not protected against impersonation. It is observing impersonation. Plenty of organizations published a DMARC record years ago, checked the box, and never moved past monitoring. Reaching p=quarantine and then p=reject is where the actual protection lives.
Why This Compounds in Rural Networks
Rural facilities share more than geography. They share referral relationships, transfer agreements, regional health network membership, the same handful of regional EHR and revenue cycle vendors, and often the same regional reference lab. Staff at one facility are in the address books of staff at five others.
That is the exposure. When an attacker successfully impersonates a facility's domain, the highest value targets are not strangers. They are the people who already trust that domain, which means the other organizations in the network. A weak configuration at one clinic becomes an attack surface for every organization it works with, and none of those organizations can fix it from their side. Inbound filtering helps, but a message from a domain with no DMARC policy is a message your filter has less basis to reject.
This is also the argument for handling it at the network or association level rather than one facility at a time. The value of one hospital raising its floor is real. The value of every hospital in a regional network raising the floor together is considerably higher, because the trust relationships run in every direction.
Where HIPAA Actually Lands, and Where It Does Not
Be careful here, because this is where vendors overclaim and credibility gets spent.
The HIPAA Security Rule does not name SPF, DKIM, or DMARC. It does not require email authentication as a specific control. Anyone telling you that DMARC is a HIPAA requirement is selling something.
What the rule does require is a risk analysis. Under 45 CFR 164.308(a)(1)(ii)(A), risk analysis is a Required implementation specification: an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. A domain that can be trivially impersonated, in an environment where staff mailboxes contain ePHI and where a credential harvest leads directly to those mailboxes, is a risk and vulnerability. If your risk analysis has never considered it, your risk analysis has a gap.
Paired with that, 45 CFR 164.308(a)(1)(ii)(B) makes risk management Required as well: implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Email authentication is one reasonable and appropriate measure among others for the specific risk of domain impersonation. It is not the only one, and it does not address display name spoofing or lookalike domains.
Outside the rule itself, HHS treats this as baseline expectation. Email Security is one of the Essential Goals in the HHS Healthcare and Public Health Sector Cybersecurity Performance Goals, aimed specifically at reducing risk from spoofing, phishing, and fraud. The CPGs are voluntary and are not regulation, but they are the department's own statement of what a floor looks like, and that is the kind of thing that gets referenced when an investigator asks what you were measuring yourself against.
Protection from malicious software at 45 CFR 164.308(a)(5)(ii)(B) is relevant where phishing is the delivery vehicle for malware, and it is Addressable. Addressable does not mean optional. Under 45 CFR 164.306(d)(3), you must assess whether the specification is a reasonable and appropriate safeguard in your environment, implement it if it is, and if it is not, document why it would not be reasonable and appropriate and implement an equivalent alternative measure where that is reasonable and appropriate. Skipping it silently is not one of the options.
What email authentication is not: it is not Transmission Security under 45 CFR 164.312(e). That standard covers guarding ePHI while it is being transmitted, with Integrity controls and Encryption as its two Addressable implementation specifications. SPF, DKIM, and DMARC govern whether a receiving server can verify who sent a message. They do not encrypt anything, and they do not protect the ePHI inside your outbound mail. If a vendor maps DMARC to 164.312(e) on a compliance matrix, that mapping is wrong, and an auditor who knows the rule will notice.
On the proposed Security Rule overhaul: the Notice of Proposed Rulemaking published January 6, 2025 under RIN 0945-AA22 would eliminate the Addressable designation and make implementation specifications Required. It remains proposed. The comment period closed March 7, 2025, and HHS has since moved the rule to its Long-Term Actions agenda with a July 2027 target for final action. Unified Agenda dates are planning estimates, not deadlines. Plan against the rule that is in force today.
What OCR Actually Penalizes
The enforcement pattern here is consistently misread, and the correction matters more for small organizations than large ones.
In February 2026, OCR announced a settlement with Top of the World Ranch Treatment Center, a substance use disorder treatment provider in Illinois. A phishing attack had given an unauthorized third party access to ePHI through a single workforce member's email account. The ePHI of 1,980 patients was compromised. OCR's investigation found that the organization had failed to conduct an accurate and thorough risk analysis. The settlement was $103,000 and a two year corrective action plan, and it was the eleventh enforcement action in OCR's Risk Analysis Initiative.
Read those numbers again. One mailbox. Under 2,000 patients. This is not a large health system, and it is not an unusual fact pattern. It is a small provider with a compromised email account and no documented risk analysis.
The scale contrast is instructive. In April 2025, OCR settled with PIH Health, a California health care network, for $600,000 after a June 2019 phishing campaign compromised 45 employee email accounts and exposed the ePHI of 189,763 individuals. The dollar figures differ by a factor of six. The finding is the same one: no accurate and thorough risk analysis.
That is the pattern. OCR does not penalize organizations for being phished. Getting phished is not a violation, and no configuration prevents it entirely. What draws enforcement is the absence of a documented risk analysis that would have identified the exposure, and the absence of a risk management response to what it found. A small facility that has honestly assessed its email risk and taken proportionate steps sits in a fundamentally different position than one that never looked.
The Deliverability Angle, Stated Honestly
Since May 5, 2025, Microsoft has required senders delivering more than 5,000 messages per day to Outlook.com, Hotmail.com, and Live.com to pass SPF and DKIM and to publish a DMARC policy of at least p=none. Non-compliant mail is rejected with a 550 5.7.515 error. Google and Yahoo introduced comparable bulk sender requirements in 2024.
Most Critical Access Hospitals, Rural Emergency Hospitals, and community clinics will never send 5,000 messages a day to consumer mailboxes, so these thresholds probably do not apply to you directly. That is worth saying plainly rather than using the deadline as a scare tactic. What matters is the direction: the largest receiving providers have decided that unauthenticated mail is presumptively untrustworthy, and the threshold has been moving downward across the industry, not upward. Patient statements, appointment reminders, and portal notifications land in exactly these consumer mailboxes. Authentication increasingly determines whether they arrive.
What to Do This Week
Run the three DNS queries above against every domain your organization owns. Not just your primary mail domain. Parked domains, the old domain from before a name change, the marketing domain, the domain that only hosts the website. An unused domain with no DMARC record is a free impersonation vector, and a parked domain that never sends mail is the easiest possible fix: publish an SPF record of v=spf1 -all and a DMARC record of v=DMARC1; p=reject; and it is done.
For domains that do send mail, inventory the senders before you tighten anything. Every EHR notification, patient reminder service, survey tool, payroll system, and marketing platform that sends as your domain. Health care organizations routinely find more senders than they expected. Publish DMARC at p=none with a reporting address first, read the reports for thirty days, fix what surfaces, then move to p=quarantine and eventually p=reject. Tightening before you have the inventory is how you stop your own appointment reminders from being delivered.
Several free tools will do the lookups and interpret the results if you would rather not parse records by hand. visuaFUSION Systems Solutions publishes a free email domain health check built specifically around rural health care, which scores SPF, DKIM, and DMARC out of ten and performs read only DNS lookups without storing data about the domains it scans. Disclosure: visuaFUSION is affiliated with this publication's parent company, so in fairness, MXToolbox, dmarcian's domain checker, and Red Sift Investigate all offer free public checks as well. Any of them will tell you the same underlying facts, because they are all reading the same public records.
Whichever you use, the results are not confidential and never were. The only question is whether you have read them before someone else does.
Disclosure: Health Tech Authority is owned and operated by SMP Consulting LLC, which is affiliated with visuaFUSION Systems Solutions. Health Tech Authority maintains editorial independence from visuaFUSION, and unaffiliated tools offering equivalent free checks are named above.
This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.
Sources
45 CFR 164.308, Administrative safeguards, eCFR: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
45 CFR 164.312, Technical safeguards, eCFR: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
HHS Office for Civil Rights, HIPAA Security Rule Notice of Proposed Rulemaking (RIN 0945-AA22), Federal Register, January 6, 2025: https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
HHS Office for Civil Rights, Settlement with Top of the World Ranch Treatment Center, February 19, 2026: https://www.hhs.gov/press-room/ocr-settles-hipaa-security-rule-investigation-twrtc.html
HHS Office for Civil Rights, Settles Phishing Attack Breach with Health Care Network for $600,000 (PIH Health), April 23, 2025: https://www.hhs.gov/press-room/ocr-hipaa-racap-pih.html
Microsoft, Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730
HHS, Healthcare and Public Health Sector-Specific Cybersecurity Performance Goals: https://hphcyber.hhs.gov/performance-goals.html
Microsoft Learn, Set up DKIM to sign mail from your Microsoft 365 domain: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure
CMS, Rural Emergency Hospitals: https://www.cms.gov/medicare/health-safety-standards/certification-compliance/rural-emergency-hospitals
