Mailgun SPF, DKIM and DMARC setup: pass alignment on your own domain

Good news first: Mailgun is one of the easier providers to get DMARC-aligned, because its standard domain verification puts SPF and DKIM on your own domain rather than Mailgun's. The part worth two minutes of thought is which sending domain you verify — get that right and everything else is copying DNS records.

Step 1: use a subdomain as your sending domain

When you add a domain in Mailgun (Sending > Domains > Add new domain), it suggests a subdomain like mg.example.com rather than example.com itself. Take that suggestion. Three reasons:

  • It keeps your root SPF record clean. Mailgun's include:mailgun.org goes on the subdomain's record, not your root's — which protects your 10-DNS-lookup budget for the providers that genuinely need to be there.
  • It separates reputation. Your transactional or bulk stream through Mailgun builds its own sending history without dragging your day-to-day mailbox provider's reputation with it.
  • Alignment still works. DMARC's default relaxed alignment treats mg.example.com and example.com as the same organizational domain — so mail with a From address on your root domain still passes. More on this below.

Step 2: publish the DNS records Mailgun shows you

After adding the domain, Mailgun lists the exact records to create. The two that decide DMARC are:

mg.example.com                  TXT  "v=spf1 include:mailgun.org ~all"
smtp._domainkey.mg.example.com  TXT  "k=rsa; p=MIIBIjANBgkq..."
  • The first is SPF for the sending subdomain. The ~all ending is fine — softfail vs hardfail matters much less than people think once DMARC is in place.
  • The second is your DKIM public key. The hostname's first label is the selector — often smtp, or one you chose when adding the domain. Copy the hostname and value exactly as your dashboard shows them; they vary by account and region (EU-region domains get EU-specific values).

Mailgun also offers a tracking CNAME (email.mg.example.com) and MX records for receiving replies on the subdomain. Both are optional and neither affects DMARC — add them if you use click tracking or inbound routing, skip them if not.

Once DNS propagates, hit Verify DNS settings and the domain state goes to Active.

Step 3: understand why this aligns (when other ESPs don't)

Send an email through Mailgun from you@example.com and here's what a receiver sees:

CheckDomain checkedResultAligned with example.com?
SPFmg.example.com (the Return-Path)passYes — relaxed alignment, same organizational domain
DKIMd=mg.example.com (the signature)passYes — same reason

Both identifiers pass and align, which is exactly what DMARC wants — and it's the default outcome of Mailgun's setup, not a buried extra feature. Compare that with platforms whose defaults leave everything on the platform's own domain until you enable domain authentication — the situation covered in SendGrid & Mailchimp alignment.

One caveat: this relies on relaxed alignment, which is DMARC's default. If your DMARC record sets strict alignment (aspf=s or adkim=s), a subdomain sending domain stops aligning with a root-domain From address. Almost nobody needs strict alignment — if your record has those tags and you're not sure why, remove them.

Step 4: publish DMARC on your root domain

The DMARC record goes on your organizational domain, not the Mailgun subdomain:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

Mail with a From address on example.com is governed by this record directly, and mg.example.com inherits it unless you publish a subdomain record — you don't need one. Start at p=none, watch the reports, and tighten when everything legitimate passes — the rollout order is in p=none vs quarantine vs reject.

Step 5: verify with a real message

Send a test through Mailgun to a Gmail address you control and open Show original. You want:

  • spf=pass for mg.example.com
  • dkim=pass with header.d=mg.example.com
  • dmarc=pass

Then let your aggregate reports confirm it at scale over the following days. If nothing arrives within 48 hours, see not receiving DMARC reports.

Traps to avoid

  • Adding include:mailgun.org to your root domain's SPF. If Mailgun sends from mg.example.com, the include belongs on that record. On the root it authorizes nothing that's ever checked, and burns DNS lookups.
  • Verifying the root domain to "keep it simple". It works — SPF and DKIM then live on example.com and align exactly — but you give up the reputation separation and the clean root SPF record for no real gain.
  • Assuming the tracking CNAME is part of authentication. It only handles click/open tracking links. Skipping it never causes a DMARC failure.

On a different provider? The same walkthrough exists for Google Workspace, Microsoft 365, Zoho Mail, and Amazon SES. Managing DNS in Cloudflare or GoDaddy? The exact clicks are in adding the record in Cloudflare and in GoDaddy.

Step 4 asks where to send reports — send them somewhere useful. Point rua at PlainDMARC and get a plain-English weekly verdict instead of zipped XML: whether Mailgun's mail passes aligned, what else is sending as your domain, and when you're ready to tighten the policy. There's an API too, if you'd rather script it.

Get a plain-English weekly DMARC verdict — create a free account