# HIPAA-Compliant Email Marketing: Choose the Right CRM and Sending Route HIPAA-compliant email marketing requires an allowed use of patient information, an appropriate business associate agreement with the services handling it, and a configuration that stays within those services' limits. Choose the communication's purpose before choosing the platform. Then check the actual recipient list, template, links, integrations and reporting route. A signed BAA does not make every campaign or feature permissible. [HHS marketing guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/marketing/index.html), [business associate contracts](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html). Canonical URL: https://www.martechdevs.com/blog/hipaa-compliant-email-marketing By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo) Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com) [LinkedIn](https://linkedin.com/in/jafrinalo) Last updated: 2026-10-25 Next step: [Braze vs Reteno for Subscription Apps: Pricing, RevenueCat and Migration](https://www.martechdevs.com/blog/braze-vs-reteno) This guide addresses US HIPAA-regulated healthcare organisations and their service providers. Privacy counsel should approve the campaign classification and applicable federal and state requirements; marketing operations and engineering should demonstrate that the implementation follows that decision. The central buying question is specific: can this product, on this plan, in this configured account, process this data for this communication? “The vendor works with healthcare companies” does not answer it. Nor does removing a diagnosis from the subject line if the audience itself identifies patients receiving a particular treatment. ## When can a healthcare team email patients? Classify the communication by its purpose, recipient and any third-party payment involved. HIPAA's definition of marketing concerns communications encouraging use or purchase of a product or service, with specified exceptions for treatment and certain healthcare operations. Financial remuneration can change the treatment of those exceptions; refill reminders have their own cost-related condition. [45 CFR 164.501](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.501). Uses or disclosures of PHI for marketing generally require a valid authorisation. The narrow face-to-face and nominal-gift exceptions do not turn an ordinary email campaign into an exempt communication. Where applicable third-party remuneration is involved, the authorisation must disclose it. [45 CFR 164.508](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508). Use this triage table to take a proposed campaign to the privacy owner. It is a review method, not a substitute for classifying the actual facts. | Proposed communication | First question | Operational consequence | | --- | --- | --- | | Reminder for a booked appointment | Is this the actual treatment-related reminder? | Use the approved reminder route and communication preference | | Follow-up about an existing care plan | Who approved the care purpose and content? | Preserve the clinical instruction without adding unrelated promotion | | Promotion for another organisation's product | What PHI and remuneration are involved? | Hold until the authorisation and disclosure requirements are resolved | | General newsletter | How was the audience obtained, and does membership reveal a care relationship? | Review the audience and processing, even if the copy is general | HHS explicitly treats appointment reminders as treatment communications that can be made without an authorisation. That does not remove the need for an appropriate delivery arrangement and safeguards. [Appointment-reminder guidance](https://www.hhs.gov/hipaa/for-professionals/faq/are-appointment-reminders-allowed-under-hipaa-without-authorization/index.html). Keep a campaign's approved purpose in its operating record. A “recall” label is not enough if the message actually promotes a new paid service. When the offer, sponsor, audience rule or content changes, send the revised campaign back for classification instead of inheriting the old approval. Do not confuse an email opt-in with a HIPAA authorisation. The latter has specific required content, including the information, use or disclosure, parties, expiry and signature, as applicable. Record the approved evidence and handle withdrawal under the governing policy. [Authorisation requirements](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508). ## Which CRM and email tools support the required arrangement? Several vendors offer a BAA, but their permitted data and features differ substantially. Compare the exact product boundary before comparing price. The rows below identify an evaluation route; your executed agreement and configuration still need to cover the proposed work. | Product | Published route | Important boundary | Evaluate it when | | --- | --- | --- | --- | | HubSpot | Enterprise subscription with Sensitive Data setup and applicable BAA | Only permitted data in covered features | CRM processes and restricted healthcare information need one operating system | | Customer.io | BAA available on Premium and Enterprise | Confirm the actual messaging and integration scope | Event-driven lifecycle work needs a defined health-data arrangement | | Paubox Marketing | BAA included with accounts | Review the authorised campaign and connected systems | Secure patient email is the primary requirement | | Braze | Order-designated HIPAA account on its HIPAA cluster | No medical records/images; no diagnoses or test results in messages | Engagement work fits those explicit restrictions | | Constant Contact email marketing | Its standard BAA on request | Contact/relationship context only; no broader patient health detail | Generic outreach fits a deliberately narrow data scope | Sources for the eligibility and restriction columns: [HubSpot setup](https://knowledge.hubspot.com/account-security/store-sensitive-data), [HubSpot terms](https://legal.hubspot.com/sensitive-data-terms), [Customer.io plan features](https://docs.customer.io/accounts/billing/plan-features/), [Paubox Marketing](https://www.paubox.com/pricing/paubox-marketing), [Braze BAA](https://www.braze.com/company/legal/baa), [Constant Contact BAA](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/6240-Business-Associate-Agreements-BAAs?lang=en_US). ### What should a HubSpot healthcare account check? A Super Admin must enable Sensitive Data, select both Health/Medical Data and the HIPAA-covered-entity/business-associate option, and accept the applicable terms. Classify permitted PHI properties and restrict access. The feature is offered across specified Enterprise subscriptions; buying an ordinary paid account is insufficient. [HubSpot Sensitive Data setup](https://knowledge.hubspot.com/account-security/store-sensitive-data). Sensitive Data properties cannot be used in personalisation tokens, chatbots, playbooks or sandboxes. Workflows can use them in filter-based enrolment and branches, but not in copy-property actions, sensitive personalisation tokens or event-occurs triggers based on their value changes. Do not copy a protected value into an ordinary field to bypass those limits. [HubSpot tool restrictions](https://knowledge.hubspot.com/account-security/sensitive-data-in-hubspot-tools). Design properties before importing. HubSpot's normal rule fixes sensitivity at creation, while a beta allows conversion of specified existing custom field types after incompatible uses are removed. Selected data categories cannot simply be removed. Turning protection off is another beta that requires deleting PHI and Highly Sensitive properties first. Treat any such change as a controlled data migration, not a quick campaign fix. [Property and protection controls](https://knowledge.hubspot.com/account-security/store-sensitive-data). HubSpot's legal terms limit permitted sensitive data to expressly covered features and leave third-party products under their own policies. Match the actual workflow to that covered-service list. [Sensitive Data terms](https://legal.hubspot.com/sensitive-data-terms). Use [HubSpot's pricing model](https://www.martechdevs.com/blog/hubspot-pricing) only after the functional and contractual boundary is settled. ### What distinguishes the other eligible routes? Customer.io's Premium and Enterprise plans allow a BAA. Its security guidance recommends keeping sensitive health details behind an authenticated area, with email directing the recipient there. That is a useful design to evaluate for general reminders; it does not make an identifying notification or its recipient list anonymous. [Plan eligibility](https://docs.customer.io/accounts/billing/plan-features/), [email security guidance](https://customer.io/legal/security). Paubox Marketing expressly supports personalised emails containing PHI, enforces TLS for campaigns and includes a BAA with accounts. Its free entry covers 100 contacts. Confirm that the approved use, sender, integrations and recipient handling fit your organisation before scaling it. [Paubox Marketing features](https://www.paubox.com/pricing/paubox-marketing). Braze's BAA requires an instance marked HIPAA-eligible on the order and provisioned on the HIPAA cluster. It excludes medical records and images and prohibits messages with diagnoses, test results or similar sensitive medical information. It is intended for engagement rather than patient treatment. A standard Braze account cannot inherit those permissions from the brand's healthcare positioning. [Braze's contractual boundaries](https://www.braze.com/company/legal/baa). Constant Contact signs only its standard BAA and permits the limited fact that subscribers may have a relationship with your business. It excludes additional PHI and sensitive health information. That makes it a possible generic-newsletter route, not a condition-based patient database. [Constant Contact's permitted use](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/6240-Business-Associate-Agreements-BAAs?lang=en_US). ### What about Mailchimp and Klaviyo? Do not place either on an approved patient-data shortlist without establishing the required contractual scope. Mailchimp's standard terms put HIPAA suitability on the customer and disclaim responsibility if the service does not meet it; those terms do not establish a BAA arrangement. A generic newsletter design is not permission to import a patient list. [Mailchimp terms](https://mailchimp.com/legal/terms/). Klaviyo's help centre says sensitive personal information, including health data, cannot be collected or stored in the platform. Its acceptable-use policy also restricts specified medical and telehealth offerings. Do not use a wellness-industry landing page as approval for patient information. [Klaviyo sensitive-data restrictions](https://help.klaviyo.com/hc/en-us/articles/360035875272), [acceptable-use policy](https://www.klaviyo.com/legal/acceptable-use-policy). At Martechdevs, [CRM and lifecycle implementation](https://www.martechdevs.com/crm-lifecycle) can turn the approved boundary into field mappings, access controls, sending rules and verification evidence. The platform decision should follow that boundary, not force the privacy review to accommodate a tool already purchased. ## What can reveal patient information outside the email body? Inspect the recipient relationship and metadata as carefully as the visible message. HIPAA protects individually identifiable information about health, care provision and payment within its scope; an email address alone is not automatically PHI in every context, but its association with a care relationship can matter. [HHS Privacy Rule summary](https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html). The following are exposure paths to review, not declarations that every occurrence has the same legal classification: | Location | Example of unnecessary disclosure | Safer implementation direction | | --- | --- | --- | | Segment name and membership | A named person in a diagnosis-based audience | Restricted eligibility record; neutral operational label | | Subject and preview text | Treatment or test-result detail on a shared screen | Minimal approved notification; secure destination where appropriate | | Link path and query string | Patient ID, service name or diagnosis in a URL | Approved neutral route with no clinical parameters | | Integration logs | Full patient profile attached to a failed send | Restricted evidence with only required diagnostic fields | | Reporting export | Patient-level click data copied into an ordinary dashboard | Approved reporting recipient and necessary aggregation | Renaming a segment does not change what its membership reveals. A neutral campaign code can reduce accidental exposure in tools and screenshots, but a dataset mapping that code to identifiable patients remains subject to its actual classification. Do not send the whole electronic health record to a CRM because the connector supports it. For each field, record the communication it enables, who can access it, how long it is needed and where it goes next. A failed-email investigation rarely needs the patient's clinical notes. Data minimisation is a useful engineering default, but do not misstate the legal rule. HIPAA's minimum-necessary standard has exceptions, including authorised uses/disclosures, disclosure to the individual and certain treatment disclosures. The approved purpose, safeguards and vendor restrictions still govern the implementation. [HHS minimum-necessary guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html). ## How should patient and prospect journeys be separated? Separate purposes, eligibility and data permissions, not merely list names. A “prospect” who supplies identifiable health information while requesting care should not automatically enter an ordinary advertising workflow. A patient who subscribes to general education still needs the correct communication and processing arrangement. Create an operating record for each journey: - The approved purpose and privacy decision reference. - The authoritative system for eligibility and recipient identity. - The required permission or authorisation evidence, where applicable. - The fields allowed in the CRM, template and reporting output. - The permitted sending service, integrations and optional features. - The stop conditions, communication preferences and escalation owner. Keep subscription preference, HIPAA authorisation and clinical eligibility as separate records. One boolean called `consent` cannot accurately represent all three. The [preference-centre design guide](https://www.martechdevs.com/blog/customer-preference-centre) explains how to preserve a withdrawal when a stale integration update arrives; [CRM property ownership](https://www.martechdevs.com/blog/crm-property-ownership) assigns the authoritative writer for each value. Use role-specific access. A campaign operator may need to know that a recipient is eligible without seeing the clinical reason. An integration maintainer may need a failure code without access to the patient record. Protect exported files and troubleshooting evidence to the same level as the data they contain. HHS requires appropriate business-associate contracts for the relevant relationships, including downstream subcontractor responsibilities. Review the integration provider, reporting service and other recipients independently; a CRM's BAA does not automatically cover them. [Business-associate contract responsibilities](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html). ## How should links and landing-page tracking work? Treat the click as a new data flow. A covered email platform can redirect a patient into an uncovered analytics tool, an advertising pixel, an error collector or a scheduling embed. Review the full route before approving the email. The [Meta healthcare data-flow audit](https://www.martechdevs.com/blog/meta-pixel-hipaa) follows the landing page, server sender, pending retries and advertising exports. Use neutral campaign parameters and avoid patient or clinical values in URLs. Inspect redirects, referrers, page titles, form submissions and the logs created during failures. If a secure portal is the destination, verify authentication and the intended account boundary. A forwarded email must not reveal another person's record. Keep click tracking only where its purpose, recipient and feature scope are approved. Where it is unnecessary, disabling it can simplify the design. Where it is needed, test the actual request rather than assuming a branded tracking domain changes who receives the data. The [healthcare analytics guide](https://www.martechdevs.com/blog/hipaa-compliant-analytics) covers the page and recipient review in more detail. For this email workflow, the acceptance test is narrower: follow one synthetic recipient through the entire link path and confirm that only approved destinations receive the permitted fields. HHS permits provider-patient email with reasonable safeguards and discusses checking recipient addresses, limiting unnecessary detail and accommodating reasonable confidential-communication requests. It does not impose a blanket ban on all unencrypted treatment email; the Security Rule and actual circumstances still matter. Do not turn a marketing vendor's encryption claim into a universal legal rule. [HHS email safeguards](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-permit-health-care-providers-to-use-email-to-discuss-health-issues-with-patients/index.html). ## What would an approved clinic follow-up look like? Start with a hypothetical clinic considering outreach to people with no completed visit for 18 months. The elapsed time is a proposed eligibility rule, not evidence that the message is legally treatment-related. The clinic's clinical and privacy owners first decide the purpose, authorised audience and appropriate channel. Suppose they approve a general care-follow-up workflow using a BAA-covered service. The source system supplies only the approved recipient reference, verified address, language, current communication preference and eligibility decision. Detailed diagnoses stay in the care system. The campaign uses a neutral internal label and an approved portal destination. The draft message might say: “If you would like to arrange a follow-up, sign in to your patient portal or contact our office.” The exact wording, sender and recipient context still need approval. Generic copy reduces unnecessary detail; it does not erase the care relationship or eliminate the need for the agreed processing arrangement. Before sending, check the current source again. A person who already booked should exit. A changed communication preference should suppress or reroute the message. A missing eligibility decision should hold the record for review. The clinic should also define how replies are handled, because patients may respond with sensitive information even when the outgoing message is brief. | Synthetic acceptance case | Expected operational result | Evidence to inspect | | --- | --- | --- | | Approved eligibility, valid address and permitted channel | One message through the approved sender | Current eligibility decision, recipient and send record | | Recipient books before the queued send | Suppress the now-unnecessary reminder | Updated booking state and cancelled pending action | | Authorisation is required but missing or withdrawn | Hold the marketing action | Permission evidence and the recorded hold reason | | A clinical field appears in an unapproved template or export | Reject the release and remove the exposure | Rendered template or outbound payload and corrected allowlist | | Duplicate source record requests the same step | One customer-facing action | Stable message-step key and deduplication result | | Reply contains health details | Route to the approved restricted handling process | Reply recipient, access controls and assigned handling owner | Apply those tests to the configured system using synthetic people. Passing a template preview alone does not test the eligibility query, queue, redirect, export or reply route. ![A healthcare communication first needs purpose and audience approval, otherwise it is held. Approved communications need covered services and data paths, then configured-journey review; failed coverage or review returns to route or contract changes, and only all approved gates lead to release with named owners.](https://www.martechdevs.com/assets/blog/hipaa-compliant-email-marketing.svg) Diagram connections: - Proposed healthcare communication to Purpose and audience approved?. - Purpose and audience approved? to Hold for privacy classification: No. - Purpose and audience approved? to Services and data path covered?: Yes. - Services and data path covered? to Change the route or contract scope: No. - Services and data path covered? to Configured journey passes review?: Yes. - Configured journey passes review? to Change the route or contract scope: No. - Configured journey passes review? to Release with named operating owners: Yes ## What should pass before the first healthcare send? Approve the actual workflow with evidence from its full path. Keep the decision and test record tied to the template version, integration configuration and service scope so later changes cannot silently inherit approval. ## Checklist - [ ] The organisation's role and applicable requirements are established. - [ ] The campaign purpose, audience and any remuneration are reviewed. - [ ] Required authorisation evidence and withdrawal handling are defined. - [ ] Relevant BAAs cover the purchased product, account and actual functions. - [ ] CRM fields, templates and exports obey vendor-specific restrictions. - [ ] Patient and prospect routes have explicit data and purpose boundaries. - [ ] Identity, permissions, preferences and current eligibility reconcile. - [ ] Links, redirects, landing-page requests and logs are inspected. - [ ] Test data is synthetic, including previews and troubleshooting exports. - [ ] Duplicate, changed-preference and no-longer-eligible cases suppress correctly. - [ ] Replies, incidents and failed sends have restricted handling paths. - [ ] Privacy, security and operating owners approve the release evidence. Review new AI features, integrations, exports and template changes before enabling them on patient workflows. A previously approved email route can change when a new feature starts processing its audience or content. For help turning the approved requirements into an implementation, [get the $99 martech audit](https://www.martechdevs.com/pricing). Bring the journey specification and vendor scope, not a live patient export. The output should identify the necessary configuration, remaining decisions and tests your organisation needs to approve the launch. ## Frequently asked questions ### Can a BAA make any AI feature acceptable for patient data? No. The agreement must cover the actual service and feature, and the proposed use must still be permitted. Check prompts, retrieved records, generated output, logging and downstream recipients. Keep a new AI feature disabled on patient workflows until those boundaries are approved. A product-level security badge does not establish that an optional assistant has the same processing arrangement. ### Can we upload a patient list to an ad platform only for suppression? Suppression still transfers a list and its associated context to another recipient. Have the privacy owner assess that disclosure and the destination's terms before enabling it. Hashing identifiers is not an automatic approval or de-identification method. A CRM agreement does not extend to an advertising platform merely because the upload originates from a covered account. ### Should the email preference centre show a patient's condition? Usually the communication choices can be expressed without displaying clinical details. Show the approved categories the recipient can control, and restrict any sensitive account information behind appropriate authentication. Test forwarded links and shared inboxes. Keep preference changes separate from clinical eligibility and any required authorisation, so choosing fewer newsletters does not silently rewrite unrelated care or legal records. ### Who should maintain the BAA and feature register? Assign an operating owner to keep the register current and qualified privacy, security and legal owners to approve its contents. Record the legal entity, product, plan, account, permitted data, exclusions and incident contacts. Link each journey to the relevant entry. Review the register when a vendor, feature or data recipient changes instead of treating the original signature as permanent approval for every expansion. ### Does a general newsletter need review if it contains no diagnosis? Yes. Review how the recipient list was created, what membership reveals, the campaign purpose and every service receiving the information. A general message sent to a patient-derived audience is different from a public newsletter with no care-related selection. The review should classify the actual use; neither the absence of a diagnosis nor the label “newsletter” determines the answer by itself. ## Sources 1. [HHS: Marketing](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/marketing/index.html). 2. [45 CFR 164.501: Definitions, including marketing](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.501). 3. [45 CFR 164.508: Authorisations](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508). 4. [HHS: Appointment reminders](https://www.hhs.gov/hipaa/for-professionals/faq/are-appointment-reminders-allowed-under-hipaa-without-authorization/index.html). 5. [HHS: Business associate contracts](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html). 6. [HHS: Privacy Rule summary](https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html). 7. [HHS: Minimum necessary requirement](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html). 8. [HHS: Provider-patient email safeguards](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-permit-health-care-providers-to-use-email-to-discuss-health-issues-with-patients/index.html). 9. [HubSpot: Store Sensitive Data](https://knowledge.hubspot.com/account-security/store-sensitive-data). 10. [HubSpot: Sensitive Data in tools](https://knowledge.hubspot.com/account-security/sensitive-data-in-hubspot-tools). 11. [HubSpot: Sensitive Data terms and BAA](https://legal.hubspot.com/sensitive-data-terms). 12. [Customer.io: Plan features](https://docs.customer.io/accounts/billing/plan-features/). 13. [Customer.io: Security guidance](https://customer.io/legal/security). 14. [Paubox: Marketing features and BAA](https://www.paubox.com/pricing/paubox-marketing). 15. [Braze: HIPAA BAA](https://www.braze.com/company/legal/baa). 16. [Constant Contact: BAA and permitted data](https://knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/6240-Business-Associate-Agreements-BAAs?lang=en_US). 17. [Mailchimp: Standard terms](https://mailchimp.com/legal/terms/). 18. [Klaviyo: Sensitive personal information restrictions](https://help.klaviyo.com/hc/en-us/articles/360035875272). 19. [Klaviyo: Acceptable-use policy](https://www.klaviyo.com/legal/acceptable-use-policy).