HIPAA and Email Signatures: A Governance Guide for Healthcare Organizations (2026)

TL;DR: HIPAA doesn't regulate what goes in an email signature, and it doesn't require a disclaimer. It does regulate protected health information (PHI) and every vendor that handles it. For a healthcare organization the signature questions that matter are: keep PHI out of signatures and banners, decide whether signature tracking belongs on mail to patients, and, before you route outbound email through any signature service, establish whether that vendor becomes a business associate and will sign a business associate agreement (BAA). If you can't get a BAA, use a deployment where mail never passes through the vendor.

Last reviewed: October 2026.

This is general information, not legal advice. HIPAA obligations depend on whether you're a covered entity or business associate and on how each system handles PHI; confirm requirements for your organization and any state law with your privacy officer and counsel. Sections of the HIPAA Rules are linked to the eCFR text, and HHS guidance to hhs.gov.

This guide is for IT, security and privacy leads at hospitals, health systems, clinic groups, payers and health-tech companies who are standardizing email signatures. It covers governance: what may and may not appear in a signature, how signature vendors fit into your business associate inventory, patient-facing versus internal signatures, and mobile. For copy-ready disclaimer wording (provider, billing, business associate and patient-portal templates), use our HIPAA email disclaimer templates; for disclaimer rules outside healthcare, the Handbook's email disclaimers guide.

What does HIPAA actually say about email and signatures?

Nothing about signatures specifically. Three parts of the HIPAA Rules shape how you manage them:

• Email with patients is allowed with safeguards. HHS says covered health care providers may communicate electronically with patients, for example by email, provided they apply reasonable safeguards, such as checking the address before sending and limiting the amount or type of information in unencrypted email (HHS FAQ: email with patients). Patients can also request communication by alternative means or at alternative locations (45 CFR 164.522(b)).
• Electronic PHI needs technical safeguards. The Security Rule requires access controls, audit controls, integrity controls and transmission security for ePHI sent over a network (45 CFR 164.312). A disclaimer is none of these: it's a notice to a mistaken recipient.
• Vendors that handle PHI are business associates. A person or company that creates, receives, maintains or transmits PHI on behalf of a covered entity is a business associate (45 CFR 160.103), and the covered entity needs satisfactory assurances in a written contract before disclosing PHI to it (45 CFR 164.502(e); contract terms in 164.504(e); Security Rule equivalent in 164.308(b)).

So the signature itself is a low-risk object. The risk sits in two places: content that someone adds to it, and the path outbound email takes through the signature vendor.

What must not go in a healthcare email signature?

A standard staff signature (name, credentials, role, department, location, work phone) is not PHI. The definition of PHI excludes employment records held by a covered entity in its role as employer (45 CFR 160.103), and staff contact details are about the workforce, not patients. PHI gets into signatures in less obvious ways:

• Personalized links. A "manage your appointment" or portal link with a patient identifier, medical record number or appointment ID in the URL puts PHI into every copy of the email and into whatever system logs the click. Keep patient-facing links generic and let the patient authenticate on arrival.
• Condition-specific banners. A banner like "Living with diabetes? Join our program" is harmless on a newsletter page. Attached to a one-to-one email from a clinician to a patient, it can imply something about the recipient's health. Keep clinical-service banners off patient-facing signatures, or restrict them to general service announcements.
• Free-text fields. Signature fields filled from the directory sometimes carry notes someone typed into a profile. Map only the fields the template needs.
• Pasted content. Staff who build their own signatures sometimes paste in a "PS" from a previous email. Central templates that overwrite local edits remove the problem.

The minimum necessary standard requires covered entities to limit uses and disclosures of PHI to the minimum necessary for the purpose (45 CFR 164.502(b)). Applied to signatures, the practical reading is simple: a signature should never carry PHI at all, so nothing about it should vary by patient.

Marketing banners and the HIPAA definition of marketing

Under the Privacy Rule, "marketing" is a communication that encourages recipients to buy or use a product or service, with exceptions that include communications about the covered entity's own health-related products and services, unless the covered entity receives financial remuneration from a third party for making the communication (45 CFR 164.501). Using PHI for marketing generally requires the individual's authorization (45 CFR 164.508(a)(3)). For signatures that means: a banner promoting your own new urgent care location is a different case from a banner a device or drug manufacturer pays you to run. Route any sponsored or third-party banner to your privacy officer before it goes on patient-facing email.

Substance use disorder programs

Programs covered by 42 CFR Part 2 have an additional requirement: disclosures made with patient consent must be accompanied by a specific notice about redisclosure (42 CFR 2.32). Some programs place that notice in a footer on email that may contain Part 2 records. Whether a footer is the right vehicle, and the exact wording, is a question for counsel; if you do use it, apply it centrally to the relevant mailboxes only.

Server-side signatures and PHI: what does the vendor touch?

How a signature tool is deployed decides whether it ever sees email content, and that decides whether it belongs in your business associate inventory.

Deployment	What the vendor handles	Does email content pass through the vendor?
Client-side add-in or API (Outlook add-in, Gmail signature settings)	Staff directory data and the signature HTML; the signature is inserted in the mail client	No. Scribe documents that with its Microsoft 365 cloud-based installation, emails don't go through Scribe's servers (Scribe: Microsoft 365 client-side)
Server-side relay (mail flow rule to a smart host)	Every routed outbound message: headers, body and attachments	Yes. Scribe's documentation says the relay inserts the signature and passes recipients, subject, attachments and body through unchanged (Scribe: Microsoft 365 server-side)
Native mail flow rule or footer (Exchange Online, Google Workspace)	Nothing outside your email platform	No; it stays within the platform you already have a BAA for, if you have one

With server-side routing, outbound email that contains PHI is received and transmitted by the signature vendor on your behalf. Don't assume the "conduit" exception covers it. HHS describes that exception as limited to transmission-only services, and says a cloud service provider that creates, receives or maintains ePHI is a business associate even if it can't view the data because it's encrypted (HHS: HIPAA and cloud computing). A relay that rewrites the message body and re-signs it is doing more than carrying it. Whether a particular signature relay is a business associate is a determination for your privacy officer and counsel, but the conservative default is to treat it as one.

Where Scribe stands, from its published documentation

• Scribe publishes no business associate agreement. Its Trust Center lists SOC 2 Type II and GDPR as its frameworks and offers a GDPR data processing agreement (Scribe Trust Center); it doesn't list HIPAA.
• Scribe's help center states that "Scribe does not collect or process personal health information (PHI)" (Scribe: data collected overview). That statement describes Scribe's intended data; it doesn't by itself settle the status of a relay that PHI-bearing email passes through.
• Scribe's server-side documentation says it "cannot read or edit your emails", that the connection to Scribe is TLS-enforced in both directions, and that the return connector accepts mail only from two fixed Scribe IP addresses (Scribe: Microsoft 365 server-side). It doesn't document how long, if at all, message content is held on the relay.

Confirm BAA availability with Scribe before enabling server-side routing for any mailbox that may send PHI. Ask, in writing: will Scribe sign a BAA, for which deployment types, whether message content is stored on the relay and for how long, where the relay is hosted, and which subprocessors handle routed mail. If the answer is no, or until it's yes, use client-side deployment only for those mailboxes.

The same questions apply to any signature vendor with a server-side option. For the architecture itself, see client-side vs server-side signatures.

Should signature tracking be on for email to patients?

Most signature tools count views and clicks. Scribe documents that tracking of signature openings and clicks starts when signatures are installed, that it records an anonymized IP address, the country derived from it, the email client and version, and the device type, and that it can be switched off in workspace settings (Scribe: how Scribe tracks and stores data). The setting is workspace-wide in the documentation; per-signature or per-recipient opt-outs aren't described.

HHS's bulletin on online tracking technologies addresses websites and mobile apps, not email, and part of it was vacated by a federal court in June 2024 as it applied to unauthenticated public webpages (HHS: online tracking technologies). Its central concern still carries over by analogy: data such as IP address, device and timing, collected in the context of a patient's relationship with a provider, may be individually identifiable health information. Signature views on clinician-to-patient email reveal who opened mail from which practice and when.

Practical options, from most to least conservative:

1. Turn signature tracking off for the workspace that serves clinical and patient-facing staff.
2. Run patient-facing staff in a separate workspace with tracking off, and keep tracking for corporate, recruiting or B2B teams in another. Scribe's paid plans allow multiple workspaces (Scribe: Plans); confirm with Scribe that your directory and mail integration can be split this way before you plan on it.
3. Keep tracking on only where your privacy officer has documented why it's acceptable, and avoid personalized tracking links on patient-facing templates.

Patient-facing vs internal and partner signatures

Most healthcare organizations need at least three signature types:

Audience	Include	Avoid
Patients	Name, credentials, role, location, a general phone number, portal link without identifiers, a short notice asking mistaken recipients to delete the message, a line that email isn't for emergencies	Direct mobile numbers, condition-specific or sponsored banners, tracking links, long legal text
Payers, vendors and business associates	Name, role, department, direct line, entity name, confidentiality notice	Marketing banners
Internal	Name, role, department, extension, pager or on-call information if your workflow uses it	The external legal block, which only lengthens threads

Scribe's internal variant applies when every recipient is on the sender's domain; it works in Outlook and with server-side routing, but not with the client-side Gmail install, where one signature serves all mail (Scribe: signature variants). Groups that use several domains (a hospital domain and a medical group domain, for example) should check whether "internal" in their tool means same domain or same organization.

Patient-facing signatures should be assigned by role rather than by hand. Assign them to the clinical departments or groups synced from your directory, and set the auto-assign option so new hires pick up the right template on day one (Scribe: assign teammates).

Mobile devices and coverage gaps

Clinicians send a large share of their email from phones. Client-side signature tools can't reach every mobile app: Scribe documents that its client-side installation works in the Gmail iOS app and the Outlook apps for iOS and Android, but not in the Gmail Android app or Apple Mail (Scribe: mobile). Server-side routing closes the gap but raises the BAA question above. If you're client-side only, close the gap another way:

• Require the Outlook mobile app for corporate mail through your mobile device management policy, so mobile mail goes through a supported client.
• Add the essential notice with a native rule: Exchange Online's "Apply disclaimers" mail flow rule (Microsoft Learn) or Google Workspace's footer setting (Google Workspace Admin Help). These run inside the platform, so no additional vendor sees the mail. Add an exception so messages that already carry the signature don't get a second notice.

More detail in mobile email signatures.

How do you roll out signatures across clinics and locations?

1. Inventory mail paths. List every way email leaves the organization: Outlook and Gmail clients, mobile, the EHR's patient messaging, the patient portal's notifications, CRM and marketing platforms. Signature tools only cover the first two or three; the rest have their own footer settings.
2. Decide the deployment per population. Client-side for anyone who may send PHI unless a BAA is in place for the server-side relay; server-side only where it's approved.
3. Clean the directory. Location, department, credentials and phone numbers come from Entra ID, Google Workspace or your HRIS. In Scribe a block whose field is empty is omitted from the signature, so missing credentials don't print as a blank label (Scribe: Smart Fields). See Entra ID attributes.
4. Build templates per audience and location. One patient-facing template can cover many clinics if the location block comes from the directory.
5. Have the privacy officer approve the notice wording, the tracking decision and the banner rules, and record the decision.
6. Pilot one clinic, check mail from desktop and each mobile app, then roll out by department. See the rollout playbook.
7. Audit monthly: coverage, failed installs, missing data and template versions; see the email signature policy guide.

For the platform setup itself, see the Microsoft 365 and Google Workspace guides.

Questions to ask any signature vendor before a healthcare deployment

• Will you sign a BAA, and does it cover server-side routing, client-side deployment, or both?
• Does message content pass through your systems in each deployment type? Is any of it stored, logged or queued, and for how long?
• Where are the relay and the signature service hosted, and which subprocessors touch routed mail?
• Is transport encryption enforced, and how is the return path restricted?
• Can view and click tracking be disabled per workspace, per signature or per audience?
• What directory fields do you import, and can we limit them?
• What audit trail exists for template and setting changes?
• What independent assurance do you have (for example SOC 2 Type II), and will you share the report under NDA?

Frequently asked questions

Does HIPAA require an email signature or disclaimer?

No. HIPAA requires safeguards for protected health information, such as transmission security for ePHI, and HHS allows email with patients when reasonable safeguards are applied. A disclaimer is a notice, not a safeguard. Templates are in our HIPAA email disclaimer guide. This is general information, not legal advice.

Is a staff email signature PHI?

Generally not. A staff member's name, credentials, role, location and work phone describe the workforce, and the HIPAA definition of PHI excludes employment records a covered entity holds as an employer. PHI enters signatures through personalized patient links, condition-specific banners or pasted content.

Do I need a BAA with my email signature vendor?

If outbound email that may contain PHI is routed through the vendor (server-side signatures), treat the vendor as a likely business associate and get a BAA before enabling it; HHS describes the conduit exception as limited to transmission-only services. Client-side deployments that never receive email content raise a different, smaller question. Confirm with your privacy officer.

Does Scribe sign a BAA?

Scribe doesn't publish a BAA, and its Trust Center lists SOC 2 Type II and GDPR rather than HIPAA. Confirm BAA availability with Scribe directly before routing PHI-bearing mail through its server-side relay. Its documentation says client-side Microsoft 365 installation doesn't route email through Scribe's servers.

Should email signature tracking be used on patient email?

Be cautious. View and click tracking records data such as IP-derived location, device and timing for each recipient. On clinician-to-patient email, many organizations switch it off or keep it to non-clinical teams. Scribe documents a workspace-level setting to opt out of tracking.

Can healthcare marketing banners go in email signatures?

Banners about your own services are generally treated differently under HIPAA from third-party or sponsored promotions, which can fall within the Privacy Rule's definition of marketing. Keep condition-specific and sponsored banners off patient-facing signatures and have the privacy officer approve banner rules.

How do I cover signatures on clinicians' phones?

Client-side tools don't reach every app: Scribe's client-side install works in Gmail for iOS and the Outlook apps, but not Gmail for Android or Apple Mail. Either require the Outlook mobile app, add a native Exchange or Google Workspace footer for the essential notice, or use server-side routing once a BAA question is resolved.

Related Handbook guides

• Email disclaimers: legal requirements by country and industry
• Client-side vs server-side email signatures
• Mobile email signatures
• Email signature policy template
• GDPR and email signatures