If your carefully written cold emails, invoices, or product updates keep landing in spam, you're not alone -- and it's almost never about your writing. Mailbox providers like Gmail, Outlook, and Yahoo increasingly rely on authentication signals baked into your domain's DNS, not just content filters. Here are the seven most common technical causes, ranked by how often we see them in real scans.
1. Missing or broken SPF record
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are allowed to send email on behalf of your domain. If you don't have one, spammers can spoof "from@yourdomain.com" with no resistance, and legitimate providers like Gmail will treat your unauthenticated mail with suspicion.
Fix: add a single TXT record at your root domain starting with v=spf1, listing every service that sends mail for you (your ESP, CRM, helpdesk, etc.), ending in -all for a hard fail.
2. Too many SPF lookups (the "10 lookup limit")
SPF has a hard RFC 7208 limit of 10 DNS lookups. Every include:, a, mx, ptr, exists, and redirect mechanism counts -- and nested includes count too. Go over 10, and receiving servers are required to treat your SPF as a permanent error, which often means an automatic fail.
Fix: flatten your SPF record, remove unused includes, and consolidate multiple sending services behind fewer includes where possible. Read our step-by-step SPF 10-DNS-lookup limit troubleshooting guide or test your domain with the Free SPF Checker.
3. No DKIM signing
DKIM adds a cryptographic signature to your outgoing mail, proving it wasn't altered in transit and really came from an authorized server. Without it, SPF alone is weaker protection, and many providers now expect both.
Fix: enable DKIM in your email provider's admin console (Google Workspace, Microsoft 365, Postmark, Resend, etc.) and publish the TXT record it gives you at selector._domainkey.yourdomain.com. You can verify your key with the Free DKIM Checker.
4. No DMARC record at all
DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both -- and, critically, where to send you reports about it. As of February 2024, Gmail and Yahoo require a DMARC record for anyone sending more than ~5,000 messages/day, and enforcement keeps expanding to smaller senders too.
Fix: publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; at minimum, then tighten the policy over time (see our DMARC policy guide and test your record in the Free DMARC Checker).
5. DMARC policy stuck at p=none
A DMARC record with p=none is monitoring-only -- it collects reports but does nothing to stop spoofed mail, and provides no deliverability benefit on its own. Many domains set it up once during a compliance push and never move past none.
Fix: after 1-2 weeks of clean aggregate reports, move to p=quarantine, then eventually p=reject once you're confident all legitimate senders are covered. Follow our safe rollout guide for p=none vs p=quarantine vs p=reject.
6. Sending from a domain with no MX records
If your sending domain (or subdomain) has no MX record, some receiving servers treat it as suspicious, since it looks like a domain that was never meant to receive mail at all -- a common spoofing pattern.
Fix: ensure your sending domain has valid MX records, even if it's a dedicated subdomain used only for marketing or transactional email.
7. Poor sender reputation from inconsistent volume or list hygiene
This one isn't DNS-related, but it compounds everything above: sudden spikes in send volume, high bounce rates, and low engagement all hurt your domain and IP reputation over time, regardless of how clean your SPF/DKIM/DMARC setup is.
Fix: warm up new sending domains gradually, keep your list clean, and monitor bounce/complaint rates in your ESP dashboard.
Check your own domain in 5 seconds
Rather than guessing which of these applies to you, run a free scan -- it checks SPF, DKIM, DMARC, and MX in one pass and gives you copy-paste-ready fixes for anything broken.