Healthcare SaaS — HIPAA-Compliant Transactional Email Infrastructure

A US-based healthcare SaaS platform serving 800,000 patients across 47 states delivers appointment reminders, test result notifications, and prescription refill alerts on behalf of the hospital networks and independent clinics that license the software. In mid-2023, the platform's internal analytics team confirmed what clinical operations had suspected for months: 22% of messages sent to Gmail inboxes were being classified as spam, with Outlook placement at 32% and a slow decline on Yahoo. Lab result notifications — the highest-stakes message type in the product — were among those routinely filtered to junk.

Email in this context is not marketing. A missed appointment reminder results in a clinic no-show. A missed prescription refill reminder can delay medication adherence. A missed lab result notification can, in the worst case, delay a patient learning about an abnormal finding. Under HIPAA, healthcare communications containing references to treatment or patient identifiers must be handled with demonstrable encryption in transit and documented processor relationships. The platform's shared-ESP configuration met neither requirement at the level the compliance team needed for their annual audit.

The first priority was not full migration; it was stabilizing the highest-risk message types — lab results and prescription refill alerts — on clean infrastructure before the next weekly batch was due. The full cutover would follow once the clean path had been proven under real load.

1. Day 1–2: Clean IP provisioning and BAA execution

   Provisioned 3 dedicated IPs on US-East infrastructure with DPA and BAA signed before any traffic was routed. Configured mandatory TLS 1.2+ with opportunistic fallback disabled — connections that could not negotiate TLS would defer rather than send in plain text. Authentication baseline: SPF with explicit IP inclusion, DKIM with 2048-bit keys, DMARC staged at p=none during the ramp.

2. Day 3–5: Lab results and prescription alerts migrated

   The two highest-stakes message types were routed to the new IPs first, as a controlled canary. Volume was capped at 40,000 per day during the initial warmup, which was sufficient for these two categories alone. Gmail inbox placement for this narrow message mix reached 97% by Day 5, confirming the infrastructure was sound and the previous failure was a reputation problem, not a content problem.

3. Day 6–9: Appointment reminders migrated, DMARC advanced

   With reputation established on the canary streams, appointment reminders (the highest-volume category, roughly 60% of total traffic) were migrated across two days. DMARC was advanced to p=quarantine with pct=25, monitoring for any legitimate-but-misaligned sources. The aggregate reports surfaced two: a legacy billing integration and an EU-based customer support tool. Both were fixed before further DMARC progression.

4. Day 10–12: Full cutover and p=reject

   All remaining transactional email was migrated. DMARC advanced to p=reject. Administrative email (internal reports, partner communications) remained on a separate dedicated IP, fully isolated from patient-facing reputation. Total migration from first traffic to full cutover: 12 business days.

Technical Assessment: Infrastructure Layers Examined

The pre-migration audit covered four layers that are typical for any healthcare-email engagement: authentication and identity (SPF, DKIM, DMARC alignment), transport security (TLS negotiation rates, cipher suites in use), reputation signals (Postmaster Tools, SNDS, blacklist check across 50+ DNSBLs), and operational practices (list hygiene frequency, bounce processing latency, complaint feedback loop enrollment). Three of the four had material findings.

IP Pool Architecture

The shared IP pool the platform had been using served 140+ other senders at the same ESP — a mix of retail, finance, and B2B SaaS. The pool's reputation was an aggregate of that mix. When a retailer on the same pool ran a reactivation campaign that produced a 0.3% complaint rate, the pool's Gmail sender score dropped from 88 to 62 within 72 hours. Every sender on that pool — including the healthcare platform — saw inbox placement degrade immediately. The platform had no visibility into the root cause because the contaminating sender's traffic was not theirs to inspect.

The post-migration architecture isolated patient-facing transactional traffic on 3 dedicated IPs, administrative email on 1 separate IP, and reserved 1 additional IP for future provider-facing communications (clinic staff notifications, API alerts). The cardinality matters: with 4.2 million messages per month concentrated on 3 production IPs, each IP handled roughly 47,000 messages per day — well within Gmail's per-IP engagement-aware throttle windows for an IP with established reputation.

PowerMTA Domain Block Configuration

The domain block configuration was calibrated per-ISP based on observed deferral rates during the canary phase. Gmail and Yahoo received conservative throttles during the first two weeks (50 connections max, 100 messages per connection, backoff on 421 deferrals). Outlook received a separate configuration reflecting Microsoft's different retry expectations. The domain blocks are not a set-and-forget configuration — they are adjusted quarterly based on accounting log analysis of deferral patterns and Postmaster Tools feedback.

Authentication Upgrade

The DKIM key in use was 1024-bit, below the current ISP recommendation of 2048-bit minimum. Gmail and Yahoo have both indicated they intend to deprecate 1024-bit key validation within their verification pipelines. The migration included generation of a new 2048-bit RSA key with a dated selector (healthcare-2024-q3) and DNS-level deployment with a 72-hour overlap period during which both keys signed outbound traffic to avoid verification gaps at verifiers that might still be caching the old selector.

Infrastructure Rebuild: Configuration Decisions

The three non-obvious configuration decisions that had the largest operational impact:

TLS enforcement over opportunistic encryption. The pre-migration TLS rate was 45%, meaning 55% of patient notifications were delivered in plain text whenever the receiving MTA did not advertise STARTTLS. For HIPAA-regulated content, this is unacceptable. The PowerMTA configuration was set to require TLS 1.2 or higher on every outbound connection, with deferrals rather than plaintext fallback. The practical cost: a small number of messages (0.04% of volume) to recipients at receiving MTAs without TLS support were delayed or bounced. The compliance benefit: 100% of delivered patient messages are now encrypted in transit, demonstrable in accounting logs for audit.

Subdomain separation for DMARC. Patient-facing mail sends from notifications.platform.com, administrative mail from admin.platform.com, and the parent domain platform.com is protected by an independent DMARC record with sp=reject. This means an attacker spoofing any subdomain is rejected by recipient policy, regardless of whether they target the parent or a child. The subdomain split also meant the DMARC aggregate reports were cleanly segmented by business function — reputation signals for patient communications could not be conflated with signals from administrative or provider traffic.

Complaint feedback loop enrollment across all major ISPs. FBL processing was enabled on every IP from Day 1, with automated suppression of any complainant within 15 minutes of complaint receipt. For a healthcare platform, a patient who marks a notification as spam is almost always expressing a preference about notification frequency or channel — not the content. Rapid suppression prevents repeat complaints from the same recipient from compounding the IP's reputation damage. Monthly review of FBL data surfaces delivery-setting patterns that inform the product team's notification preferences UI.

Operational Monitoring: What Changed Permanently

The infrastructure migration was one half of the engagement. The operational practices put in place to prevent recurrence were the other half.

Daily Postmaster Tools and SNDS review. Google Postmaster Tools and Microsoft SNDS are now reviewed at start of every business day by the managed-services team. Any metric drift (sender reputation from High to Medium, spam rate above 0.1%, authentication failure above 0.5%) triggers an alert within 4 hours rather than being discovered at the next weekly report. For a healthcare platform where each day of degraded delivery compounds patient-safety risk, the monitoring cadence had to match the stakes.

Quarterly list hygiene audits. Hard bounces are removed within 24 hours, but passive signals (no opens in 180 days for a patient who had previously engaged) are surfaced for business review quarterly. The platform's product team decides whether to archive, deactivate, or re-engage such accounts based on the patient's relationship status with the underlying clinic. This is not an automated suppression decision because a patient who has not opened a reminder in six months may still need to receive their next lab result notification. The decision is contextual to the patient's clinical status.

Monthly bounce pattern analysis. Accounting log review distinguishes transient deferrals (which recover with retry) from structural failures (which indicate a receiving infrastructure change). When Microsoft changed its greylisting thresholds in early 2024, the monthly review caught the shift within 10 days and the PowerMTA configuration was adjusted before any meaningful delivery delay was observable at the business level.

Healthcare-adjacent email has asymmetric risk: a 1% spam placement rate that would be acceptable for a retail newsletter is a patient-safety event when the message is a lab result notification. The infrastructure decisions that meet this standard — dedicated IPs, enforced TLS, separation of transactional and administrative streams, DMARC at p=reject with subdomain protection — are not advanced features. They are the minimum baseline for any healthcare or compliance-regulated sender above 500,000 messages per month.

The contaminating cause in this engagement was not a content problem, not a list-quality problem, and not an authentication problem. It was a co-tenant problem: the platform was being penalized for the behaviour of senders it did not control and could not inspect. Shared IP pools are adequate for low-volume marketing. For regulated transactional email at any meaningful scale, they are a structural risk that surfaces without warning.