Email domain spoofing is one of the simplest attacks available to cybercriminals — and one of the most consistently underdefended vulnerabilities at home health agencies. Without DMARC, DKIM, and SPF configured on your email domain, any technically competent attacker can send an email that appears to come from your agency's email domain. Not a lookalike domain that differs by a character — your actual domain, delivering email to your patients, your referral hospital discharge planners, your billing company, and your own staff. The email appears to be from your executive director, your billing manager, or your care coordinator. The content can be anything the attacker wants it to be.
I have worked with home health agencies where physicians' offices received fraudulent payment requests appearing to come from the agency's billing department. Where patients received fake appointment confirmation emails appearing to come from the agency's scheduling coordinator, directing them to call a fraudulent phone number. Where hospital discharge planners received impersonated referral acceptance emails that were actually social engineering attempts to harvest credentials. Every one of these attacks was possible because the agency had not configured the three email authentication standards that together make domain spoofing technically impossible.
How Email Domain Spoofing Works Without These Controls
Email was designed in an era when identity verification was not a design consideration. The Simple Mail Transfer Protocol that underlies all email transmission allows the sender to specify any "From" address in an email regardless of which mail server actually sent the message. Without authentication controls, there is no mechanism for the receiving mail server to verify that the email claiming to be from "[email protected]" was actually sent by a mail server authorised to send email from "youragency.com." SPF, DKIM, and DMARC provide that verification mechanism — together, they create a cryptographic chain of authentication that allows receiving mail servers to confirm that an email claiming to be from your domain was actually sent by an authorised source.
SPF: Defining Who Is Authorised to Send From Your Domain
Sender Policy Framework is a DNS record — a text entry in your domain's DNS settings — that lists the IP addresses and mail servers authorised to send email from your domain. When a receiving mail server receives an email claiming to be from your domain, it checks your SPF record to determine whether the sending server is on the authorised list. If it is not, the email fails SPF authentication. An SPF record for a typical home health agency using Microsoft 365 looks like: "v=spf1 include:spf.protection.outlook.com -all" — this tells receiving servers that only Microsoft's mail servers are authorised to send email from your domain, and all other senders should be rejected.
DKIM: Proving Your Messages Have Not Been Tampered With
DomainKeys Identified Mail adds a cryptographic signature to every outbound email from your mail server. The signature is generated using a private key held by your mail server, and the corresponding public key is published in your DNS records. When the receiving mail server receives your email, it retrieves the public key from your DNS, uses it to verify the signature on the email, and confirms that the message content has not been altered since it was signed by your server. DKIM provides both sender authentication (the email was signed by your mail server) and message integrity (the content was not modified in transit).
DMARC: Tying It Together and Enforcing Policy
Domain-based Message Authentication, Reporting, and Conformance is the policy layer that ties SPF and DKIM together and tells receiving mail servers what to do with emails that fail authentication. A DMARC record at the "reject" policy setting — "v=DMARC1; p=reject" — instructs receiving mail servers to reject any email claiming to be from your domain that does not pass both SPF and DKIM authentication. This means that spoofed emails using your domain are rejected at the receiving server and never reach the recipient's inbox.
Do not jump directly to "reject" policy. Start with "p=none" (monitor mode) for two weeks to see which legitimate email sources may be failing authentication, then move to "p=quarantine" (send failing emails to spam folder) for two weeks, then to "p=reject." The gradual progression prevents legitimate email from being inadvertently blocked during configuration.
Protecting your home health agency does not have to be complicated. It has to be done — completely, correctly, and documented in a way that holds up when it matters. ShieldForce makes that possible for organisations without IT departments, without compliance staff, and without the budget of a hospital system. Start with a free assessment.
→ Schedule Your Free HIPAA Risk Assessment — shieldforce.io/hipaa-assessment
→ Explore Home Healthcare Cybersecurity — shieldforce.io/home-healthcare
→ View Transparent Pricing from $35/user/month — shieldforce.io/pricing-comparison