mailnix / Destinations

    Core concepts

    Destinations

    A destination is the outbound side of the pipeline the actual provider mailnix dispatches messages to. You can connect as many as you want; routing rules and failover policies decide which one gets each message.

    Supported providers

    ProviderUse caseVerification
    SMTP (custom)Your webhoster's mailserver (Hostpoint, IONOS, OVH, etc.) or self-hosted Postfix.The destination's from domain must be one you can send for via the SMTP host. We don't check this; the host will.
    SESAWS Simple Email Service.Verify your sending domain in the AWS SES console.
    ResendResend.com API.Verify your domain via the Resend dashboard.
    PostmarkPostmark API.Verify your sender signature in Postmark.
    MailgunMailgun API.Verify your domain on Mailgun.

    Webhoster presets

    For SMTP, instead of typing the host + port + TLS settings, pick a preset from the catalog. We know the right smtp_host, port, and encryption for these:

    cyon, hostpoint, hoststar, infomaniak, ionos, strato, mittwald, all-inkl, ovh, gandi

    The preset fills the host/port/TLS fields; you only enter your mailbox username + password. For an unknown webhoster, pick "custom SMTP" and enter the host yourself.

    Domain verification

    For real-recipient sends (not sandbox), the recipient's mailserver will reject your message if your sending domain doesn't pass at least SPF and ideally also DKIM + DMARC. Three records:

    • SPF: a TXT record on your sending domain that says "this list of IPs is authorized to send for me." Example: v=spf1 include:_spf.mailnix.ch ~all. The exact content depends on the destination provider; we generate it for you.
    • DKIM: a TXT record on a *._domainkey.<domain> selector that publishes the public half of a signing key. The provider signs outbound messages; receivers verify the signature against the DNS record.
    • DMARC: a TXT record on _dmarc.<domain> that tells receivers what to do when SPF and DKIM both fail. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (monitor mode); tighten to p=quarantine then p=reject once you've confirmed clean traffic for a few weeks.

    To check the current state of your records, the dashboard surfaces a domain-verification page per destination. The MCP server exposes the same checks via email_domain_verify_status(domain).

    Test sends

    Once a destination is active, hit the Send test button on its detail page. We send a one-line message to an inspect inbox and show you the captured copy + the SPF/DKIM/DMARC results parsed from the received headers. This is the fastest way to confirm the destination actually works end-to-end.

    Capabilities

    Each destination advertises a set of capabilities the routing engine checks:

    • transactional: standard 1:1 sends
    • webhooks_delivery: the provider reports delivery via webhooks (so we can populate provider_event_delivery etc. on the trace)
    • webhooks_bounce: bounce / complaint webhooks
    • webhooks_open / webhooks_click: tracking-pixel + link-tracking webhooks
    • templates: server-side template variables (Postmark / Mailgun style)
    • attachments: arbitrary-MIME-type attachments

    Custom SMTP destinations get transactional only no webhooks (SMTP has no out-of-band mechanism for them) and no template support. Use a cloud provider when you need either.

    What's next

    • Routing pick a destination per message.
    • Failover swap when a destination misbehaves.