I’m having trouble with my Mailgun DNS setup. The service wants me to create a TXT record for mail.mysite.com containing v=spf1 ... and also add a CNAME record for send.mail.mysite.com pointing to mailgun.org.
Mailgun accepted my domain verification without issues. But when I try sending emails, some mail servers bounce them back saying “Sender address rejected: Domain not found”. I think this happens because mail.mysite.com doesn’t actually resolve - there’s no CNAME record for it since I’m using that name for the TXT record already.
The problem is I can’t make both a TXT and CNAME record for the same subdomain name. Is there a way to move the SPF record (the v=spf1 part) to a different TXT entry so I can use the subdomain for a proper CNAME record? This might fix the sender verification issues I’m seeing with stricter email servers.
Hit this same issue last month with a client’s Mailgun setup. The problem isn’t just moving the SPF record - you need to understand what Mailgun actually wants. That TXT record at mail.mysite.com? It’s probably for domain verification, not SPF. Your SPF record goes on whatever domain shows in your FROM address, but don’t delete that verification TXT record or Mailgun will reject your emails. Here’s what worked: kept the verification TXT at mail.mysite.com and made a separate CNAME at email.mysite.com for the tracking subdomain. Check your Mailgun dashboard - they usually suggest alternative subdomains that avoid this mess entirely.
This DNS conflict points to a deeper issue with your Mailgun setup. When mail servers throw ‘Domain not found’ errors, they’re doing reverse DNS lookups on your sending infrastructure - not just checking SPF records. That TXT record at mail.mysite.com is probably Mailgun’s domain verification token. Don’t delete it - you need that active. Your bounce issues likely come from incomplete MX records or missing PTR records, not the CNAME conflict. I’ve fixed similar problems by making sure the sending domain has proper MX records pointing to valid mail servers, even when you’re not receiving mail there. Also check if your Mailgun account uses dedicated IP pools - shared IPs sometimes trigger stricter validation that causes these bounces.
You’re right - DNS records can’t mix CNAME with other types on the same name. But there’s confusion in your setup. The SPF record goes on your sending domain (your main domain or FROM address), not mail.mysite.com. I’ve seen similar Mailgun bounces, and it’s usually because the SPF record isn’t where the actual sender address lives. Check what domain you’re sending FROM - that’s where SPF needs to be. Also verify DKIM is set up right since missing DKIM often triggers those “domain not found” errors. Then mail.mysite.com can use the CNAME without any conflicts.
had that mailgun headache too. just use separate subdomains, dont fight the dns restictions. your spf should be on the actual sending domain, then set up like mg.mysite.com for cname instead of mail.mysite.com. mailgun lets you customize those in their panel, so no conflicts.
You’re experiencing email bounces with the message “Sender address rejected: Domain not found” when using Mailgun. This is likely because of a conflict in your DNS records, specifically related to your SPF record and a CNAME record required by Mailgun. You’re trying to use the same subdomain (mail.mysite.com) for both a TXT record (for SPF) and a CNAME record, which is not possible.
TL;DR: The Quick Fix:
Place your SPF record on your main domain (e.g., mysite.com) instead of a subdomain like mail.mysite.com. This resolves the DNS conflict. Then, use a different subdomain (e.g., mg.mysite.com) for your Mailgun CNAME record.
Understanding the “Why” (The Root Cause):
The error “Sender address rejected: Domain not found” arises from email server validation checks, particularly reverse DNS lookups. These checks verify that the sending domain (the domain in your email’s FROM address) is correctly configured and associated with legitimate mail servers. While SPF records help with sender authentication, they are not the only factor. Stricter email servers perform a comprehensive check, including verifying the existence and proper configuration of MX records (Mail Exchanger records, which define where mail is received) and PTR records (Pointer records, for reverse DNS lookups). By placing your SPF record on the main domain, you avoid this DNS conflict since you no longer have conflicting record types (TXT and CNAME) on the same subdomain (mail.mysite.com). The Mailgun verification TXT record should remain on mail.mysite.com as it’s independent of your sending domain.
Step-by-Step Guide:
Move SPF Record: Instead of placing your SPF record on mail.mysite.com, move it to your root domain (mysite.com). This avoids the conflict and ensures proper verification by receiving mail servers. Your DNS provider’s interface will allow you to create or modify a TXT record for mysite.com. The exact process differs slightly depending on your provider, but it typically involves adding a new TXT record or editing an existing one.
Create a New CNAME Record: Use a different subdomain, such as mg.mysite.com (or any other subdomain not used for your main website or other Mailgun settings), and create a CNAME record for it pointing to mailgun.org. This will not conflict with your existing records.
Verify DNS Propagation: After making these changes, allow sufficient time (often 24-48 hours) for DNS propagation. This ensures all mail servers will see the updated records. You can use online DNS lookup tools to check the propagation status.
Test Email Sending: Attempt to send a test email using your Mailgun account. Check if the “Sender address rejected: Domain not found” error persists. If the issue remains, carefully re-check steps 1-3, verifying the DNS records are correctly configured and have propagated across all DNS servers.
Common Pitfalls & What to Check Next:
Incorrect SPF Syntax: Double-check the syntax of your SPF record for any typos or errors. An incorrectly formatted SPF record can also cause email delivery problems.
DKIM and DMARC: Ensure that DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance) records are correctly configured for your sending domain. These authentication mechanisms work alongside SPF to improve email deliverability.
MX Records: Verify that your MX records are properly configured and point to the correct mail servers. Incorrectly configured MX records can affect sender verification.
PTR Records (Reverse DNS): While less common, issues with PTR records can also contribute to sender verification failures. If other steps don’t resolve the problem, investigate whether your domain’s reverse DNS settings are correct.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
DNS conflicts suck, but automation’s the way to handle this mess properly.
I’ve hit this exact problem tons of times. It’s not just about where you put records - you need to manage the whole email chain right. SPF on your sending domain, DKIM alignment, proper subdomain structure for tracking.
Manual DNS gets ugly fast when you’re dealing with verification records, SPF entries, and CNAMEs across different subdomains. Screw up once and your delivery rates crash.
Better approach? Automate the entire email workflow. Set up sequences that handle domain verification, DNS management, and sending through one system. Skips the DNS conflicts completely and your deliverability improves.
I use Latenode for this setup. Connects directly with email services and automates the DNS coordination behind the scenes. No more fighting with conflicting records or guessing if your SPF’s in the right spot.
The automation handles domain validation, manages record hierarchy, and keeps everything aligned when you make changes. Way cleaner than trying to coordinate multiple DNS entries manually.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!