How to resolve Mailgun domain setup, DMARC, DKIM, BIMI, and IP blacklist issues?
Updated on 13 Oct 2026: We clarified Mailgun authentication troubleshooting and DMARC test mode compatibility, with specific BIMI and IP blacklist checks.
Resolve Mailgun setup issues by checking DNS, message authentication, BIMI, and IP reputation separately. First verify the Mailgun sending domain DNS records, then confirm the DMARC record seen in public DNS. Test a real Mailgun message for DKIM and DMARC domain match, then decide whether the UCEPROTECT blocklist (blacklist) listing is causing SMTP rejections or temporary deferrals.
For setup work, use this order: DNS first, message authentication second, BIMI third, and IP reputation last. Prioritize any active delivery incident. BIMI requires DMARC enforcement, and an IP blacklist warning needs delivery evidence before you treat it as the cause. For one fast starting point, run a domain health check and send a real Mailgun test message before changing multiple DNS records.
- Fix order: Merge Mailgun SPF into the existing SPF record at the sending host, publish the supplied DKIM records, and wait for DNS propagation.
- DMARC visibility: Mailgun only shows aggregate data sent to the rua destination configured for its reporting service.
- DKIM mismatch: Test the exact From address and sending domain used by your application.
- UCEPROTECT: Monitor the listing when there are no matching delivery failures, then escalate when rejection or deferral evidence names it.
Diagnose Mailgun DNS and authentication failures
Mailgun domain setup checks usually fail for ordinary DNS reasons: the record is in the wrong zone, the host name has the domain appended twice, a TXT value contains literal quote characters, a CNAME is proxied, or an old record still exists. Check what public DNS returns instead of relying on what the DNS control panel appears to show.
Mailgun sending domain DNS verification settings for SPF, DKIM, tracking CNAME, and MX records.
|
|
|
|---|---|---|
Mailgun verification pending | Wrong DNS host | Public DNS answer |
DMARC reports absent | Wrong rua destination | _dmarc TXT record |
DKIM signature fails | Missing key or altered message | Live message headers and selector DNS |
DKIM passes, DMARC fails | From-domain mismatch | DKIM d= and SPF Return-Path domains |
BIMI logo missing | DMARC policy or certificate issue | Policy, SVG, and certificate requirements |
Sending IP listed | IP or network reputation | Mailgun bounce logs |
Use this table to decide which issue to fix first.
Mailgun's authentication basics explain the roles of SPF, DKIM, DMARC, and BIMI. The practical detail is that your production message has to pass with the same visible From domain your users see. A record can be published correctly and still fail the message test if the app sends through a different Mailgun domain.
Fix Mailgun domain verification first
In Mailgun, copy the DNS records from the sending domain page exactly. Do not rebuild them from memory. The sending domain is either a root domain, such as example.com, or a subdomain, such as mg.example.com. That difference changes where records must be published.
The most common Mailgun DNS mistake
Many DNS providers automatically append the domain name to the host field. If Mailgun asks for a host such as smtp._domainkey.mg.example.com and your DNS UI already shows example.com outside the field, entering the full host can create smtp._domainkey.mg.example.com.example.com. Public DNS will then never return the record Mailgun expects.
- SPF: Keep one SPF TXT record per host and merge include:mailgun.org into it. Nested include and redirect terms count toward the 10-lookup limit; exceeding it causes SPF permerror.
- DKIM: Publish the exact TXT record or both Automatic Sender Security CNAME records Mailgun supplies, at the specified selectors.
- Tracking CNAME: Add it when you use click, open, or unsubscribe tracking, and keep it DNS-only when proxy controls are available.
- MX records: Add Mailgun inbound MX records only for inbound routing. Do not replace MX records that already receive your normal mail.
- Region: Confirm you are checking the same Mailgun region as the domain configuration.
Mailgun DNS record checklist
Host: mg.example.com Type: TXT Value: v=spf1 include:mailgun.org ~all Host: selector._domainkey.mg.example.com Type: TXT or CNAME, exactly as Mailgun shows Value: paste the exact Mailgun DKIM value Host: email.mg.example.com Type: CNAME Value: paste the exact Mailgun tracking target
After publishing, allow up to 24 to 48 hours for DNS propagation, even though records often appear sooner. Then ask Mailgun to recheck. If Mailgun still says pending, compare the public DNS answer with the value in Mailgun. Confirm the required sending records, then test a live message. An unused DKIM key marked Unverified or an optional inbound MX record does not by itself prove that sending authentication is broken.
Why DMARC changes do not appear in Mailgun
When DMARC changes do not appear in Mailgun, check public DNS and report routing separately. Public DNS must expose the intended record, and Mailgun must receive DMARC aggregate reports for that domain. DMARC reporting is not automatic because Mailgun sends the email. Receivers send aggregate reports to the addresses in the DMARC rua tag.
Check the live TXT record at _dmarc.example.com when the visible From address uses example.com, or _dmarc.mg.example.com when it uses mg.example.com. A subdomain without its own DMARC record inherits a parent policy through DMARC policy discovery. Keep one DMARC policy record at each host, with v=DMARC1 first. If rua points elsewhere, Mailgun will not receive those reports. Add Mailgun's reporting address to the existing record, separating multiple rua destinations with commas. External destinations also need report authorization in the destination domain's DNS.
DMARC record with a valid RUF URI
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensics@example.com; aspf=r; adkim=r;
Do not overvalue failure reports
Use ruf=mailto:dmarc-forensics@example.com, not ruf=dmarc-forensics@example.com. Many receivers limit or disable failure reports because they can expose message data. Aggregate reports through rua are the main signal for Mailgun authentication work, policy rollout, and source discovery.
Expect a delay. DNS can update in minutes, but DMARC aggregate reports usually arrive daily, and not every receiver sends them. Mailgun includes aggregate reporting in Optimize for paid plans, as described in its DMARC reporting documentation. Confirm the domain is enabled for reporting and allow 24 to 48 hours after sending to receivers that issue reports. Suped's DMARC monitoring workflow helps teams identify sending sources, diagnose failures, and decide when to tighten policy. These reports do not establish inbox placement.
Use current DMARC policy tags
RFC 9989 defines DMARC and replaces RFC 7489. The pct tag is historic, so omit it when creating or revising a DMARC record. RFC 9989 adds t for policy test mode. Aggregate reporting and message-specific failure reporting have separate specifications in RFC 9990 and RFC 9991.
Use p=none while discovering legitimate sources. At receivers that implement RFC 9989, p=quarantine; t=y requests none handling for DMARC failures while reports continue. Remove t=y to request full quarantine. Choose p=reject for a controlled sending domain only after legitimate Mailgun and non-Mailgun sources pass DMARC and indirect mail paths have been reviewed.
A dedicated transactional subdomain can move to p=reject after report review. For a general-purpose email domain used by people, RFC 9989 advises against p=reject because forwarding and mailing lists can cause valid mail to lose its domain match.
Current DMARC monitoring record
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; aspf=r; adkim=r;
DMARC policy test record for RFC 9989 receivers
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.net; aspf=r; adkim=r;
Test mode depends on receiver support
Receivers using RFC 7489 ignore the unknown t=y tag and apply the published p policy. Do not rely on test mode to preserve delivery of legitimate failures. Keep p=none until enforcement is safe. For BIMI, use full quarantine or reject without t=y.
Resolve DKIM mismatches in real messages
A DNS lookup can return a valid DKIM key while a real Mailgun message still fails DMARC. A passing DKIM signature needs the signing domain to match the visible From domain under the configured DMARC mode. A cryptographic DKIM failure is different: check for a missing selector, an incorrect key, or message changes after signing.
DNS record checks
- Selector: Confirms the DKIM selector exists in DNS.
- Value: Confirms the public key or CNAME target is present.
- Syntax: Confirms the record format is parseable.
- Limit: Does not prove your app sent through that selector.
Message checks
- Header From: Confirms the domain the recipient sees.
- DKIM d= domain: Confirms the signing domain used by Mailgun.
- DKIM s= selector: Identifies the key at selector._domainkey.signing-domain, using s= and d= from the signature.
- SPF return path: Confirms the bounce domain used by Mailgun.
- Authentication-Results: Shows whether the live message passes DMARC.
Send an actual production-like message through Mailgun to an email tester. Confirm both authentication and domain matching: DMARC passes when at least one of DKIM or SPF passes and its authenticated domain matches the visible From domain under the configured mode.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
With relaxed matching, mg.example.com can match a visible From domain of example.com. Strict matching requires identical domains: adkim=s controls DKIM, and aspf=s controls SPF. Check Mailgun's DKIM authority setting if the signing domain is the root domain while the From address uses a subdomain. Change one variable at a time, using the message headers to decide whether the sending configuration or DNS needs correction. If the message signs with a Mailgun-owned domain, configure custom DKIM signing for your Mailgun sending domain.
Mailgun's DKIM rotation documentation explains Automatic Sender Security: publish both supplied CNAME records so Mailgun can rotate 2048-bit keys every 120 days. Legacy manual keys remain visible after activation; an unused Unverified key is not proof of a failure. With manual rotation, verify every active signing selector. Retain the old public key while messages already signed with it are still in transit.
Fix Mailgun SPF alignment and forwarding failures
SPF checks the SMTP MAIL FROM domain, usually shown in the delivered Return-Path. SPF alignment compares that authenticated domain with the visible From domain. Adding include:mailgun.org to the root domain does not repair a mismatch when the message uses another Return-Path domain.
Relaxed SPF matching for a Mailgun subdomain
From: billing@example.com Return-Path: <bounce@mg.example.com> SPF: pass for mg.example.com aspf=r: SPF domain matching passes aspf=s: SPF domain matching fails
- Check the receiving server's Authentication-Results for spf=pass and smtp.mailfrom, then compare that domain with header.from.
- If SPF returns permerror, remove duplicate SPF records and fix syntax or lookup-limit errors at the MAIL FROM host. SPF records are not inherited by subdomains.
- Forwarding changes the connecting IP and often breaks SPF. Sender Rewriting Scheme (SRS) can restore SPF for the forwarder's domain, but does not restore its match with the original From domain.
- Keep DKIM signing on your domain. A passing signature with the required domain match can preserve DMARC through forwarding if the signed content remains intact.
Compare a direct Mailgun delivery with a forwarded copy before changing SPF. The SPF lookup rules explain permerror, while Mailgun's authentication explanation describes why forwarding affects SPF. A DMARC pass still leaves inbox placement dependent on the receiver's other filtering decisions.
Add BIMI after DMARC enforcement works
A missing BIMI record is usually not urgent. BIMI depends on enforced DMARC. If your policy is still p=none or uses t=y, fix Mailgun authentication first. Move to full quarantine or reject only after reports show that legitimate sending sources pass.
DMARC policy stages before BIMI
Use BIMI only after the domain has enough authentication coverage for full enforcement.
Monitor
p=none
Collect reports and fix Mailgun domain matching.
Policy test
p=quarantine; t=y
Request none handling for failures at receivers supporting RFC 9989 test mode.
Full enforcement
p=quarantine or p=reject
Remove test mode and apply quarantine or reject.
Publish the BIMI TXT record for the visible From domain, normally at default._bimi.example.com for mail from example.com. Host a compliant SVG Tiny PS logo at a stable HTTPS URL and return the image/svg+xml content type. Gmail requires a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC), as described in its BIMI setup requirements. A VMC supports Gmail's verification checkmark; a CMC supports logo display without that checkmark. Requirements differ by mailbox provider.
Example BIMI record
Host: default._bimi.example.com Type: TXT Value: v=BIMI1; l=https://example.com/bimi.svg; a=https://example.com/vmc.pem;
If the logo is still missing, confirm that the message passes DMARC, the receiving mailbox supports BIMI, and the SVG and certificate PEM URLs are publicly accessible over HTTPS. Check certificate validity and that it covers the sending domain. For receivers using legacy DMARC rules, omit pct or retain only its default value of 100; a lower value does not provide full enforcement. A valid BIMI record does not guarantee logo display.
BIMI will not fix inbox placement
If Mailgun messages are failing authentication or reputation checks, BIMI can wait. Add BIMI only after authentication is stable and the domain has an enforcement policy that participating mailbox providers accept.
Handle the Mailgun IP blocklist or blacklist warning
A Mailgun IP appearing on UCEPROTECT does not by itself establish delivery impact. Check Mailgun events for receiver responses that name the blacklist (blocklist). A 4xx SMTP response is a temporary deferral; a 5xx response is a permanent rejection. Match the listed address to the actual sending IP in the affected event or message headers. If there are no matching delivery failures, monitor the listing and keep working on authentication.
|
|
|
|---|---|---|
No matching SMTP failures | No proven rejection or deferral impact | Monitor the listing and delivery trends |
Shared IP | Mailgun controls the address | Send evidence to Mailgun |
Dedicated IP | Your traffic affects IP reputation | Audit traffic and DNS |
UCEPROTECT Level 2 or 3 | Network allocation or ASN listing | Escalate with bounce samples |
Use bounce evidence to decide the next action.
For a shared Mailgun IP, you usually cannot fix the listing yourself. Gather the IP, full SMTP response, timestamps with timezone, recipient domains, Mailgun message IDs, and the UCEPROTECT level. Open a Mailgun support case when the listing is tied to rejections or deferrals. For a dedicated IP, pause problematic campaigns, investigate unexpected traffic or compromised credentials, verify consent, and suppress bounced or opted-out addresses. Resume with a controlled sending volume after correcting the cause. Mailgun preconfigures PTR records for shared and dedicated IPs; raise PTR or forward DNS problems with Mailgun support.
Avoid paid expedited removal as the first response. Fix the cause and ask Mailgun to handle any provider-controlled listing. UCEPROTECT Level 1 covers an individual IP; Level 2 covers an allocation, and Level 3 covers an autonomous system (ASN). A network listing does not establish abuse by your own account. The operator's listing policies distinguish these scopes. Suped's blocklist monitoring keeps IP and domain listings beside authentication and delivery signals, which helps teams avoid treating every blacklist notice as the root cause.
Rule for UCEPROTECT
If UCEPROTECT is the only warning and there are no matching delivery failures, monitor the listing and sending trends. If receiver responses name the listing or a recipient confirms an IP reputation rejection, use that evidence in a Mailgun escalation. Changing SPF or DMARC does not remove an IP blacklist entry.
Use Suped to keep the setup stable
The hard part is keeping Mailgun, product apps, CRM systems, billing systems, and support mail sending correctly as people add sources. Suped is our DMARC reporting and email authentication platform. It connects source data with DNS diagnostics, issue steps, policy management, alerts, and blocklist monitoring in one workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped, teams can monitor the sending domain, confirm Mailgun's source identity, verify whether DKIM or SPF provides the DMARC pass, and follow issue steps for sources sending without the required domain match. Review incoming aggregate reports after each application or DNS change.
- Source inventory: Identify every system sending as the domain before enforcing DMARC.
- Issue detection: Surface Mailgun authentication failures with steps to fix them.
- Policy staging: Move out of monitoring only after legitimate sources pass.
- Reputation context: View blocklist (blacklist) signals beside authentication results.
During an incident, that workflow helps the team answer practical questions: which source failed, what record is wrong, whether the policy should change, and whether a blocklist alert is tied to delivery failures.
Views from the trenches
Best practices
Check public DNS before trusting any provider dashboard or cached verification status.
Tie every blacklist alert to bounce evidence before treating it as the root cause.
Add mailto: to RUF addresses, but use RUA aggregate reports for operational decisions.
Common pitfalls
Teams add BIMI before DMARC enforcement, then mistake no logo display for a DNS bug.
A valid DKIM DNS record gets treated as proof that real messages pass DMARC authentication.
UCEPROTECT listings get escalated without checking if recipients are rejecting mail.
Expert tips
Keep a dated record of Mailgun DNS values so unexpected changes are easy to spot in public DNS.
Run one production-like test email after each DNS change, not only a record lookup.
Separate shared-IP provider issues from domain authentication failures in DMARC reports.
Marketer view
Marketer from Email Geeks says UCEPROTECT has little impact when there are no matching bounces, so the better response is monitoring rather than panic.
2025-04-17 - Email Geeks
Marketer view
Marketer from Email Geeks says Mailgun DMARC results depend on where aggregate reports are sent, not only on whether the DNS record exists.
2025-04-17 - Email Geeks
