Why are my emails going to spam?

The three notes a receiving server reads

When a mail server receives a message claiming to be from you, it has no reason to believe it. Anyone can write any address in the From line; the protocol was designed in 1982 and has no opinion about it. Three small records in your domain’s public settings are what give a receiver something to check.

SPF is a list of the servers allowed to send mail using your domain. If a message arrives from somewhere not on the list, the receiver knows.

DKIM puts a cryptographic seal on each message as it leaves. The receiver fetches your public key and checks the seal, which proves the message came from you and has not been altered in transit.

DMARC is the one that ties it together. SPF and DKIM both check the technical envelope, which is not the address a person sees; DMARC requires that one of them match the visible From address, and tells receivers what to do when neither does. Without it, somebody can pass SPF perfectly using their own domain while putting yours in the From line.

The four things that are usually wrong

Two SPF records. The commonest cause of mail that was fine last month and is in spam now. A business signs up for a newsletter service, is told to add a TXT record, and adds it beside the one already there. Receivers do not merge them or pick the better one: they treat the whole check as broken, which is worse than having no SPF at all.

Too many lookups. A receiver may make ten DNS lookups while checking SPF and gives up beyond that, failing the check. You cannot see this by reading your record, because the cost is inside the includes: each one pulls in another record with lookups of its own, and one large provider can spend five. This page follows them and counts.

DMARC set to p=none. It looks like protection and is not. p=none tells receivers to deliver failing mail anyway and send a report. It passes any test of whether you have DMARC, which is exactly why so many domains have sat on it for years. It is the correct place to start and a stage rather than a destination: read the reports until every legitimate sender of yours passes, then move to p=quarantine.

No reporting address. A p=none record with no rua= is doing nothing whatsoever. It is not protecting anything and it is not telling you anything either, so there is no way to know when it would be safe to move on.

Why DKIM can only be guessed at

SPF and DMARC live at fixed addresses: the domain itself, and _dmarc under it. Either they are there or they are not.

DKIM does not work that way. A key lives under a selector, an arbitrary word chosen when it was set up, and there is nothing in DNS that lists them. The selector travels in the header of every message you send, so a receiver always knows which key to fetch, but from outside there is no way to enumerate them. Amazon SES and Mailgun generate random ones on purpose.

So this page tries the selectors the large providers use by default. Finding one proves DKIM is set up and tells you which provider signed it. Finding none proves nothing at all, and the result says so rather than reporting a problem that may not exist. To check for certain, open a message you have sent, view the original, and read the s= value out of its DKIM-Signature header.

What this page cannot tell you

Whether your mail reaches the inbox. Authentication answers one question: does this message really come from the domain it claims? Delivery also turns on your sending reputation, what the message says, how old the list is, how many recipients press the spam button, and rules that differ between providers and change without notice. A domain that passes everything here can still go to spam, and a page that promised otherwise would be the most useful-sounding lie it could tell.

A score. There is no number out of a hundred here, because any such number requires deciding what a missing DKIM key is worth against a weak DMARC policy, and that weighting is invented whoever does it. What is real is the list of specific things that are wrong.

Anything, if the lookups were blocked. This is the one tool on this site that has to ask the internet something: a browser cannot make a DNS query, so the domain is sent to a public resolver over HTTPS. Ad blockers and company networks block those endpoints fairly often, and a blocked lookup looks exactly like a domain with nothing set up. They are reported separately here and never read as each other.