Skip to content
Mumara

Deliverability · DKIM · CNAME · MX

Three subdomains. One authenticated identity.

Mumara generates the DKIM keys (your choice of 512, 1024, 2048, or 4096 bits), tells you exactly which SPF and MX records to publish, and verifies every record on demand — and again every 24 hours. List-Unsubscribe ships automatically on every send, with RFC 8058 one-click support so Gmail and Yahoo's bulk-sender rules stop being a problem.

Get started Skip DNS entirely · Auto DNS →
  • DKIM at 512, 1024, 2048, or 4096 bits
  • Custom tracking subdomain via CNAME
  • Custom bounce subdomain via SPF + MX
  • List-Unsubscribe on every send (RFC 2369 + 8058)
DKIM Verified 
key._domainkey.acme.com  TXT
v=DKIM1; k=rsa; p=MIIBIjANBg...
TRACKING Verified 
click.acme.com  CNAME
track.mumara.com
BOUNCE Verified 
bounce.acme.com  SPF + MX
v=spf1 include:bounces.mumara.com -all
MX → bounces.mumara.com

Owned, not borrowed

Your domain. Your keys. Your verification.

Authentication is where most senders get stuck. Mumara generates what it can, surfaces what you have to publish, and verifies it on a cadence so configuration drift never becomes a deliverability incident.

DKIM key generation
RSA
DKIM key generation
Pick the bit size at create-time — 512, 1024, 2048, 4096 — to match your compliance policy and your DNS provider's limits. Customisable selector.
custom tracking subdomain
CNAME
custom tracking subdomain
click.yourbrand.com instead of an opaque mumara.com tracker — recipients see your domain in every link.
custom bounce subdomain
SPF + MX
custom bounce subdomain
bounce.yourbrand.com handles return-path traffic in your namespace; bounces resolve cleanly against DMARC.
scheduled re-verification
24h
scheduled re-verification
On top of on-demand verification — a daily DNS poll catches accidental record changes before they become silent failures.

Add a sending domain

One form. DKIM, tracking subdomain, bounce subdomain — set up at once.

Adding a sending domain is a single form. Type the domain. Pick the DKIM key size (2048-bit is the recommended default). Choose the selector. Toggle on the tracking subdomain (CNAME) and the bounce subdomain (SPF + MX) if you want branded click and return-path traffic. Hit Save — Mumara generates the key pair, surfaces the records you publish, and waits for you to verify.

  • DKIM bit-size picker

    Pick from 512, 1024, 2048, or 4096-bit RSA keys. 2048-bit is recommended; larger keys may exceed some DNS providers' TXT record length limits — the picker warns you when relevant.

  • Custom selector field

    Default `key` works for most setups. Change the selector when you're rotating keys or running multiple selectors in parallel (typical during a key-rotation window).

  • Optional tracking + bounce subdomains

    Toggle each ON to brand click-tracking and bounce return-path traffic with your own subdomain. Leave OFF and Mumara's defaults handle it (still works, less branded).

  • Save & generate records

    Save triggers DKIM key generation and surfaces the exact DNS records you need to publish at your DNS provider. Auto DNS addon does the publishing for you across CloudFlare, Route 53, GoDaddy, and others.

Mumara Add Sending Domain form — Sending domain input (acme.com), DKIM section with Selector input (key) and Key size radio pills (2048 selected), Custom subdomains section with tracking and bounce toggles ON, Save & generate records button

Three subdomains, three roles

Sending vs Tracking vs Bounce — they're not the same thing.

A complete sending identity needs each of them. Each maps to different DNS records, fixes a different problem, and stays separately verifiable.

The send identity

Sending domain (DKIM + SPF)

The domain on the From line. DKIM signs each message with a private key Mumara generates and stores; you publish the public key as a TXT record at key._domainkey.yourbrand.com. SPF tells receivers which servers can send from your domain — Mumara surfaces the include directive to paste into your existing SPF record. DMARC alignment depends on both being verified.

  • DKIM key 512–4096 bits
  • Custom selector
  • SPF guidance
  • DMARC-alignable
Explore Sending domain (DKIM + SPF)

Branded click and open links

Tracking subdomain (CNAME)

By default, click and open tracking flows through Mumara's tracker domain. With a custom tracking subdomain (click.yourbrand.com → CNAME → Mumara) every link in every email shows your brand instead. Configure multiple tracking subdomains and Mumara picks one at random per domain creation, which protects reputation across separate sending streams.

  • CNAME-based
  • Per-brand subdomain
  • Random rotation across pool
  • Independent of DKIM
Explore Tracking subdomain (CNAME)

Return-path identity

Bounce subdomain (SPF + MX)

Bounces and complaints need a return-path that aligns with your sending domain to keep DMARC happy. A bounce subdomain (bounce.yourbrand.com) with its own SPF include and an MX record pointing at Mumara's bounce handler keeps the return-path in your namespace — and lets Mumara classify and process every bounce per the rules you configure.

  • SPF + MX records
  • Per-brand return-path
  • DMARC-aligned
  • Feeds bounce processing
Explore Bounce subdomain (SPF + MX)

From added to sending

From a fresh domain to the first authenticated send.

The default flow when you skip the Auto DNS addon. Most domains complete in under an hour — the wait is your DNS provider's propagation, not Mumara's processing.

  1. Step 1

    Add the domain

    Sending Domains → + Add Domain. Type the domain. Pick which features to enable — DKIM, custom tracking subdomain, custom bounce subdomain — and the DKIM key size.

  2. Step 2

    Mumara generates

    The DKIM key pair (your chosen bit size, RSA), the tracking CNAME target, the bounce SPF + MX values. The private key stays in Mumara; the public values surface in the records view.

  3. Step 3

    You publish

    Copy each record into your DNS provider — Cloudflare, Route 53, GoDaddy, Hetzner, whatever you use. Or skip this step entirely with the Auto DNS addon, which pushes records to your DNS provider directly.

  4. Step 4

    Verify

    Click Verify in the UI — Mumara runs the DNS lookup live. Verified records turn green. A scheduled 24-hour re-verification catches record drift between manual checks.

  5. Step 5

    Send

    Once the relevant records are verified, the domain is eligible for use on broadcasts, drips, triggers, and the API. Force-DKIM-aware users have their sends gated until their domains pass verification.

What an unauthenticated domain costs

Three deliverability failures, one root cause.

Most senders only think about DKIM, SPF, and DMARC once a deliverability incident has already happened. By then the damage is in the spam-folder rate, the complaint rate, and the bounce-back ratio.

  • Spam-folder placement

    Major mailbox providers (Google, Microsoft, Apple) increasingly require both DKIM and SPF alignment for inbox placement on bulk mail. An unsigned message, or one signed by a different domain than the From line, lands in spam — often without bouncing — so you don't even see the problem until engagement craters.

  • Bounce-back ratio inflates

    Without a custom bounce subdomain, the platform's default return-path handles your bounces. That return-path may not align with your DMARC policy, causing bounces to be rejected as misaligned — which means you don't process them, which means your hard-bouncing addresses keep getting tried, which means your bounce-back ratio climbs.

  • List-Unsubscribe noise

    Gmail and Yahoo now require RFC 8058 one-click List-Unsubscribe on bulk mail. Without it, your unsubscribe rate gets quietly downgraded to spam complaints — because users hit "Report Spam" when they can't find the unsub link fast enough. Mumara ships the header automatically; senders without it are paying for the wrong metric.

  • Trackers leak your sending platform

    Clicking a link in an unconfigured Mumara email reveals the Mumara tracker domain. For agencies and resellers, that's the brand leak that ends client confidence. Custom tracking subdomains (click.yourbrand.com) hide the implementation from recipients while keeping the data flowing.

Different shapes of sender

One Sending Domains surface. Four ways to use it.

  • Single-brand sender

    Setup
    One business, one domain, one set of newsletters. Add yourbrand.com, enable DKIM + custom tracking + custom bounce, publish the records once.
    Outcome
    Every send signed, every click branded, every bounce processed in-namespace. DMARC reachable in weeks, not months.

  • Multi-brand portfolio

    Setup
    Four product lines, four domains. Add each separately, configure tracking subdomains per brand (click.brandA.com, click.brandB.com), rotate randomly across the pool when broadcasts pick a tracker.
    Outcome
    Per-brand reputation kept distinct. A complaint storm on one brand never poisons the others — separate DKIM keys, separate trackers, separate bounce processing.

  • Reseller / agency

    Setup
    Each client account gets their own domain configured under Team & Users with Force DKIM / Force tracking / Force bounce mandatory toggles. Client-tenant can't send until their authentication is green.
    Outcome
    Client traffic always authenticated. Brand never leaks. Onboarding becomes "publish three records, verify, send" — a process you can automate or hand to the client.

  • ESP migration

    Setup
    Coming from another ESP. Add your existing sending domain in Mumara, generate the new DKIM selector under a fresh name, publish — keep the old selector live during the transition to avoid breaking in-flight sends elsewhere.
    Outcome
    Phased migration with both selectors valid until you switch traffic over. No deliverability dip during the cutover.

Common questions

What buyers usually ask.

Does Mumara generate DKIM keys for me?

Yes — when you enable DKIM on a sending domain, Mumara generates an RSA key pair at the bit size you choose (512, 1024, 2048, or 4096 bits). The private key stays in Mumara and signs every outgoing message; the public key surfaces in the DNS-records view as a TXT record value, ready to paste at key._domainkey.yourdomain.com. You also choose the selector — `key` is the default, but you can use `selector1`, `mumara2026`, or whatever fits your rotation policy.

Does it generate SPF and DMARC records too?

SPF — Mumara surfaces the include directive you need (e.g. `include:bounces.mumara.com`) to add to your existing SPF record. It doesn't overwrite your SPF for you, because most domains already have other senders to allow. DMARC — Mumara doesn't generate the DMARC record (DMARC policy is your call, not the platform's), but the moment your DKIM and SPF verify, DMARC alignment becomes reachable. Most senders start at `p=none` to monitor, then move to `p=quarantine` and eventually `p=reject`.

What's a "custom tracking subdomain" and why do I need one?

By default, click-tracking and open-tracking pixels in your emails point at Mumara's tracker domain. That works, but recipients see the Mumara URL when they hover a link — and for agencies, resellers, and any brand-conscious sender, that's a leak. A custom tracking subdomain (e.g. click.yourbrand.com CNAME → track.mumara.com) routes every link and every pixel through your brand's namespace. Recipients see your domain everywhere; Mumara still does the actual tracking.

Can I have multiple tracking subdomains per sending domain?

Yes — and when you do, Mumara picks one at random during domain creation. The selection is deterministic per domain but distributed across the pool, which spreads tracker traffic and protects you from any single tracker getting flagged or blocklisted. Most senders run two or three; resellers with many client domains often configure one per client.

What does a custom bounce subdomain actually do?

Bounces have a return-path — the email address that gets the bounce back when a send fails. Without a custom bounce subdomain, your bounces flow back to Mumara's default bounce handler, which works fine for processing but may not align with your DMARC policy (because the return-path domain differs from your From-line domain). A custom bounce subdomain (bounce.yourbrand.com with SPF + MX records) keeps the return-path inside your namespace, so DMARC alignment stays clean — and Mumara still classifies and processes every bounce that arrives.

Does Mumara add a List-Unsubscribe header?

Yes — automatically, on every send. RFC 2369 (mailto + URL) and RFC 8058 one-click POST are both supported. This matters because Gmail and Yahoo's bulk-sender rules (effective February 2024) require RFC 8058 on any bulk sender exceeding 5,000 messages per day — without it, your unsubscribe friction climbs and your spam-complaint rate with it. Mumara handles the header construction; you handle the unsubscribe semantics (which list, which scope) in the campaign settings.

How does verification work?

Two paths. On-demand: click Verify in the UI — Mumara runs DNS lookups against the records expected for that domain (DKIM TXT at the selector, tracking CNAME, bounce SPF + MX) and returns a per-record status in seconds. Scheduled: every 24 hours, Mumara re-verifies every domain in the background. The scheduled pass catches accidental record changes (a teammate edits the SPF record and breaks the include) before they become a silent failure.

What if my DNS provider is awkward to manage?

Auto DNS — a paid addon — bypasses the publish-records-yourself step entirely. It connects to your DNS provider via API (CloudFlare, Route 53, GoDaddy, Hetzner, Google Cloud DNS, ClouDNS, Dynu, DNS Made Easy supported today) and pushes the SPF / DKIM / tracking / bounce records directly. You add the domain in Mumara, click authorise, send. See the [Auto DNS addon page](/campaigns/addons/auto-dns/) for the full provider list.

Can I enforce DKIM / tracking / bounce on users (resellers)?

Yes — Team & Users exposes three per-user toggles: Force DKIM Authentication, Force Custom Tracking Domain, Force Custom Bounce Domain. When ON, that user cannot send broadcasts via an unauthenticated sending domain, an uncustomised tracker, or the default bounce return-path. Critical for agencies and resellers who don't want client traffic going out unauthenticated and leaking the platform brand. See [Team & Users](/campaigns/features/user-management/) for the full hierarchy.

How are custom email headers configured?

Two scopes. Global custom headers apply to every send across the installation (e.g. X-Campaign-Source for downstream analytics). Per-sending-node headers attach to a specific SMTP / API gateway (e.g. X-Mailer-Variant for gateway-specific debugging). Both are validated for RFC compliance before saving. Headers are merged in the Mailer before delivery.

Related

Pages that pair with this one.

Mumara Campaigns · Sending Domains

Authenticate once. Send everywhere. Verify forever.

Sending Domains ship with every Mumara Campaigns plan — Self-Hosted and Mumara Machine. DKIM key generation, SPF guidance, custom tracking + bounce subdomains, automatic List-Unsubscribe, scheduled re-verification — all included. Auto DNS removes the manual publish step entirely.

Get started See pricing