Why does my e-mail go to spam? DNSBL, PTR, SPF, DKIM and DMARC

When a message lands in spam, the first thought is usually “something is wrong with the content”. More often the problem sits lower: the receiving server does not trust the sending server, or cannot confirm that the message really comes from your domain. Most of these signals are ordinary DNS records that you can check in a few minutes.

How the receiving server judges the sender

When your server connects to the recipient’s server, the latter asks a few questions within a fraction of a second:

1. Is the sender’s IP address on a blocklist? (DNSBL)
2. Does the IP address have a sensible reverse name? (PTR, reverse DNS)
3. Does the domain allow this server to send mail? (SPF)
4. Does the message carry a valid domain signature? (DKIM)
5. What does the domain say to do when SPF and DKIM fail? (DMARC)

Only then do content filters and long-term reputation come into play. If any of points 1–5 fails, even the most polite message has an uphill battle.

1. Blocklists (DNSBL)

DNSBLs are lists of IP addresses (and domains) that have sent spam. The receiving server asks about your address with an ordinary DNS query, and a “listed” answer often means the message is rejected straight away.

The most common reasons for a listing:

• an infected computer on the network sending spam through the same public address,
• a poorly protected contact form or a mailbox with a stolen password,
• an address inherited from a previous “tenant” (VPS, new address from the ISP),
• an address from a residential or mobile pool, which PBL-type lists block by policy.

Check the sending server’s address with the DNSBL blacklist check. If it is listed, remove the cause first and only then request delisting. Every list has a form on its website, and many remove the entry automatically after a few quiet days.

2. Reverse name (PTR)

A mail server should have a PTR record, a name assigned to its IP address such as mail.example.com. That name should in turn point back to the same address with an A record, and match what the server announces in the SMTP greeting (HELO/EHLO).

A missing PTR, or a name like host-203-0-113-7.dynamic.isp.net, tells many recipients “home computer, not a server”. The PTR record is set by the owner of the IP address, usually your server or connectivity provider, not by you in your own DNS zone. You can check it in DNS lookup by entering the IP address itself.

3. SPF: who may send mail for your domain

SPF is a single TXT record in the domain that lists the servers allowed to send mail, for example:

example.com.  TXT  "v=spf1 ip4:203.0.113.7 include:_spf.google.com ~all"

Watch out for:

• Only one SPF record. Two v=spf1 records are an error (permerror), even if each is valid on its own. When adding a new service, add it to the existing record.
• The 10 DNS lookup limit. Every include, a, mx, exists and redirect uses one lookup, and providers’ includes contain more. Once the limit is exceeded, SPF stops working entirely.
• Ending with ~all or -all. ~all means “other servers are suspicious”, -all means “reject”. +all lets anyone send and defeats the purpose of the record.
• Avoid ptr. The mechanism is deprecated and slow.

4. DKIM: the message signature

DKIM adds a cryptographic signature to every message. The public key lives in DNS under <selector>._domainkey.example.com, and the selector is visible in the DKIM-Signature header (the s= field). The recipient verifies the signature and knows the message was not altered on the way and that your domain signed it.

Signing is enabled on the mail server or service (Google Workspace, Microsoft 365, your own Postfix with OpenDKIM), and you only add the key record to DNS. An RSA key should be at least 2048 bits long.

5. DMARC: what to do with forgeries

DMARC ties SPF and DKIM to the address shown in the “From:” field. A message passes DMARC when SPF or DKIM passes for the same domain that appears in “From:”. The record lives at _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

A sensible rollout order:

1. p=none with an rua= address: nothing changes, but you start receiving reports from large mailbox providers about who sends mail on your behalf.
2. After a few weeks, when the reports show only your own servers: p=quarantine (forgeries go to spam).
3. Finally p=reject (forgeries are rejected).

Since 2024 Gmail and Yahoo require SPF, DKIM and DMARC from bulk senders. For smaller senders a missing DMARC record does not block mail, but it clearly lowers the score.

Checklist