5 DNS Mistakes That Are Silently Killing Your Email Campaigns

5 DNS Mistakes That Are Silently Killing Your Email Campaigns

The Scenario Nobody Expects

You just sent a 50,000-email campaign. Your content is solid. Your list is clean. Your email platform reports that 49,800 messages were successfully delivered.

Open rate: 3%.

Before you rewrite the subject line or audit the list, consider this: delivered does not mean inbox. Your email platform tracks whether it handed the message off to the receiving mail server. What happens next — whether the message lands in the inbox, the spam folder, or gets rejected outright — is determined by something your email platform does not control.

It is determined by your DNS.

Two Different Problems, Managed by Two Different Teams

There is a critical distinction that most organizations miss: your email platform manages delivery, but your DNS tells receiving mail servers whether to trust what your email platform sends.

Email platforms like Mailchimp, HubSpot, SendGrid, and Salesforce Marketing Cloud are excellent at what they do. They report on opens, clicks, bounces, and unsubscribes. What they cannot report on is whether your DNS authentication records are correctly configured — because that is not their responsibility. It’s yours.

When deliverability problems are caused by DNS misconfiguration, the email platform has no way to surface it. Marketing blames the content. IT blames the list quality. Nobody checks the DNS. Meanwhile, the next campaign goes out with the same broken configuration.

The Email Authentication Stack: SPF, DKIM, and DMARC

Three DNS records control whether your email is trusted by receiving mail servers:

All three live in DNS as TXT records. This means a routine DNS change made by your IT team — for reasons completely unrelated to email — can silently break your email authentication and send your next campaign to spam.

Here are the five mistakes that cause it most often.

Mistake 1: Multiple SPF Records

RFC 7208, the standard that defines SPF, is unambiguous: a domain must have exactly one SPF record. If a receiving mail server finds two SPF records for your domain, it returns a permerror result, which DMARC treats as a hard authentication failure. Your email goes to spam or gets rejected entirely — for every sending service, not just one.

How it happens: IT adds an SPF record for Google Workspace. A few months later, marketing sets up Mailchimp and follows the onboarding instructions, which say to add an SPF record. Now there are two.

Wrong — two separate records:

example.com  TXT  "v=spf1 include:_spf.google.com ~all"
example.com  TXT  "v=spf1 include:servers.mcsv.net ~all"

Right — one combined record:

example.com  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

All authorized senders must be listed in a single SPF record. The fix is straightforward once you know the problem exists — but if nobody is monitoring DNS for unexpected additions, the second record can sit there silently failing authentication for months.

Mistake 2: Exceeding the SPF 10-Lookup Limit

Every include: directive in an SPF record triggers a DNS lookup when a receiving mail server evaluates it. The SPF specification caps this at 10 lookups. Exceed the limit and SPF returns permerror — the same hard failure as having two records — with no warning and no error message visible to your marketing team.

How it creeps up: Organizations rarely add six sending services at once. They add them one at a time, over months or years, as the marketing stack grows.

The example above is exactly at the limit. Add one more service — a new transactional email provider, a customer support platform, anything that requires an SPF include: — and SPF silently breaks for every sender on the list.

Fixes: Remove include: entries for services you no longer use. Consider using subdomains for different senders (e.g., marketing.example.com for campaign email, keeping the root domain’s lookup count manageable). SPF flattening — replacing include: references with their resolved ip4: addresses — is another option, though it requires maintenance as providers change their IP ranges.

Mistake 3: DKIM Key Rotation Without a Transition Window

DKIM works by having your mail server sign outgoing messages with a private key. Receiving mail servers look up the corresponding public key in your DNS and use it to verify the signature. If the public key in DNS does not match the private key used to sign the message, DKIM verification fails.

Rotating DKIM keys is good security practice. But if the old key is removed from DNS too quickly — before DNS caches across the internet have expired — any message signed with the new private key will fail verification against the still-cached old public key.

How it happens: IT rotates the DKIM key, publishes the new public key in DNS, and removes the old one. Caches across the internet still hold the old key for hours or days. Marketing’s next campaign is signed with the new private key, but receivers are checking it against the old public key. Every message fails DKIM. Neither team connects the cause to the effect.

The correct rotation approach:

1. Publish the new public key under an inactive DKIM selector
2. Run dual-signing for 3 to 7 days — signing each outgoing message with both keys
3. Switch the active selector to the new key
4. Remove the old key only after confirming successful delivery

Skipping the overlap window is the most common mistake. The 3 to 7 day window accounts for DNS TTL expiration across resolvers worldwide. Without it, there will always be a window where verification fails.

Mistake 4: No DMARC Record — or p=none Forever

DMARC is the record that ties SPF and DKIM together and gives domain owners control over what happens when authentication fails. Many domains have no DMARC record at all. Many others added a p=none policy years ago and never moved past it.

Without DMARC, receiving mail servers make their own decisions about what to do with authentication failures. The results are inconsistent across Gmail, Outlook, Yahoo, and other providers, and there is no reporting to help you understand what is happening.

With p=none, DMARC generates aggregate reports but takes no enforcement action. p=none is the right starting point — it lets you collect data without affecting delivery while you work through your authentication configuration. The problem is that p=none is also where most domains stop, leaving them with no protection against spoofing and no enforcement of their own authentication policy.

The rollout path:

p=none → p=quarantine → p=reject

Start with p=none, analyze the aggregate reports, identify and fix all legitimate senders that are failing authentication, then advance to quarantine (failures go to spam) and eventually reject (failures are blocked).

It is worth noting that Google and Yahoo began requiring DMARC records for bulk senders in February 2024. If you send more than 5,000 emails per day to Gmail or Yahoo addresses and do not have a DMARC record, your messages are likely already being treated with elevated suspicion.

Mistake 5: DMARC Alignment Mismatch

This is the most confusing email authentication failure, and the most common source of “but SPF and DKIM both pass — why is DMARC failing?” questions.

The answer is alignment. DMARC does not just require that SPF and DKIM pass. It requires that the domain authenticated by SPF or DKIM matches the domain in the From: header that the recipient sees in their mail client.

Example: Your From: header says newsletter@example.com. Your campaign is sent through Mailchimp, which sends from its own infrastructure. SPF passes — but for bounces.mailservice.com, not example.com. DKIM passes — but signed by mailservice.com, not example.com. Neither authenticated domain matches the From: domain. DMARC fails, despite both SPF and DKIM passing individually.

The fix: Configure custom DKIM signing for each third-party sending service. This means adding a DKIM TXT record to your DNS that allows Mailchimp (or SendGrid, or HubSpot, or whichever platform you use) to sign messages with d=example.com instead of their own domain. Every major email platform supports this, but it requires a deliberate setup step that is easy to skip during onboarding.

Why These Problems Persist: The Organizational Gap

These five mistakes are preventable. They persist because of a structural problem in how organizations manage email.

Marketing owns the campaigns. IT owns the DNS. The two teams operate in separate tools with no shared visibility. When deliverability drops, marketing optimizes subject lines. IT logs a ticket about an unrelated SPF update. Nobody asks whether the two events might be connected.

The table below illustrates the gap:

The DNS configuration that your email depends on is managed by a completely different team, in a completely different tool, with no connection to your email platform and no automatic notification when something changes.

Before Your Next Campaign: A DNS Checklist

Run through these before your next send:

• Do you have exactly one SPF record? (not zero, not two)
• Is your SPF record under 10 DNS lookups?
• Is DKIM configured with custom signing for each sending service?
• Is your DMARC policy set to quarantine or reject? (not p=none indefinitely)
• Do your third-party senders pass DMARC alignment?
• Does anyone on your team get notified when DNS records change?
• (If sending from your own mail server or a dedicated IP): Does that IP have a PTR record that resolves back to your sending hostname?

If the answer to any of those is “I don’t know,” the problem may not be the campaign. It may be the DNS configuration the campaign depends on.

Quick checks you can run today: MXToolbox Domain Health will run hundreds of DNS and email authentication tests against your domain and flag anything misconfigured — SPF, DKIM, DMARC, blacklisting, and more. It is free for on-demand use. Mail-Tester lets you send a test message to a unique address and receive a spam score based on your message content, sending IP reputation, and authentication results. Both are useful for checking whether your configuration is correct right now. What they cannot show you is covered in the next section.

Catching DNS Changes Before They Break a Campaign

The underlying challenge with all five of these mistakes is visibility. SPF records grow silently. DKIM keys get rotated without notifying marketing. DMARC policies never advance because nobody tracks them. Second SPF records appear because two teams are both following correct onboarding instructions independently.

ResorsIT DNS/IP Management gives you version history, change detection, and compare reports for every DNS record across every domain you manage. When a second SPF record appears, you see it. When a DKIM key is rotated, you see what the previous value was and can restore it in seconds if something breaks. When a DMARC record has been at p=none for two years, that is visible too.

Email deliverability problems that are caused by DNS are not fundamentally hard to fix. They are hard to find. Knowing what changed, and when, is the difference between a 20-minute resolution and a 3-day investigation.

Explore the ResorsIT DNS/IP SaaS or take a look at the product tour to see the audit log and compare report in action.