A HIPAA compliant email API is an email provider that signs a Business Associate Agreement (BAA) with you, protects the protected health information (PHI) that passes through it, and gives you the controls you need to meet your own obligations under the HIPAA Security Rule. No API is HIPAA compliant just by existing. HHS does not certify products, and private "HIPAA certifications" do not relieve you of your legal obligations (HHS). This page covers what the rules ask for when you send email through an API, what stays your responsibility whatever provider you pick, and how Volanea fits.

This is a technical guide, not legal advice. Have your privacy officer or counsel review your setup.

Why an email API is a business associate

A covered entity (a health plan, a clearinghouse, or a provider that bills electronically) has to sign a BAA with any vendor that creates, receives, maintains or transmits PHI on its behalf (HHS business associate guidance). Business associates have to sign one with their own subcontractors too. So if you are a health-tech SaaS that is already a business associate of a clinic, your email provider is your subcontractor and needs a BAA with you.

Some teams hope the "conduit exception" applies to email. HHS reads it narrowly: it covers transmission-only services, with only the temporary storage that transmission needs (HHS conduit FAQ). An email API keeps logs, delivery events and often message content, which goes well past that. HHS also says a cloud provider that stores ePHI is a business associate even if it cannot decrypt it (HHS cloud computing guidance). Treat your email provider as a business associate and sign the BAA before any PHI goes out.

What a HIPAA compliant email API needs

1. A signed BAA

HHS lists what the contract must cover. The business associate has to use appropriate safeguards (including the Security Rule's for ePHI), report improper uses and disclosures and security incidents, pass the same terms down to its subcontractors, and agree that the contract can be ended over a material breach (HHS sample BAA provisions). Read the provider's BAA for its scope too: which products and features it covers, and which ones you must not use with PHI.

2. As little PHI in the message as possible

The Privacy Rule's minimum necessary standard asks covered entities to make reasonable efforts to use and disclose only the PHI a purpose needs (HHS minimum necessary). For email, that comes down to design choices:

Subject lines. They show up in lock-screen notifications, inbox previews and the provider's logs. "Your test results are ready" is safer than "Your HIV test results are ready, Maria".
Bodies. Send a notice and a link to an authenticated portal instead of the clinical detail itself. A login link or one-time code gets the patient there (see magic link and OTP emails).
Metadata. Tags, custom headers and template variables are stored in delivery logs. Use opaque IDs, not diagnosis codes or names.
Recipients. Check the address before you send. HHS specifically suggests confirming addresses to avoid sending to the wrong person (HHS email FAQ).

An email that carries no PHI is the easiest one to defend.

3. Encryption in transit with TLS

The Security Rule's transmission security standard requires safeguards against unauthorized access to ePHI sent over a network. Encryption is an "addressable" specification under it (45 CFR 164.312). HHS is clear that addressable does not mean optional. You either put it in place or document why an equivalent alternative is reasonable (HHS technical safeguards). HHS has also proposed Security Rule changes that would make encryption of ePHI in transit and at rest required, with limited exceptions (HHS NPRM fact sheet). Check whether that rule is final when you read this.

An email passes over two links, and they need separate checks:

Your app to the API. This should be HTTPS, or SMTP with TLS. Amazon SES, for example, accepts API calls only over TLS 1.2 or 1.3 and requires TLS on its SMTP interface (AWS).
The provider to the recipient's mail server. SES uses opportunistic TLS by default here: it upgrades with STARTTLS when the receiving server supports it and otherwise sends unencrypted. A configuration-set option can require TLS instead, in which case SES drops a message it cannot deliver securely (AWS). The tradeoff is explained in opportunistic vs enforced TLS.

TLS protects the message in transit, not once it sits in the patient's mailbox. HHS allows providers to email patients with reasonable safeguards, and patients may choose unencrypted email after being told the risks (HHS email FAQ). Record that preference. For content that has to stay encrypted end to end, use a portal or S/MIME/PGP. See also email encryption.

4. Access controls

The Security Rule requires a unique identity for each user and access limited to people and software that have been granted rights (45 CFR 164.312(a)). For an email API, that means:

API keys kept server-side only, in a secrets manager, rotated when people leave or keys leak (handling API keys).
Separate keys per environment and per service, so you can revoke one without stopping everything.
Named dashboard accounts, with no shared logins, and two-factor authentication turned on (2FA).

5. Audit logging

You must have mechanisms that record and examine activity in systems that contain or use ePHI (45 CFR 164.312(b)). Keep your own application log of which user or job triggered which send, and when. Log message IDs, not content. Then stream the provider's delivery events into the same store through webhooks, so every delivery, bounce or complaint can be traced to the action that caused it.

6. Retention

HIPAA requires you to keep Security Rule documentation, such as policies, procedures and assessments, for six years from when it was created or last in effect (45 CFR 164.316(b)(2)). That rule covers compliance paperwork, not every email body. For message data, ask the provider how long it keeps content, logs and events. The less PHI it stores, the smaller any breach.

What stays your responsibility

Picking a provider that signs a BAA does not make your program compliant. Responsibility is split like this:

Area	Email provider	You
BAA	Signs it, honours its terms	Gets it signed before PHI flows; tracks it as a vendor
Message content	Delivers what you send	Decides what PHI goes in subjects, bodies and metadata
Transport	Uses TLS on its endpoints and outbound	Calls the API over TLS; chooses opportunistic vs enforced delivery
Access	Offers keys, roles, 2FA	Scopes keys, offboards people, protects secrets
Audit	Exposes logs and delivery events	Keeps its own audit trail and reviews it
Risk analysis	Secures its own systems	Runs the required risk analysis for your systems
Patient preferences	—	Records consent for unencrypted email and confidential-communication requests
Breach response	Reports incidents to you under the BAA	Assesses and notifies under the Breach Notification Rule

PHI encrypted to HHS's guidance counts as "secured", and a breach of secured PHI does not trigger notification (HHS breach guidance), which is one more reason to keep PHI behind an encrypted portal.

Email APIs and HIPAA compliance for hospitals

Hospitals send reminders, portal notices, statements, password resets and staff alerts. At that scale, a few points matter more:

Many senders, one domain. The EHR, the patient portal, the scheduling tool and the marketing team may all send as the hospital. Each vendor needs its own BAA, and each mail stream needs working SPF, DKIM and DMARC. You can check a domain with the DMARC checker.
Reminders can be PHI. A reminder tells the recipient that a named person is a patient of a named provider. Treat reminders as PHI unless counsel tells you otherwise, and keep the specialty out of the subject line.
Confidential-communication requests. If a patient asks not to be emailed, or rejects unencrypted email, your send logic has to check that preference before every message, not only during campaigns.
Transactional and marketing are different. Marketing communications have their own HIPAA authorization rules. Keep them on separate streams from care-related transactional email.

How Volanea fits

Volanea is a developer-first email platform for transactional email, campaigns and automation, built on Amazon SES.

BAA on request. Volanea supports HIPAA workloads and signs a Business Associate Agreement. Email hello@volanea.com to get one in place before you send PHI.
Built on SES. Amazon SES is on AWS's HIPAA Eligible Services Reference (last updated October 15, 2026), and AWS requires a BAA with AWS before those services handle PHI (AWS). AWS also says there is no HIPAA certification for cloud providers (AWS HIPAA), so Volanea does not claim one.
Useful controls. Each verified sending domain comes with SPF, DKIM and DMARC set up. You also get delivery-event webhooks for your audit trail, idempotency keys so retries do not send twice, and a suppression list with automatic bounce and complaint handling. The security page explains how Volanea protects data.

A send that keeps PHI out of the message looks like this:

async function notifyPortalMessage({ patientEmail, portalMessageId }) {
  const res = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      Authorization: "Bearer " + process.env.VOLANEA_API_KEY,
      "Content-Type": "application/json",
      // Stable key: a retry of the same notice will not send twice.
      "Idempotency-Key": `portal-msg:${portalMessageId}`,
    },
    body: JSON.stringify({
      from: "notifications@clinic.example",
      fromName: "Example Clinic",
      to: patientEmail,
      subject: "You have a new message in your patient portal",
      text: "Sign in to your patient portal to read it: https://portal.clinic.example/messages",
      html: '<p>Sign in to your patient portal to read it.</p><p><a href="https://portal.clinic.example/messages">Open the portal</a></p>',
    }),
  });
  if (!res.ok) {
    // Log status and your own IDs only, never the message content.
    throw new Error(`Send failed for portal message ${portalMessageId}: HTTP ${res.status}`);
  }
}

Every feature is on every plan, including Free. See pricing.

FAQ

Is there a HIPAA certified email API?

No. HHS does not certify products or recognize private "HIPAA certifications" as meeting your obligations (HHS). Look for a provider that signs a BAA and gives you the controls described above.

What makes a HIPAA email API different from a regular one?

The sending is the same. The difference is a signed BAA plus TLS, access controls, audit logs and clear retention terms.

Does Amazon SES support HIPAA?

Amazon SES is on AWS's list of HIPAA eligible services, and AWS requires a BAA with AWS before you use it with PHI (AWS). If you send through a platform built on SES, you need a BAA with that platform.

Can I put a patient's name or condition in the subject line?

Avoid it. Subject lines appear in notifications and logs. Use a neutral subject and link to an authenticated portal for the details, following the minimum necessary standard.

Is TLS enough for HIPAA email?

No. TLS covers transmission only, and opportunistic TLS can fall back to unencrypted delivery. Pair it with minimal PHI, a portal for sensitive content, and recorded patient preferences.

Does Volanea sign a BAA?

Yes. A BAA is available on request at hello@volanea.com. Sign it before any PHI goes through your account.

Ready to build? Create a free Volanea account, then email hello@volanea.com to put a BAA in place.

HIPAA Compliant Email API: What It Requires and Where Volanea Fits