Email Deliverability: 7 DNS Misconfigurations Killing Your Inbox Rate

You can write the best email of your life and still land in spam. If your DNS is misconfigured, mailbox providers make that decision before a human ever sees the subject line.

Deliverability isn't mostly about content anymore. Gmail, Outlook, and Yahoo authenticate every message against the DNS records published for your sending domain, and they increasingly require those records to be correct. Get them wrong and your open rates quietly collapse — not with a bounce, but with a silent slide into the junk folder.

Here are the seven DNS misconfigurations we find most often when auditing a domain's email setup, why each one hurts, and how to check and fix it.

TL;DR — the 7 misconfigurations

1. SPF that doesn't cover every sender (or exceeds the 10-lookup limit)
2. SPF left on ~all or +all instead of a hard -all
3. DKIM missing, weak, or unaligned
4. DMARC stuck at p=none — monitoring forever, never enforcing
5. Authentication that passes but doesn't align with your From domain
6. Missing PTR (reverse DNS) and HELO mismatches on your sending IPs
7. Forgotten records — stale SPF includes, dangling subdomains, unprotected sending subdomains

Want the fast version? You can run a free 30-second email & DNS audit that checks most of these automatically — no credentials required.

Why DNS decides your inbox placement

Three records do the heavy lifting: SPF (which servers may send as your domain), DKIM (a cryptographic signature proving a message wasn't altered), and DMARC (what receivers should do when SPF or DKIM fail, plus where to send reports). Together they answer the mailbox provider's core question: is this really from who it claims to be?

Since 2024, Google and Yahoo require bulk senders to have SPF and DKIM and DMARC in place. "Set up years ago and never touched" is exactly where problems hide, because your sending tools change even when your DNS doesn't.

1. Your SPF record doesn't cover every sender

SPF lists the servers allowed to send email for your domain. The failure mode isn't usually a missing record — it's an incomplete one. You add a new tool (a CRM, a support desk, a marketing platform) and forget to authorize it, so its mail fails SPF.

The second, sneakier failure is the 10-lookup limit. Every include: in your SPF chain can trigger more lookups, and if the total exceeds 10, receivers return a permerror and may treat the whole record as invalid. Stacking Google Workspace + a CRM + a helpdesk + an ESP blows past 10 faster than most teams expect.

Check: Look up your TXT record for v=spf1. Count the lookups (each include, a, mx, ptr, exists). Fix: Flatten or consolidate includes, remove tools you no longer use, and keep the chain under 10.

2. SPF is still on ~all (or +all)

The qualifier at the end of your SPF record tells receivers how strict to be. -all (hard fail) says "reject anything not on this list." ~all (soft fail) says "accept it, but mark it suspicious." +all says "let anyone send as us" — effectively no protection at all.

Most domains sit on ~all indefinitely because it feels safer. But soft fail leaves room for spoofing and weakens the DMARC decision downstream. Once you're confident your SPF list is complete (see #1), move to -all.

Check: The final mechanism in your v=spf1 record. Fix: After verifying all legitimate senders are covered, change ~all to -all.

3. DKIM is missing, weak, or unaligned

DKIM adds a signature to your headers that receivers verify against a public key in your DNS. No DKIM means one of your two authentication pillars is simply absent — and DMARC needs at least one of SPF/DKIM to align to pass.

Two quieter problems: weak keys (older setups still use 1024-bit; 2048-bit is now the expectation) and unsigned streams (your ESP is signed, but transactional mail from your app server isn't).

Check: Send a message to a Gmail account, open Show original, and confirm DKIM: PASS. Fix: Enable DKIM on every sending source, rotate to 2048-bit keys, and confirm the signing domain matches your domain. Our complete email security stack guide walks through SPF, DKIM, and DMARC end to end.

4. DMARC is stuck at p=none

p=none is the right starting point — it turns on reporting without affecting delivery so you can see who's sending as you. The mistake is treating it as the destination. A domain on p=none forever gets no spoofing protection and, increasingly, less trust from receivers who reward enforcement.

The path is p=none → p=quarantine → p=reject, moving up as your reports confirm all legitimate mail authenticates. Most teams stall at none because nobody reads the reports.

Check: Look up _dmarc.yourdomain.com and read the p= value. Fix: Use aggregate reports to reach full authentication, then progress to p=reject. We cover the exact 90-day path in DMARC implementation: from p=none to p=reject.

5. Authentication passes — but doesn't align

This is the misconfiguration that surprises people. SPF can pass and DKIM can pass, yet DMARC still fails, because DMARC also checks alignment: the domain that authenticated must match the domain in your visible From: header.

It happens constantly with third-party tools that send "on your behalf" using their return-path or signing domain. The mail is authenticated — just not as you. To DMARC, that's a fail.

Check: In Gmail's Show original, confirm SPF/DKIM pass and that the aligned domain matches your From domain. Fix: Configure custom return-path and DKIM signing (CNAMEs) for each ESP so authentication aligns to your domain.

6. Missing PTR (reverse DNS) and HELO mismatches

If you send from your own IPs (your app server, a self-hosted MTA), receivers check for a PTR record — reverse DNS that maps the IP back to a hostname. No PTR, or a PTR that doesn't match the server's HELO/EHLO name, is a classic spam signal. Some receivers reject outright.

This mostly bites teams running their own mail infrastructure or transactional senders on cloud VMs, where reverse DNS is an afterthought.

Check: Run a reverse lookup on your sending IP and confirm the hostname resolves back to it and matches your HELO. Fix: Set the PTR at your hosting provider so forward and reverse DNS agree. See our DNS security guide for the broader picture.

7. Forgotten records are quietly hurting you

The last category is entropy. Over time, DNS accumulates cruft that drags down deliverability and widens your attack surface:

• Stale SPF includes for tools you stopped using (wasting lookups, per #1).
• Dangling subdomain records — a CNAME pointing at a service you've since abandoned, which an attacker can claim and use to send as you.
• Unprotected sending subdomains — DMARC on your root domain but not on the subdomains that actually send mail, leaving them spoofable.
• Reputation debt from any of the above. Once a domain or IP earns a poor sending reputation, recovery takes weeks of clean sending.

Check: Inventory every DNS record and every tool authorized to send as you. Fix: Remove what you don't use, publish DMARC on sending subdomains, and monitor going forward.

Not sure which of these apply to you? Our free email & DNS audit checks SPF, DKIM, DMARC, alignment, and common DNS gaps in about 30 seconds — no access or credentials needed.

How to verify everything in 10 minutes

1. Send one message each from every tool you use (CRM, ESP, helpdesk, app) to a Gmail address.
2. Open Show original on each and confirm SPF, DKIM, and DMARC all say PASS — and that they align with your From domain.
3. Look up your v=spf1 record and count lookups; confirm it ends in -all.
4. Look up _dmarc.yourdomain.com and confirm you're progressing past p=none.
5. Reverse-lookup any IPs you send from directly.

If every message passes and aligns, and your DMARC reports are clean, you've closed the gaps that quietly cost the most inbox placement.

Frequently asked questions

Why is my email going to spam even though I have SPF, DKIM, and DMARC? Usually alignment (#5) or an incomplete SPF list (#1). Records can each "pass" individually while DMARC still fails because the authenticated domain doesn't match your visible From domain. Check a real message in Gmail's Show original to see which check is actually failing.

Does moving DMARC to p=reject risk blocking my own email? Only if you enforce before your legitimate mail authenticates. That's what the p=none monitoring phase is for — you read the aggregate reports, fix every sender, and then progress to quarantine and reject. Done in order, enforcement doesn't block real mail.

How often should I audit my email DNS? At least quarterly, and any time you add or remove a sending tool. Most deliverability problems come from a change on your side that never made it into DNS.

---

Email deliverability rarely fails loudly. It erodes — one unauthorized sender, one soft-fail record, one un-enforced DMARC policy at a time. Fixing these seven misconfigurations is the highest-leverage hour you can spend on your email program.

If you'd rather have it handled, PlatOps manages email and DNS security end to end — from getting to p=reject safely to keeping it there as your stack changes. Run a free audit to see where your domain stands today.