HIPAA email security requirements for medical practices — what you actually need

If you run a medical practice, you've probably seen the term "HIPAA email compliance" thrown around by IT vendors and consultants. Half of them will sell you expensive software. The other half will terrify you into inaction with vague warnings about fines.

This article skips both of those. Here's a plain-English breakdown of what HIPAA actually requires for email security, what the real risks are, and what your starting point should look like.

What HIPAA says about email (the short version)

HIPAA's Security Rule requires "covered entities" — including medical practices — to implement technical safeguards to protect electronic Protected Health Information (ePHI). When it comes to email, the key requirements are:

• Encryption in transit — emails containing PHI must be encrypted when transmitted
• Access controls — only authorized individuals should be able to access PHI
• Audit controls — you should be able to log and review access to ePHI
• Integrity controls — ensure ePHI isn't altered or destroyed
• Business Associate Agreements (BAAs) — if you use a third-party email provider, you need a signed BAA with them

HIPAA doesn't name specific technologies. It specifies outcomes. That's why there's so much confusion — there's no single checklist that satisfies every auditor. But the technical foundations are well understood.

The email risk most practices overlook: spoofed emails

Here's the connection most guides miss: HIPAA compliance isn't just about encrypting outbound emails. It's also about preventing your domain from being used to expose PHI through attacks you didn't send.

Consider this scenario: A scammer spoofs your practice's email domain and sends a phishing email to your patients. The email looks like it came from your office — your name, your domain. It asks patients to "verify insurance information" through a fake portal. Patients fill it out, exposing their PHI.

Your domain was the delivery mechanism. Your practice gets the reputational fallout. And depending on how the breach is characterized, your practice may bear compliance liability even though you never sent the email.

This isn't hypothetical. Healthcare is the most frequently targeted sector for Business Email Compromise (BEC) attacks, according to the FBI.

Why SPF, DKIM, and DMARC matter for HIPAA

SPF, DKIM, and DMARC are three DNS records that protect your domain from being spoofed in email. They don't encrypt email content — but they prevent bad actors from sending email that impersonates your domain.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain. Without SPF, any server in the world can send email that claims to be from [email protected].

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your outbound emails. When an email arrives, the receiving server checks the signature against a public key in your DNS. If the signature doesn't match, the email fails the check. This also proves that your emails weren't tampered with in transit — directly relevant to HIPAA's integrity requirement.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC is the policy layer on top of SPF and DKIM. It tells receiving servers what to do when an email fails authentication: monitor only (p=none), send to spam (p=quarantine), or reject outright (p=reject).

A DMARC policy set to p=reject means a spoofed email pretending to be from your practice will be blocked before it ever reaches a patient's inbox. This is a meaningful safeguard against PHI exposure through phishing attacks impersonating your domain.

What auditors actually look for

When a HIPAA auditor or cybersecurity assessor reviews your email environment, they typically check:

• Does your email provider have a signed BAA with you? (Google Workspace, Microsoft 365, and most enterprise providers offer this — but you have to request it.)
• Is email encrypted in transit? (Most modern email providers handle TLS by default, but it should be verified.)
• Is PHI encrypted at rest? (A harder requirement — often requires a dedicated HIPAA-compliant email solution if you're sending clinical information.)
• Are SPF, DKIM, and DMARC configured? (Increasingly common as a baseline check.)
• Do employees know not to send PHI through regular email? (Training records matter.)
• Is there a documented email security policy? (Even a one-page policy is better than nothing.)

The practical email setup for a small medical practice

Here's what a reasonably compliant email posture looks like for a small practice (2–50 employees):

1. Use a major, HIPAA-eligible email platform — Google Workspace Business or Microsoft 365 Business, both of which offer signed BAAs and encrypt email in transit.
2. Sign a Business Associate Agreement with your email provider. This is a paperwork step that most practices skip. Don't skip it.
3. Configure SPF, DKIM, and DMARC on your domain. Your IT provider or email platform's help documentation will walk you through this. It takes less than an hour.
4. Avoid sending PHI via regular email. Use a patient portal, encrypted messaging, or a HIPAA-compliant secure messaging tool for anything clinical.
5. Train staff on what can and can't go in email. One phishing awareness session per year, documented, goes a long way with auditors.

Start with a domain scan

Before you do anything else, find out where your domain stands. Many practices think they're protected because they use Microsoft 365 or Google Workspace — but those platforms don't automatically configure SPF, DKIM, and DMARC for you. You have to set them up.

The bottom line

HIPAA email compliance isn't a single product you buy — it's a combination of platform choices, configuration, and practices. The most commonly missing piece for small medical practices is basic domain security: SPF, DKIM, and DMARC configured and enforced.

It costs nothing. It takes less than an hour to set up. And it closes one of the most significant risk gaps your practice likely has today.

Related: What is DMARC — and why does every small business need it?

Also: SPF, DKIM, and DMARC explained in plain English