{"id":13465,"date":"2026-10-06T07:35:00","date_gmt":"2026-10-06T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13465"},"modified":"2026-09-25T09:45:52","modified_gmt":"2026-09-25T07:45:52","slug":"spf-dkim-and-dmarc-explained-simply-what-each-record-checks-and-which-one","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/it-networks\/tutorials-en-it-networks\/spf-dkim-and-dmarc-explained-simply-what-each-record-checks-and-which-one\/","title":{"rendered":"SPF, DKIM and DMARC Explained Simply: What Each Record Checks and Which One Rejects Email"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

\n\"A
All three see the same message. Only the third one can act on what it sees.<\/figcaption><\/figure>\n

What SPF, DKIM and DMARC each are<\/h2>\n

SPF is a list of servers.<\/strong> 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.<\/p>\n

DKIM is a signature.<\/strong> 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.<\/p>\n

DMARC is an instruction.<\/strong> 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.<\/p>\n

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.<\/p>\n

Why SPF alone stops nothing<\/h2>\n

An SPF check produces a result. It does not produce a consequence.<\/p>\n

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.<\/p>\n

SPF records themselves say something about this. A record can end in -all<\/code>, meaning “everything else is a forgery”, or in ~all<\/code>, 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.<\/p>\n

DKIM has the same limit. A failed signature is a finding, not a verdict.<\/p>\n

The hidden budget: ten lookups and no more<\/h2>\n

SPF has a limit that catches a lot of domains out, because nothing about it is visible in the record itself.<\/p>\n

A record may refer to other records. include:_spf.google.com<\/code> 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\n\"Three
\n<\/figure>\n

How long a DKIM key has to be<\/h2>\n

A DKIM key can be found and read, and its length is worth reading.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/code>, google<\/code>, selector1<\/code>, s1<\/code> 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”.<\/p>\n

Why most domains stop at p=none<\/h2>\n

DMARC is the only one of the three that can order a rejection, and it is the one most domains never finish setting up.<\/p>\n

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

p=none<\/code> 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.<\/p>\n

Then comes the step to quarantine<\/code>, then to reject<\/code>, 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<\/code>, the record exists and protects nothing.<\/p>\n

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.<\/p>\n

What five minutes of checking shows<\/h2>\n

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.<\/p>\n

Does an SPF record exist, does it end in -all<\/code> or ~all<\/code>, 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.<\/p>\n

The email authentication checker<\/a> 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.<\/p>\n

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

\n

Questions and answers<\/h2>\n

Why can a forged message pass SPF and still fail DMARC?<\/h3>\n

Because SPF checks a different address from the one that appears in the inbox. SPF refers to the envelope sender, which is given when the message is handed over and later appears in the message as the Return-Path. The visible From line is independent of it. A forger can therefore put a domain of their own with a matching SPF record into the envelope, set someone else’s domain in the From line, and pass the SPF check.<\/p>\n

DMARC closes this gap with an additional condition called alignment: a passing SPF or DKIM result only counts if the checked domain matches the domain in the visible From line. For DKIM that is the domain named in the signature. A message passes DMARC as soon as one of the two checks passes and is aligned.<\/p>\n

For the step to reject, this implies an order. Forwarded mail usually loses its aligned SPF result, because a different server now delivers it; the DKIM signature survives forwarding as long as nobody changes the message. Mailing lists that alter the subject or append a footer, on the other hand, break the signature too. Before the policy is tightened, every system sending on behalf of the domain should therefore sign with an aligned DKIM signature. The reports from the p=none phase show where that is still missing.<\/p>\n

Does a domain that sends no email at all need these records?<\/h3>\n

That kind of domain most of all. A domain without any outgoing mail can be locked down without risk: with an SPF record v=spf1 -all<\/code> that permits no server, and a DMARC record with p=reject<\/code>. Since no legitimate message exists, none can be rejected by mistake, and the weeks at p=none can be skipped.<\/p>\n<\/div>\n

\n

Sources<\/h2>\n