Security & trust at MailFrame
How MailFrame handles your email data, authenticates access, and secures delivery — stated conservatively, with a clear line between what ships today and what's on the roadmap.
MailFrame is in early access. This page describes practices that are in place today; items marked Early access or Roadmap are labelled as such. Detailed security documentation — including a security questionnaire response and data-processing addendum — is available on request as part of an Enterprise review.
How your data is handled
MailFrame processes the raw email you send and returns typed JSON. The data path is deliberately small: you POST content, we extract against your schema, you get the result back.
- Synchronous processing pathAvailable today
The shipped integration path is a synchronous POST /v1/parse: you send raw RFC 822 MIME (or plain-text email-like input) plus a JSON Schema, and the validated JSON is returned in the same HTTP response. There is no separate store-and-poll step in this path.
- Minimal retention for delivery and debuggingAvailable today
We retain raw email content for the minimum time needed to deliver your response and surface debugging. We do not sell or share customer data. Detailed retention windows are provided as part of an Enterprise security review.
- Schema validation in the responseAvailable today
Extraction is validated against the JSON Schema you supply. The response carries the typed data payload, the parse status, and any schema validation_errors — failed validation does not silently drop data, so you always control what happens next.
Authentication & secrets
Access to the API is via bearer tokens. Secrets you hold are handled so that a database read alone does not expose them.
- API keys stored hashedAvailable today
You authenticate with: `Authorization: Bearer ${MAILFRAME_API_KEY}`. API keys are stored hashed, so the raw key is not recoverable from our records — treat the key shown at creation as the only copy and rotate it if it may have leaked.
- Webhook signing secrets shown once, stored encryptedEarly access
For teams using async delivery (early access), each webhook signing secret is shown once at creation and stored encrypted. Deliveries are signed with an X-MailFrame-Signature HMAC-SHA256 header and an X-MailFrame-Timestamp header so your endpoint can verify authenticity and guard against replay.
Delivery integrity
Whether you take results synchronously or via webhook, the contract is designed to be verifiable and to fail safely.
- Signed webhook delivery with retries and replayEarly access
Async webhook delivery is available in early access: signed HMAC-SHA256 deliveries with exponential-backoff retries, attempt history, a dead-letter queue, and replay. Verify the signature against your shared secret before trusting a payload. Specific retry counts and timing are being refined during early access.
- Health endpoint for your own monitoringAvailable today
GET /health returns 200 when the parse pipeline is accepting traffic, so you can wire MailFrame into your own probes and alerting. Posted operational status is published on the status page.
Compliance & certifications
MailFrame is in early access. We state our compliance posture plainly rather than implying certifications we do not yet hold.
- SOC 2 Type IIRoadmap
SOC 2 Type II certification is on the post-Enterprise-launch roadmap. The team is documenting controls and audit posture now; Enterprise customers can request the current security questionnaire response as part of their agreement.
- PCI scope of parsed outputAvailable today
Schemas for Stripe and payment processors return last-four digits and card brand, never full PAN, so parsed output itself stays out of PCI scope. You remain responsible for how your downstream systems store parsed data.
- HIPAA / PHIRoadmap
MailFrame is not yet HIPAA-eligible as a Business Associate. Do not send PHI through the API without a signed BAA.
On the security roadmap
These capabilities are planned but not shipped. We label them as roadmap so you can plan around what exists today.
- PDF & image inputRoadmap
Parsing the body of an attached PDF or a screenshot of a receipt is planned. Today the API accepts raw RFC 822 MIME and plain-text email-like input.
- Inbox forwarding addressesRoadmap
Forwarding email to a MailFrame-provided inbox address per customer is planned. Today you fetch or receive the raw email yourself and POST it to /v1/parse.
- Async / batch parse modeRoadmap
A dedicated async / batch parse mode for high-volume ingestion is planned, in addition to the early-access webhook delivery path.
Your responsibilities
Security is shared. MailFrame secures the parse path; these are the parts you own as an integrator.
- Keep your API key secret. It is shown once and stored hashed on our side — rotate it immediately if it may have been exposed.
- Verify the X-MailFrame-Signature HMAC on every webhook delivery before trusting the payload, and reject stale X-MailFrame-Timestamp values to guard against replay.
- Send only the data you need parsed. Do not send PHI without a signed BAA, and scrub fields you do not require before POSTing.
- Secure the downstream systems that store parsed JSON — parsed output can contain personal or financial fields, and their storage is in your control.
- Set an HTTP client timeout aligned with the 30-second request timeout, and handle error envelopes and validation_errors explicitly.
Reporting a security issue
If you believe you've found a security vulnerability, please reach out through the access form so we can coordinate a response. Enterprise customers can request our full security documentation and data-processing addendum during their review.
Building on MailFrame?
Read the docs to see the full request contract, check live posture on the status page, or request access to start parsing.