mailnix Docs
    mailnix / Common use cases

    Getting started

    Common use cases

    mailnix is a translation, routing, and observability layer for transactional email. The same product fits a handful of distinct workflows. Use this page to find the one closest to yours, then jump to the article that walks through the setup.

    If you are new to mailnix entirely, start with Getting started for the three-minute first send. The use cases below assume you already have an account.

    An AI agent that sends email on a user's behalf

    You are building a personal-assistant agent in Claude Code, Cursor, LangGraph, or a Custom Connector. The agent books appointments, sends recap emails, drafts replies, and you want it to send through real SMTP without forcing your end-user to wire a provider before the agent can demonstrate itself.

    How mailnix fits:

    • The agent calls email_send_test(to, subject, text) on mcp.mailnix.ch. The first call mints an anonymous project plus a sandbox destination, so the agent can send before the user signs up.
    • When the user is ready to attach the agent to their account, the agent calls account_claim with their email. A magic-link email arrives; one click attaches the anonymous project to the user's mailnix account, and any sandbox traces come along with it.
    • Every send returns a trace_id the agent can hand to the user (or pass back to itself on the next turn) for a full audit of what happened.

    Read MCP server for the full agent integration and Inspect for sandbox-inbox capture during testing.

    Transactional email for a SaaS app

    You run a 10-person SaaS that sends signup confirmations, password resets, receipts, and shipping notifications. Today you use Postmark, Resend, or AWS SES directly. You want:

    • Tracing on every send, so support can answer "what happened to the welcome email for user@example.com 5 minutes ago".
    • Multi-provider routing so a single outage does not stop transactional mail.
    • A way to expose email status to your AI support assistant.

    How mailnix fits:

    • Connect each provider as a separate destination. Routing rules pick which provider handles each send based on category, recipient domain, or priority. See Routing.
    • Failover policies move the send to a backup destination when the primary returns a 5xx, a 429, or a timeout, without your app having to know. See Failover.
    • Every send carries an IdempotencyKey so retried requests do not double-send the same receipt.
    • Your support team (or its AI assistant) looks up traces by recipient and time window from /traces or via the MCP tool email_trace_lookup.

    Read Destinations, Routing, and Failover for the setup.

    Bring-your-own-provider, escape vendor lock-in

    You are an engineering manager whose ESP just hit you with a 2x price hike. You want to evaluate moving to Resend or AWS SES without rewriting every call site in your app.

    How mailnix fits:

    • Point your app at mailnix once. Configure SendGrid as destination_id=A, Resend as destination_id=B. Use routing rules to gradually shift traffic; the trace_id stays consistent across providers so your dashboards do not need a per-provider rewrite.
    • Failover policies let you keep the old provider as a fallback during the cutover, so a Resend outage in week one does not lose mail.
    • The environment field per destination lets you cut over staging before production with the same config shape.

    Read Destinations and Routing.

    Webhoster SMTP for small-business sites

    You are a freelance dev building a contact form for a 5-person consultancy. The client already has a mailbox on their webhoster (cyon, Hostpoint, Hoststar, Infomaniak, IONOS, Strato, OVH, Gandi, all-inkl, Mittwald). They do not want a SendGrid account; they want to use the credentials they already pay for.

    How mailnix fits:

    • The destination picker has presets for every Swiss and European webhoster listed above plus generic SMTP. You enter the mailbox email and password; mailnix probes the connection and confirms it works.
    • One MCP call (email_provider_connect) wires the same thing for agents. Useful when you want Claude or Cursor to "connect my cyon mailbox" without you opening the dashboard.
    • Swiss data residency is preserved; the mail is forwarded out through the webhoster's own SMTP server.

    Read Destinations for the preset catalog and the SPF/DKIM verification helper.

    Deliverability monitoring and inbox testing

    You run a marketing-ops team at a B2B startup. You send 50k newsletters a month and want continuous deliverability scoring so that an SPF or DKIM regression on your sending domain does not silently tank open rates for two weeks before someone notices.

    How mailnix fits:

    • Mint a per-test inspect address at /inspect. Send your marketing email to it.
    • mailnix runs a 17-check rubric (SPF, DKIM, DMARC alignment, blacklist membership, link-trust scoring, content heuristics) and returns a 0 to 10 score.
    • Free within your sandbox quota; tools like mail-tester and GlockApps cover the same checks but charge per test.

    Read Inspect for the full check list and the rubric.

    Multi-tenant SaaS sending on customers' behalf

    You are building a Calendly-style scheduling app, an email-marketing platform, or any SaaS where each of your customers wants confirmations to leave from their own domain via their own provider credentials.

    How mailnix fits:

    • A sub-project is a per-tenant child under a master project. Each sub-project has its own destinations, traces, and quotas. Your master project authorizes the call; the sub-project scopes it.
    • The send cap per sub-project can be overridden independently of the org tier default, so a VIP tenant can have a higher daily budget than the rest.
    • Sub-projects inherit the master's organization and plan, so a bounce caught in one sub-project's traffic protects every sub-project under the same master via the org-wide suppression list. See Suppressions.

    Read Sub-projects for the SaaS-on-mailnix integration recipe.

    Keep your existing SMTP app, gain tracing and suppression

    You have a WordPress site, a Django app, a printer that emails its own status, or a Nodemailer service. The app already sends over SMTP. You do not want to rewrite it to an HTTP API, but you do want mailnix's pre-send checks (suppression, domain verification) and full tracing on every message.

    How mailnix fits:

    • Point your SMTP client at the mailnix SMTP relay (smtp.mailnix.ch) using credentials you mint from /settings/smtp-credentials.
    • mailnix authenticates the SMTP submission, runs the same pre-send filtering as the API (including dropping suppressed recipients), records a full trace, and forwards the message verbatim to the destination you bound the credential to.
    • Your own provider still does final delivery, so DKIM signing and sender reputation stay on infrastructure you control.

    Read SMTP relay for ports, auth, and the WordPress and Django config snippets.

    Where to go next

    Pick the article that matches your use case above, or read Traces for the underlying data model every other feature builds on.