Emails Going to Spam? A DNS Checklist to Work Through

When legitimate mail lands in spam, the cause is one of two things: authentication (the receiver cannot confirm the mail really comes from your domain) or reputation (it can, and does not like what it sees). DNS fixes the first. It does not fix the second, but until the first is right, nothing else you do will count.

This checklist works through the DNS side in the order that finds problems fastest. The concepts behind it are explained in MX, SPF, DKIM and DMARC explained; here we stay practical.

Step 0 — Read the headers of a message that went to spam

Do not guess. Send a message to a mailbox you control at the provider where the problem occurs, open it, and choose "show original" / "view source". Look for the Authentication-Results header that the receiver added:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

This one line tells you most of what you need:

Field	Question it answers
spf= and smtp.mailfrom=	Did the sending IP match the SPF record of the envelope domain, and which domain was that?
dkim= and header.d=	Was there a valid signature, and for which domain?
dmarc= and header.from=	Did SPF or DKIM pass for the domain the recipient sees?

In the example everything "passes" and DMARC still fails: SPF and DKIM passed for the mailing service's domains, not for example.com. That is the single most common finding, and Step 4 deals with it.

Also note the sending IP in the top-most Received: line added by the receiver; you will need it in Step 5.

Step 1 — List everything that sends mail as your domain

Authentication fails most often for a sender nobody remembered: the mailbox provider, the newsletter tool, the CRM, the invoicing system, the helpdesk, the website's contact form, the office scanner, monitoring alerts. Write them down. Every one must be covered by SPF or DKIM, preferably both.

Step 2 — SPF

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

Check:

• Exactly one record starting with v=spf1. Two records is a permanent error (permerror), and the result is as if you had none.
• Every sender from Step 1 is covered by an include:, ip4: or ip6:.
• No more than 10 DNS lookups in total. include, a, mx, exists and redirect each count, and includes nest. Exceeding the limit is also a permerror. Remove services you no longer use before reaching for "SPF flattening".
• It ends in ~all or -all. +all authorises the whole internet; ?all says nothing.
• No ptr mechanism. It is slow, unreliable and discouraged by the SPF specification itself.
• Subdomains that send mail (news.example.com) have their own SPF record. SPF is not inherited.

Remember what SPF checks: the envelope sender (Return-Path), not the From header. If a service uses its own bounce domain, SPF passes for their domain and does not help your DMARC result unless you configure a custom return-path.

Step 3 — DKIM

Take the selector (s=) and domain (d=) from the DKIM-Signature header of a real message, then query the key:

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• The record exists and contains a p= value. An empty p= means the key was revoked.
• Long keys are split into several quoted strings without stray spaces or line breaks pasted in by the control panel.
• Key length is 2048 bits where the provider allows it; 1024 is the minimum receivers accept.
• If the provider asked for CNAME records instead of TXT, they are present and not "flattened" or proxied by your DNS provider.
• d= is your domain, not the provider's. Most services sign with their own domain until you complete their "authenticate your domain" setup. This is what makes DKIM count for DMARC.
• Each sending service has its own selector.

There is no way to list a domain's DKIM selectors from outside. You find them in message headers or in the provider's settings.

Step 4 — DMARC and alignment

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• One record at _dmarc.example.com, starting with v=DMARC1, with a valid p=.
• A rua= address that somebody, or some tool, actually reads. If it is on a different domain, that domain must publish an authorisation record.
• For every sender, at least one of SPF or DKIM passes with a domain that matches the From domain (the same organisational domain is enough in the default relaxed mode).

Since February 2024, Gmail and Yahoo require SPF, DKIM and a DMARC record (at least p=none) with alignment from anyone sending around 5,000 or more messages a day to their users, plus one-click unsubscribe for marketing mail and a low complaint rate. Other large providers have announced similar rules. Smaller senders need SPF or DKIM at minimum, and in practice are judged by the same standards.

p=none gets you reports and satisfies the minimum. It does not protect the domain from spoofing. Move to quarantine and reject once the reports show that all legitimate sources are aligned.

Step 5 — The sending server: reverse DNS and HELO

Only relevant if you run the mail server yourself. With the IP from Step 0:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25

• A PTR record exists and is not the provider's generic default.
• The name resolves back to the same IP.
• The server greets with the same name in EHLO.
• If the server has IPv6, the same holds for that address, or outgoing mail is restricted to IPv4.

Details are in reverse DNS and PTR records.

Step 6 — MX and the domain itself

• The domain has working MX records pointing to hostnames (not IPs, not CNAMEs) that accept mail. Receivers distrust senders that cannot receive bounces and replies.
• postmaster@ and abuse@ reach a human.
• Domains that never send mail say so: v=spf1 -all, a null MX (0 .) and v=DMARC1; p=reject. Parked domains are a favourite for spoofing.

Step 7 — TLS

• Outbound mail uses STARTTLS. Gmail marks unencrypted mail with a red padlock, and bulk-sender rules require TLS.
• Your own MX offers STARTTLS with a certificate that is not expired:

$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Step 8 — Blocklists and reputation

• Look up the sending IP and the domain at the major blocklist operators' own lookup pages. A listing on an obscure list rarely matters; a listing on a widely used one does. Fix the cause (compromised account, open form, purchased list) before requesting removal.
• Register the domain with the postmaster tools that large mailbox providers offer. They show how those providers see your domain: spam complaint rate, authentication results, reputation.

When DNS is fine and mail still goes to spam

Then it is reputation or content, and no record will help:

• a new domain or new IP sending volume from day one, with no warm-up
• recipients who never asked for the mail, and complain
• old lists with many dead addresses
• link shorteners, links to poorly regarded domains, image-only messages
• a From domain that differs from the domain in the links and the domain in the signature
• on shared IPs: other customers' behaviour

DNS gets you judged as yourself. What happens next depends on what you send.

Common mistakes

• Adding a second SPF record for a new service instead of extending the existing one.
• Seeing spf=pass and dkim=pass and stopping there, without checking which domain passed.
• Jumping to p=reject without reading reports, and losing invoices sent by a forgotten system.
• Testing only from your own mailbox to your own mailbox on the same provider.
• Expecting changes to show instantly; SPF and DMARC records are cached for their TTL.

Check it with OrbitProbe

The OrbitProbe MX lookup shows a domain's MX hosts and priorities, the likely mail provider, and the SPF and DMARC records with findings on common configuration mistakes. It cannot list DKIM selectors, because nobody can from outside; check those from a message header as described in Step 3. Run it for the exact domain in your From address, and again for any subdomain that sends mail.