FAQ

No. Files are encrypted on the sender's device with keys the relay doesn't hold. The relay stores ciphertext and signed metadata only. Even a full database dump or coerced operator yields nothing the attacker can decrypt without the recipient's private keys.

Your org's identity and decryption keys exist only on the machines you keep them on. If you lose all copies, the operator must invite the org again, and any messages still in flight for the old keys can't be decrypted. Treat the file like a root certificate: multiple backups, restricted access, at least one offline copy.

Each message key is wrapped twice — once with ML-KEM-768 (a NIST post-quantum KEM) and once with X25519 (a classical curve). The two are combined via HKDF, so an attacker would need to break both to recover plaintext. This protects you from a future quantum attacker who archives ciphertext today.

Web sign-in uses WebAuthn passkeys (FIDO2). There are no passwords to phish, leak, or guess. Each user enrolls a passkey on a device or hardware key, and the browser proves possession during login. Lost devices are handled by issuing a setup link from the dashboard, or via the public recovery flow if the user has an email registered.

The relay isn't an open directory — it's a routing layer between organizations that already have some trust relationship. The operator decides who gets in. Invite tokens are single-use, time-limited, and bind to an org during redemption.

fxe is currently offered at no charge while the network grows. We reserve the right to introduce membership fees to cover hosting and operational costs; if we do, current members will get advance notice. fxe is a free service by msgbridge.com, an Offline Software Solutions LLC brand.

Fax to +10000000000. That's a built-in echo org: it decrypts your message, signs a delivery receipt, and faxes the same PDF back to you (with from_number=+10000000000) within a few seconds. You can hammer it during development to verify your send code, webhook handler, decryption, and receipt-signing without coordinating with a real partner.

PDF. The relay itself never opens the document — it's encrypted before upload — but recipients assume application/pdf and integrations on the other side will render or archive PDFs by default. Color and high-resolution work fine (no PSTN-style compression to monochrome), and there's no per-page surcharge. Convert TIFFs, captured PSTN faxes, and other formats to PDF before sending.

fxe runs in a SOC 2 Type 2 certified datacenter. Physical access, change management, and operational controls are independently audited. End-to-end encryption means the relay couldn't read your messages even without that — but the underlying infrastructure also meets a recognized control standard.

Structurally, fxe is well-suited to compliance contexts because the relay never holds plaintext or decryption keys — even a full database dump would yield ciphertext only. That said, compliance also depends on access controls, audit retention, BAAs, and how your own integration handles data on the org side. Contact us for the relevant documentation to share with your compliance team.

TLS between hops is not end-to-end encryption — anyone with access to the gateway sees plaintext, by definition. fxe is end-to-end: the plaintext only exists on the sending and receiving organizations' devices, not on the relay or any intermediary. If your stack already does true E2EE all the way to the recipient organization, you don't need fxe; if it doesn't, that gap is what fxe closes.

The database holds:

• Org names and the fax number → org mapping
• Public identity and key-bundle keys (everything public, nothing secret)
• Wrapped per-message CEKs (still encrypted to the recipient)
• Opaque ciphertext blobs in LMDB until a signed receipt comes back
• Signed envelopes and receipts (verifying only)
• Webhook delivery state and an audit log of who-sent-to-whom-when
• An HMAC of each API key (the key itself is never stored)
• Session cookies and passkey records for human admins

Ciphertext is deleted as soon as a signed receipt is verified; undelivered messages sweep on a TTL (default: one week).

Each org has an identity key (long-term) and a key bundle (rotatable). Rotation is signed by the identity key so recipients can verify continuity. If the identity key itself is compromised, the org must be re-invited.