We've been doing these DNS episodes, and this one lands in a really practical spot. The prompt asks, essentially, you've got your domain email running through Google Workspace, MX records pointing to Google, everything working fine. Now you want to send marketing emails or transactional emails through a service like Resend or Mailchimp, and suddenly you're being asked to add more DNS records. Some of them are TXT records for verification, which feels harmless enough, but occasionally a service asks you to create an MX record, and that's where the alarm bells go off. The core question is, how do you set all this up so your marketing emails actually land in inboxes without breaking your regular business email or triggering spam flags?
This is such a good question, and it gets at something that trips up a lot of people who are technically competent but haven't spent time in the email deliverability weeds. The short answer is that properly configured email-sending services should never ask you to add MX records. They use TXT records, CNAME records, and sometimes a dedicated subdomain. But the anxiety is completely warranted because if you mess with MX records, you can absolutely break your inbound mail.
When a service does ask for an MX record, what's actually happening there?
Nine times out of ten, it's a misunderstanding on the user's part about what's being asked, or it's a poorly designed onboarding flow. What they typically want is for you to set up a subdomain with its own MX records. So not your root domain, not example dot com, but something like mail dot example dot com or send dot example dot com. That subdomain handles the outbound marketing mail, while your root domain continues to handle your regular Gmail through Google's MX records. They never touch each other.
That's the key distinction then. Subdomain versus root domain. The horror scenario of someone overwriting their Google MX records with some random email vendor's records is, what, all your inbound mail just vanishes?
No bounce-back, no error message. The sending server thinks it delivered successfully because it handed the mail off to whatever server the MX record pointed to. That server just has no idea what to do with it. Meanwhile, you're wondering why nobody's emailed you in three days.
The email equivalent of forwarding your mail to a vacant lot.
And here's the thing, the major reputable services, Resend, SendGrid, Mailgun, Postmark, they all explicitly tell you to use a subdomain. Resend's own documentation says, and I'm quoting roughly here, "Add your domain and verify it by adding the DNS records we provide." Those records are always TXT records for verification, and then CNAME records for DKIM signing. No MX records anywhere near your root domain.
Let's unpack what's actually happening under the hood when you send email through one of these services, because I think understanding the mechanism makes the DNS setup feel less like ritual incantation and more like a rational thing you're doing.
There are three authentication mechanisms that matter for deliverability. SPF, DKIM, and DMARC. SPF says which servers are allowed to send mail from your domain. DKIM cryptographically signs your emails so receiving servers can verify they haven't been tampered with. DMARC tells receiving servers what to do if SPF or DKIM checks fail, and it also provides reporting so you can see who's sending mail claiming to be from your domain.
Google Workspace already has you set up SPF. The standard setup includes adding Google's servers to your SPF record.
Yes, the Google Workspace SPF record includes spf dot google dot com. And here's where the first potential problem comes in. You can only have one SPF record per domain. Just one TXT record that starts with v equals spf one. If you try to add a second one, things break unpredictably. So when you add an email sending service, you don't create a new SPF record. You modify the existing one to include the new service's servers.
That's the kind of detail that's easy to miss if you're just following a wizard and clicking "add record.
Most of the good services handle this by not asking you to modify SPF at all. Instead, they have you set up DKIM on a subdomain, which avoids the SPF collision entirely. The subdomain gets its own SPF record, its own DKIM signing, and your root domain's email routing remains completely untouched.
The subdomain approach isn't just about avoiding MX record conflicts, it's about creating a clean separation so that the reputation of your marketing emails doesn't drag down your regular business email.
That's the other half of this, and honestly, it might be the more important half. Email reputation is tracked at the domain level. If you send marketing emails from your root domain and a bunch of people mark them as spam, that affects deliverability for everything from that domain, including your one-on-one business emails. I've seen situations where someone's important client email went to spam because their marketing team sent a poorly targeted blast three days earlier.
Even if you technically could make it work from the root domain, you shouldn't.
You absolutely should not. And this is where the prompt's instinct is right on the money. The question asks about avoiding deliverability issues and spam triggers, and the single most impactful thing you can do is use a dedicated subdomain for any bulk or automated sending. It quarantines the reputation risk.
Let's get concrete. Someone's using Google Workspace, they want to start sending transactional emails through Resend. Walk me through the exact DNS records they need.
Step one, pick a subdomain. Common choices are mail dot yourdomain dot com, mg dot yourdomain dot com, or send dot yourdomain dot com. Resend's documentation recommends mail dot yourdomain dot com, but the specific name doesn't matter as long as it's consistent.
This subdomain, they don't need to set up a website there or anything?
No, it exists purely for email authentication. Step two, in Resend, you add this subdomain as a domain in their dashboard. Resend then generates a set of DNS records for you to add. Typically, three TXT records for verification and DKIM, and one CNAME record for tracking. No MX records.
Three TXT records. That's the kind of thing where someone who's added records for a few services might start to feel like they're accumulating clutter.
That clutter is real, and the prompt mentions it specifically. The verification records pile up. But here's the thing, those TXT verification records, the ones that say things like google site verification or mailchimp verification, those are purely for proving you own the domain. Once the service verifies you, you can technically delete them and nothing breaks. Most people don't know that.
You can delete the verification record after verification succeeds?
For most services, yes. The verification is a one-time check. They don't continuously re-verify. There are exceptions, some services periodically re-check, but for the majority of these marketing tools and email senders, that TXT record is a vestigial organ the moment verification completes.
That's going to save some people a lot of scrolling through their DNS dashboard.
Do not delete the DKIM records. Those are checked on every single email. Every receiving mail server looks up that DKIM TXT record to verify the cryptographic signature. Delete that and your emails start failing authentication.
Verification TXT records, disposable. DKIM TXT records, permanent infrastructure.
And the CNAME record for link tracking is also important if you want click tracking to work properly. It allows the sending service to rewrite links in your emails under your own domain instead of their domain, which looks more professional and improves deliverability.
The prompt mentions that "sent on behalf of" thing that sometimes shows up in Gmail. That's what the CNAME tracking record prevents?
The "sent on behalf of" or "via" label in Gmail appears when the email is sent through a server that doesn't align with the From address domain. If you authenticate properly with DKIM and SPF, and the From address matches the authenticated domain, that label goes away. The subdomain setup handles this because you're sending from your subdomain with proper authentication.
The recipient sees the email coming from, say, notifications at mail dot yourdomain dot com, and it looks clean. No "via resend dot com" or whatever.
And you can even set up the From address to be your root domain if you want, like hello at yourdomain dot com, but the actual sending happens through the subdomain. The authentication still passes because DKIM signs with the subdomain that you've authorized. There's a whole specification around this called DMARC alignment.
Let's talk about that alignment, because I think that's where a lot of the spoofing warnings the prompt mentions actually come from.
DMARC alignment has two modes, relaxed and strict. In relaxed mode, which is what most people use, the domain in the From address and the domain used for SPF or DKIM authentication just need to share the same organizational domain. So mail dot yourdomain dot com and yourdomain dot com are considered aligned. In strict mode, they have to match exactly. Almost nobody uses strict mode for exactly this reason, it breaks legitimate subdomain sending.
Even with a subdomain setup, DMARC is satisfied because mail dot yourdomain dot com and yourdomain dot com share the same root domain.
And this is why the subdomain approach is so elegant. You get full authentication, DMARC passes, and your root domain's email continues to work exactly as before.
What about the scenario where someone's already got a bunch of these verification records, maybe from trying out different tools, and they're not sure which ones are still needed?
This is the DNS spring cleaning problem. My recommendation is to document what you have. Go through your DNS records, make a list, and for each one, ask yourself, do I still use this service? If the answer is no, and the record is a verification TXT record, it's safe to delete. If it's a DKIM record for a service you still use, keep it. If it's a DKIM record for a service you stopped using, you can delete it, but double-check that you're not still sending mail through that service.
If you're not sure?
A few extra DNS records don't hurt anything. The only real cost is clutter. But if you delete a DKIM record for a service that's still sending mail, you'll start seeing authentication failures, and that will hurt deliverability.
The risk-reward on deletion is asymmetric. Deleting an unused verification record has basically zero upside beyond tidiness. Deleting an active DKIM record has significant downside.
That's the right way to think about it. Now, let me address the MX record anxiety directly, because I think this is the heart of the question. Under what circumstances would a legitimate email sending service ask you to add an MX record?
Because the prompt says sometimes they do, and that's where the nervousness comes from.
There are a couple of scenarios. One is inbound email processing. Services that receive email on your behalf, like ticketing systems, help desks, or email forwarding services, those legitimately need MX records because they're handling inbound mail. But those aren't sending services, they're receiving services. If you're using something like Zendesk or Front, they need MX records because emails from your customers need to reach their servers.
That makes sense. Inbound processing needs MX. Outbound sending doesn't.
The other scenario is when a service wants you to set up a dedicated subdomain for sending, and that subdomain needs its own MX records for bounce handling. When an email bounces, the bounce message goes back to the return path address, which is typically at the sending subdomain. If that subdomain doesn't have MX records, the bounce message has nowhere to go, and the sending service can't track bounces properly.
The MX record they're asking for goes on the subdomain, not the root domain.
And this is where people get confused because the service might say "add this MX record" without clearly specifying that it goes on the subdomain, not your main domain. The interface might just say "add to your DNS" and if you're not paying attention, you add it to the wrong place.
The DNS equivalent of "careful which directory you're in when you run that command.
And the consequences of adding an MX record to your root domain that points to a service that isn't your email provider are, as we said, silent and catastrophic.
Let's talk about the specific services the prompt mentioned. Resend, MailZero, Mailchimp. Are there any gotchas with those in particular?
Resend is actually one of the cleaner setups. Their domain verification process is straightforward. You add your domain, they give you TXT records for DKIM and verification, and a CNAME for tracking. They explicitly recommend using a subdomain. Their documentation is clear about this. No MX records needed for sending.
Mailchimp's setup has evolved over the years. They now strongly recommend, and in some cases require, domain authentication. They use CNAME records for DKIM signing, and they have you verify your domain with TXT records. They also have an option to set up a dedicated sending domain. Again, no MX records for outbound sending.
The prompt mentioned MailZero, which is interesting because it operates in the cold email space, and that's a whole different deliverability landscape.
Cold email deliverability is a completely different beast. The authentication requirements are actually stricter because cold email is inherently closer to spam in the eyes of receiving servers. You're sending to people who don't know you and haven't opted in. The major inbox providers are actively looking for reasons to filter cold email. Proper SPF, DKIM, and DMARC setup is table stakes. You also need to worry about things like custom tracking domains, warm-up periods, and sending volume limits.
Warm-up periods. This is where a new sending domain needs to gradually ramp up volume so it builds reputation rather than looking like a spam operation that just spun up yesterday.
If you set up a brand new subdomain and immediately start sending thousands of emails, that's a strong spam signal. The major providers, Google and Microsoft especially, they're watching for that pattern. A proper warm-up might take four to six weeks, starting with maybe twenty emails a day and gradually increasing.
Someone who's just trying out a tool and sends a test blast to a few hundred recipients from a fresh subdomain might accidentally tank their reputation before they even get started.
Yes, and that's another reason the subdomain approach is valuable. If you tank the reputation of mail dot yourdomain dot com, your regular email at yourdomain dot com is unaffected. You can abandon that subdomain, set up a new one, and try again with a proper warm-up.
That's actually a really practical point. The subdomain isn't just about keeping things clean, it's about creating a blast radius that doesn't take out your primary communication channel.
Blast radius is exactly the right metaphor. In engineering, you isolate failure domains. Same principle applies here.
What about the scenario where someone's using Google Workspace and wants to send transactional emails, but they're not doing marketing. Just the standard "password reset" and "welcome to the app" kind of emails. Is there a simpler approach?
Google Workspace has SMTP relay settings that allow you to send through Google's servers directly. You can configure your application to use smtp dot gmail dot com with your Workspace credentials. But there are sending limits. For Google Workspace, it's typically two thousand messages per day for the SMTP relay service. If you're under that volume, you can skip the third-party service entirely and just send through Google.
Two thousand messages a day. That covers most small applications.
For transactional email, absolutely. A typical SaaS app with a few thousand users might send a few hundred transactional emails a day. Password resets, welcome emails, notification digests. That's well within Google's limits. And the advantage is you don't need any additional DNS setup. Your existing Google Workspace configuration handles everything.
The decision point is really about volume and features. If you're under two thousand a day and don't need fancy templates or analytics, just use Google's SMTP. If you need more volume or better analytics, bring in a dedicated service and set up the subdomain.
If you're doing marketing emails, even at low volume, use a dedicated service on a subdomain. The reputation isolation alone is worth it. Never send marketing emails through the same infrastructure as your transactional or personal email.
Why is that distinction so important? An email is an email, right?
Transactional emails have extremely high engagement rates. People open password reset emails. They click welcome emails. Receiving servers see that engagement and it boosts your domain reputation. Marketing emails have much lower engagement. People delete them without opening, they unsubscribe, they mark them as spam. That drags reputation down. If you mix them, the marketing emails drag down the deliverability of your transactional emails, and suddenly your password reset emails are landing in spam folders.
That's a nightmare scenario. User can't log in because the reset email went to spam, and they blame your app.
They'll never tell you. They'll just assume your app is broken and move on. I've consulted for companies where this exact thing was happening, and it took weeks to diagnose because nobody thinks to check whether transactional emails are being delivered. They assume those always work.
Let's circle back to DNS record management for a moment. The prompt mentions that most people aren't checking their DNS records regularly, and that leads to clutter. Is there a best practice for keeping things organized?
A few things. First, use a DNS provider that has a decent interface. Cloudflare, for example, makes it easy to see all your records and add notes to them. Second, when you add a record for a service, add a comment or use a naming convention that makes it obvious what it's for. A TXT record with a value of some random string is meaningless six months later. If you can add a note that says "Mailchimp DKIM key" you'll thank yourself later.
Third, periodic audits.
Once or twice a year, go through and look for records associated with services you no longer use. It's not urgent, but it prevents the kind of accumulated cruft that makes DNS management feel overwhelming.
The prompt also mentions MCP servers in the context of Resend's API. That's the Model Context Protocol, which lets AI agents interact with services. Is there any DNS implication there?
The MCP server integration is about letting an AI agent send emails through Resend's API. The DNS setup is the same regardless of whether a human or an AI is triggering the send. The authentication still happens at the domain level.
The agent sends through the API, the API sends through the authenticated subdomain, and the receiving server sees a properly authenticated email. The agent is just another client as far as the email infrastructure is concerned.
And this is actually a good use case for the subdomain approach because AI agents might be sending at unpredictable volumes, and you want that traffic isolated from your main domain.
Let's address the verification clutter problem directly. Someone's tried out five different email marketing tools over the years. Their DNS has TXT records from Mailchimp, SendGrid, Mailgun, Constant Contact, and some tool they don't even remember signing up for. What's the actual risk of leaving all of those in place?
Functionally, almost zero risk. TXT records are just text strings. They don't affect routing, they don't affect performance, they don't affect anything unless a service is specifically looking for them. The only real downside is that if you ever need to find a specific record, you have to wade through the clutter.
There's no security risk? A verification record for a defunct service can't be exploited?
The verification record itself, no. It's just a token that proves you control the domain. The risk, and this is a small one, is that if the service still has your domain registered in their system and their system gets compromised, an attacker could potentially use the existing verification to send mail that appears authenticated. But this is a highly theoretical risk. In practice, if you're not paying for the service anymore, your account is probably deactivated.
The practical advice is, don't lose sleep over verification record clutter. Focus on making sure your active DKIM and SPF records are correct.
Your MX records are pointing where they should be. That's the one you really don't want to get wrong.
What about DMARC? The prompt mentions putting it in the bucket of advanced tools. Is it still advanced, or has it become table stakes?
In two thousand twenty-six, DMARC is table stakes for any domain that sends email. Google and Yahoo started requiring it for bulk senders back in early two thousand twenty-four, and the requirements have only tightened since then. If you're sending more than five thousand emails a day, you need DMARC. But honestly, even if you're sending less, you should have it. It protects your domain from being spoofed.
Setting it up is basically one TXT record.
Start with a policy of "none," which means monitor but don't reject. That gives you reporting so you can see who's sending email from your domain. Once you're confident your legitimate senders are all authenticated, you can move to "quarantine" or "reject." The whole process is well-documented and the record itself is one line.
The prompt's author mentioned feeling more confident about tech topics after these episodes, and I think DNS is one of those areas where a little bit of understanding goes a long way. It's not that complicated once you understand the basic model.
DNS is deceptively simple. It's a distributed key-value store. The complexity comes from the fact that small mistakes have big consequences, and the feedback loop is slow. You change a record, and it might take hours to propagate. If you get it wrong, you might not know for days.
Email sits on top of DNS, adding its own layer of complexity. But the core principles we've covered, separate your sending domains, understand which records are structural and which are decorative, don't touch your MX records unless you know exactly what you're doing. That covers most of what can go wrong.
I'd add one more. Test your setup. There are free tools like MXToolbox and Mail Tester that will analyze your email configuration and tell you if anything's misconfigured. Send a test email to one of these services and they'll give you a detailed report on SPF, DKIM, DMARC, and your overall deliverability score.
That's the kind of thing you do once when you set everything up and then maybe check quarterly.
Or whenever you add a new sending service. It takes five minutes and it catches configuration errors before they affect real email.
Let's talk about a specific failure mode that I think is worth flagging. The prompt mentions using Google Workspace, and Google Workspace has its own DKIM setup in the admin console. If you're also setting up DKIM through a third-party service on a subdomain, those don't conflict because they're on different domains, right?
Google Workspace DKIM signs emails sent through Gmail from your root domain. Resend or Mailchimp DKIM signs emails sent through their service from your subdomain. They operate independently. The receiving server checks the DKIM signature against the domain that signed it. If the email claims to be from mail dot yourdomain dot com, the server looks up the DKIM record for mail dot yourdomain dot com. It doesn't care about the DKIM record for yourdomain dot com.
The separation is clean.
And this is why the subdomain approach is so widely recommended. It eliminates entire categories of potential conflict.
What about the scenario where someone wants to send from their root domain through a third-party service? Like, they want the From address to be theirname at theirdomain dot com, but they want to use Resend for the actual delivery. Is that possible without the subdomain?
It's possible but not recommended. You'd need to include Resend's sending servers in your root domain's SPF record, and you'd need to set up DKIM signing for your root domain through Resend. That means adding Resend's DKIM keys to your root domain's DNS. It works technically, but now your marketing email reputation affects your regular email, and you've created a configuration where multiple services have DKIM keys for the same domain, which is harder to manage.
Harder to troubleshoot when something goes wrong.
When an email fails authentication, you have to figure out which service's DKIM configuration is the problem. With subdomains, the failure is isolated to the subdomain that's misconfigured.
The subdomain approach isn't just best practice, it's self-defense against future headaches.
It's the email equivalent of not putting all your services on one server.
One last thing I want to touch on. The prompt mentions the startup tutorial for Google Workspace being basically "add these MX records and you're done." That's been the standard advice for years, and it works for basic email. But the ecosystem has evolved. Now you've got DMARC requirements, DKIM signing, subdomain sending, all these things that the basic tutorial never covered. Is there a point where Google Workspace's documentation should be updated?
Google has actually updated their documentation quite a bit. They now have detailed guides on DMARC, DKIM, and email authentication. The problem is that the initial setup wizard is still designed to get you up and running as quickly as possible, which means it skips all of that. You get basic email working, and then you're on your own for everything else.
Which is fine if you're just doing regular business email. But the moment you start doing anything beyond that, you need the advanced stuff.
That's the gap this conversation is trying to fill. The space between "I have email working" and "I'm sending marketing emails that actually land in inboxes.
To summarize the concrete advice for someone in this situation. One, use a dedicated subdomain for any bulk or automated sending. Two, never add MX records to your root domain unless you're changing email providers. Three, verification TXT records are disposable after verification succeeds, DKIM records are not. Four, test your configuration with a tool like MXToolbox after making changes. Five, implement DMARC starting with a none policy and work your way up.
Six, if you're under two thousand transactional emails a day, consider just using Google's SMTP relay and skip the third-party service entirely. It's simpler and there's less to go wrong.
Seven, document your DNS records. Future you will appreciate it.
Eight, the subdomain also serves as a reputation blast radius. If your marketing emails get marked as spam, your regular email is unaffected.
That's a solid checklist. And I think the underlying principle is that email deliverability isn't magic. It's a set of protocols that work in predictable ways. Once you understand the separation between inbound routing, which is MX records, and outbound authentication, which is SPF, DKIM, and DMARC, the whole thing becomes much less intimidating.
The anxiety the prompt describes, that feeling of "am I about to break something," that's completely rational. DNS is one of those systems where the feedback is delayed and the consequences of mistakes are invisible. But with the subdomain approach, you're not touching anything that affects your primary email. The worst case scenario is that your marketing emails don't get delivered, which is a problem you'll notice and can fix.
As opposed to the worst case scenario of messing with your MX records, which is that your inbound email silently disappears and you don't notice until a client asks why you haven't responded to their email from last Tuesday.
That is a phone call nobody wants to have.
And now: Hilbert's daily fun fact.
Hilbert: In the eighteen-tens, the British Royal Navy named a remote atoll in what is now Tuvalu "Ellice's Island" after a merchant who never set foot there, which is why the entire island nation was called the Ellice Islands until independence in nineteen seventy-eight.
A nation named after a guy who never visited. That's on brand for the British Empire, really.
Remote marketing before it was cool.
This has been My Weird Prompts. If you enjoyed this episode, leave us a review wherever you get your podcasts, it genuinely helps more people find the show. We're back next week with another prompt.
