Email going to spam? Check these three DNS records first

Email deliverability sounds like a marketing topic until the day an invoice does not arrive, or a password reset never shows up, or a customer says they have been waiting three days for a reply that has been sitting in their junk folder the whole time.

Almost every case comes down to three DNS records that tell receiving mail servers whether your messages are genuine. They are published as plain text records on your domain, anyone can read them, and you can check all three in about a minute from a phone. What follows is what each one does, what a good record looks like, and the specific mistakes that quietly break them.

Why your mail gets judged before it is read

Anyone can put any address in the From field of an email. The protocol has worked that way since the 1980s and it is not going to change. So receiving servers do the next best thing: they check whether the server that actually delivered the message was authorised by the domain it claims to be from.

That check happens in the first few hundred milliseconds, before any content filtering, before any reputation scoring. If it fails, your carefully written message is already starting from a deep hole. If it passes, you get the benefit of the doubt.

All three mechanisms are published in DNS, which means all three are public, and which means you can inspect a competitor's, a vendor's, or your own with the same lookup.

SPF: who is allowed to send

SPF is a TXT record on your domain listing the servers permitted to send mail as you. It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Read it left to right: this is an SPF record, mail from Google's servers is fine, mail from SendGrid's servers is fine, and anything else should be treated with suspicion.

That last token is the one people get wrong:

Ending	Meaning	Use it?
-all	Hard fail. Reject anything not listed.	Once you are confident the list is complete
~all	Soft fail. Accept but mark as suspicious.	Sensible default while you are still finding senders
?all	Neutral. Says nothing at all.	No. This is the same as having no policy
+all	Anyone may send as you.	Never. This is actively harmful

The three mistakes that break SPF

Two SPF records. A domain may have exactly one. Publish two and the result is undefined, and most receivers treat it as a permanent error. This happens constantly when a new email provider is added and nobody notices the old record is still there. It is the single most common SPF fault.

More than ten DNS lookups. Every include: costs a lookup, and those includes can contain their own includes. Exceed ten and the whole evaluation fails, even though the record looks perfectly reasonable. Stacking three or four providers gets you there faster than you would expect.

Forgetting a sender. Your helpdesk, your invoicing system, your newsletter tool and your CRM all send as your domain. Miss one and its mail fails SPF while everything else passes, which produces the maddening "only our invoices go to spam" pattern.

DKIM: proof it was not tampered with

SPF authorises a server. DKIM authenticates the message itself.

Your mail server signs outgoing messages with a private key and adds the signature to the headers. Your public key sits in DNS at a selector based name such as selector1._domainkey.example.com. The receiver fetches the key, verifies the signature, and knows both that the message really came from you and that nothing was altered in transit.

The important quirk: you have to know the selector to look it up. There is no way to list all DKIM records for a domain, because the name depends on a selector chosen by whoever configured it. Common ones are google, selector1 and selector2 (Microsoft), k1 (Mailchimp), s1 and s2. Your provider's setup documentation will tell you which one it uses, and any message you have already sent carries it in the DKIM-Signature header.

DKIM tends to break in two ways. Either the record was never published, because someone completed half of a provider's setup wizard, or the key was rotated on the provider side and the DNS record still holds the old one.

DMARC: what to do when checks fail

DMARC ties the other two together and tells receivers what you want done with mail that fails. It lives at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

The policy value is the part that matters:

• p=none means "do nothing differently, but send me reports." This is where every domain should start.
• p=quarantine means "put failures in spam."
• p=reject means "refuse them outright."

The rua address receives aggregate reports from receiving providers, and those reports are genuinely useful: they show every source sending mail as your domain, including ones you forgot about and ones that are spoofing you.

The upgrade path is simple and worth following in order. Publish p=none. Read reports for a few weeks. Fix every legitimate sender that is failing. Move to p=quarantine. Wait again. Then move to p=reject. Skipping straight to reject is how a company discovers, loudly, that its billing system was never in the SPF record.

The alignment rule nobody mentions

DMARC requires more than a passing SPF or DKIM check. It requires the passing domain to align with the domain in the From header. A message can pass SPF cleanly for a bulk sender's own domain and still fail DMARC, because the From address says your domain and SPF passed for theirs. This is why mail sent through a third party platform often fails DMARC despite every individual check looking green, and why providers ask you to set up a custom sending domain.

Checking all three

All three records are public TXT records, so a DNS record lookup reads them directly from the source.

1. Pull the TXT records on the domain

   The SPF record starts with v=spf1. Confirm there is exactly one, count the include: entries, and check what the record ends with.

2. Look up _dmarc on the domain

   Query _dmarc.example.com for TXT. If nothing comes back, you have no DMARC policy, and that alone is a deliverability disadvantage with the major providers.

3. Look up your DKIM selector

   Query <selector>._domainkey.example.com. Get the selector from your provider's documentation or from the DKIM-Signature header of a message you have sent.

4. Check the MX records while you are there

   They should point where you expect. A domain that changed mail providers and left an old MX record behind delivers a share of its mail to a server nobody reads.

5. Check the TTL on each record

   If you are about to change any of them, the TTL tells you how long the old value will keep being served. Lower it before you make the change, not after.

# SPF and other TXT records live on the domain itself
https://netdebug.app/open/dnsexplorer?target=example.com

# DMARC lives on a dedicated subdomain
https://netdebug.app/open/dnsexplorer?target=_dmarc.example.com

# DKIM, once you know the selector
https://netdebug.app/open/dnsexplorer?target=selector1._domainkey.example.com

When the records are fine and mail still lands in spam

Authentication gets you through the door. It does not guarantee the inbox.

Reputation. Providers track how recipients treat your mail. Deletions without opening, spam reports and bounces all count against you, and a shared IP at a budget provider means you inherit the behaviour of everyone else on it.

A brand new domain. Domains registered days ago are treated with suspicion because that is what disposable spam domains look like. Volume needs ramping up gradually.

Content signals. A single image with no text, link shorteners, mismatched display and link URLs, and attachments in unusual formats all push a message toward the junk folder regardless of authentication.

Missing reverse DNS. If you run your own mail server, the sending IP should have a PTR record that resolves back to the hostname it announces. A reverse lookup on the IP checks this in seconds, and plenty of receivers reject mail outright without it.

Blocklists. One compromised account or one badly targeted campaign can get an IP or domain listed. Most lists have a lookup and a delisting process.

The short version

Three records decide whether your mail is trusted: SPF says which servers may send, DKIM proves the message was not altered, and DMARC says what to do when either fails. Check that you have exactly one SPF record with fewer than ten lookups, that your DKIM selector actually resolves, and that DMARC exists at all, even if it only starts at p=none. Those three lookups take a minute and catch most deliverability problems before anyone tells you about them.