E-mail is the first channel the platform opened, and it serves it end to end. By default, with no provider to carry it, it manages its own sending reputation: that is a constraint – it has to be built – and a guarantee, since no message, no address and no content then passes through a third party. A space that carries no health data can also hand delivery to an external router using its own account – Mailjet and Brevo are integrated, and any routing solution that exposes an API can be: the route changes, tracking and unsubscribe remain with Missivia.
The MTA keeps nothing: the queue, the leases and the results stay inside the API’s perimeter. The “in memory” box lights up for one attempt, then empties.
Built-in delivery
Messages are handed directly to the recipients’ mail servers, from the platform’s own IP addresses.
No third-party sender by default: on the MTA route, the content of a message does not pass through an outside platform.
Opportunistic encryption of the exchange with the recipient server, and an explicit, recorded fallback when it is not available.
For a space that holds health data, TLS is mandatory to the recipient server: without valid TLS, delivery fails explicitly, with no retry, rather than going out in the clear. The contact is not penalised – no bounce, no suppression.
Stateless MTA: it takes a lease on the platform’s queue and asks for the body at the time of the attempt. The platform renders it on the fly and signs it with DKIM itself: no rendered body is stored, and the DKIM keys never leave the perimeter.
On that request, the platform checks unsubscribe, restriction, suppression and inactivity again: a message that has become ineligible since it was queued is not delivered.
Nothing is sent from within an HTTP request: it all goes through the queue, with spaced retries and deferral rather than failure.
Unknown outcome: a body transmitted without an answer from the recipient server is not immediately resent; the message is retried after a single delay – two hours by default – to avoid a duplicate. A late verdict – delivered, or hard bounce – is taken into account when it arrives: it corrects the message status and the counters, including for a message already counted as failed, and the correction is published as an event.
A space’s sending windows and quotas are honoured message by message.
Delivery route of your choice
The Missivia MTA by default; an external router per space, on the customer’s account – Mailjet and Brevo today, and any routing solution that exposes an API. Whatever the route, tracking and suppression remain with Missivia.
The choice is a property of the space, not a platform setting: a space that was never configured is delivered by the MTA. The provider’s credentials are encrypted with the route and never returned – a fingerprint shows which ones are stored.
A verification calls the provider read-only and records the outcome on the route; a provider refusing the credentials is an answer, not a server error.
Rendering remains ours, with the consent rules evaluated at rendering time: our pixels, our rewritten links, our unsubscribe link and its headers. The provider’s tracking is disabled when sending, and its measurement feedback – opens, clicks – is ignored on the way in.
For Brevo, every write to the route requires an attestation, dated and named, that open and click tracking is disabled on the provider account used by the space. An earlier route without an attestation is flagged, to be regularised.
Suppression is synchronised in one direction only: Missivia decides – unsubscribe, hard bounce, complaint – and reports the decision to the provider’s block list. Its list is never imported.
The provider’s feedback – bounce, complaint, unsubscribe, invalid address – produces the same effects as the MTA’s; the feedback URL carries a token specific to the route, rotatable, stored hashed.
A space that declares a health attribute stays on the MTA by construction, in both directions: no switch to a provider, and no health attribute declared on a space already routed – with no operator override.
A provider plugs in behind a single internal interface (sending, feedback, suppression sync): adding a routing solution that exposes an API is one more adapter, with no change for the spaces.
Coming back to the MTA requires no DNS change: the provider’s records are added to ours, they do not replace them.
What does not apply outside the MTA
Sending-domain warm-up and IP health: they drive our IPs and our reputation; on an external route, the reputation is the provider’s.
The aligned bounce domain: the return address belongs to the provider, which receives and classifies its own bounces.
Our DKIM signature: the provider rewrites the body and signs with its own key; the sending domain is therefore authenticated by the provider too, in addition to us.
Unchanged: daily quota, sending windows, consent, suppression list, inactive contacts, rendering, pixels, rewritten links, unsubscribe link and headers.
An external route whose credentials cannot be read fails the send explicitly: no silent fallback to the MTA, which would send from an IP and a domain the space never prepared.
Sending domains
An unverified domain sends nothing. Verification is a condition, not a recommendation.
Declare a domain, publish the DNS records returned – SPF, DKIM, DMARC – and it is verified before the first send.
DKIM signing per domain, with keys kept encrypted and never returned.
An aligned bounce domain per sending domain, so that DMARC alignment is satisfied.
A tracking domain per space for images, public pages and rewritten links – served with no cookie and no external resource.
Removing a domain is checked: it does not break sends in flight.
What you publish in your DNS zone
A sending authorisation for the platform’s IP addresses (SPF).
A public signing key per domain (DKIM), whose private key stays encrypted within the perimeter.
A policy for unaligned messages (DMARC), and the address to receive its reports.
A record for the aligned bounce domain, which makes alignment possible.
A record for the space’s tracking domain: images, public pages and rewritten links.
Reputation and warm-up
A new IP address does not send like an established one.
Progressive warm-up per IP address and per sending domain: daily caps that grow with reputation.
When a cap is reached, the message is deferred, not lost.
Health monitoring per recipient family: large mailbox providers do not react the same way.
Automatic pause when bounce or complaint rates cross a space’s thresholds: we stop before being blocked.
Reputation signals collected from mailbox providers are aggregates about our own IP addresses and domains – never about a person.
Bounces, complaints and suppression
What comes back is handled, and what must stop, stops.
Hard bounces and complaints go straight to the suppression list: that address is not written to again.
Soft bounces are retried at a decreasing rate, then abandoned cleanly.
The suppression list is held as fingerprints, outlives the anonymisation of a record, and is never purged.
A one-click unsubscribe from the mail client takes effect immediately, with no intermediate page. The link in the body goes through a confirmation page, so that a bot following the links in a message unsubscribes no one.
Inactive-contact handling is based solely on the exempt deliverability signal: stopping writing to someone who no longer opens does not require their consent to be measured.
What puts an address on the suppression list
A hard bounce: no such mailbox, invalid domain, outright refusal by the recipient server.
A spam complaint, reported by the mailbox provider.
An unsubscribe, which applies to the purpose concerned and, if the person asks, to all of them.
An objection recorded by the data controller.
A suppression entry is never lifted automatically: it outlives the anonymisation of the record.
Signals and statistics
Numbers that say what they measure, and who they refer to.
Sent, delivered, bounced (hard and soft kept apart), complaints, unsubscribes: delivery signals are independent of any consent to measurement.
Open and click rates are reported against the consenting population, published next to the result.
Breakdown per sending domain, per journey, per campaign and per step.
Exports on demand or scheduled, with no personal data.
Counters served to platform operating roles are masked below the display threshold.
GET /v1/stats/overview?from=2026-09-01&to=2026-09-07
{
"sent": 48210, "delivered": 47655,
"bounced_hard": 212, "bounced_soft": 343,
"complained": 9, "unsubscribed": 127,
"performance": {
"consented_population": 12480,
"opened": 5311, "clicked": 842,
"open_rate": 0.4256, "click_rate": 0.0675
}
}
# Rates are computed on the consenting
# population – never on sends.
