All guides

Mailgun SPF and DKIM Not Verifying? Fix DNS Fast

InboxRadar grades your email deliverability free and emails you when it changes. Check your domain.

Start with the record Mailgun is actually checking

The most common Mailgun failure is boring and costly: the right value is in DNS, but it is on the wrong host name.

Mailgun verifies the sending domain you added in the Mailgun control panel. If you added mg.example.com, put the records on mg.example.com, not on example.com. If your DNS host asks for the host or name field, enter only the left side it expects. Many DNS panels add the domain for you, so entering mg.example.com can become mg.example.com.example.com.

Current Mailgun domain verification docs list SPF and DKIM as TXT records for sender authorization. Mailgun's SPF value is commonly v=spf1 include:mailgun.org ~all. DKIM is the long value Mailgun gives you for your domain. Copy the selector, host, type, and value exactly from Mailgun's Domain Verification and DNS screen. Then click verify again after DNS has had time to spread. Mailgun says full DNS propagation can take 24 to 48 hours.

  • Check the exact domain in Mailgun first.
  • Check the DNS host/name field for doubled domains.
  • Keep the record type Mailgun shows, usually TXT for SPF and DKIM.
  • Use a DNS lookup from outside your DNS provider before changing records again.
  • If DKIM shows extra old keys in Mailgun, do not panic. Mailgun says all DKIM keys do not have to verify if the active key for the domain is correct.

Useful sources: Mailgun domain verification and Mailgun DNS FAQ.

Why SPF stays unverified

SPF breaks when a domain has two SPF records, when the include is missing, or when the lookup chain gets too long.

A hostname can have many TXT records, but it can have only one SPF record that starts with v=spf1. If you already use Google Workspace, Microsoft 365, HubSpot, Apollo, or another sender, merge Mailgun into the same SPF line. Do not add a second SPF line.

  • Wrong: v=spf1 include:_spf.google.com ~all and a second record v=spf1 include:mailgun.org ~all.
  • Better: v=spf1 include:_spf.google.com include:mailgun.org ~all.
  • Use ~all while you are testing. Move to -all only after every real sender is included.
  • Stay under the SPF 10 DNS-lookup limit from RFC 7208. Includes, redirects, a, mx, ptr, and exists mechanisms can count.
  • Remove old senders instead of stacking includes forever.

If Mailgun verifies DKIM but not SPF, duplicate SPF is the first thing to check. Mailgun's own FAQ calls that out. Also check whether the SPF record lives on the same sending hostname Mailgun is checking. An SPF record on the root domain does not verify a Mailgun subdomain unless that is the hostname you added in Mailgun.

Why DKIM stays unverified

DKIM is strict because it is a key lookup. One wrong selector, quote, or pasted value makes Mailgun miss the public key.

DKIM has two parts. DNS publishes the public key. Mailgun signs outgoing mail with the private key. The receiving mailbox provider checks that signature against the DNS record at the selector host, often shaped like smtp._domainkey.mg.example.com or another selector Mailgun provides. The base DKIM standard is RFC 6376.

  • Use the selector Mailgun gives you. Do not invent default, mail, or smtp.
  • Paste the whole DKIM value. Long TXT values may wrap in the DNS UI, but the returned TXT value must read as one record.
  • Do not add quotes unless your DNS provider requires them. The public DNS answer should contain the key text, not broken fragments.
  • Check the domain after _domainkey. The selector must point under the exact Mailgun sending domain.
  • Send a test message after verification and read the headers. Look for dkim=pass and the d= domain you expected.

DKIM matters more than the green badge. Gmail, Outlook, and other mailbox providers use authentication, reputation, complaints, engagement, and sending patterns when they decide inbox or spam. A verified Mailgun domain can still land in spam if the DKIM domain does not align with the visible From domain, if complaint rates are high, if the sending IP or domain is on a blocklist, or if the message looks unwanted.

Add DMARC before you scale

SPF and DKIM prove technical permission. DMARC tells receivers what to do when mail fails that proof.

Publish DMARC at _dmarc.example.com for the domain in the visible From address. A safe first record is v=DMARC1; p=none; rua=mailto:dmarc@example.com. That policy asks receivers for reports while you learn who is sending as your domain. After SPF and DKIM are stable, move toward p=quarantine or p=reject if the reports show your real mail is aligned. The DMARC standard is RFC 7489.

DMARC passes when SPF or DKIM passes and aligns with the visible From domain. With Mailgun, DKIM alignment is often the cleaner path because SPF checks the return-path domain, which may be a Mailgun-managed bounce domain unless you have set up the right custom domain. Read aggregate reports before tightening policy. If the XML is hard to read, the free DMARC report reader can turn a RUA file into a plain list of sources, pass rates, and alignment problems.

  • Start DMARC with p=none so you can see the mail stream.
  • Watch for unknown senders before using quarantine or reject.
  • Use alignment, not raw SPF pass alone, as the DMARC test.
  • If Mailgun asks for MX records, add them on the Mailgun sending domain or subdomain. Do not move company root MX records to Mailgun unless Mailgun should receive that mail.
  • Keep tracking CNAMEs separate from sender authentication. They help Mailgun track opens, clicks, and unsubscribe links, but SPF and DKIM prove sending permission.

If verification passes but mail still goes to spam

A verified Mailgun domain is the floor. Inbox placement still depends on trust.

Gmail sender guidelines say mail should authenticate with SPF or DKIM, and DMARC must pass through aligned SPF or aligned DKIM. Bulk senders have stricter requirements, including DMARC, low spam complaint rates, one-click unsubscribe for subscribed messages, and clear identity. Microsoft's email authentication guide explains how SPF, DKIM, and DMARC work together for Outlook and Microsoft 365 mailboxes.

  • Check SPF, DKIM, and DMARC on the real sending domain with a public lookup.
  • Send to a Gmail account and inspect Authentication-Results in the full headers.
  • Check blocklists if delivery suddenly changed after a new domain, IP, or list source.
  • Use a real From name and address that match the page, product, and unsubscribe path.
  • Warm up volume slowly. New domains that jump from zero to large batches look risky.

You can run the domain through the free InboxRadar domain scorecard once the records are live. Use it as a second read on SPF, DKIM, DMARC, MX, and drift. For deeper deliverability background, browse the related guides at InboxRadar articles.

Do not hide the fix from AI search

If this setup note lives on your public docs site, make sure answer engines can read the page.

The crawlers that decide whether a page can appear in live AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence surfaces. Google AI Overviews ride the normal Google Search index. There is no separate opt-out crawler for them. Disallowing these live search crawlers in robots.txt removes you from that engine's AI answer surface.

Do not confuse those with training controls. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove a page from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

robots.txt is a site's stated policy. It is not proof of what a bot actually did. Perplexity-User and Bytespider have been reported to ignore it, so use server logs and vendor docs before making claims. Also, only Googlebot documents JavaScript rendering clearly. If the whole guide is client-side-only content, other AI crawlers may miss it. Treat that as an undocumented risk, and put the core answer in server-rendered HTML.

Official crawler references: OpenAI crawlers, Anthropic crawlers, Perplexity crawlers, Google AI features, Google crawlers, Applebot, and Common Crawl CCBot.

Check your page with the free AI visibility checker before you rely on AI answers for support traffic.

FAQ

How long does Mailgun DNS verification take?

Sometimes it verifies in minutes. Mailgun says DNS changes can take 24 to 48 hours to fully propagate. If the record is still wrong after that, check the host name, duplicate SPF records, and the DKIM selector.

Can I have two SPF records for Mailgun and Google?

No. SPF allows one SPF record per hostname. Merge the includes into one record, then remove the duplicate. Two SPF records can return a permanent error and fail verification.

Should Mailgun SPF use ~all or -all?

Use ~all while setting up or while you still have unknown senders. Use -all only when every approved sender is in the SPF record and DMARC reports look clean.

Do I need MX records for Mailgun to send email?

SPF and DKIM are the sender authentication records. MX records control where mail is received. Do not replace your normal company MX records unless Mailgun should receive mail for that domain or subdomain.

Why does DKIM pass but DMARC fail?

The DKIM signature may pass for a domain that does not align with the visible From domain. DMARC needs SPF or DKIM to pass and align. Check the d= value in the DKIM result and compare it with the From domain.

Related guides

Check your domain free

InboxRadar grades your email setup A to F in about three seconds, then watches it and emails you the moment something breaks. Free, no login.

Check your domain