Pipeline notePlatform-domain onboarding now publishes DMARC in monitoring mode by default.Read the record

From registrar to inbox

Four steps, and the ledger records every one.

Both onboarding paths end in the same place: a verified domain, a signed inbound endpoint and a mailbox that keeps a complete record of what arrived and what left.

  1. 01

    Choose your path

    Bring your own Resend account and keep full control of the sending reputation, or move to a paid plan and have Mailhaven provision the sending domain under the operator account.

  2. 02

    Verify for real

    We call Resend with your key, confirm the domain’s verification status and run a live test send. Each result you see is the provider’s own response — there are no synthetic green ticks in this product.

  3. 03

    Point the mail at us

    Inbound arrives on a signed webhook unique to your account. Deliveries are deduplicated by provider id and Message-ID, threaded, spam-scored and filed before the body is fetched in the background.

  4. 04

    Work the ledger

    Read, reply, forward and search from a two-pane mailbox that reads like a register — with every delivery, fetch attempt and send recorded against your account.

What happens to a single message

Five stages, in this order, every time. The order is what makes the guarantee possible: verify, archive, persist, then fetch.

  1. Delivery arrives

    Resend posts to the endpoint that belongs to your account. Nothing is read from the body until the svix signature, timestamp window and account state have been checked.

    POST /webhook/inbound/<slug> · svix-id · svix-timestamp · svix-signature

  2. Raw payload archived

    The exact bytes we received are written to object storage before any parsing. That archive is what makes a retry possible hours later.

    raw/<slug>/<date>/<uuid>.json

  3. Metadata persisted idempotently

    Sender, recipients, subject, headers and threading identifiers are stored. A repeat delivery of the same provider id or Message-ID updates nothing and creates nothing.

    unique(accountId, resendMessageId) · unique(accountId, messageIdHeader)

  4. Content fetch queued

    A durable job collects the body and attachments. Transient failures back off exponentially and are retried; exhausted jobs are dead-lettered for the operator, never dropped.

    FETCH_MESSAGE_CONTENT · attempts ≤ 6 · backoff 5s → 30m

  5. Threaded, scored, filed

    In-Reply-To and References are resolved against your stored Message-IDs, authentication results are scored, and the message lands in Inbox or Spam with its reasons attached.

    thread matched by in-reply-to | references | subject window

Mail handled like cargo with provenance.

Signed for at the door

Every inbound webhook is signature-verified against your own secret — or the operator secret on the shared path — before a single byte is stored. Unsigned traffic is rejected and recorded, never quietly accepted.

Nothing lost in transit

Metadata is persisted the moment mail arrives. The body and attachments are collected by a durable background job with exponential backoff, so a provider hiccup delays a message instead of losing it.

Threads that actually hold

Message-ID, In-Reply-To and References are read on the way in and written on the way out, so your replies group correctly in the recipient’s client as well as in your own mailbox.

Read without being tracked

Mail renders inside a sandboxed frame with remote images blocked until you ask for them. Attachments are reachable only through signed links that expire in minutes.

The machinery stays visible

DNS propagation, webhook deliveries, fetch attempts and raw Message-IDs are printed in monospace like a shipping manifest. Pending states say pending, with the time of the last check.

Sealed credentials, strict tenancy

Provider keys are encrypted at rest with a per-record salt, and every query is scoped to a single account. There are no shared views and no cross-tenant joins anywhere in the product.

Straight answers about how the mail moves.

Open a mailbox
Do I need my own Resend account?
On the Starter plan, yes — you supply a Resend API key, a webhook signing secret and a verified domain, and you keep full control of your sending reputation. On paid plans you can instead let Mailhaven provision the sending domain for you under the operator account.
What happens if the same webhook arrives twice?
Nothing visible. Deliveries are deduplicated on the provider message id and the Message-ID header, both scoped to your account, so a retried delivery updates the record it already created instead of producing a duplicate in your inbox. The second delivery is still logged so you can see it happened.
Can Mailhaven staff read my mail?
The operator console shows connection health, delivery outcomes and job state — never message bodies or attachments. Message content is only ever queried with your account id bound to the request, and provider credentials are encrypted at rest.
How long does DNS take on the done-for-you path?
Usually minutes, occasionally up to 48 hours. Each record is checked individually against public resolvers and reported as pending with the time of the last look-up until it appears. Slow propagation never shows up as a failure.
What happens to a message that is scored as spam?
It is filed in the Spam folder with the reasons it scored, and it stays there until you move it. Mailhaven never deletes mail automatically, and one click returns a message to the inbox.
Can I move from my own account to the platform domain later?
Yes. The connection type is per account and can be switched once you are on a paid plan and your identity check is approved. Existing mail, threads and attachments stay exactly where they are.