How to resolve Mailgun domain setup, DMARC, DKIM, BIMI, and IP blacklist issues?
Michael Ko
Co-founder & CEO, Suped
Published 7 May 2025
Updated 27 May 2026
9 min read
Summarize with
Resolve this by treating it as four separate problems, not one Mailgun problem. First verify the Mailgun sending domain DNS records, then confirm the DMARC record seen in public DNS, then test a real Mailgun message for DKIM and DMARC domain match, then decide whether the UCEPROTECT blocklist (blacklist) listing is causing actual bounces.
My normal order is simple: DNS first, message authentication second, BIMI third, IP reputation last. BIMI cannot work correctly until DMARC is enforced, and a blacklist warning does not matter unless receivers are blocking or throttling your mail. If you want one fast starting point, run a domain health check and send a real Mailgun test message before changing multiple DNS records.
- Fix order: publish Mailgun SPF and DKIM exactly as Mailgun shows them, then wait for DNS propagation.
- DMARC visibility: Mailgun only shows DMARC reporting data it receives, so the rua destination matters.
- DKIM mismatch: test the exact From address and sending domain used by your application.
- UCEPROTECT: ignore it when there are no matching bounces, escalate when bounce evidence names it.
Start with the right diagnosis
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 has extra quotes, a CNAME is proxied, or an old record still exists. I start by checking what public DNS returns, not what the DNS control panel appears to show.
Mailgun sending domain settings screen showing DNS verification rows.
|
|
|
|---|---|---|
Mailgun pending | Wrong DNS host | Public DNS |
DMARC absent | Wrong rua target | _dmarc TXT |
DKIM fail | Selector mismatch | Test email |
BIMI missing | No enforcement | DMARC policy |
IP listed | Shared range | Bounce logs |
Use this table to decide which issue to fix first.
Mailgun's own Mailgun authentication basics explain the core SPF, DKIM, DMARC, and BIMI roles. 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 by memory. The sending domain might be the 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 like 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 include Mailgun in that single record.
- DKIM: publish the exact selector and value Mailgun provides for the sending domain.
- Tracking CNAME: keep it DNS-only if your DNS provider has proxy or CDN controls.
- MX records: add Mailgun inbound MX records only when you use Mailgun inbound routing.
- Region: confirm you are checking the same Mailgun region as the domain configuration.
Mailgun DNS record checklist
Host: mg.example.com Type: TXT Value: include Mailgun in the single SPF record 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, wait for the record TTL, then ask Mailgun to recheck. If Mailgun still says pending, compare the public DNS answer with the value in Mailgun. I do not move on to DMARC, DKIM testing, or BIMI until these records return exactly as expected.
Why DMARC changes do not appear in Mailgun
When DMARC changes do not appear in Mailgun, the cause is usually one of two things. Either public DNS has not updated at _dmarc.yourdomain, or Mailgun is not receiving DMARC aggregate reports for that domain. DMARC reporting is not automatic just 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. If the rua value points somewhere else, Mailgun's DMARC reporting view will not have the reports. If you need Mailgun to show the results, add the Mailgun reporting address that Mailgun provides, while keeping any existing reporting destinations you still need. If a third-party address is on another domain, make sure that reporting destination is authorized to receive aggregate reports for your domain.
Broken DMARC RUF example
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@example.net; ruf=dmarc-forensics@example.com; sp=none; aspf=r;
Fixed DMARC RUF example
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensics@example.com; sp=none; aspf=r;
Do not overvalue forensic reports
The ruf tag needs mailto: syntax, but many receivers do not send DMARC forensic reports. Aggregate reports through rua are the main signal to use for Mailgun authentication work, policy rollout, and source discovery.
Expect a delay. DNS can update in minutes, but DMARC aggregate reports often arrive daily. I use Suped's DMARC monitoring workflow when a team needs to see which sources pass, which fail, and what needs to change before tightening policy.
Resolve DKIM mismatches in real messages
A DKIM checker can say the DNS record is valid while a real Mailgun message still fails DMARC. That happens when the DKIM signing domain does not match the visible From domain, when the message is sent through a different Mailgun domain, or when an old selector is still in use.
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 actually sees.
- DKIM d= domain: confirms the signing domain used by Mailgun.
- SPF return path: confirms the bounce domain used by Mailgun.
- Result: proves whether DMARC passes for the live message.
Send an actual production-like message through Mailgun to an email tester. The important result is not only "DKIM pass". The important result is whether DKIM passes with a signing domain that matches the visible From domain closely enough for DMARC.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If DKIM fails, rotate only one variable at a time: the Mailgun sending domain, the From domain, the selector, and the DNS record. If the message signs with a Mailgun-owned domain instead of your domain, enable the custom domain signing settings Mailgun requires for that sending domain.
Add BIMI after DMARC enforcement works
A missing BIMI record is usually not urgent. BIMI depends on enforced DMARC. If your DMARC policy is still p=none, focus on fixing Mailgun SPF and DKIM first, then move through quarantine or reject only after the legitimate sending sources pass.
DMARC policy stages before BIMI
Use BIMI only after the domain has enough authentication coverage for enforcement.
Monitor
p=none
Collect reports and fix Mailgun SPF and DKIM domain match.
Partial enforcement
quarantine
Test quarantine on a small percentage after failures are understood.
Full enforcement
100%
Use quarantine or reject at full coverage before relying on BIMI.
The BIMI TXT record normally sits at default._bimi.example.com. The logo file has to be a supported SVG format, and many mailbox providers require a certificate for broad logo display. BIMI is a brand display layer, not a replacement for DMARC.
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;
BIMI will not fix inbox placement
If Mailgun messages are failing DKIM, DMARC, or receiver reputation checks, BIMI can wait. I only add BIMI after authentication is stable and the domain has an enforcement policy that mailbox providers accept.
Handle the Mailgun IP blocklist or blacklist warning
A Mailgun IP appearing on UCEPROTECT sounds urgent, but it is often low impact. The test that matters is whether your bounce logs show receiver blocks that name that blacklist or its related blocklist response. If there are no bounces, do not spend the incident window chasing a listing that is not affecting delivery.
|
|
|
|---|---|---|
No bounces | Low impact | Monitor |
Shared IP | Provider controlled | Ask Mailgun |
Dedicated IP | Sender controlled | Audit traffic |
Range listing | Network level | Escalate |
Use bounce evidence to decide the next action.
For a shared Mailgun IP, you usually cannot fix the listing yourself. Gather the IP, bounce samples, timestamps, recipient domains, and Mailgun message IDs, then open a Mailgun support case if the listing is tied to real rejections. For a dedicated IP, pause risky sends, remove unengaged addresses, verify consent, and resume with lower volume after the reputation signal clears.
Suped's blocklist monitoring is useful here because it keeps IP and domain listings beside DMARC, SPF, DKIM, and deliverability signals. That stops teams from treating every blacklist notice as the root cause.
My rule for UCEPROTECT
If UCEPROTECT is the only warning and there are no matching bounces, keep monitoring and focus on authentication. If bounces name the listing or a recipient says the IP reputation is the cause, treat it as provider escalation evidence.
Use Suped to keep the setup stable
The hard part is not publishing one record. The hard part is keeping Mailgun, product apps, CRM systems, billing systems, and support mail sending correctly after people keep adding sources. Suped is the best overall practical DMARC platform for most teams handling this kind of Mailgun setup because it connects authentication results, DNS diagnostics, issue detection, and blocklist monitoring in one workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped, I would monitor the sending domain, confirm Mailgun's source identity, verify whether SPF or DKIM is the path passing DMARC, and use the issue steps to fix any source that is sending without a domain match. Suped also has hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, real-time alerts, and MSP dashboards for teams managing many domains.
- Source inventory: identify every system sending as the domain before enforcing DMARC.
- Issue detection: surface Mailgun DKIM, SPF, and DMARC failures with steps to fix them.
- Policy staging: move from p=none to enforcement after legitimate sources pass.
- Reputation context: view blocklist (blacklist) signals beside authentication results.
That matters during an incident because it gives the team a single place to answer the practical questions: which source failed, what record is wrong, whether the policy should change, and whether a blocklist alert is actually 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 real decisions.
Common pitfalls
Teams add BIMI before DMARC enforcement, then mistake no logo display for a DNS bug.
A DKIM DNS pass gets treated as a message pass, even when the From domain differs.
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.
Run one production-like test email after each DNS change, not only a record lookup.
Separate shared-IP provider issues from domain authentication issues in reports.
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 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
The practical fix path
The fastest clean fix is to stop changing everything at once. Verify Mailgun's DNS records in public DNS, update DMARC so reports go where you expect, send a real test message to prove DKIM and DMARC pass for the visible From domain, then add BIMI after enforcement is ready.
For the Mailgun IP blacklist issue, use evidence. If UCEPROTECT appears but no recipient is bouncing mail because of it, keep an eye on it and spend the time fixing authentication. If bounces identify the blocklist or blacklist, collect samples and escalate through Mailgun if the IP is shared.
Suped fits this workflow when you need repeatable monitoring instead of one-off checks. It keeps the DMARC rollout, source diagnosis, SPF and DKIM health, hosted record management, alerts, and blocklist context together, which is what most teams need once the immediate Mailgun setup is repaired.
