SPF, DKIM, DMARC, BIMI, and MTA-STS: What Every Pediatric Practice Needs to Know About Domain Security in 2026

Hacking and IT incidents — including phishing — now account for more than 80% of large healthcare data breaches reported to HHS, with 725 large breaches reported in 2024 and a new record of 772 in 2025 (HIPAA Journal Healthcare Data Breach Statistics). The HHS Office for Civil Rights (OCR) received 663 breach notifications affecting 500 or more individuals in 2024 alone, exposing roughly 242.9 million records (HHS OCR 2024 Annual Report to Congress). Most of these incidents start the same way: a spoofed or phished email.

SPF, DKIM, DMARC, BIMI, and MTA-STS are the five DNS-based controls that determine whether your practice’s domain can be impersonated — and whether an attacker can intercept email carrying patient information in transit. For a pediatric practice, where staff routinely email referring physicians, insurance companies, labs, and parents, these controls are foundational, not optional.

Why This Matters More for a Pediatric Practice Than a Typical Small Business

Three structural facts make medical practices, including pediatric offices, a preferred phishing and spoofing target:

• A dense referral and vendor network. Pediatric practices email referring pediatricians, specialists, labs, insurance companies, and school offices constantly. Every one of those relationships is a potential impersonation target — a spoofed email that looks like it’s from “the lab” or “the specialist’s office” fits naturally into an already-busy inbox.
• Parents are conditioned to respond quickly to practice emails. Appointment reminders, portal notifications, and billing messages train parents to click links from what looks like their pediatrician’s office without much scrutiny — exactly the trust a spoofed email exploits.
• Every email touching a patient’s name, diagnosis, or account carries ePHI. Unlike a generic small business, a pediatric practice’s routine email traffic is itself regulated data. A single successful phishing email that harvests a staff login can expose the entire patient panel, not just one record.

HHS OCR has directly settled cases over exactly this failure mode: a $600,000 settlement followed a phishing attack that compromised a healthcare network’s patient data (HHS OCR press release). And the scale of a single incident can be enormous — one 2025 phishing incident at a business associate affected at least 25 cancer care and oncology practices in a single event, according to HIPAA Journal’s healthcare breach reporting (HIPAA Journal June 2025 Report). Phishing remains the top initial attack vector across all industries at 16% of breaches, with an average breach cost of $4.8 million, according to IBM’s 2025 Cost of a Data Breach Report (IBM Cost of a Data Breach Report 2025).

Domain authentication doesn’t stop a staff member from clicking a bad link inside a real-looking email. What it does stop is someone else successfully sending mail that appears to come from your practice’s domain — which is the exact mechanism behind the referral-network and vendor-impersonation phishing attacks that lead to exactly these kinds of breaches.

SPF: Sender Policy Framework

What it does: SPF is a DNS TXT record listing every mail server authorized to send email on behalf of your practice’s domain. When a receiving server gets a message claiming to be from yourpractice.com, it checks the SPF record to confirm the sending server is on the approved list.

What it doesn’t do: SPF only validates the sending server, not the “From” address a recipient actually sees. It’s also broken by email forwarding — a common source of false authentication failures on otherwise legitimate mail.

Common misconfiguration: Practices using a patient portal platform, an appointment-reminder service, a billing/clearinghouse system, and their primary email provider often forget to add every one of those services to the SPF record. Any omitted service either fails authentication or, worse, leaves an unmonitored gap a spoofer can exploit.

DKIM: DomainKeys Identified Mail

What it does: DKIM adds a cryptographic signature to outgoing email using a private key controlled by the sending domain. The receiving server checks that signature against a public key published in DNS — if the message was altered or wasn’t sent by an authorized system, the signature fails.

Why it matters more than SPF alone: DKIM survives most forwarding scenarios, since the signature travels with the message content rather than depending on the originating server’s IP address — important for a practice where staff frequently forward referral correspondence between providers.

Common misconfiguration: Practices that switch EHR or patient communication platforms often leave old DKIM keys active or forget to publish new ones for the replacement system, leaving legitimate mail unsigned.

DMARC: Domain-based Message Authentication, Reporting & Conformance

What it does: DMARC ties SPF and DKIM together and instructs receiving mail servers what to do when a message fails both checks. A DMARC policy has three levels:

Policy	What Happens to Failing Mail	Use Case
p=none	Nothing — message is delivered, but a report is generated	Monitoring phase; visibility without disruption
p=quarantine	Message is routed to spam/junk	Mid-rollout, once legitimate senders are confirmed passing
p=reject	Message is blocked entirely	Full enforcement; the goal state for every domain

Why enforcement matters: DMARC’s protection only activates at p=quarantine or p=reject. A domain sitting at p=none has visibility but zero actual protection against spoofed mail reaching an inbox. According to the EasyDMARC 2026 DMARC Adoption & Enforcement Report, global DMARC adoption across the top 1.8 million domains reached 52.1% in 2026, up from 27.2% in 2023 — but more than half of domains with a DMARC record remain stuck at p=none (EasyDMARC 2026 DMARC Adoption Report). Small independent medical practices are disproportionately represented among domains with no DMARC record at all.

Google, Yahoo, and Microsoft made this non-optional. Starting February 2024, Google and Yahoo began requiring any domain sending 5,000+ messages per day to personal Gmail or Yahoo accounts to have SPF, DKIM, and at minimum a p=none DMARC record, or face throttling and rejection (Google’s official bulk sender requirements). Microsoft added its own enforcement for outlook.com, hotmail.com, and live.com starting May 2025. A single pediatric practice rarely hits 5,000 emails/day directly — but any practice using a shared patient communication or appointment-reminder platform to reach parents may be aggregated into that vendor’s total sending volume.

BIMI: Brand Indicators for Message Identification

What it does: BIMI lets your practice’s verified logo appear directly next to your emails in supporting inboxes (Gmail, Yahoo, Apple Mail) — before a parent even opens the message. For a pediatric practice, this is a visible trust signal at the exact moment parents are being trained by phishing awareness campaigns to second-guess “your doctor’s office” emails.

Requirements:

1. DMARC must be at enforcement — p=quarantine or p=reject. A p=none policy is invisible to BIMI.
2. A specially formatted logo file (SVG Tiny PS format).
3. A certificate verifying your organization owns the logo — either a Verified Mark Certificate (VMC), which requires a registered trademark and typically costs $1,000–$1,500 per year through an approved Certificate Authority (DigiCert or Entrust), or a newer Common Mark Certificate (CMC), which Google introduced in 2025 and doesn’t require a trademark — just proof the logo has been in public use on the domain for at least 12 months (Google Workspace official BIMI setup guide).

Most independent pediatric practices don’t have a registered trademark on their logo, which makes the CMC path the realistic option for adding a verified brand presence to patient-facing email.

MTA-STS: The Layer Almost Everyone Forgets

SPF, DKIM, and DMARC all answer the same question: is this email really from who it claims to be from? None of them answer a separate, equally important question for a healthcare practice: is this email encrypted while it travels between mail servers?

That’s what MTA-STS (Mail Transfer Agent Strict Transport Security) does. Defined in RFC 8461, the official internet standard maintained by the IETF, MTA-STS publishes a DNS-and-HTTPS policy telling sending mail servers: “don’t deliver to us unless you can establish an encrypted TLS connection with a valid certificate.” Without it, standard email transmission (SMTP) allows encryption to be silently downgraded or stripped by an attacker on the network path — meaning a referral letter containing a patient’s diagnosis, or lab results sent by email, could theoretically be intercepted in plaintext between servers, even with SPF/DKIM/DMARC configured correctly.

For a pediatric practice routinely emailing referral letters, lab results, and insurance correspondence containing ePHI, MTA-STS closes a gap that identity-verification controls alone don’t address — and it’s a concrete, documentable technical safeguard a HIPAA risk analysis should account for.

The 5-Layer Email Security Stack

Layer	Protects Against	Requires
SPF	Unauthorized servers sending as your domain	DNS TXT record listing approved senders
DKIM	Message tampering in transit	Cryptographic signing key + DNS public key record
DMARC	Spoofed “From” addresses reaching the inbox	SPF + DKIM alignment, policy set to quarantine/reject
BIMI	Lack of visible trust signal in the inbox	DMARC at enforcement + VMC/CMC + hosted logo
MTA-STS	Interception/downgrade of ePHI in transit	DNS policy record + HTTPS-hosted policy file + valid TLS certs

The 90-Day Rollout Plan

Jumping straight to p=reject without preparation is the most common mistake practices make — it risks blocking legitimate mail from staff, your EHR vendor, patient portal, and billing clearinghouse.

Days 1–30 — Monitor:

• Publish SPF and DKIM for every legitimate sending source (email provider, EHR/patient portal, appointment-reminder service, billing clearinghouse)
• Publish a DMARC record at p=none to start collecting aggregate reports without disrupting mail flow
• Review DMARC reports weekly to build a complete inventory of every system sending mail as your domain

Days 31–60 — Quarantine:

• Once reports confirm all legitimate senders are passing SPF/DKIM alignment, move DMARC to p=quarantine at a low percentage (pct=25)
• Gradually increase to pct=100 over several weeks while monitoring for false positives, particularly from patient portal notification systems

Days 61–90 — Reject and Expand:

• Move to p=reject once quarantine has run cleanly with no legitimate mail flagged
• Publish an MTA-STS policy in “testing” mode, then move to “enforce” once TLS connectivity to your mail provider and key vendors is confirmed clean
• Apply for a VMC or CMC and publish your BIMI record now that DMARC is at enforcement

A Real Scenario: Referral Network Impersonation

A pediatric practice in Miami-Dade County with no DMARC enforcement in place received what appeared to be a routine message from a specialist’s office the practice regularly referred patients to, asking staff to send a batch of patient records to a “new secure portal” for an urgent case review. Because the practice’s domain — and the specialist office’s domain — both had SPF and DKIM published but DMARC set to p=none, there was no protection against a lookalike domain registered one character off from the real specialist office’s domain. Front-desk staff caught the request as unusual only because the “portal” link looked slightly off, not because any technical control flagged the message.

This is a critical nuance: DMARC protects your exact domain from being spoofed directly. It does not stop lookalike-domain attacks (a domain registered to look nearly identical to a real referral partner’s). For that risk, practices need a combination of DMARC enforcement on their own domain, staff training on verifying any request to change how or where patient records are transmitted by phone, and awareness that referral partners’ domains may not be protected even if yours is.

Checklist: Domain Security Audit

• Confirm SPF record includes every legitimate sending service (email provider, EHR/patient portal, appointment-reminder platform, billing clearinghouse)
• Confirm DKIM is configured and signing for every one of those same services
• Check current DMARC policy — if it’s p=none or missing entirely, you have zero enforcement today
• Review DMARC aggregate reports for unrecognized sending sources
• Confirm MTA-STS policy is published and set to “enforce,” not just “testing”
• Confirm TLS-RPT is configured to receive reports on any TLS connection failures
• Evaluate whether BIMI is worth pursuing (CMC path if no trademark, VMC if you have one)
• Establish a verbal-confirmation policy for any request — from staff, vendors, or referral partners — to change how patient records are transmitted, regardless of how legitimate the email looks
• Document domain authentication controls as part of your next HIPAA Security Risk Analysis

How ITva Helps Pediatric Practices Lock Down Domain Security

We handle the full SPF/DKIM/DMARC/BIMI/MTA-STS rollout as part of our managed IT service for pediatric practices — not as a separate line-item project:

• Full DNS audit and staged 90-day rollout from p=none to p=reject, so you’re never at risk of blocking legitimate patient portal, EHR, or vendor mail
• Weekly DMARC report review during the transition period to catch unauthorized senders early
• BIMI setup and VMC/CMC guidance so your practice’s logo displays correctly to parents once DMARC reaches enforcement
• MTA-STS and TLS-RPT configuration to protect referral letters, lab results, and other ePHI in transit
• HIPAA compliance expertise, so domain authentication controls are documented properly as part of your Security Risk Analysis
• 3.5-minute average ticket response time and 24/7 SOC monitoring if anything looks abnormal in your mail flow
• No long-term contracts and a 90-day satisfaction guarantee

Frequently Asked Questions

What’s the difference between SPF, DKIM, and DMARC?

SPF authorizes which servers can send mail for your domain. DKIM cryptographically signs messages to prove they weren’t altered in transit. DMARC ties both together and tells receiving servers what to do — deliver, quarantine, or reject — when a message fails those checks.

Is domain authentication actually a HIPAA requirement?

HIPAA’s Security Rule doesn’t name SPF, DKIM, or DMARC specifically, but it does require reasonable and appropriate technical safeguards against unauthorized access to ePHI. Since phishing and email spoofing are documented as leading causes of healthcare breaches, domain authentication controls are a concrete, auditable safeguard that a HIPAA Security Risk Analysis should account for.

Does DMARC stop a referral partner’s domain from being spoofed?

No. DMARC only protects the exact domain it’s published for. If a specialist’s office or lab you refer patients to doesn’t have DMARC enforcement on their own domain, their domain can still be spoofed regardless of what controls your practice has in place — which is why staff training on verifying unusual requests by phone matters alongside the technical controls.

What does BIMI actually require, and is it worth it for a small practice?

BIMI requires DMARC at enforcement, a properly formatted logo file, and a certificate — either a Verified Mark Certificate (roughly $1,000-$1,500/year, requires a trademark) or a newer, no-trademark-required Common Mark Certificate that Google introduced in 2025. Most independent pediatric practices don’t have a registered trademark, making the CMC path the practical option.

What is MTA-STS and why does it matter for a medical practice specifically?

MTA-STS encrypts email in transit between mail servers, protecting against interception — a different problem than SPF/DKIM/DMARC, which verify sender identity. For a practice regularly emailing referral letters and lab results containing ePHI, it closes a gap that identity-verification controls alone don’t address.

How long does a full domain security rollout take?

A properly staged rollout — from initial SPF/DKIM setup through DMARC monitoring, quarantine, and full enforcement, plus MTA-STS and BIMI — typically takes about 90 days done correctly. Rushing straight to enforcement without the monitoring phase risks blocking legitimate mail from your EHR vendor, patient portal, or billing clearinghouse.

Get a Free Domain Security Audit

Not sure where your practice’s domain security actually stands? Book a free assessment and we’ll run a full SPF/DKIM/DMARC/MTA-STS audit and show you exactly what’s exposed. Or call us directly at (305) 629-5925.