How to set up DMARC/DKIM/SPF for Mailgun
Published 5 Aug 2026
Updated 5 Aug 2026
11 min read
Summarize with
Mailgun needs an authenticated sending domain before production mail can pass SPF and DKIM. I use a dedicated subdomain such as mg.example.com, publish the exact records shown by Mailgun, then put DMARC on the domain used in the visible From address. With relaxed matching, a Return-Path at mg.example.com can pass SPF alignment for mail sent as user@example.com.
The sequence matters: verify the Mailgun domain, confirm a real message passes authentication, collect DMARC reports under p=none, and enforce only after every approved sender has been identified. Mailgun's authentication guidance explains the protocol requirements. Mailgun's current workflow applies them through domain verification and DNS records.
Add your domain
I separate application mail from the root domain so its reputation and DNS stay easier to manage. Use a subdomain such as mg.example.com in Mailgun, while the visible From address can remain user@example.com under relaxed DMARC matching.
- Open domains. Sign in to the Mailgun Control Panel, expand Sending, select Domains, then click Add New Domain.
- Enter the domain. Add mg.example.com or another dedicated sending subdomain. A Mailgun domain cannot be renamed later.
- Set the region. Choose the US or EU region used by the application and its Mailgun API endpoint.
- Enable key rotation. Turn on Automatic Sender Security if available. It delegates two DKIM selectors to Mailgun and rotates 2048-bit keys automatically.
- Create the domain. Click Add Domain and keep the DNS records page open. Copy values from this page rather than from a generic example.
Mailgun Add New Domain form for mg.example.com
Keep inbound mail separate
Do not replace the root domain's existing MX records with Mailgun MX records. Mailgun MX records are needed only when Mailgun will receive mail for that exact sending domain. The tracking CNAME is separate and is needed for Mailgun click, open, and unsubscribe tracking.
Set up SPF
SPF authorizes Mailgun's sending servers for the envelope sender domain in Return-Path. Because Mailgun supports a custom sending domain, publish SPF on mg.example.com when that is the Mailgun domain. Under relaxed DMARC matching, mg.example.com and example.com share the same organizational domain.
Mailgun normally displays include:mailgun.org in the required TXT value. Use the exact host and value in the Mailgun DNS records page because account configuration can change what Mailgun requests.
- Find the host. In Mailgun, open Sending, Domain settings, select the domain, then open DNS records.
- Check existing SPF. Query TXT for the exact sending host. There must be no more than one record beginning with v=spf1.
- Publish one record. If the host has no SPF record, add Mailgun's value. If one exists, insert Mailgun's include before its final all mechanism.
- Keep lookups valid. Count all include, a, mx, exists, and redirect mechanisms reached during evaluation. SPF permits at most 10 DNS-querying terms.
SPF for a dedicated Mailgun subdomainDNS
Host: mg.example.com Type: TXT Value: v=spf1 include:mailgun.org ~all
Run the SPF check after publishing. It resolves the TXT record and exposes duplicate records, syntax faults, or excess DNS lookups before a live message depends on them.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A valid SPF record does not prove DMARC will pass. Send a message and confirm that the smtp.mailfrom domain shown in Authentication-Results shares the organizational domain used in the visible From address.
Some sending sources cannot set a custom Return-Path. For those sources, do not publish an unrelated SPF include solely to silence SPF alignment errors. DKIM can carry DMARC by itself when DKIM passes and its signing domain matches the From domain. Mailgun does support Return-Path matching through the verified sending domain, so SPF should be configured here.
Set up DKIM
DKIM is the more durable DMARC path because forwarding often breaks SPF while a valid DKIM signature can survive. I prefer Mailgun Automatic Sender Security for new domains because its two CNAME selectors let Mailgun rotate hosted 2048-bit keys without repeated DNS edits.
- Copy both selectors. On Mailgun's DNS records page, copy the two DKIM CNAME hostnames and their targets exactly.
- Create CNAME records. Add each selector at the DNS host. Do not append the zone twice if the DNS interface adds it automatically.
- Disable proxying. Publish the selectors as ordinary DNS CNAME records. Any HTTP proxy option must remain off.
- Confirm the signing domain. Send a message and inspect the DKIM-Signature d= value. It must match the From domain exactly or share its organizational domain under relaxed DMARC matching.
Mailgun Automatic Sender Security DKIM CNAME records
Automatic Sender Security
- DNS format. Two CNAME selector records point to Mailgun.
- Rotation. Mailgun rotates keys every 120 days by default.
- Use case. Best fit for new domains and low-maintenance key rotation.
Manual DKIM
- DNS format. A selector TXT record contains the public key.
- Rotation. You publish and retire selectors on your own schedule.
- Use case. Useful when security policy requires direct key control.
Multiple DKIM keys can be normal
Mailgun can show old, secondary, or rotation keys as unverified. The active selector used in a delivered message must resolve and pass. Do not delete an old key until test messages consistently use a verified replacement.
Set up DMARC
Publish DMARC on the domain after the @ in the visible From address, not automatically on the Mailgun sending subdomain. For user@example.com, the record goes at _dmarc.example.com even when Mailgun uses mg.example.com for Return-Path.
Start at p=none unless the domain already uses p=quarantine or p=reject. Keep an existing stricter policy in place. The p=none phase collects evidence without asking receivers to block failures.
- Check for DMARC. Resolve TXT at _dmarc.example.com. Edit the existing record if one exists because a domain must not publish two DMARC records.
- Choose reporting. Use a mailbox or reporting address that can receive aggregate XML. Do not use an employee's personal inbox.
- Generate the record. Use the DMARC record generator when you need a different reporting address or optional tags.
- Publish TXT. Create the record at _dmarc for the visible From domain, then wait for its TTL to expire.
Starting DMARC recordDNS
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
The checker should return one valid record with version DMARC1, policy none, and the intended aggregate reporting address. Mailgun's DMARC documentation also confirms that Mailgun mail must pass either SPF or DKIM with matching domains.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the check finds more than one DMARC record, merge the required tags into one record and remove the duplicate. Receivers treat multiple records as an error, so enforcement and reporting become unreliable.
Leave adkim and aspf at their relaxed defaults unless every real message uses exact domain equality. Strict mode often breaks legitimate subdomain designs without adding enough value to justify the operational risk.
Verify and troubleshoot
Return to Mailgun after DNS has propagated. Open Sending, Domain settings, choose the domain, select DNS records, then click Check status. DNS changes often appear within minutes, but cached answers can take up to 24 to 48 hours.
Verification in the control panel proves Mailgun can see its required DNS records. A delivered-message test proves that the application uses the intended Mailgun domain and that the final message passes DMARC. Both checks matter.
- Refresh status. Click Check status and confirm Mailgun marks the required SPF and active DKIM records as verified.
- Send production-shaped mail. Use the same API domain, From address, template path, and tracking settings as the application.
- Read the result. Confirm SPF pass, DKIM pass, and DMARC pass. At least one passing method must also have domain matching.
- Test variants. Repeat for every From domain, Mailgun sending domain, API region, and dedicated IP pool used by the application.
Mailgun DNS records page with verified SPF and DKIM
The email tester is the quickest end-to-end check. Send the generated test address a message through the same Mailgun code path used in production, then inspect its SPF, DKIM, DMARC, headers, and content diagnosis.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A Mailgun domain can remain unverified when the DNS host field contains the full domain twice, a CNAME is proxied, or an old TXT value conflicts with the new record. Compare the authoritative DNS answer with the exact host and target shown by Mailgun.
If SPF passes but DMARC fails, compare smtp.mailfrom with the visible From domain. If DKIM passes but DMARC fails, compare the DKIM d= domain with the visible From domain. The DMARC checker validates DNS, while message headers reveal the domains actually evaluated.
|
|
|
|---|---|---|
SPF permerror | Duplicate record or lookup limit | Merge records and reduce lookups |
DKIM neutral | Selector does not resolve | Correct the CNAME host or target |
DMARC fail | No passing method has domain matching | Fix Return-Path or DKIM d= domain |
Mailgun unverified | DNS cache or malformed host | Check authoritative DNS and TTL |
Common Mailgun authentication failures
Get alerted when it breaks
DNS authentication can break after launch when an SPF edit creates a second record, a DKIM selector disappears, or application traffic moves to an unapproved Mailgun domain. One successful setup check does not detect those later changes.
- Collect reports. Route aggregate DMARC XML to a monitored processor instead of trying to read attachments by hand.
- Watch source changes. Alert when Mailgun traffic begins failing, a new sending IP appears, or an unknown source uses the domain.
- Monitor DNS health. Track SPF lookup count, DKIM selectors, DMARC policy, and domain or IP blocklist (blacklist) status.
- Assign fixes. Turn each alert into a specific DNS or Mailgun configuration task with an owner.
Suped is our DMARC platform and the best overall practical choice for this workflow. Its DMARC monitoring identifies Mailgun as a source, separates verified and unverified traffic, detects authentication issues, and gives steps to fix them. Real-time alerts reduce the gap between a DNS change and detection.
A practical Suped workflow
- Add reporting. Use the aggregate report destination generated for the domain.
- Verify Mailgun. Mark expected Mailgun traffic as an approved source after checking its domains and pass results.
- Enable alerts. Notify the team when failure volume crosses the chosen threshold.
- Review issues. Use the source-specific fix steps before changing policy.
The same platform brings together DMARC, SPF and DKIM monitoring, blocklist monitoring, deliverability checks, Hosted SPF, and multi-tenant management. That matters when a Mailgun fix changes DNS or when an agency needs the same alerting across many client domains.
Secure your domain with p=reject
Move to p=reject only after DMARC reports show that every approved source passes through SPF or DKIM with domain matching. The goal is full enforcement without rejecting legitimate application mail, billing mail, support mail, or employee mail.
- Build the inventory. Use DMARC reports to list each approved source and confirm which business system owns it.
- Fix approved traffic. For Mailgun, confirm the intended Return-Path, an active DKIM selector, and the same From domain family on real messages.
- Stage enforcement. Change to quarantine for a limited percentage, review failures, then raise the percentage after legitimate traffic stays clean.
- Enforce reject. Set p=reject and pct=100 after approved traffic remains stable through normal sending cycles and peak jobs.
- Keep monitoring. Continue alerts because a new application release or DNS edit can break a previously passing source.
Full enforcement recordDNS
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Ready for reject
- Approved sources. Every source has an owner and a verified authentication path.
- Mailgun traffic. Production messages pass DMARC across all active domains and pools.
- Unknown traffic. Failures have been investigated and are safe to reject.
Stay in monitoring
- Unowned sources. Reports still contain legitimate traffic nobody has classified.
- Intermittent failures. Mailgun passes vary by stream, domain, or application path.
- Recent DNS work. A key, include, or From-domain change has not completed a normal cycle.
Suped makes this rollout safer by showing pass rates per source, flagging unverified senders, and providing policy staging through Hosted DMARC. Automated issue detection and real-time alerts give the team evidence for each policy increase and warn when Mailgun authentication regresses after enforcement.
Mailgun authentication FAQ
Authentication-Results, DKIM-Signature, DNS answers, and DMARC aggregate reports expose the details behind most post-setup failures.
- Check the message. Authentication-Results and DKIM-Signature show what receivers evaluated.
- Check the source. rDNS and SPF clues can identify Mailgun, but they do not prove authorization by themselves.
Always compare those clues with the Mailgun domain configured in the application and the source shown in DMARC aggregate reports.
