Encryption in transit and at rest, per-mailbox access logging, retention controls and enforced two-factor. Here is exactly what that does and does not mean for your practice.
We do not currently offer a business associate agreement. This page describes the technical controls we operate. It is not a compliance attestation, and no software product can make a practice compliant on its own. If a signed BAA is a requirement for you today, you need a vendor that offers one — we would rather tell you that than sell around it.
Compliance is a property of an organisation, not a feature of a mail server. It is your risk analysis, your policies, your workforce training and your agreements with vendors. Software is one input among several. What a mail provider can honestly promise is that its controls will support that work rather than obstruct it — and that it will tell you what those controls are in enough detail for you to evaluate them.
Transport encryption between mail servers is opportunistic by default. If the receiving server does not offer TLS, most senders will deliver the message in the clear rather than fail it. So a provider saying "your email is encrypted" is usually describing a best effort, not a guarantee about any particular message.
We enforce TLS 1.3 on connections we control and record the outcome per message, so the question "was this delivered over an encrypted channel" has an answer you can look up instead of assume.
TLS 1.3 on our connections, AES-256 on stored mail and attachments. Delivery outcomes are logged, so you can see whether a message actually travelled encrypted.
Who opened which mailbox, from where, and when. Exportable, so an internal review does not depend on us running a query for you.
Set how long mail is kept, and export a full mailbox on demand rather than negotiating for your own data.
Enforced for the whole workspace at sign-in, with recovery codes and an administrator reset path that does not depend on the user reaching their own inbox.
Healthcare is one of the most impersonated sectors in phishing, and the attack rarely involves breaking encryption. It involves a message that looks like it came from a clinic, sent from a domain one character off the real one, asking a patient to click something.
Encryption does not address that, because the fraudulent message is encrypted too. What helps is giving patients a way to confirm the sender is a real clinician — which is what the verified badge, checked against the public NPI registry and reviewed by hand, is for.
It describes the technical controls: AES-256 encryption at rest, TLS 1.3 in transit, per-mailbox access logging, retention and export controls, and enforced two-factor authentication at login. It is a statement about infrastructure, not a certification, and it is not the same as a compliance attestation.
No, and be wary of any provider that implies otherwise. Compliance is a property of your whole organisation — your policies, your training, your risk analysis and your agreements with vendors. Software is one input. What a provider can do is supply controls that make compliance achievable rather than obstruct it.
Transport encryption between mail servers is opportunistic: if the receiving server does not offer TLS, many senders will deliver in the clear rather than fail. We enforce TLS 1.3 on our own connections and log the outcome, so you can see whether a given message was delivered over an encrypted channel instead of assuming it.
That is the problem the verified badge addresses. Healthcare is among the most impersonated sectors in phishing, and telling patients to "check the address carefully" does not work, because a lookalike domain reads as correct. A badge backed by NPI-registry review gives them something checkable instead.
Start free, inspect the controls, and decide. No card, and nothing to cancel if it isn't a fit.
Create your free accountNo credit card. No trial clock.