Blog · Dmarc
Why Your Mailgun Subdomain DMARC Record Is Not Working
When you set up a DMARC record on your Mailgun sending subdomain and messages still fail authentication, the issue is almost never the record itself. It is almost always that the record on the subdomain is not enough to fix a misalignment between the domain that DMARC is checking and the domain that Mailgun is actually authenticating.
The core problem is this: Mailgun sends from mg.domain.com using Mailgun's own servers. Your DMARC policy checks domain.com. When the email arrives, the authenticated sending domain is mg.domain.com but the From header shows domain.com. DMARC alignment fails because those two domains do not match.
This is not a Mailgun-specific bug. It is how email authentication is designed to work. Here is how to diagnose exactly what is failing and how to fix it.
How to Diagnose Which Alignment Is Failing
DMARC checks two types of alignment independently: SPF alignment and DKIM alignment. Either or both can fail. Here is how to test each one.
Testing SPF alignment
SPF authenticates theEnvelope From domain, which is the MAIL FROM address used in the SMTP session. This is not the same as the From header you see in an email client.
To check what SPF record your Mailgun subdomain has, run:
dig txt mg.domain.com +short
Look for the Mailgun include statement. It should look like:
v=spf1 include:mailgun.org ~all
If this record exists and resolves, SPF passes for mg.domain.com. But SPF alignment for your domain.com From header requires the MAIL FROM domain to also be domain.com. That is almost never the case when using a Mailgun subdomain. SPF alignment almost always fails in this setup.
Testing DKIM alignment
DKIM authenticates the domain in the DKIM-Signature header, which is set by the signing server. To check which domain Mailgun is DKIM-signing for, run:
dig txt ._domainkey.domain.com +short
Or use an online DKIM checker and look at which domain the DKIM signature covers. If Mailgun is signing mg.domain.com but your From header shows domain.com, DKIM alignment fails.
Why Subdomain Sending Breaks DMARC Alignment
DMARC alignment is strict by default. For a message to pass DMARC when your policy is p=reject or p=quarantine, either SPF alignment or DKIM alignment must match. "Aligned" means the domain that passed SPF or DKIM authentication must be the same as the From header domain, or a declared subdomain of it.
Here is what a typical failure looks like in a DMARC aggregate report:
- `source_domain`: mg.domain.com
- `dkim_result`: pass (signed by mg.domain.com)
- `spf_result`: pass (from mg.domain.com)
- `alignment`: fail (both aligned to mg.domain.com, From header shows domain.com)
Both authentication checks pass individually. But neither is aligned with the From header domain. DMARC fails.
This is the exact scenario where aggregate reports would show the failure clearly. Without reading the report, you only see that email is bouncing or that authentication appears broken. The report tells you exactly what is misaligning and whether the signing domain is mg.domain.com or something else entirely.
Fix 1: Add SPF to Your Mailgun Subdomain
If the Mailgun sending subdomain has no SPF record, that is the first thing to fix. Without SPF, the subdomain has no authenticated identity at all.
Add this TXT record to your DNS for mg.domain.com:
v=spf1 include:mailgun.org ~all
Replace mg.domain.com with your actual Mailgun sending subdomain. Then test it with dig before assuming it works:
dig txt mg.domain.com +short
SPF on the subdomain helps but does not fix alignment on its own. The MAIL FROM domain for outbound SMTP from Mailgun is still mg.domain.com, not domain.com. SPF alignment still fails unless your Mailgun setup is configured to use your root domain as the MAIL FROM.
Fix 2: Set Up DKIM Signing on the Subdomain
Mailgun provides DKIM keys at the subdomain level. The standard setup asks you to add CNAME records that point to Mailgun's DKIM infrastructure. These CNAMEs are verified during Mailgun domain setup and look like:
k1._domainkey.mg.domain.com IN CNAME k1._domainkey.mailgun.org
k2._domainkey.mg.domain.com IN CNAME k2._domainkey.mailgun.org
If these CNAMEs are missing or were never verified, Mailgun falls back to signing with its own internal domain, and DKIM alignment on your subdomain fails completely.
To verify DKIM is working, use a DKIM checker and look at the d= tag in the DKIM-Signature header. If it shows mg.domain.com, the subdomain is being signed. If it shows mailgun.org or a Mailgun internal domain, the subdomain DKIM is not active.
For DKIM alignment to work with your From header, you need the signing domain to match your From domain. With Mailgun subdomains that means either using mg.domain.com as your From address (which brands your transactional emails with the subdomain) or configuring Mailgun to DKIM-sign with your root domain (requires verified CNAME delegation and is not available for all domain configurations).
Fix 3: Set a DMARC Record on the Subdomain
Your Mailgun sending subdomain needs its own DMARC record, not just the one on your root domain. Add this to mg.domain.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@domain.com; aspf=r;
What each part does:
- `p=none` means monitor only. Do not reject or quarantine anything based on this subdomain yet.
- `rua` sends aggregate reports to the address listed. These reports are the only way to confirm whether your fixes are actually working.
- `aspf=r` sets relaxed alignment, which treats subdomains of the From domain as aligned. This is more forgiving when your MAIL FROM is a subdomain of your From domain.
Do not set p=quarantine or p=reject on the subdomain without first confirming that aggregate reports show zero authentication failures. Setting enforcement before verifying is how legitimate transactional email gets silently blocked.
How to Read DMARC Reports to Confirm the Fix
After making DNS changes, you need to confirm they are actually working. The only reliable way is to read the aggregate reports sent to your rua address.
A DMARC aggregate report arrives as an XML file attached to an email. It contains one
- `
` should show `mg.domain.com` - `
` should be pass, and the ` ` it authenticates should align with your intended From domain - `
` should be pass - `
` should be pass for at least one of SPF or DKIM
If you are using a DMARC monitoring tool like DMARCFlow, you can configure the rua destination to forward reports directly to your monitoring dashboard and see per-subdomain authentication results without manually parsing XML. DMARCFlow parses aggregate reports automatically and shows you which Mailgun subdomains are passing or failing alignment, which means you do not have to read a single XML file to confirm your DNS changes are working.
Why This Keeps Happening
The root cause is a structural mismatch in how transactional email platforms work versus how DMARC expects email authentication to be set up.
Transactional email services like Mailgun are designed to send high volumes of email from infrastructure they control. That means the sending domain in SMTP is their subdomain, not yours. But DMARC was designed assuming the sending infrastructure and the From address domain would be the same.
The pattern that causes this failure looks like this:
- You set up Mailgun with a sending subdomain like `mg.domain.com`
- You publish a DMARC record on `domain.com` with `p=reject` because your main domain is protected
- Mailgun sends your transactional email from `mg.domain.com`, not `domain.com`
- Both SPF and DKIM authenticate `mg.domain.com`
- The From header shows `domain.com`
- DMARC checks `domain.com`, finds no aligned authentication from that domain, and fails
The fix is to ensure the subdomain has its own SPF and DKIM records and its own DMARC policy set to p=none with reporting enabled, so you can monitor whether the subdomain is now passing alignment before you apply any enforcement.
The same pattern applies to any transactional email service that uses subdomain sending: SendGrid, Postmark, Amazon SES, and others all follow this same structure. The troubleshooting steps are identical regardless of which service you use.
FAQ
I added the SPF record but my DMARC report still shows failures. Why?
The SPF record on the subdomain means the subdomain passes SPF. But SPF alignment checks whether the MAIL FROM domain matches the From header domain. If Mailgun is still sending from mg.domain.com as the MAIL FROM while your From header is domain.com, SPF alignment still fails. You need either DKIM alignment to pass, or you need Mailgun configured to use your root domain as the MAIL FROM.
My DKIM check passes but DMARC still fails. What is happening?
If DKIM passes but DMARC fails, the signing domain does not match your From domain. Check the d= tag in the DKIM-Signature header. If it shows your Mailgun subdomain rather than your From domain, DKIM is passing but not aligned. This is a DKIM alignment failure, not a DKIM authentication failure.
Can I just set p=none on my root domain and ignore the subdomain?
You can, but it does not fix the problem. Setting p=none on your root domain means you are not enforcing anything, so the subdomain can send without DMARC blocking it. But the subdomain is still failing DMARC alignment, which means third parties that check DMARC before accepting mail may still reject your emails. A passing DMARC check at p=none is still better than a failing one.
How do I know if my Mailgun subdomain is using the root domain or the subdomain as the From address?
Check your Mailgun sending domain settings. There is a "Domain Verification" step that asks you to confirm your From address domain. If you set domain.com as the From address but Mailgun is still sending from mg.domain.com in SMTP, alignment fails. Configure your transactional email templates to use From addresses that match the domain Mailgun is actually authenticating.