Encrypted when it must be. Invisible when it can be.
Most mail between modern providers is already encrypted in transit. The problem is the exceptions — the clinic on an old server, the client on a forgotten ISP address — and the fact that nobody tells you when it happened. PXCMail turns “usually” into “always”, and shows you the record.
The engine picks the strongest path the recipient can handle.
TLS required
Delivery requires TLS 1.2+ with a valid certificate chain; MTA-STS and DANE are honored when the recipient publishes them. The recipient sees a normal email. The audit trail records the cipher and the hop.
S/MIME
When the recipient’s organization publishes a certificate (hospitals, insurers, law firms, agencies), the message is encrypted end to end to that certificate and signed with yours. Certificates are discovered and cached; you can pin them.
Locked delivery
If TLS can’t be negotiated, or policy says the content is sensitive, the message is held encrypted and the recipient opens it with a one-time code. No account, no app, no password. Secure reply and attachments included.
What the patient or client goes through
- A notification arrives in their normal inbox
From your name and domain: “Lakeside Family Dental sent you a secure message.” Your logo on Pro. Subject lines never contain content. - One tap, one code
They choose text or email for a 6-digit code (voice call on request). Codes expire in 10 minutes; five wrong attempts lock the message for an hour. - Read, reply, download
In the browser on any device; attachments up to 2 GB; secure replies return to your mailbox encrypted and are archived. - It expires
30 days by default (1–90 configurable); you can revoke earlier; every open, reply and download is logged with time and IP.
English and Spanish templates included; additional languages on request. Accessible to screen readers and keyboard users (WCAG 2.1 AA).
Nothing new to learn
- Automatic — detection packs decide; most senders never think about it
- Force it — type
[SECURE]at the start of the subject from any device - Delivery receipt — Hosted users get a receipt when the recipient opens; Gateway users see it in the console
- Revoke — from the console or the receipt; the recipient sees “this message was withdrawn by the sender”
- Outlook and Gmail add-ins with a “Send secure” button — on the roadmap
Branding (Hosted Pro and Gateway Pro add-on)
Your logo, accent color and sender name on notifications and the reading page; a custom subdomain such as secure.yourfirm.com for the reading page.
Details your IT provider and auditor will ask for
| Transport encryption | TLS 1.2/1.3 required outbound; certificate validation; MTA-STS and DANE honored; opportunistic fallback is never used for policy-marked content |
|---|---|
| Locked delivery storage | AES-256, envelope-encrypted with the organization’s KMS key; stored in US regions; deleted on expiry or revocation |
| Codes | 6-digit, 10-minute validity, rate-limited; SMS via 10DLC-registered US numbers, email, or voice |
| Attachments | Up to 2 GB per message via the reading page; 35 MB via normal email |
| Expiry | 30 days default; 1–90 days; revoke any time |
| Recipient data kept | Address or phone number and open/reply events for the audit record; no account created |
| S/MIME | Automatic certificate discovery and caching; organization signing certificate issued at onboarding; pinning per domain |
| Accessibility & languages | WCAG 2.1 AA reading page; English, Spanish; others on request |
Questions about encrypted delivery
Why not encrypt everything with a code?
Because patients stop reading. TLS-delivered mail lands in the inbox like any other message and is already encrypted in transit; the code step is reserved for cases where TLS isn’t available or the content is sensitive by policy. That balance is what keeps open rates high.
Is a PDF attachment with a password an option?
We chose the reading page over password-protected PDFs because replies stay encrypted, attachments work, and people actually open it. Read PDF, portal or TLS?
What if the recipient loses the notification?
They can request a new one from the reading page link, or you can resend from the console. Codes are never reused.
Can recipients open with their Google or Microsoft account instead of a code?
That option is on the roadmap and listed on What’s new; the code works on any phone today.
Does this count as “encryption” for HIPAA and the Safeguards Rule?
Yes: data is encrypted in transit (TLS) and at rest (AES-256 under your key), and the audit record proves it per message. Encrypted data that is lost is not a reportable breach under the HIPAA safe harbor.