Setup Guides · Mailgun

Mailgun Authentication Setup: SPF, DKIM & DMARC

Mailgun's setup hinges on one decision: send from a subdomain like mg.yourdomain.com, not your root. Do that and its DNS records - SPF, the DKIM CNAMEs, a tracking CNAME and (only if you receive mail) two MX records - sit on the subdomain and never disturb your root domain's existing mail, while still aligning for DMARC. This guide is the exact records, the SPF include people most often get wrong (it's .org, not .net), the region-specific values in the EU, the DKIM you never have to rotate, and the failures we keep finding in audits.

Last updated 11 September 2026 · applies to Mailgun (US and EU regions)

Why a sending subdomain

Mailgun recommends a dedicated sending subdomain - mg.yourdomain.com is the convention - rather than your root domain. It keeps Mailgun's SPF, DKIM and optional MX off the root, so your existing Google or Microsoft MX and your root-domain SPF are untouched, and it lets the subdomain build its own sending reputation. Because the subdomain still shares your organizational domain, SPF and DKIM align for a DMARC policy published at _dmarc.yourdomain.com - you lose nothing by isolating the sending domain.

What you need

  • A Mailgun account and a domain added in the correct region. The US uses api.mailgun.net; the EU uses api.eu.mailgun.net. The region also changes two of the DNS records below - EU inbound MX are mxa.eu.mailgun.org/mxb.eu.mailgun.org and the EU tracking CNAME points at eu.mailgun.org - and a domain can't be moved between regions by editing DNS. Copy every value from your own panel.
  • Access to your domain's public DNS - and, on Cloudflare, the ability to set records to DNS only (grey cloud).

The setup, step by step

1 Add the sending subdomain in Mailgun

In the Mailgun control panel add a domain and enter your subdomain, e.g. mg.yourdomain.com. Mailgun generates the record set (SPF, DKIM, tracking, and MX) for that subdomain and shows them under Domain settings → DNS records - with the values already set for your region.

2 Publish the SPF record

A TXT record on the sending subdomain:

Type  Host              Value
TXT   mg.yourdomain.com   "v=spf1 include:mailgun.org ~all"

The include is mailgun.org - not mailgun.net - and it's the same in the US and EU regions. If the subdomain already has an SPF record, merge the include into it (v=spf1 include:mailgun.org include:other.com ~all) rather than publishing a second SPF record - only one SPF TXT is valid per host. Keep the whole record within SPF's 10-DNS-lookup limit: a record that resolves more than ten lookups fails with a permerror. The include:mailgun.org directive counts toward that limit, along with any further lookups its own record chains to.

3 Publish the DKIM records

New Mailgun domains default to Automatic Sender Security (ASS), which delivers DKIM as two CNAME records pointing at Mailgun-hosted keys - so Mailgun generates 2048-bit keys and rotates them for you (every 120 days by default), and you never touch a raw key:

Type   Host                              Value
CNAME  pdk1._domainkey.mg.yourdomain.com   [exact target from Mailgun]
CNAME  pdk2._domainkey.mg.yourdomain.com   [exact target from Mailgun]

The two selectors let Mailgun rotate keys with no signing gap. The targets carry a per-domain ID, so copy the exact values Mailgun shows. The rotation interval is configurable through Mailgun's DKIM Security API (down to a 5-day minimum), and you can force a rotation manually at any time.

Legacy manual DKIM (a single TXT key)

If your domain uses Mailgun's older manual DKIM instead, it's one TXT record at a selector like mx._domainkey.mg.yourdomain.com with a k=rsa; p=… value, and you choose 1024 or 2048-bit. With a 2048-bit key some DNS providers need the long TXT split into two quoted strings - if you paste it as one string it gets truncated and DKIM fails. Enabling the ASS CNAMEs deactivates a manual TXT key once verified, so use one method, not both.

4 Publish the tracking CNAME

For open/click tracking and branded links, add the tracking CNAME Mailgun shows (typically email.mg.yourdomain.com). The target is region-specific:

Type   Host                    Value (US)      Value (EU)
CNAME  email.mg.yourdomain.com   mailgun.org     eu.mailgun.org

This is what lets Mailgun rewrite links to track clicks and issue a TLS certificate for HTTPS tracking links. It isn't required for basic sending, but tracking won't work without it - and on Cloudflare it must be DNS only (grey cloud), or the TLS challenge and link resolution break. Use the exact target your panel shows for your region.

5 Add MX records only if you receive mail

If you want Mailgun to receive inbound mail or run Inbound Routes on the subdomain, add both MX records; for send-only use, skip them. The hosts are region-specific:

Type  Host              Value (US)             Value (EU)
MX    mg.yourdomain.com   10 mxa.mailgun.org      10 mxa.eu.mailgun.org
MX    mg.yourdomain.com   10 mxb.mailgun.org      10 mxb.eu.mailgun.org

Do not add these to a domain another provider already receives mail for - they'd divert its incoming mail. This is exactly why the dedicated subdomain matters: mg.yourdomain.com can carry Mailgun MX while your root domain keeps its real mailboxes on Google or Microsoft.

6 Verify, then publish your own DMARC

Click Verify DNS settings in the panel (or call the verify API). You can verify right away - if the records aren't visible yet, allow up to 24-48 hours for propagation, though in practice it usually happens faster; Mailgun also auto-checks on its own. Verifying lifts the sandbox-style daily cap and the "sent via mailgun.org" wording. Then publish DMARC. Mailgun pre-generates the value (default p=none), but you add it as a TXT record at your organizational domain:

Type  Host                    Value
TXT   _dmarc.yourdomain.com   v=DMARC1; p=none; rua=mailto:[email protected]

Add DMARC only once SPF and DKIM pass, collect the aggregate reports, then move through p=quarantine to p=reject. If your domain already has a DMARC record, keep it - don't overwrite an enforced policy with p=none; just confirm Mailgun's mail passes aligned under your existing policy. Our DMARC enforcement guide walks that path, and the Postbox DMARC Monitor reads the reports for you.

How SPF, DKIM and DMARC line up here

  • DKIM - Mailgun signs with d=mg.yourdomain.com, which shares your organizational domain with the visible From, so DKIM aligns under relaxed alignment (DMARC's default).
  • SPF - the Return-Path is on mg.yourdomain.com and SPF passes via include:mailgun.org; the subdomain shares your org domain, so SPF aligns too.
  • DMARC - passes when either SPF or DKIM aligns; the subdomain approach gives you both. See our SPF, DKIM and DMARC guide for how the three fit together. Publish DMARC at the organizational domain (_dmarc.yourdomain.com) when your visible From is on that domain - the common Mailgun pattern - and keep alignment relaxed.

Dedicated vs shared IP, and reverse DNS

Mailgun sends from a shared IP by default - the right fit, in its guidance, for lower-volume or spiky senders, with nothing to configure. A dedicated IP makes sense once you're sending steadily at scale: Mailgun's help center puts the practical floor at about 100,000 emails a month (below that, or with volatile spikes, a dedicated IP may not help), and sizes higher volumes at roughly one dedicated IP per million emails a month. Mailgun warms new IPs automatically by ramping the sending rate over time. On a dedicated IP Mailgun can set custom reverse DNS (PTR) via a support request so mail appears to come from your own hostname - configure forward-confirmed reverse DNS (the PTR resolves to a hostname whose A/AAAA resolves back to the same IP) or Gmail can reject with 550 5.7.25 (see our SMTP error codes reference). Reverse DNS can't be customised on a shared IP, since it resolves to a single hostname. Start on shared and move up only when volume justifies the warmup.

The failures we keep finding

Using mailgun.net in the SPF include

The SPF include is include:mailgun.org. Copy-pasting mailgun.net (the API host) instead means SPF never authorizes Mailgun's servers - it fails or falls to neutral. Use .org.

Publishing US values on an EU domain (or vice versa)

The DNS records aren't identical across regions: an EU domain's tracking CNAME points at eu.mailgun.org and its inbound MX are mxa.eu.mailgun.org/mxb.eu.mailgun.org. Copy every value from your own panel rather than from a guide, or an EU setup can break click and open tracking (wrong tracking CNAME) or inbound routing (wrong MX).

Putting the records on the root instead of the subdomain

Every Mailgun record belongs on the exact host it shows - the mg. subdomain. Publishing SPF/DKIM on the root (or the subdomain records at the apex) leaves the domain unverified and can collide with your root's existing SPF.

Adding Mailgun MX to a domain that already receives mail

If the subdomain (or worse, the root) already has MX for another provider, Mailgun's MX diverts inbound mail. Only add MX if you intend Mailgun to receive, and keep it on the dedicated subdomain.

A 2048-bit DKIM TXT that wasn't split

On legacy manual DKIM, a 2048-bit public key exceeds the 255-character TXT string limit. If your DNS provider needs it split into multiple quoted strings and you paste it as one, the record is truncated and DKIM fails. Split it, or use the ASS CNAMEs and avoid the problem.

Proxying the CNAMEs on Cloudflare

The DKIM and tracking CNAMEs must be DNS only (grey cloud). Orange-clouded, they resolve to Cloudflare instead of Mailgun, so DKIM won't verify and tracking-link TLS breaks.

Verify it end to end

A green "Verified" in Mailgun means the records exist - it doesn't prove a real send authenticates. Confirm on an actual message:

  • Send a test through Mailgun to Postbox Mailtester and confirm SPF aligned, DKIM pass with d=mg.yourdomain.com, and DMARC pass (aligned).
  • Or read the received message's Authentication-Results header: dkim=pass header.d=mg.yourdomain.com, spf=pass, and dmarc=pass. If DMARC fails while SPF and DKIM pass, the cause is usually alignment or the policy, not a missing record: check that the authenticated SPF domain and DKIM d= share your From domain, and that _dmarc is published for the domain in your From address (usually your organizational domain, which subdomains inherit).

Frequently asked questions

What DNS records does Mailgun need to verify a domain?

On your sending subdomain: an SPF TXT (v=spf1 include:mailgun.org ~all), the DKIM records (two CNAMEs pdk1._domainkey/pdk2._domainkey under Automatic Sender Security, or a legacy DKIM TXT), a tracking CNAME (US target mailgun.org, EU eu.mailgun.org), and two MX (mxa/mxb.mailgun.org, or the .eu.mailgun.org hosts in the EU region, priority 10) that are only needed for inbound. You publish DMARC at _dmarc.yourdomain.com yourself. Copy the per-domain DKIM targets from your panel.

Should I use my root domain or a subdomain with Mailgun?

A subdomain (mg.yourdomain.com). Mailgun recommends it so its SPF/DKIM/MX never disturb your root's existing mail, while the subdomain builds its own reputation. It still shares your organizational domain, so SPF and DKIM align for a DMARC record at _dmarc.yourdomain.com.

What is the Mailgun SPF record?

A TXT on the sending subdomain: v=spf1 include:mailgun.org ~all - the include is mailgun.org, not mailgun.net, in both the US and EU regions. Merge it into an existing SPF record rather than adding a second one; a host may have only one SPF TXT.

Do I need the Mailgun MX records?

Only if Mailgun should receive inbound mail or run Inbound Routes. For send-only use they're optional. Don't add mxa/mxb.mailgun.org (or the EU .eu.mailgun.org hosts) to a domain another provider already receives mail for - it diverts that mail. A dedicated subdomain avoids the conflict.

Does Mailgun set up DMARC for me?

Mailgun pre-generates a p=none value on its DNS page, but you publish it yourself at _dmarc.yourdomain.com - Mailgun doesn't host it. Add it after SPF and DKIM verify, start at p=none, then tighten. Both SPF and DKIM align on a Mailgun subdomain.

Do I need a dedicated IP with Mailgun?

Most senders don't. Shared IPs suit lower-volume or spiky sending; a dedicated IP makes sense once you're steady at scale (Mailgun puts the floor around 100,000/month, and sizes higher volumes at roughly one IP per million/month), warms automatically, and can take custom reverse DNS via support. Reverse DNS can't be customised on a shared IP. Start on shared.

Sources (Mailgun documentation): Domain Verification · DKIM Security (Automatic Sender Security) · Regional endpoints (US/EU) · IP Addresses and Sending Volume · Implement DMARC.

Not sure your Mailgun mail is actually aligned?

Chat with us!