SPF, DKIM and DMARC Explained Simply: What Each Record Checks and Which One Rejects Email

Any name can be written on an envelope. Email works the same way: the sender address in a message is a line of text, written by whoever sends it, and nothing in the protocol requires it to be true.

Three DNS records exist to deal with this. Two of them are checks. Only one is an instruction – and that difference decides whether a forged message in a domain’s name arrives or bounces.

What SPF, DKIM and DMARC each are

SPF is a list of servers. The domain owner publishes which machines are allowed to send mail in that domain’s name. A receiving mail server compares the sending machine against the list and gets a yes or a no.

DKIM is a signature. The sending server signs the message with a private key; the matching public key sits in DNS. If the signature still fits when the message arrives, nothing was altered on the way and it really came from a system holding that key.

DMARC is an instruction. It says what should happen when the first two fail: let the message through anyway, put it in the spam folder, or reject it outright.

That is the whole architecture. Two questions and one answer to them. What surprises most people is which part is missing on most domains – it is the third.

Why SPF alone stops nothing

An SPF check produces a result. It does not produce a consequence.

The receiving server learns that the sending machine is not on the list. What it does with that knowledge is entirely up to the receiving server, and without further instruction most of them do the cautious thing: deliver, perhaps with a marker. Rejecting a legitimate message is far worse for a mail provider than accepting a forged one, so in doubt they accept.

SPF records themselves say something about this. A record can end in -all, meaning “everything else is a forgery”, or in ~all, meaning “everything else is suspicious”. The second is a request for leniency, and it is what the majority of domains publish – often because it was the default in a setup guide, not because anyone decided it.

DKIM has the same limit. A failed signature is a finding, not a verdict.

The hidden budget: ten lookups and no more

SPF has a limit that catches a lot of domains out, because nothing about it is visible in the record itself.

A record may refer to other records. include:_spf.google.com means “everything that entry allows counts here too”. Convenient, and it is how mailing services get added. But every such reference costs a DNS lookup, the referenced record may refer onward, and the total is capped at ten.

Beyond ten, the check does not merely fail – it ends in a permanent error, and by the rules the whole record then counts for nothing. Every entry in it, including the servers that were listed correctly.

The catch is that this cap can be crossed without touching the record. A mailing provider adds one referral inside its own entry, that entry now costs one lookup more, and a domain that sat at ten quietly sits at eleven. Nothing on the domain changed. The check simply stops working.

A well-known payment provider currently sits at nine of ten. That is not carelessness – it is what a company with many mailing systems ends up with, and it is one referral away from failing.

How long a DKIM key has to be

A DKIM key can be found and read, and its length is worth reading.

1024 bits was the standard for years and is still widespread. It is no longer considered adequate; 2048 is the current recommendation. The key is not secret – the public half sits in DNS for anyone to fetch – and a key that can be broken lets someone else produce signatures that check out.

There is a second reason short keys survive: a 2048-bit key does not fit in a DNS record in one piece and has to be split. That works, but it is a step that gets skipped, and the old key stays.

One honest limit belongs here. DKIM keys sit under a selector, a name chosen freely by whoever set it up, and DNS offers no way to list the selectors a domain uses. Any check from outside can only try common names – default, google, selector1, s1 and a few dozen more. A domain whose selector is not among them shows no keys, and that means “none found here”, never “none exist”.

Why most domains stop at p=none

DMARC is the only one of the three that can order a rejection, and it is the one most domains never finish setting up.

A DMARC record contains a policy: p=none, p=quarantine or p=reject. Only the last one actually turns messages away. p=none means: check, report, deliver anyway.

p=none is the right place to start. Reports arrive, the picture of who sends in the domain’s name fills in, and forgotten systems surface – the invoicing tool, the newsletter service, the old shop nobody thought of. That takes a few weeks.

Then comes the step to quarantine, then to reject, and that step is where it stops, because it is the only one that can go wrong in a visible way. As long as the policy stays at none, the record exists and protects nothing.

Which is how the most common state on the internet comes about: three records, all correct, all readable, all passing a superficial check – and a forged message in that domain’s name still arrives.

What five minutes of checking shows

All of it is public. SPF, DKIM and DMARC sit in DNS, readable by anyone for any domain, and there are four questions worth asking of any of them.

Does an SPF record exist, does it end in -all or ~all, and how close is it to the ten-lookup cap. Are DKIM keys findable, and how long are they. Does a DMARC record exist, and what does its policy say. And can the mail servers of the domain be reached at all.

The email authentication checker answers all four for any domain. It counts the lookups the way a receiving server counts them, tries the common DKIM selectors, reads the DMARC policy, and says plainly which findings are facts and which are the limits of checking from outside.

The answer worth having is short: whether a forged message in that domain’s name would be turned away – or merely noticed.