ReceiveHQ
Inbound email to webhook. Hosted in Germany.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Product update #7 — last in the series: after fan-out, filters, anti-spam, retries, and German hosting — the pages procurement actually opens.
The pain
A useful inbound→webhook pipeline still stalls if legal has to email you for a DPA, sub-processor list, hosting declaration, or imprint. "We'll send the PDF later" is a delay, not a posture — especially for EU legal/tax/healthcare buyers.
The ReceiveHQ cut
Four public pages, no chase:
- Hosting — https://receivehq.com/hosting — Germany / EEA, Hetzner baremetal, private K8s; mail + app data stay in the EEA
- DPA — https://receivehq.com/dpa — Art. 28 processor terms; no AI training on your mail; 14-day raw
.emlwindow; 72h breach notice; NL law - Sub-processors — https://receivehq.com/sub-processors — short list; ≥30 days notice on changes; Abusix metadata-only if you enable DNSRBLs
- Imprint — https://receivehq.com/imprint — Cortena B.V., Amsterdam — who you contract with
Your webhook destinations are yours, not our subprocessors.
Spine: we built this after years on Postmark inbound (great product, wrong continent) and deciding finance-critical mail shouldn't share US infra with the spammers next door.
Also published on Dev.to: https://dev.to/receivehq/why-compliance-pages-matter-dpa-sub-processors-hosting-imprint-142k
Try: https://receivehq.com · Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free
Signed DPA: compliance@cortena.ai · DPO: dpo@cortena.ai
Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Product update #6: after fan-out, filters, anti-spam, and retries — where the mail actually lives.
The pain
US-first inbound relays bury residency behind a region picker (or none). For EU legal/tax/healthcare customers, "ship it through American infra because there was no alternative" is not a plan.
The ReceiveHQ cut
- Germany by default — Hetzner dedicated / bare-metal, private Kubernetes
- Mail content, parse artifacts, delivery logs, tenant config → EU (no US region for core mail)
- Cortena-operated MinIO on the same German infra · 14-day raw
.emlevidence - Short list: Hetzner (DE) for core; Abusix metadata only if you enable DNSRBLs (no mail content)
- Your webhook destinations are yours — not our subprocessors
Public: https://receivehq.com/hosting · /dpa · /sub-processors · /imprint
Spine: we built this after years on Postmark inbound (great product, wrong continent) and deciding finance-critical mail shouldn't share US infra with the spammers next door.
Try: https://receivehq.com · Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free
Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Product update #4: after multi-endpoint fan-out and recipient filters, keep junk from POSTing your handlers.
The pain
Every matching inbound becomes a webhook. Without upstream controls, spam burns workers and ticket queues — or you reinvent reputation checks in every app.
The ReceiveHQ cut
MIME parsed once in Germany. Then before forward:
- Optional EU-hosted DNSRBLs at SMTP time (per domain)
- Rule / heuristic scoring so borderline mail never hits HTTPS
- You set policy in console or MCP — not a black box
Clean mail still uses drop-in Postmark / Mailgun / CloudMailin shapes. Same MX (mx.receivehq.com). Recipient filters still decide which endpoint sees which address.
Setup: domain → verify MX → turn on domain anti-spam → keep endpoints. Docs: https://receivehq.com/mcp.md
Next: retries, resend, same message → different endpoints.
Try: https://receivehq.com · Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free
Trust: https://receivehq.com/hosting · /dpa · /sub-processors · /imprint
Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Product update #3: after multi-endpoint fan-out, add recipient filters so each webhook only sees the addresses it should.
The pain
One inbound domain, several webhooks (prod + staging, or support + billing). Without filters, invoices@ hits support and support@ hits AR — or you ship a god-handler that re-routes in app code.
The ReceiveHQ cut
MIME parsed once in Germany. Then per-endpoint delivery with recipient filters:
- Support endpoint →
support@/help@→ ticketing webhook - Invoices endpoint →
invoices@/billing@→ finance webhook - Optional blackhole / catch-all for the rest (MCP triage)
Same MX (mx.receivehq.com). Separate retries and delivery logs. Drop-in Postmark / Mailgun / CloudMailin shapes.
Setup: domain → verify MX → create endpoints → set recipient filters (console or MCP). Docs: https://receivehq.com/mcp.md
Next: anti-spam before webhooks fire.
Try: https://receivehq.com · Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free
Trust: https://receivehq.com/hosting · /dpa · /sub-processors · /imprint
Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Product update #2 in our use-case series: multi-endpoint fan-out — the feature we wanted while we were still using Postmark for inbound.
The pain
You need the same mailbox on inbound.example.com in production and staging. Second MX, re-POST proxy, or duplicated DNS — all awkward, especially for GDPR-sensitive mail.
The ReceiveHQ cut
One MX (mx.receivehq.com). MIME parsed once in Germany. Then independent webhook endpoints on that domain:
- Prod → your live Postmark/Mailgun/CloudMailin-shaped handler
- Staging → a second HTTPS URL (same or different payload format)
- Optional blackhole → store-only for MCP / audit
Separate retries and delivery logs per endpoint. Staging can fail without poisoning prod. Raw .eml retained 14 days.
Setup: create domain → verify MX → add two webhook endpoints (console or MCP create_inbound_domain_endpoint). Docs: https://receivehq.com/mcp.md
Next up: recipient filters so staging doesn't eat invoices@.
Try: https://receivehq.com · Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free
Trust: https://receivehq.com/hosting · /dpa · /sub-processors · /imprint
Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.
-
1
The prod/staging split is a clear pain, but how often does this actually force teams into a second MX, proxy, or duplicated setup? Have customers paid for ReceiveHQ specifically to remove that workaround?
-
1
Good question, for everyone who's doing mail inbound and want to route it and don't want to run their own inbound mailserver it's impossible on mail ingress side but way later, either you route to a central endpoint and split there yourself to the final service actually processing or (the more common case also in our case initially) you set-up additional email domains. The challenge is that it's always a real pain to get this one single awful email which broke everything in prod to behave the exact same way in staging.
So you build a lot of tools around this to make somewhat work and debug, most often when you don't have time for that, so yes, people paying for this exact feature and even better, with our product you can do it even post-fact: Find the email which was the problem to process, re-schedule it to a new endpoint on demand to test, combined with Punchmole (a very simple self-hosted open-source proxy of which I'm the author) you can do it even up to into your local development environment.
-
We were tired of shipping European data through American infrastructure — so we built our own inbound email stack.
At Cortena we run baremetal Kubernetes, keep a short mostly-EU subprocessor list, and sell to German legal / tax / healthcare / defensive practices where GDPR is not a slide in the deck.
For years inbound went through Postmark: great product, wrong continent, and no serious European inbound-only alternative with a sane price. When customers asked for outbound (dunning / AR), we did not want finance-critical mail next to spam tenants — so we consolidated email onto our platform.
Researching EU inbound options again: still thin. That is the product signal.
ReceiveHQ (https://receivehq.com) — European inbound email → webhook:
- Custom inbound domains in minutes
- Multi-endpoint fan-out + per-endpoint filters
- Fine-grained anti-spam
- MCP so an agent can have an email address
- Drop-in Postmark / Mailgun / SendGrid / CloudMailin webhook shapes
- Baremetal EU hosting + DPA / sub-processors / hosting / imprint pages
€10/mo or €100/yr for 100k inbound. Built because we needed it.
I'm Sebastian, CTO & co-founder of Cortena B.V. — I work on ReceiveHQ.
I'm Sebastian (CortenaSeb), CTO at ReceiveHQ / Cortena B.V. Quick product update: how we let Cursor or Claude own a real inbound mailbox over MCP — no webhook required on day one.
Why blackhole endpoints
Most inbound tools assume you already have a public HTTPS handler. Agents often don't. ReceiveHQ blackhole endpoints receive, parse, and store mail without forwarding. Delivery status is blackholed. When you're ready, flip the same route to a webhook (Postmark / Mailgun-SendGrid / CloudMailin shapes) without changing MX.
Connect MCP
Add https://receivehq.com/api/mcp to your MCP client (OAuth 2.1 + PKCE). Docs: https://receivehq.com/mcp.md
Typical agent flow:
- setup_inbound_domain with endpointKind: "blackhole"
- Point MX to mx.receivehq.com, then verify_inbound_domain_mx
- list_messages / get_message / list_deliveries
The agent can also manage domains, endpoints, resend, teammates, and billing from the same session.
Why not paste mail into chat
Real SMTP on your domain, MIME parsed once, raw .eml retained 14 days, German hosting (Hetzner). Same account can later fan out to production webhooks.
Try it: https://receivehq.com
Product: https://www.indiehackers.com/product/receivehq
€10/mo or €100/yr · 100k inbound · first 10 free per tenant
Trust: https://receivehq.com/hosting · /dpa · /sub-processors · /imprint
Also on Dev.to: https://dev.to/receivehq/let-your-agent-receive-email-when-it-needs-to-1g7
Today we’re launching ReceiveHQ, a simpler way to get email into an application: SMTP in, HTTPS out.
ReceiveHQ receives mail on your domain, parses MIME, and delivers webhook payloads compatible with Postmark, Mailgun/SendGrid, and CloudMailin. Point your MX records at ReceiveHQ and keep the handler you already have.
We built it for teams that want inbound-only infrastructure, predictable pricing, and German hosting by default — especially EU/GDPR-sensitive products handling invoices, payroll, or support mail.
What’s live:
- Multi-endpoint fan-out with retries and delivery logs
- Searchable activity console, raw .eml, and resend controls
- Multi-tenant domains, address filters, and optional webhook Basic auth
- Blackhole endpoints for storing mail before a webhook exists
- MCP support over OAuth 2.1 + PKCE, so Cursor, Claude, or another MCP client can configure domains, create endpoints, and search messages
Pricing is €10/month for up to 100,000 inbound emails, or €100/year. The first 10 emails are free per tenant (up to 3 trial tenants), and there’s no outbound bundle required.
If you’re migrating an established inbound integration, I’d love to hear which provider-specific edge cases were hardest to preserve.
I’m Sebastian, CTO & co-founder of Cortena B.V., and I work on ReceiveHQ.
Website: https://receivehq.com
EU/GDPR pages: https://receivehq.com/hosting · https://receivehq.com/dpa · https://receivehq.com/sub-processors
1 Comment
The pages remove a real procurement friction, but have any prospects actually moved faster or continued a deal because the compliance details were available upfront?