Email Routing — Platform Address Map
Living document — update this file when adding or removing any platform email address.
Purpose: ADR-style decision record mapping every @raxx.app and @moosequest.net address to its
handling system, direction, and watcher. Use this as the authoritative reference for onboarding,
debugging, or extending email infrastructure without misrouting.
Last updated: 2026-05-12 UTC Related issues: #1216 (this card), #651 (parent epic: support.raxx.app), #708 (support@ SLA-bearing inbound wiring), #1759 (closed — MX-swap approach superseded), #1665 (Postmark inbound stream provisioning), #1666 (bridge Lambda)
Two-track design principle
All platform email follows one of two tracks. This is a hard architectural separation — do not blur the boundary between them.
| Track | Stack | Use case | Rationale |
|---|---|---|---|
| Human-to-human | Google Workspace (primary domain moosequest.net, alias domain raxx.app) |
Replies from humans: investor emails, partner conversations, attorney correspondence, billing receipts, ops alerts | Messages require human judgment, no SLA clock, not ticketable |
| Serviceable / SLA-bearing inbound | Google Workspace routing rule → Postmark inbound → SNS → SQS → Lambda → FreeScout at tickets.raxx.app |
Customer support requests requiring tracking, assignment, and response SLA | Messages require ticket lifecycle, audit trail, and assignable ownership |
This separation is documented in project_email_mental_model.md (in-memory) and was established
as part of epic #651. See also docs/business/business-email.md for the Google Workspace
multi-domain architecture that underpins the human-to-human track.
How support@raxx.app inbound is routed
Decision (locked, confirmed 2026-05-12 UTC): support@raxx.app inbound is handled by a
Google Workspace routing rule that forwards the address to Postmark's inbound stream. Google MX
records on raxx.app remain in place.
Why routing rule — not MX swap
PR #1759 originally proposed swapping the raxx.app MX records from Google to Postmark. The
operator rejected that approach and the PR was closed as superseded. The routing-rule design is
the locked implementation.
The MX-swap approach was rejected for three reasons:
- Google inbound on raxx.app must survive. The
raxx.appMX chain (priority 1–10,aspmx.l.google.com) handles inbound delivery forkris@raxx.app,ops@raxx.app,billing@raxx.app, and any future Google-routed addresses. Swapping MX to Postmark would silently break all of those. - Routing rule achieves the same result without DNS risk. Google Workspace routing rules intercept mail to a specific recipient address before delivering to a mailbox, and forward it to an external address (in this case Postmark's inbound webhook relay address). No DNS change required; no MX competition.
- Two-track integrity is preserved. Google holds the MX layer for all
@raxx.appaddresses. The routing rule creates the SLA-bearing branch forsupport@without affecting any other address. Human-to-human and ticketed inbound coexist cleanly on the same MX chain.
What support@raxx.app IS (and is not)
- It IS a Google Workspace routing target — Google MX receives the message and the routing rule forwards it to Postmark.
- It is NOT a Google Workspace mailbox or user account — no one signs in to read it in Gmail. There is no Google inbox for this address.
- It is NOT a Google Workspace alias on a user account.
The downstream pipeline from Postmark onward is unchanged from the durable-email-delivery design
(docs/architecture/durable-email-delivery.md):
Sender
└─► Google MX (raxx.app)
└─► Google Workspace routing rule: support@raxx.app
└─► Postmark inbound webhook relay
└─► API Gateway POST /webhooks/postmark/inbound
└─► SNS FIFO: raxx-email-inbound.fifo
└─► SQS FIFO: raxx-email-inbound-bridge.fifo
└─► Lambda: raxx-email-inbound-bridge (#1666)
└─► FreeScout API POST /api/conversations
Issue #708 — satisfied by routing-rule design
Issue #708 (parent epic item: "Add raxx.app inbound routing for support@") is satisfied by this
routing-rule approach. The requirement was to deliver inbound mail to support@raxx.app into
FreeScout — the routing rule achieves that without any MX record changes. #708 does not require or
imply an MX swap.
Adding future SLA-bearing addresses
When a new SLA-bearing address (e.g., abuse@raxx.app, dpo@raxx.app) is needed, the path is:
- Add a Google Workspace routing rule for the new address → Postmark inbound relay.
- Add the address to the SSM routing map
/raxx/email/mailbox_routing_mapwith the target FreeScout mailbox ID. - Do NOT modify
raxx.appMX records.
Address map — @raxx.app
| Address | Type | System | Direction | Watcher | Related issues | Status |
|---|---|---|---|---|---|---|
support@raxx.app |
Customer support | Google routing rule → Postmark inbound → FreeScout (Postmark SMTP relay outbound) | Inbound + outbound | Kristerpher via FreeScout | #651, #708, #710, #1665, #1666 | Live — do not modify |
ops@raxx.app |
Operations alerts | Google Group → kris@moosequest.net |
Inbound + outbound | Kristerpher | — | Pending provisioning |
billing@raxx.app |
Billing receipts / invoices | Google Group → kris@moosequest.net |
Inbound + outbound | Kristerpher | — | Pending provisioning |
no-reply@raxx.app |
Automated outbound only | Google Workspace alias (send-as) or dedicated user | Outbound only | n/a (intentional discard on inbound) | — | Pending provisioning |
For provisioning instructions (Google Admin steps) and the full Postmark sender signature state,
see docs/ops/email-routing.md.
Address map — @moosequest.net
| Address | Type | System | Direction | Watcher | Notes |
|---|---|---|---|---|---|
kris@moosequest.net |
Primary operator email | Google Workspace (primary mailbox) | Inbound + outbound | Kristerpher | Primary human-to-human; all @raxx.app aliases resolve here unless overridden |
support@moosequest.net |
Operator personal support channel | Google Workspace | Inbound + outbound | Kristerpher | Two-track design: this is the human channel; support@raxx.app is the ticketing channel. Keep separate. |
The moosequest.net domain uses Oracle Dyn for DNS (stays on Dyn per ops policy — never
migrate). SPF, DKIM, and DMARC state for this domain is documented in
docs/ops/email-dns-state.md.
Routing decisions — reference table
| Address | Inbound system | Outbound system | Notes |
|---|---|---|---|
support@raxx.app |
Google MX → routing rule → Postmark inbound → FreeScout | FreeScout via Postmark SMTP | Routing rule, not MX swap; see design rationale above |
ops@raxx.app |
Google MX → Google Group | Postmark (CloudWatch alarm SNS target) | Ops alerts are human-readable notifications, not ticketable events |
billing@raxx.app |
Google MX → Google Group | Stripe / billing system webhooks | Billing alerts require human review, not SLA-tracked responses |
no-reply@raxx.app |
Discard (alias — no monitored inbox) | Postmark transactional | Automated outbound only; no legitimate inbound expected |
kris@moosequest.net |
Google Workspace | Google Workspace | Primary human mailbox; no SLA bearing |
support@moosequest.net |
Google Workspace | Google Workspace | Operator's personal support channel; not customer-facing |
MX record state — raxx.app
raxx.app MX records point to Google Workspace (added 2026-04-22 for Google Workspace alias-domain
setup). These records must not be modified when wiring new SLA-bearing addresses. Use Google
Workspace routing rules instead.
| Priority | MX host |
|---|---|
| 1 | aspmx.l.google.com |
| 5 | alt1.aspmx.l.google.com |
| 5 | alt2.aspmx.l.google.com |
| 10 | alt3.aspmx.l.google.com |
| 10 | alt4.aspmx.l.google.com |
Related documents
docs/ops/email-routing.md— Operational detail: provisioning state, Google Admin step-by-step, FreeScout mailbox IDs, Postmark sender signaturesdocs/ops/email-dns-state.md—moosequest.netSPF/DKIM/DMARC audit (2026-05-11 UTC)docs/architecture/durable-email-delivery.md— Email pipeline design (SNS/SQS/Lambda/Postmark) — downstream of Postmark inbounddocs/business/business-email.md— Google Workspace multi-domain architecture- Issue #651 — Parent epic: support.raxx.app (FreeScout)
- Issue #708 — support@ SLA-bearing inbound wiring (satisfied by routing-rule design, not MX swap)
- Issue #710 — Postmark inbound webhook wiring
- Issue #1665 — Postmark inbound stream provisioning (SC-E2)
- Issue #1666 — Bridge Lambda: inbound Postmark → FreeScout (SC-E3)
- PR #1759 — CLOSED: MX-swap approach superseded by routing-rule design (2026-05-12 UTC)