How to Implement SPF, DKIM, and DMARC for Secure Healthcare Emails

Email is still one of the most common ways healthcare teams share schedules, referrals, billing updates, lab notifications, and links to patient portals. That makes it a favorite entry point for spoofing, phishing, and business email compromise, especially when messages appear to come from a trusted clinic or hospital domain.

SPF, DKIM, and DMARC do not replace encryption, access controls, or staff training. What they do is make it much harder for attackers to impersonate your organization and trick patients, vendors, or employees into handing over credentials or sending PHI to the wrong place.

Why healthcare email authentication gets complicated fast

Healthcare environments rarely send mail from just one platform. A typical Sacramento area practice might use Microsoft 365 for staff mailboxes, a patient engagement platform for reminders, a clearinghouse for billing notices, and a cloud fax vendor that still sends “email-like” delivery notifications.

When even one of those senders is not covered by your DNS authentication records, receivers may treat your mail as suspicious. If you later enforce DMARC without inventorying every sender, you can also block legitimate messages that patients and partners rely on.

Here are the pressure points most often seen in PHI workflows:

• Multiple sender systems: EHR/EMR modules, marketing tools, ticketing systems, and scan-to-email devices.
• Vendor constraints: Some vendors cannot sign with your domain unless you configure a custom sending domain.
• Brand protection risk: Attackers spoof “From:” addresses to request records, reroute payments, or harvest logins.

SPF: authorize where your domain is allowed to send from

SPF (Sender Policy Framework) is a DNS TXT record that tells receiving mail systems which servers are allowed to send mail using your domain in the envelope sender (the “MailFrom” / Return-Path domain). If a message claiming to be from your domain comes from a server not listed in SPF, SPF fails.

A simple Microsoft 365 SPF record often looks like this:

If you also send from Google Workspace or other services, you add more mechanisms and includes. The catch is that SPF has sharp edges: only one SPF record is allowed per domain, SPF evaluation is limited to 10 DNS lookups, and long records can exceed common DNS limits if not formatted correctly.

After you publish or update SPF, you should validate it using (or a reputable checker) and confirm that real outbound mail sources pass.

Common SPF “gotchas” tend to repeat:

• Two SPF TXT records on the same domain: Receivers may treat this as a permanent error and ignore SPF.
• Too many lookups: Long include chains can exceed the 10-lookup limit and cause SPF to fail.
• Missing senders: A forgotten appointment reminder service can break deliverability once DMARC is enforced.

DKIM: prove the message was authorized and not altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages. Receivers fetch the public key from DNS and verify the signature. This gives integrity protection for the message and provides another path to passing DMARC, even when SPF is imperfect due to forwarding or routing changes.

DKIM is published as a TXT record at a selector under , like:

The record contains your public key and parameters, while the private key stays on the sending system (or in your mail provider). Most healthcare organizations should use 2048-bit keys when supported, and they should plan for key rotation rather than leaving a selector unchanged for years.

In Microsoft 365, DKIM commonly uses CNAME records that point your selectors to Microsoft-hosted DKIM keys. In Google Workspace, you generate a key in the admin console and publish the TXT record it provides.

A practical DKIM checklist helps keep things clean:

• Key length: Prefer 2048-bit when available.
• Selectors: Use a naming pattern that supports rotation (example: ).
• Coverage: Make sure every system that sends as your domain signs with DKIM, not only user mailboxes.

DMARC: tell receivers what to do when SPF and DKIM fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM results to what the user actually sees in the “From:” header. That last part matters in healthcare because spoofing is usually a display-name and From-address trick, not a technical Return-Path detail.

DMARC answers two questions:

1. Did SPF or DKIM pass and align with the From domain?
2. If not, what should the receiver do with the message?

A DMARC record is a DNS TXT record at , containing a policy and reporting addresses. A starter record for monitoring is often:

DMARC “pass” requires that either SPF or DKIM passes with alignment. DMARC “fail” means both failed (or did not align), and the receiver can quarantine or reject based on your policy.

After you publish DMARC, you start receiving aggregate XML reports (RUA). These reports are extremely useful, but they need processing and review. Many organizations route them to a parser or managed service rather than trying to read raw XML in a mailbox.

A staged rollout plan that protects PHI without breaking delivery

Moving straight to can be the right end state for many healthcare domains, but it should be earned through inventory, testing, and reporting review. When PHI-related emails are at stake, “almost correct” is not correct enough.

A workable rollout typically follows three steps:

1. Inventory every sender: Microsoft 365, Google Workspace, cloud fax notices, patient reminders, billing platforms, website forms, scanners, and any SMTP relays.
2. Fix alignment: Make sure the From domain matches what SPF and/or DKIM authenticate. This is where third-party platforms often need a custom sending domain.
3. Increase DMARC enforcement: none → quarantine → reject, with monitoring at each stage.

The table below shows a conservative policy progression that reduces risk while giving time to remediate unknown senders.

If your organization uses subdomains for vendors or portals, consider an explicit subdomain policy (). That avoids a situation where a forgotten subdomain becomes the weak link.

Record examples you can adapt (with healthcare-specific senders in mind)

Below is a simple reference table for what the records might look like. Treat these as patterns, not copy-and-paste answers, because your sender list drives the final content.

Two alignment settings are worth calling out:

• controls SPF alignment (relaxed or strict )
• controls DKIM alignment (relaxed or strict )

Relaxed alignment is common during rollout. Strict alignment can be appropriate later if your mail streams are well-controlled and standardized.

Operational safeguards that keep authentication from drifting

Email authentication is not a “set it and forget it” task. Healthcare environments add vendors, switch patient engagement platforms, and change fax services. Any of those can introduce a new sender that starts failing DMARC.

A simple operating rhythm reduces surprises:

• Change control: Treat new email-sending tools like any other system that touches PHI, with a formal review before go-live.
• Weekly checks: Review DMARC aggregate trends and investigate new sources promptly.
• Key rotation: Rotate DKIM selectors on a schedule, and after any suspected compromise.
• DNS hygiene: Lock down DNS access, log changes, and avoid ad hoc edits from multiple admins.

When bulletproofing an environment, these are the recurring issues to hunt down first:

• Split-brain sending (some mail signs DKIM, some does not)
• SPF flattening done incorrectly
• Forwarding that breaks SPF with no DKIM fallback
• Vendors sending “as you” without alignment support

Microsoft 365, Google Workspace, and mixed environments

Many healthcare organizations run Microsoft 365 for mailboxes, plus other systems that send transactional email. Your goal is consistency: every sender should authenticate, and at least one of SPF or DKIM should align with the From domain for DMARC.

After you confirm mailbox mail is passing, prioritize third-party and “appliance” senders. Scanners, copiers, and legacy apps often send unauthenticated SMTP directly to the internet, which will not survive a strict DMARC policy.

A practical way to organize that work is to group senders by how they authenticate:

• Microsoft 365 / Exchange Online: Enable DKIM for each custom domain and confirm SPF includes .
• Google Workspace: Publish the DKIM key from the admin console and confirm SPF includes .
• Third-party platforms: Prefer a custom sending domain with DKIM signing rather than shared pools that cannot align.
• On-prem relays and devices: Route through an authenticated relay that can sign DKIM or otherwise keep alignment intact.

Monitoring and reporting without creating new compliance risk

DMARC reports can include message metadata and IP addresses. In healthcare, treat report handling like any other security telemetry: restrict access, retain only what you need, and document the purpose.

Many organizations use a DMARC analytics platform to parse XML and provide dashboards. If you use an outside provider and your organization treats the data as sensitive, involve compliance and confirm whether a BAA is required based on your risk posture and vendor relationship.

A SOC-led monitoring approach can also be helpful when DMARC failures spike, since spikes can correlate with phishing campaigns targeting clinic staff and patients. Business PC Support, as a Sacramento-based managed IT services provider with SOC capabilities, often sees better outcomes when email authentication data is reviewed alongside mailbox audit logs, sign-in activity, and endpoint alerts rather than sitting in an unattended mailbox.

After your baseline is stable, set alerting thresholds. A sudden increase in DMARC failures for your primary domain, or a new sender appearing in reports, should generate a ticket and a short investigation.

Quick reference: what “good” looks like

Once SPF, DKIM, and DMARC are configured correctly, you should be able to answer these questions with evidence from headers and reports.

• SPF: Does the message show for the expected sending service?
• DKIM: Is there a with a domain that matches your From domain (or aligns by policy)?
• DMARC: Are you seeing for normal workflows, and are spoof attempts being quarantined or rejected?

After that, the work becomes mostly operational: keeping your sender inventory current, rotating keys, and making sure new healthcare workflows do not quietly bypass authentication.