Common DNS Configuration Errors That Break Email Delivery

DNS Is Where Most Email Problems Start

When email breaks, the root cause is usually found in DNS. The entire connection between a domain name and its email infrastructure — where to deliver incoming mail, who is authorised to send outgoing mail, how to verify message signatures — lives in DNS records. A missing record, a typo in a value, or a misconfigured TTL can produce anything from intermittent delivery failures to complete non-delivery, often with error messages that obscure the actual cause.

Most DNS email configuration errors follow recognisable patterns. Once you know what to look for, they're typically straightforward to find and fix — the problem is that many senders don't know what to look for until something breaks.

Missing or Broken MX Records

The MX (Mail Exchange) record tells sending servers where to deliver mail for your domain. If there's no MX record, or if the MX record points to a hostname that doesn't resolve, inbound email will fail — often silently from the sender's side, with no obvious error until someone complains that their message never arrived.

Common MX mistakes:

• MX record points to an IP address instead of a hostname — MX values must be hostnames, never IPs
• The MX hostname exists but has no A or AAAA record backing it
• MX record was deleted during a domain transfer or DNS migration and never recreated
• Multiple MX records with identical priority, creating unpredictable delivery routing

Verify your MX records with:

dig MX yourdomain.com

Then confirm the hostname resolves:

dig A mail.yourdomain.com

If you're considering a secondary MX for redundancy, the backup MX guide explains priority configuration and whether a secondary is actually necessary for your situation.

SPF Record Errors

SPF records specify which mail servers are authorised to send email from your domain. SPF misconfiguration is extremely common and produces alignment failures that cause messages to land in spam or be rejected.

Common SPF mistakes:

• Multiple SPF records: A domain must have exactly one SPF TXT record. If two or more records starting with v=spf1 exist, SPF evaluation fails with a PermError — every time, for every message. Inbox providers do not pick one; they return fail.
• Exceeding the 10-lookup limit: SPF mechanisms like include: trigger additional DNS lookups during evaluation. More than 10 lookups causes a PermError. If you're using several third-party senders, you may be over the limit without knowing it. Use an SPF flattening tool to consolidate.
• Missing sending sources: If a third-party service — your CRM, newsletter tool, support platform — sends email on your behalf and isn't listed in your SPF record, those sends fail SPF.
• Using +all: The +all mechanism authorises any server on the internet to send as your domain. This makes SPF meaningless as an anti-spoofing control. Use ~all (softfail) or -all (hardfail).

The SPF setup guide covers the full syntax and how to structure a record that handles multiple sending sources without exceeding the lookup limit.

DKIM Configuration Problems

DKIM signs outgoing messages with a private key stored on your mail server. The matching public key is published in DNS. If the DNS record is wrong, the signature can't be verified and messages fail DKIM — which affects both direct authentication and DMARC alignment.

Common DKIM DNS mistakes:

• Wrong record type: DKIM public keys must be TXT records. Some DNS providers create CNAME records when a key is very long — this can work if the CNAME delegation is intentional (pointing to your email provider's infrastructure), but breaks if the CNAME target changes.
• Truncated key value: 2048-bit DKIM keys are long. Many DNS providers have character limits on TXT record values. Long keys must be split across multiple quoted strings within the same record. An incorrectly split key won't validate.
• Selector mismatch: The DKIM selector in the email's DKIM-Signature header must exactly match the DNS subdomain where the public key is published. A selector of s1 looks for the key at s1._domainkey.yourdomain.com. If the DNS record uses a different name, DKIM fails.
• Old selectors left in DNS: After rotating DKIM keys, the old selector record often stays in DNS indefinitely. It doesn't cause failures, but removing outdated selectors is good hygiene.

The DKIM explainer covers how signing and verification work end to end, which makes these failure modes easier to diagnose.

DMARC Record Problems

DMARC builds on SPF and DKIM, so errors in either of those propagate into DMARC failures. Beyond that, common DMARC DNS-specific errors include:

• Record published at the wrong location — DMARC must be at _dmarc.yourdomain.com, not yourdomain.com itself
• Syntax errors: missing semicolons between tag-value pairs, misspelled policy values (quarentine instead of quarantine)
• Reporting addresses (rua=, ruf=) that don't exist or aren't configured to accept DMARC reports
• Subdomain policy (sp=) inadvertently set permissively while the root domain is at enforcement

TTL Values That Extend Outages

DNS TTL values control how long records are cached by resolvers. Getting TTL wrong doesn't break email immediately, but it extends outages when records need to change — if your MX TTL is 86400 seconds (24 hours) and you need to update it urgently, the old value continues to be served for up to a day.

Before any planned DNS change affecting email, reduce the TTL on affected records to 300 seconds (5 minutes) at least 24 hours in advance. Once the change is confirmed working, raise the TTL back to a stable value. The DNS TTL guide explains the timing mechanics in detail.

Diagnosing Email DNS Problems Systematically

When something breaks, a structured approach saves time:

1. Determine whether the problem is inbound (check MX records) or outbound (check SPF, DKIM, DMARC)
2. Use dig to verify each record exists and has the expected value
3. Review DMARC aggregate reports for recent authentication results — they'll show SPF and DKIM pass/fail rates for actual mail flows
4. Use MXToolbox or a similar tool to test end-to-end SMTP delivery and get a full diagnostic trace
5. Check SMTP server logs for specific 4xx and 5xx response codes — these usually point directly to the DNS problem

For ongoing DNS management and monitoring, MailDog's DNS security tools provide visibility into your authentication records and flag configuration problems before they affect delivery. Most DNS email errors are preventable — the key is catching them before your recipients do.