CamelMailer
DocsAPISDKsTemplatesHow-to

Go live: production checklist

A running install can send on day one, yet mailbox providers decide whether that mail reaches an inbox. This is the order to work through before real traffic: authenticate the domain, publish DMARC and watch it, get the network layer right, then warm the IP up. Each step links to the reference that explains the mechanism, so this page stays a sequence rather than a repeat.

The steps build on each other, so run them top to bottom. Verification unlocks sending and turns on DKIM, DMARC needs SPF and DKIM passing before it means anything, and a warm-up only pays off once the authentication underneath it is solid.

1. Verify the sending domain and publish SPF + DKIM

Add your sending domain and publish the three TXT records CamelMailer hands back: the ownership challenge, SPF, and DKIM. Verification is what unlocks sending, and a verified domain is the only thing that attaches a domain id to a message, which is in turn what makes the worker sign it with DKIM. The full record table, the per-domain key model, and the verify call live in Sending domains.

  • Publish exactly one v=spf1 record and end it in ~all or -all. If the domain already sends through another provider, merge the mechanisms into that single record.
  • Publish the DKIM record at the selector CamelMailer shows, then run the verify call and watch the domain come back verified: true.
  • Use Re-check DNS on the domain detail view until SPF and DKIM both read green. The health check compares your published p= against the exact key this server would sign with, so a green DKIM card means signing is wired end to end.
A confirmed single sender address can send without a verified domain, and that mail goes out unsigned because it has no domain to attach. For production traffic, verify the domain so DKIM signs. See Sending email for the From-address rules.

2. Publish DMARC at p=none and turn on monitoring

With SPF and DKIM passing, publish a DMARC record and start at p=none. At p=none a receiver still delivers everything, so you gather data on who sends as your domain without risking your own mail:

zone
_dmarc.acme.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

Point the rua= tag at an address CamelMailer receives, and the DMARC tab ingests the aggregate reports and reads them back as a compliance dashboard grouped by sending source. The one-click Set up inbound route button wires dmarc@<domain> to the internal report ingester for you. Tighten to p=quarantine, then p=reject, only once 30 days of data show a high pass rate. The whole policy journey and the report-source categories are in DMARC monitoring.

3. Set reverse DNS and clear the outbound path

Receivers check that the sending IP resolves back to a hostname, and that the hostname matches what your server announces at EHLO. Set a PTR record for each sending IP that matches your SMTP hostname, at your network or hosting provider. CamelMailer does not verify the PTR for you, so this one is on you to confirm.

  • Reverse DNS (PTR). Map the sending IP to the SMTP hostname, and set the installation EHLO identity to a name that matches. On a self-hosted box this is part of setup; see Self-hosting.
  • Outbound port 25. Direct-to-MX delivery needs outbound 25 open. Many clouds block it, so request an unblock (AWS, Hetzner and OVH each have a form) or send through configured smtp_relays. On a managed relay this is handled for you.

4. Terminate TLS for the API and SMTP

Put the dashboard and API behind TLS, and let SMTP submission upgrade before it authenticates:

  • Terminate TLS for the API and dashboard at a reverse proxy (Caddy, nginx, or Traefik) in front of port 5000.
  • Enable SMTP STARTTLS with your certificate through smtp_server.tls_enabled, so submission credentials stay off the wire in cleartext. The submission and TLS behaviour is covered in Self-hosting and Sending email.

5. Warm up a fresh sending IP

A brand-new IP carries no reputation, and providers throttle an unknown address that suddenly pushes volume. Start low and raise the volume over days to weeks. You run this schedule yourself by controlling how much you send through the new pool, because the product does not throttle for you.

  • Begin with your most engaged recipients at a low daily volume, then ramp gradually while you watch the DMARC pass rate and the bounce and complaint figures.
  • Keep the volume steady rather than bursty while reputation builds.
  • Give a broadcast stream its own IP pool so a marketing complaint spike stays clear of the addresses that deliver your password resets. Assigning a distinct pool to broadcast is the single most effective isolation step available. The pool model and the source-address resolution order are in Deliverability & IP pools.

You are ready when

Send one real message to a mailbox you own and read the headers before you open the traffic up. Each row below is a gate, with why it matters:

CheckWhy it matters
Domain reads verified: trueSending is unlocked and each message attaches a domain id.
SPF is one v=spf1 record ending in ~all or -allReceivers can authorize this installation to send for you.
DKIM card is green on the domain detail viewThe published key matches the one the worker signs with, so signatures verify.
DMARC is published at p=none with a working rua=Reports flow in and the compliance dashboard starts filling.
Reverse DNS matches the SMTP hostnameThe sending IP resolves back the way receivers expect.
Outbound 25 is open, or a relay is configuredMail can actually leave the building.
TLS terminates for the API, STARTTLS for SMTPCredentials and dashboard traffic stay encrypted.
A test message arrives and shows a valid DKIM signatureThe whole chain works before real recipients see it.
Ramp volume from here rather than opening the tap. A fresh IP earns trust by sending steadily, so raise throughput as the pass rate holds and the bounce and complaint numbers stay low. See Deliverability & IP pools for the reputation habits behind the ramp.