Security whitepaper

1. Design principles

Assemble, don’t invent. Mail transport, mailboxes, storage, key management and identity are provided by Amazon Web Services’ HIPAA-eligible services and by open-source components with long security histories. PXCMail’s own code is policy, orchestration and evidence.
Isolate with infrastructure. Each customer organization has its own mailbox organization, encryption key, ingress credential and policy set. There is no shared database query that could return another customer’s data.
Encrypt by default; require, don’t prefer. TLS is required to recipients; content that must be protected and cannot travel over TLS is held and delivered through the locked-delivery page.
No standing access to content. Nobody at PXCMail can read customer message content without a customer request, time-limited approval and a log entry.
Evidence is a product feature. Everything above is observable by the customer in the audit trail and reports.

2. Architecture

Ingress. Customer mail enters through Amazon SES Mail Manager ingress endpoints: authenticated endpoints for Gateway relay (per-tenant SMTP AUTH credentials or Microsoft tenant certificate validation and IP ranges) and MX endpoints for inbound delivery. Traffic policies enforce TLS, sender-domain allow-lists and reputation add-ons (Spamhaus, Abusix, Trend Micro).

Policy and encryption layer. Messages are relayed to the policy engine, running on hardened EC2 instances in private subnets across two availability zones (CipherMail-based encryption gateway with PXCMail detection packs and policy configuration). The layer performs detection, decides the action, applies S/MIME or holds the message for locked delivery, and emits events.

Egress. Outbound mail is sent through Amazon SES with configuration sets per tier, TLS required, dedicated IP pools, DKIM signing with the customer’s domain key and customer-aligned MAIL FROM. Bounce, complaint and delivery events are consumed per tenant.

Mailboxes (Hosted). Amazon WorkMail organizations, one per customer, with a customer-dedicated AWS KMS key, journaling to the archive, EWS/EAS/IMAP access and device policies.

Archive and audit. Mail Manager archiving and WorkMail journaling feed the archive; archive-plan data is written to Amazon S3 with Object Lock in compliance mode and replicated to a second US region. Audit events flow through an event bus into a security data lake and OpenSearch; daily snapshots are written to immutable storage.

Control plane. Provisioning, billing and policy management run as serverless workflows (Step Functions, Lambda) with DynamoDB for tenant metadata. The console and locked-delivery pages are served behind AWS WAF and CloudFront with no customer content cached at the edge.

3. Tenant isolation

Mailbox organization per customer; KMS customer master key per customer (Hosted and Pro) or per small group with per-tenant envelope keys (Gateway standard); ingress credential and SES configuration per tenant; policy document per tenant.
Locked-delivery objects are encrypted with a data key wrapped by the tenant’s KMS key; keys are destroyed on offboarding (crypto-shredding).
Automated cross-tenant tests run on every deployment: every API and console endpoint is called with tenant A’s credentials against tenant B’s identifiers and must return not-found.

4. Encryption and key management

In transit: TLS 1.2+ everywhere, TLS 1.3 preferred; HSTS on web properties; MTA-STS and TLS-RPT published for pxcmail.com; DANE honored outbound where published.
At rest: AES-256 via AWS KMS (FIPS 140-2 validated HSMs); S3 SSE-KMS with bucket keys; EBS and database encryption; WorkMail organization keys.
Key policies restrict use to service roles; rotation annually; key deletion scheduled with a 30-day waiting period on offboarding; all key use logged in CloudTrail.
S/MIME: organization signing certificates issued at onboarding from a public CA; recipient certificates discovered, validated and cached with pinning available.

5. Identity and access

Customers: MFA required (TOTP or FIDO2); SSO via SAML/OIDC on Hosted Pro; scoped app passwords for IMAP; session timeouts; role-based access with a published matrix; dual approval available for content access and hold release.
Workforce: single sign-on with hardware security keys; least-privilege roles; privileged access is time-limited (one hour) and approved; no SSH keys — session manager with recording; no standing access to customer content; US-only access to content; background checks and annual HIPAA/security training.
Machine access: IAM roles with short-lived credentials; no long-lived access keys in production.

6. Mail security controls

Outbound: enforced TLS, detection packs and DLP actions, S/MIME, locked delivery, DKIM/SPF/DMARC alignment for customer domains, per-tenant rate limits and reputation monitoring with automatic pause.
Inbound: reputation lists, malware scanning, URL rewriting and detonation (SCHEDULED), impersonation and lookalike-domain detection, payment-change language detection, quarantine.
Deliverability: dedicated IP pools by tier, warm-up automation, feedback loops with major mailbox providers, DMARC aggregate processing for customer domains.

7. Logging and monitoring

Infrastructure logs (CloudTrail organization trail, VPC flow logs, load balancer and WAF logs), application events and mail events are centralized in a security data lake with 6-year retention; content is excluded and log data-protection policies redact identifiers that resemble PHI.
Threat detection: GuardDuty (including malware protection), Security Hub with CIS and NIST 800-53 standards, Inspector continuous vulnerability scanning, Macie on archive buckets, host intrusion detection on EC2.
Alerting to 24/7 on-call; SLO-based alerts on ingress availability, delivery latency, OTP delivery and console availability; public status page from an independent monitor.

8. Vulnerability and change management

Infrastructure as code with peer review, static analysis and policy-as-code checks; plan/apply approvals; drift detection.
Images built from hardened bases (CIS benchmark) with signed, scanned artifacts; OS patches within 7 days for critical, 30 days for high.
Independent penetration test before general availability and annually (SCHEDULED: first test in the GA quarter); vulnerability scanning continuously; public disclosure policy and security.txt.
Maintenance windows announced 72 hours ahead; emergency changes documented within 24 hours.

9. Backups, continuity and disaster recovery

Mailboxes: managed multi-AZ replication; archive and audit: cross-region replication to us-west-2; configuration: continuous backup with point-in-time recovery; backup vaults locked against deletion.
Recovery objectives: RTO 4 hours, RPO 15 minutes; quarterly recovery exercises with results summarized in the Trust Center; full region failover runbook.
Business continuity plan covers loss of a region, loss of a key vendor, loss of key personnel and pandemic/office loss.

10. Data lifecycle

Location: United States only (us-east-1 primary, us-west-2 DR). No cross-border transfer of service data.
Retention: customer-configured mailbox and archive retention; 6-year content-free audit retention; locked-delivery objects deleted on expiry.
Deletion: 30 days after termination — mailbox organization deleted, archive deleted (unless under legal hold or compliance-mode retention still running, in which case access is removed and data expires on schedule), KMS key scheduled for deletion; certificate of destruction on request.

11. Personnel and vendor security

Background checks, confidentiality agreements, security and HIPAA training at hire and annually, phishing exercises quarterly; offboarding within 24 hours.
Tier-1 support outside the US has metadata-only access; tier-2 in the US may access content on written customer request with logging.
Vendors: risk-tiered inventory, BAAs or DPAs where data is processed, annual review; subprocessor list public with 30-day change notice.

12. Compliance program

HIPAA Security Rule risk analysis (annual and on change) and 20+ written policies; FTC Safeguards program elements; incident response plan with 72-hour customer notification commitment; tabletop exercises.
SOC 2 Type I (SCHEDULED, within 9 months of GA) followed by Type II; ISO 27001 considered for year 2; HITRUST evaluated on customer demand.
Cyber liability and technology errors & omissions insurance; certificate available to customers.

13. Shared responsibility

PXCMail secures the service, its infrastructure and its personnel. Customers remain responsible for their own policies and training, for configuring policy appropriate to their obligations, for their users’ credentials and devices (within the controls we enforce), for the content they send, and for their obligations toward the individuals whose data they handle. The checklists describe the customer side in detail.

14. Contact

Security questions and questionnaires: [email protected]. Vulnerability reports: see responsible disclosure.

How PXCMail is built and run.