The duplicate DNS mistake that silently bin-bags your outbound emails

During a weekend security audit of our sending domains with Zuri, I noticed something odd in our TXT records that looked entirely harmless at first glance.

We had two separate, perfectly valid SPF records sitting on the same root domain.

Both started with v=spf1. One was set up years ago for Zoho Mail; the other was added later for Brevo marketing sends. Each record worked fine on its own. But together, they had spent months quietly tanking our email deliverability, sending transactional alerts straight into spam without throwing a single bounce error. Here is why this happens and how to fix it in five minutes.

# Combine all 'include:' values inside one record
v=spf1 include:zoho.com include:sender.zohobooks.com include:spf.sendinblue.com include:zcsend.net mx ~all

Why two correct records make a permanent error

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which servers are authorised to send email on behalf of your domain. When someone receives an email from you, their server looks up your SPF record and checks whether the sending server is on the list. If it is, good. If not, the email fails SPF.

RFC 7208, the specification that governs SPF, is explicit: a domain must not have more than one SPF record.

If you have two, receiving mail servers do not try to merge them or pick the “better” one. They return a result called permerror. Not a fail, or a soft fail, but a permanent error.

Having two separate SPF records on the same domain is like giving your estate gate-men two completely different, conflicting lists of authorised visitors. Instead of trying to combine the lists or call you to clarify, the security guards get confused, lock the gates, and refuse to let anyone through. In the email world, this confusion triggers a permerror. The receiving server stops evaluating your SPF, and if your DMARC is set up, your email is silently tossed into the spam bin. No bounce. No error message. No notification. The email goes to spam or disappears, and you have no idea.

How does this slip into production?

Usually, it happens through accumulation.

Someone sets up Zoho Mail and adds an SPF record. A year later, someone else sets up Brevo (Sendinblue) for marketing emails and adds another one. Neither person knew the first record existed.

The domain slips into a broken state that no one notices because delivery mostly still works. Email delivery is messy enough that messages often get through anyway, which hides the problem.

In this case, the records were:

v=spf1 include:zcsend.net ~all
v=spf1 include:zoho.com include:sender.zohobooks.com include:spf.sendinblue.com mx ~all

Two separate senders. Two separate records. Neither wrong on its own. Together, broken.

The fix is simple: delete both and create one merged record.

v=spf1 include:zoho.com include:sender.zohobooks.com include:spf.sendinblue.com include:zcsend.net mx ~all

One record. All senders included. ~all to softfail anything that does not match.

Five minutes to fix. Potentially years of silent degraded deliverability before it gets caught.

Check yours. Run:

dig +short TXT yourdomain.com | grep spf

If that returns more than one line, you have a problem.

Then while you are there, check your DMARC:

dig +short TXT _dmarc.yourdomain.com

If p=none, your DMARC exists but is not enforcing anything. p=none is monitoring mode: it collects reports but does not block or quarantine mail. The goal is to move to p=quarantine, then p=reject.

Most domains I look at have either no DMARC, a p=none that was set up and forgotten, or the duplicate SPF issue above. All three are fixable in under an hour, but none of them announce themselves.