How to identify TXT record conflicts?

You've just signed up with a new email tool, it asks you to add a TXT record to your DNS, and suddenly your SPF stops working. Sound familiar? TXT record conflicts are one of the most common (and quietly damaging) DNS mistakes senders make. The good news is they're not hard to spot once you know what you're looking for.

Step 1: Pull all your TXT records

Start by querying everything that lives at your domain's root. Open your terminal and run this command, swapping in your actual domain:

dig TXT yourdomain.com

If you don't have access to a terminal, you can use an online DNS lookup tool instead. Either way, you're looking for the full list of TXT records sitting at your domain root.

Also check the subdomain where your DMARC record lives:

dig TXT _dmarc.yourdomain.com

Step 2: Scan for the warning signs

Here's what a conflict actually looks like in practice:

• Two (or more) SPF records. You'll spot this if you see more than one line starting with v=spf1. This is a hard problem. SPF only allows one record per domain. Having two will cause a permerror, which means receiving servers may reject or flag your email entirely.
• Two DMARC records at _dmarc. Same rule applies. One record, one location. If you see two v=DMARC1 entries, that's a conflict.
• Duplicate verification strings. Tools like Google Workspace or old services drop verification TXT records when you connect them. If you've switched platforms, those old strings stick around. They won't break things directly, but they add noise and can confuse audits.
• Syntax errors inside a single record. These aren't conflicts in the traditional sense, but they cause the same symptoms. Look for duplicate mechanisms (like include: appearing twice for the same sender) or mechanisms that contradict each other.

Step 3: Understand how these get created

Still most conflicts don't happen from one person making a mistake. They happen over time, across multiple people, and across multiple tools. The most common causes are adding a new SPF record instead of editing the existing one, having multiple team members manage DNS without communicating, and leaving behind records from old services you've stopped using. (That last one is surprisingly common. It's worth checking for records tied to any ESP or tool you've moved away from.)

Step 4: Fix what you find

For SPF, merge everything into a single record. If you have two records like these:

v=spf1 include:mailchimp.com ~all
v=spf1 include:sendgrid.net ~all

Combine them into one:

v=spf1 include:mailchimp.com include:sendgrid.net ~all

For DMARC, delete the duplicate and keep the most complete, current version. For old verification strings, delete anything tied to a service you no longer use.

But once you've made changes, re-run your dig command to confirm only one SPF record and one DMARC record remain. DNS propagation can take up to 48 hours, so give it a bit before testing delivery again.

One more thing worth doing

After cleaning up, document which TXT record belongs to which service. It sounds tedious, but it saves you from repeating this whole exercise in six months when someone adds another tool. A simple shared note with the record value and the service name is enough.

Want a faster way to spot these issues? Our free SPF checker will flag duplicate records and syntax problems in seconds. If things feel more broken than a quick fix can handle, the SOS hotline is free and we'll help you sort it out.