DEV Community: ReceiveHQ

Why compliance pages matter (DPA, sub-processors, hosting, imprint)

ReceiveHQ — Thu, 17 Sep 2026 08:34:52 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #7 — the last in this series: after fan-out, filters, anti-spam, retries, and German baremetal, the question procurement actually asks — where are the pages I can send to legal?

The problem

Topics 2–6 made the pipeline useful. None of that closes a security review if the buyer has to chase you in email for a DPA, a sub-processor list, a hosting declaration, or an imprint. For German legal, tax, healthcare, and similar customers, "we'll send the PDF later" is not a posture — it is a delay.

We built ReceiveHQ because we were tired of shipping European data through American infrastructure. Cortena already runs self-managed baremetal Kubernetes with a short, mostly European subprocessor list. Postmark inbound was a pragmatic compromise for years. When outbound/dunning forced consolidation, we wanted inbound that matched the rest of the stack — and public trust pages you can open without asking.

The four pages (and what each one answers)

Page	URL	What it answers
Hosting	receivehq.com/hosting	Where mail content and app data live (Germany / EEA, Hetzner baremetal, private K8s)
DPA	receivehq.com/dpa	Processor terms under GDPR Art. 28 — scope, security, breach notice, deletion, audits
Sub-processors	receivehq.com/sub-processors	Who else touches data; how you get notice when the list changes
Imprint	receivehq.com/imprint	Legal entity, address, contacts — who you are contracting with

These are not marketing footnotes. They are the documents a DPO or vendor-risk team expects before a trial becomes a production MX.

What the DPA actually covers

The public DPA (/dpa) is incorporated into the ReceiveHQ customer agreement. Highlights that matter in a review:

Processor role — Cortena B.V. processes Customer Personal Data only on documented instructions (the agreement + your endpoint config)
Purpose limit — inbound reception, MIME parse, storage, webhook/blackhole delivery, console, support. No training AI models on your mail
Security — TLS in transit, encrypted volumes at rest, private German K8s, MFA for production, CIDR-restricted SMTP, optional Basic auth on webhooks
Retention — operational MinIO raw .eml / delivery logs: 14-day window unless otherwise agreed
Breach notice — without undue delay, and in any event within 72 hours of awareness
Sub-processors — authorised list at /sub-processors; ≥30 days written notice before add/replace; objection path
Transfers — core mail and application data stay in Germany / the EEA; no unauthorised transfers outside the EEA without prior written consent
Governing law — Netherlands; Amsterdam courts
Contacts — compliance@cortena.ai · DPO Sharon Klaver (dpo@cortena.ai) · signed DPAs on request

Sub-processors vs your webhooks

Core hosting is Hetzner Online GmbH (Germany). Where you enable DNSRBLs, Abusix may see connection metadata only (sender IP/domain) — not mail content. Your configured webhook destinations are under your control; they are not Cortena subprocessors. Pointing a webhook at a US SaaS is a hop you justify, not one we hide.

Why this cut of the story matters

The canonical spine is unchanged: tired of EU data via US infra → Cortena baremetal K8s + short EU subprocessors → Postmark inbound compromise → finance-critical mail forced consolidation → no great EU inbound at sane price → ReceiveHQ (custom domains, multi-endpoint fan-out + filters, anti-spam, MCP agent inbox).

Compliance pages are how that spine survives a vendor questionnaire. Hosting says where. The DPA says under what rules. Sub-processors say who else. The imprint says who signs.

Setup sketch (for the security review, not just the MX)

https://receivehq.com — magic-link sign-in
Domain + MX → mx.receivehq.com, verify
Endpoints + filters / anti-spam as in prior posts
Send legal: hosting · DPA · sub-processors · imprint
Signed DPA / AVV: compliance@cortena.ai · DPO: dpo@cortena.ai

Series wrap

Agent inbox (MCP / blackhole)
One domain → prod + staging webhooks
Recipient filters (support@ vs invoices@)
Anti-spam before webhooks fire
Retries, resend, multi-endpoint
German baremetal — what stays in the EU
This post — why the compliance pages matter

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

German baremetal hosting: what stays in the EU

ReceiveHQ — Wed, 16 Sep 2026 08:36:19 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #6: after retries and resend, the quieter question — where does the mail actually live?

The problem

Topics 2–5 covered fan-out, recipient filters, anti-spam, and delivery survival. None of that helps if the payload still lands on US-region infrastructure by default. For German legal, tax, healthcare, and similar customers, residency is not a checkbox — it is the exam.

We ran Cortena for years with Postmark inbound: great product, wrong continent. When outbound/dunning forced consolidation, we looked for an EU inbound relay at a sane price and found almost nothing. So we built ReceiveHQ on the same posture as the rest of Cortena: self-managed baremetal, short EU-heavy subprocessors, public trust pages.

What stays in Germany / the EEA

ReceiveHQ hosts inbound mail content and related application data in the EU — specifically Germany — so payloads, parse artifacts, and delivery logs stay under EU jurisdiction by default. No US region for core mail storage.

Item	Declaration
Operator	Cortena B.V. (Netherlands)
Primary hosting country	Germany
Infrastructure	Hetzner Online GmbH
Deployment	Private Kubernetes on dedicated / bare-metal servers
Object storage	Cortena-operated MinIO on the same German infra (14-day evidence window for raw `.eml` / logs)

What lives there:

Captured inbound messages and MIME parse artifacts
Delivery attempt logs and activity console records
Tenant configuration and console account records

Customer-configured webhook destinations are under your control — they are not Cortena subprocessors. If you point a webhook at a US SaaS, that hop is yours to justify.

How access is controlled

Encryption in transit (TLS) and at rest (encrypted volumes)
Role-based access; production MFA
SMTP ingest can be CIDR-restricted
Webhooks support HTTPS and optional Basic auth
Operational access is logged so it can be reviewed

Subprocessors (the short list)

| Sub-processor | Country | Purpose |
| --- | --- |
| Hetzner Online GmbH | Germany | Core infra — servers, private K8s, DB, object storage, SMTP edge |
| Abusix.com | US / Germany | Metadata only — DNSRBL lookups for sender IP/domain when you enable blocklists; no mail content |

Live list: sub-processors. Hosting declaration: hosting. DPA: dpa. Imprint: imprint.

Why this cut of the story matters

The canonical spine is unchanged: tired of shipping European data through American infrastructure → Cortena baremetal K8s + short EU subprocessors → Postmark inbound as a pragmatic compromise → finance-critical mail forced consolidation → no great EU inbound at sane price → ReceiveHQ.

Hosting is not a marketing badge. It is the reason multi-endpoint fan-out, filters, anti-spam, and retries are useful for the customers we already serve: evidence you can open, residency you can point to, and a public page when procurement asks "where is the mail?"

Setup sketch

https://receivehq.com — magic-link sign-in
Domain + MX → mx.receivehq.com, verify
Endpoints + filters / anti-spam as in prior posts
Read hosting and DPA before the security review
For signed DPAs: compliance@cortena.ai · DPO: dpo@cortena.ai

Why compliance pages matter (DPA, sub-processors, hosting, imprint).

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

Retries, resend, and the same message to different endpoints

ReceiveHQ — Tue, 15 Sep 2026 08:41:19 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #5: after fan-out, recipient filters, and anti-spam, what happens when your webhook hiccups — or when you need that stored message somewhere else.

The problem

Topics 2–4 got one inbound domain onto several least-privilege webhooks, with junk stopped before HTTPS. That still leaves the operational reality: handlers go down, deploys wedge, and a single message sometimes needs to land on a second endpoint after the fact (new staging sink, rebuilt worker, audit copy).

US-first inbound relays often bury retry policy in a black box, or leave you fishing for raw mail in a support ticket when you need a clean resend. We wanted delivery evidence you can open yourself — on German baremetal.

Retry at the relay, not in every handler

ReceiveHQ's spine stays the same: MIME parsed once on German baremetal, then per-endpoint delivery. Retries are per endpoint, so a flaky staging sink does not stall production:

Control	What it does
Automatic backoff	1m → 5m → 30m → 1h → 2h after non-success
Per-endpoint max attempts	Cap how hard each webhook is pushed
HTTP 406	Permanently drop that delivery (no more retries)
2xx	Success — stop the schedule

At-least-once delivery still means handlers should be idempotent. What you get back is request/response attempt logs plus the retained raw .eml (14-day evidence window) — not a shrug and a ticket.

Resend when you need a second shot

From the activity console or MCP you can:

Search messages and inspect each delivery attempt
Open the raw .eml
Resend with optional To / OriginalRecipient overrides
Point a resend at a different webhook endpoint when you need the same stored message on another sink

That pairs with multi-endpoint fan-out: live traffic can already hit prod + staging; resend covers the "we added a sink later" and "replay after the outage" cases without a second MX or a mailbox dump.

Why this cut of the story matters

We built ReceiveHQ after years on Postmark inbound — great product, wrong continent — and after deciding finance-critical mail shouldn't share infrastructure with the spammers next door. Retries and resend are part of that posture: residency in Germany, short EU-heavy subprocessor list, and delivery evidence you can show when a customer asks what happened to invoice mail at 02:17.

Anti-spam decides whether a message deserves a webhook. Retries and resend decide how it survives your stack's bad day.

Setup sketch

https://receivehq.com — magic-link sign-in
Domain + MX → mx.receivehq.com, verify
Keep existing webhook endpoints (and filters / anti-spam from prior posts)
Confirm per-endpoint attempt limits fit your SLOs
On a failure: console or MCP → inspect attempts → resend (optionally to another endpoint)

Docs: https://receivehq.com/mcp.md · Trust: hosting · DPA · sub-processors

European / German baremetal hosting details — what stays in the EU.

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

Anti-spam before webhooks fire: EU DNSRBLs + scoring you control

ReceiveHQ — Mon, 14 Sep 2026 08:39:51 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #4: after fan-out and recipient filters, stop junk from ever hitting your HTTPS handlers.

The problem

Topics 2–3 got one inbound domain onto several webhooks with least-privilege recipient filters. That still leaves a quieter failure mode: every accepted SMTP message that matches a filter becomes a webhook POST.

Spam and phishing shouldn't burn your workers, fill ticket queues, or force every handler to re-implement reputation checks. US-first inbound relays often bury that policy in a black box — or push it onto your app after the POST already landed.

Filter at SMTP and before forward — in the EU

ReceiveHQ's spine stays the same: MIME parsed once on German baremetal, then per-endpoint delivery. Anti-spam sits upstream of that POST:

Layer	What it does	Where
Optional DNSRBLs	Reject / mark at SMTP time against EU-hosted blocklists	Per domain
Rule / heuristic scoring	Score before forward so borderline mail can stay out of webhooks	Per domain
You decide	Console or MCP — not a opaque vendor default you can't explain in a DPA review	Your tenant

Junk that never forwards never retries. Clean mail still lands in Postmark / Mailgun-SendGrid / CloudMailin (and other drop-in) shapes on the endpoints you already configured.

Why this cut of the story matters

We built ReceiveHQ after years on Postmark inbound — great product, wrong continent — and after deciding finance-critical mail shouldn't share infrastructure with the spammers next door. Fine-grained anti-spam is part of that posture: residency in Germany, short EU-heavy subprocessor list, and controls you can point to when a customer asks what gets through.

Recipient filters decide which of your endpoints see an address. Anti-spam decides whether a message deserves a webhook at all.

Setup sketch

https://receivehq.com — magic-link sign-in
Domain + MX → mx.receivehq.com, verify
Configure domain anti-spam (DNSRBL + scoring) in console or via MCP
Keep existing webhook / blackhole endpoints and recipient filters
Send a known-good test; confirm deliveries with console or list_deliveries

Docs: https://receivehq.com/mcp.md · Trust: hosting · DPA · sub-processors

Retries, resend, and sending the same stored message to different endpoints.

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

support@ vs invoices@: recipient filters per webhook endpoint

ReceiveHQ — Sun, 13 Sep 2026 08:32:00 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #3 in our series: after you fan out one inbound domain to several webhooks, stop every endpoint from eating every address.

The problem

Yesterday's cut was multi-endpoint fan-out — same MX, prod + staging (or support + billing) without a second domain. Useful, until invoices@ lands on your support ticket webhook and support@ hits the AR pipeline.

Classic escapes: separate MX domains per mailbox, a shared "god" webhook that re-routes in app code, or copy-paste handlers with if (to.includes("invoices")). All work. All get messy under GDPR evidence, retries, and drop-in Postmark/Mailgun parsers.

Filter at the endpoint, not in every handler

ReceiveHQ still parses MIME once in Germany. Delivery is per endpoint. Each endpoint can carry a recipient filter so only matching To / OriginalRecipient addresses forward:

Endpoint	Filter idea	Destination
Support	`support@`, `help@`	ticketing webhook (Postmark shape)
Invoices	`invoices@`, `billing@`	AR / bookkeeping webhook
Catch-all or blackhole	unmatched / empty	MCP audit, triage later

Same domain. Same MX (mx.receivehq.com). Independent delivery logs and retries. Staging can keep a looser filter; prod invoices stay on the finance URL.

Setup sketch

https://receivehq.com — magic-link sign-in
Domain + MX → mx.receivehq.com, verify
Add two (or more) webhook endpoints — console or MCP create_inbound_domain_endpoint
Set recipient filters per endpoint (address / pattern for that route)
Send tests to support@ and invoices@; confirm with console or list_deliveries

Docs: https://receivehq.com/mcp.md · Webhook shapes: Postmark / Mailgun-SendGrid / CloudMailin

Why this belongs next to fan-out

Fan-out without filters is a firehose. Filters keep least-privilege delivery: finance mail never has to touch the support stack, and support never has to special-case invoice MIME. You still get 14-day .eml retention, per-endpoint backoff (1m→5m→30m→1h→2h), and HTTP 406 drop — without rewriting every handler.

Next: anti-spam / scoring before webhooks fire.

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Trust: hosting · DPA · sub-processors · imprint

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

One inbound domain, two webhooks: prod + staging without a second MX

ReceiveHQ — Sat, 12 Sep 2026 08:28:20 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #2: one inbound domain, multiple webhooks — prod + staging without a second MX.

The problem

You want the same mailbox on inbound.example.com in production and staging. Classic options (second MX, re-POST proxy, duplicated DNS) are awkward for GDPR-sensitive or Postmark-shaped parsers.

One parse, many deliveries

ReceiveHQ accepts SMTP, parses MIME once in Germany, then delivers per endpoint on the same domain:

prod → live HTTPS webhook (Postmark / Mailgun-SendGrid / CloudMailin shape)
staging → second HTTPS URL, independent retries/logs
optional blackhole → store-only for MCP/audit

Same MX (mx.receivehq.com). Same message. Separate attempt streams. Staging can 500 without poisoning prod.

Setup

https://receivehq.com — magic-link sign-in
Create domain, MX → mx.receivehq.com, verify
Add two webhook endpoints (console or MCP create_inbound_domain_endpoint twice)
Send a test; confirm both deliveries via console or list_deliveries

Docs: https://receivehq.com/mcp.md

Why this beats a re-post proxy

Parse once (14-day .eml retention). Independent backoff (1m→5m→30m→1h→2h) and HTTP 406 drop per endpoint. Drop-in payload shapes. EU residency on German Hetzner baremetal (Cortena B.V.).

Next: recipient filters so staging does not eat invoices@.

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Trust: hosting · DPA · sub-processors · imprint

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

We were tired of shipping European data through American infrastructure — so we built ReceiveHQ

ReceiveHQ — Fri, 11 Sep 2026 18:45:54 +0000

We were tired of shipping European data through American infrastructure — so we built ReceiveHQ

At Cortena we run our own Kubernetes cluster on self-managed baremetal, treat infrastructure as code from day one, and keep a short, vetted subprocessor list — mostly European, with a couple of carefully scoped exceptions.

That posture exists because our customers are German legal, tax, healthcare, and defensive practices. For them, data protection is not a checkbox. It is the exam.

The Postmark compromise

Early on we made one pragmatic compromise: Postmark for inbound email-to-webhook. Great product. Wrong continent. At the time there was no European inbound-only option with a sane business model. We used it for years. It worked.

Then customers asked for outbound — dunning, accounts receivable, the unglamorous machinery that actually gets companies paid. That raised an uncomfortable question:

Do we want finance-critical email sharing infrastructure with the spammers next door?

No. So we decided to consolidate email onto our own platform. While researching European inbound options we found… basically nothing great at a reasonable price. Again.

We need this. So other teams probably do too.

Meet ReceiveHQ

ReceiveHQ is a European inbound email-to-webhook service. Philosophy: simple for the simple things, flexible when you need it. A straight inbound-to-webhook pipeline with what we wished Postmark had while running our own product:

Custom inbound domains — minutes, not an afternoon
Multi-endpoint fan-out — same mail to multiple webhooks, with per-endpoint filters
Fine-grained anti-spam — you decide what gets through
MCP access to email history — give an AI agent a real email address

Drop-in webhook shapes for Postmark, Mailgun/SendGrid, and CloudMailin are supported so you can keep an existing handler.

Built on our own baremetal in Europe, with the compliance pages German customers expect: hosting, DPA, sub-processors, imprint.

Pricing

€10/month (or €100/year) for up to 100k inbound emails. First 10 free per tenant.

If you have been shipping sensitive European email through US infrastructure because there was no alternative — there is now.

—
Sebastian Lagemann, CTO & Co-founder, Cortena B.V. (disclosure: I work on ReceiveHQ)

Let your agent receive email when it needs to

ReceiveHQ — Fri, 11 Sep 2026 08:34:44 +0000

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). This is a concrete walkthrough of one feature we use ourselves: giving Cursor or Claude a real inbound mailbox over MCP, without waiting for a webhook handler to exist.

The problem

Agent workflows often need email mid-task: a vendor sends a confirmation, a support reply lands, a magic link arrives, or you want the agent to triage overnight mail. Most inbound products assume you already have a public HTTPS endpoint and a parser wired up. Agents don't.

Blackhole first, webhook later

ReceiveHQ endpoints come in two kinds:

Kind	URL	What happens

Create an account at https://receivehq.com (magic-link sign-in).
Add the MCP server to your client:

{
  "mcpServers": {
    "receivehq": {
      "url": "https://receivehq.com/api/mcp"
    }
  }
}

Start the client — OAuth 2.1 + PKCE opens a browser for login and consent.
Revoke apps anytime under Settings → MCP in the console.

Endpoint docs live at https://receivehq.com/mcp.md (also /llms.txt).

Agent quick start

From Cursor, Claude, or another MCP client:

Run setup_inbound_domain with endpointKind: "blackhole" (no endpointUrl), or create the domain then create_inbound_domain_endpoint.
Point MX to mx.receivehq.com, then verify_inbound_domain_mx.## What else the agent can do

Tenants, domains, and endpoints (CRUD)
Search messages, inspect delivery attempts, resend
Invite teammates
Billing: Checkout / Customer Portal URLs
Fetch retained attempt and raw-mail objects by key (14-day evidence window)

Scopes: mcp:read for reads, mcp:admin for mutations. Tokens are user-scoped across that user's tenants.

Why this beats "paste the email into chat"

Real SMTP address on your domain (or a ReceiveHQ receive domain)
MIME parsed once; raw .eml retained for support and compliance
Same account can later fan out to webhooks without re-ingesting history
Hosted in Germany (Hetzner); DPA / sub-processors / hosting / imprint are public for GDPR buyers

Try it

Sign up: https://receivehq.com
Connect MCP: https://receivehq.com/api/mcp
Create a blackhole endpoint and send yourself a test message
Ask the agent to list_messages

Pricing: €10/mo or €100/yr for up to 100k inbound emails; first 10 free per tenant.

Trust links: hosting · DPA · sub-processors · imprint

Read mail with list_messages / get_message / list_deliveries.

When you are ready for production delivery, create or update an endpoint as webhook with your URL and payloadFormat (postmark, Mailgun/SendGrid, or CloudMailin). Same mailbox, no DNS redo.

Blackhole is the agent-friendly path: capture mail now, decide routing later.

Launching ReceiveHQ: inbound email webhook, hosted in Germany

ReceiveHQ — Thu, 10 Sep 2026 19:09:40 +0000

We're launching ReceiveHQ — inbound email infrastructure for teams that need SMTP in and HTTPS out, without rewriting webhook handlers or shipping mail through US-first relays.

https://receivehq.com

What it is

ReceiveHQ receives mail on your domain, parses MIME, and delivers it to your app as webhooks in the same shapes used by Postmark, Mailgun/SendGrid, and CloudMailin. Point your MX records at ReceiveHQ and keep the parser you already trust.

It is inbound-only, flat-priced, and hosted in Germany for GDPR-minded and EU-only stacks.

Why we built it

Moving off Postmark, Mailgun, SendGrid, or CloudMailin inbound often means two migrations: DNS and the webhook contract. ReceiveHQ makes the second one optional.

For EU buyers, “maybe an EU region” on a US product is often not enough for invoices, payroll, or support mail. ReceiveHQ runs on German infrastructure by default — not as a checkbox.

Features live today

Drop-in inbound webhooks

Postmark-compatible JSON: From, To, OriginalRecipient, TextBody, HtmlBody, attachments, headers, raw email, and more
Mailgun / SendGrid multipart: text / html, body-plain / body-html, envelope, attachment fields, and raw MIME
CloudMailin-compatible JSON: envelope, headers, plain text, HTML, and base64 attachm- Multi-tenant domains, address filters, and optional Basic auth on webhooks
14-day retention of raw mail and attempt logs for support/compliance evidence
Blackhole endpoints to receive and store mail without forwarding, useful when an agent reads the inbox via MCP/API before a webhook URL exists

Agent-native MCP

Connect Cursor, Claude, or another MCP client over OAuth 2.1 + PKCE.

Endpoint: https://receivehq.com/api/mcp
Configure domains, create blackhole or webhook endpoints, search messages, inspect deliveries, invite teammates, and manage billing from the agent
Agent docs: /llms.txt and /mcp.md

EU / GDPR posture

Hosting declaration: Germany / Hetzner
DPA
Sub-processors
Imprint (Cortena B.V., Netherlands)

Pricing

€10 / month for up to 100,000 inbound emails
Or €100 / year
First 10 emails free per tenant, with up to 3 trial tenants

There is no outbound bundle required to unlock inbound.

Try it

Sign up at receivehq.com
Add your receive domain and set MX
Pick the Postmark, Mailgun/SendGrid, or CloudMailin payload format
Or connect MCP and create a blackhole endpoint to start reading mail immediately

Webhook API docs are on the site. Feedback is especially welcome from anyone who has migrated an established inbound integration: which provider-specific edge cases were hardest to preserve?

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

—

Sebastian Lagemann

https://receivehq.com · listings@receivehq.com

Who it is for

EU / GDPR-sensitive products that already speak Postmark, Mailgun, SendGrid, or CloudMailin inbound
Teams tired of SES + SNS + Lambda glue just to get email into an HTTP handler
Agent workflows that need a real inbound mailbox readable and configurable over MCP ents

Production inbound

SMTP in → HTTPS out, with multi-endpoint fan-out
Automatic retry backoff (1m → 5m → 30m → 1h → 2h), per-endpoint attempt limits, and HTTP 406 to permanently drop
Activity console with message search, delivery attempts, request/response logs, raw .eml, and resend with To / OriginalRecipient overrides