What are the most common misconfigurations seen in deliverability audits?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You'd be surprised how many domains have broken authentication sitting quietly in the background, sometimes for years. A deliverability audit almost always turns up at least one of the issues below. Some are typos. Some are old setups nobody updated when a new ESP came on board. All of them can hurt your inbox placement.

Here's what shows up most often, and why each one matters.

SPF problems

The most common SPF mistake is having more than one SPF record on the same domain. You can only have one. Two records creates a "permerror" (a permanent failure), which means receiving servers reject the authentication entirely rather than trying to figure out which record to use. The other big one is exceeding 10 DNS lookups inside your SPF record. Each time you include a sending service, that service might include others, and you can hit the limit faster than you'd think. A third issue is using +all at the end, which tells the world that anyone can send email as your domain. That's not a misconfiguration so much as an open door.

DKIM problems

Missing DKIM entirely is surprisingly common, especially on domains that were set up years ago before DKIM became standard practice. But even when DKIM exists, the key strength matters. Keys shorter than 2048 bits (the older 1024-bit standard) are considered weak and some receiving servers flag them. The trickier issue is a selector mismatch, where the selector your ESP puts in outgoing messages doesn't match the one published in your DNS. Your emails look unsigned, even though you technically have DKIM configured. This usually happens when an ESP is switched out but the DNS record isn't updated to match.

DMARC problems

Staying on p=none forever is the classic one. None means you're collecting data but not enforcing anything, which is fine as a starting point. The problem is when domains stay there for months or years and never move to p=quarantine or p=reject. Your domain gets no protection from spoofing, and mailbox providers like Gmail and Outlook increasingly want to see enforcement. Missing report addresses is also common. Without them, you're flying blind on who's sending as your domain.

PTR (reverse DNS) problems

Now if you're sending from your own IP addresses rather than a shared ESP infrastructure, your IPs need a PTR record. That's the reverse DNS entry that maps an IP back to a hostname. Missing PTR records, or generic ones that don't match your sending domain, are a quick way to get flagged by spam filters. It's a small thing that's easy to overlook when spinning up a new server.

Most of these issues sit undetected until something goes wrong. A quarterly check of your SPF, DKIM, and DMARC records takes maybe ten minutes and catches problems before they cost you inbox placement. You can run a quick check right now with our free SPF checker or DMARC parser. If something looks off and you're not sure what to do next, the SOS hotline is free.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Paste your domain and sending services above and get a structured audit checklist

I want to audit my email authentication setup for common misconfigurations. I send from your domain using list your ESPs, e.g. SendGrid, Klaviyo, Postmark. Can you help me identify issues with my SPF record (duplicate records, too many lookups, permissive policies), DKIM setup (key strength, selector mismatches), DMARC policy (enforcement level, report addresses), and PTR records for any dedicated sending IPs?

Edit the yellow boxes, then send to the AI of your choice.