Email protection

SPF, DKIM and DMARC — why your email lands in spam

Three text records decide whether a receiving mail server believes an email is really from you. When they are missing or toothless, nothing bounces and nobody tells you. The mail just quietly arrives in Junk.

Three records, in plain words

All three live in your domain's DNS — the public directory that tells the internet where your website and mail sit. They are ordinary text records, readable by anyone, which is why this check needs no access to your site or your inbox.

SPF is the list of who may send as you. Your domain publishes the servers it sends from — your mail provider, your booking system, whatever sends your invoices — and a receiving server checks arriving mail against that list.

DKIM is the signature. Your server signs each outgoing message with a private key and publishes the matching public key in DNS, so the receiver can confirm the message came from you and was not altered on the way.

DMARC ties the two together. It tells receiving servers what to do when a message fails both checks — nothing, send it to Junk, or reject it — and where to post daily reports naming everyone sending mail as your domain. Without it, you get no reports and never learn you have a problem.

What it costs you

Failure here is silent. Nothing bounces, no error comes back, and the quote or booking confirmation lands in a folder the customer does not open. From their side, you never replied.

The second cost is that anyone can put your name in the From line. With no policy telling receivers to reject failures, a message pretending to be your business arrives in your customer's inbox alongside your real ones.

It also affects whether you can send at all. Google's published sender guidelines require every sender to authenticate with SPF or DKIM, and bulk senders to Gmail to have all three. That is an entry requirement now, not best practice.

A record that exists is not a record that works

Most checkers stop at present or absent. Ours reads what the record says, and only comments on records that exist — so nobody is told both that they have no SPF and that it is weak.

An SPF record ending in +all is reported as critical: it tells receivers to accept mail from any server as your domain, which is worse than publishing nothing. Ending in ?all is neutral and enforces nothing. SPF is also allowed only ten DNS lookups (RFC 7208, section 4.6.4), after which it returns a permanent error that receivers may ignore entirely, so an overgrown record is flagged.

On DMARC, p=none is the common case and the one worth understanding: it monitors and reports, but a spoofed email of your domain is still delivered. A policy applied to less than 100% of mail is flagged too, and so is a record with no rua= address — the reports are the only way to see who sends as you before you tighten the policy and cut off your own booking system.

A lookup that failed is not a record that is missing

We learned this one on ourselves. Our own mail was landing in Outlook's Junk folder, and at the same time every DNS check the auditor ran came back empty. Not for one domain — for all of them.

The cause was the network the auditor ran on: it was intercepting port 53, the port ordinary DNS uses, so lookups timed out. The code treated a timeout and a genuine answer of no such record as the same thing, and produced four findings per site: missing SPF, DKIM, DMARC and DNSSEC. Every one was false, and checkable by the recipient in one command.

The fix was to ask over HTTPS instead — the same port a web page uses, which nothing was intercepting (DNS over HTTPS, RFC 8484). The more important fix was in how an answer is recorded. A lookup now returns one of three states: the record exists, it genuinely is not there, or we could not ask and therefore know nothing. The third goes into the report as not assessed, with the reason, and is never counted against your score.

That distinction is the difference between an audit and a scanner printout.

Check your own domain

There is a check on this site at /check. Enter your domain and it runs these lookups and shows the records themselves — the actual SPF string, the DMARC policy, which DKIM selectors answered — rather than a colour and a grade.

If something is missing, the fix is usually a few text records added at your registrar or DNS host, and your mail provider publishes the exact values. Do it in order: SPF and DKIM first, then DMARC at p=none with a reporting address, then read the reports until you recognise every sender, and only then tighten to quarantine or reject.

What the engine checks here

Each of these is a rule in the code, not a category heading.

SPF record presentReads the TXT records at your domain and looks for one beginning v=spf1. Absent is reported as a warning, with the recommendation to add an SPF TXT record.
SPF qualifier — what happens to mail that failsFinds the qualifier before all. +all is critical: it accepts mail from any server as your domain. ?all is a warning, since neutral enforces nothing. ~all or -all pass.
SPF DNS-lookup countCounts the include, a, mx, ptr, exists and redirect mechanisms in the record. Over ten it is flagged, because SPF permits only ten lookups and then returns a permanent error receivers may ignore.
DMARC record presentLooks up the TXT record at _dmarc.yourdomain and checks it declares v=DMARC1. Absent is a warning, with advice to start at p=none rather than jumping to enforcement.
DMARC policy strengthReads p=, pct= and rua=. Flags p=none as monitoring without protection, a pct below 100 as covering only part of your mail, and a missing rua= as no reports on who is sending as you.
DKIM signing keysQueries twelve selectors used by mainstream providers — default, google, selector1, selector2, k1, dkim, mail, s1, s2, smtp, mandrill, mailchimp — at selector._domainkey.yourdomain, and reports which answered.
DNSSECChecks for a DNSKEY record. Without signed DNS answers, a poisoned resolver can point your domain at someone else's server and visitors get no warning, because the padlock belongs to whatever answered.
Unmeasured, not missingEvery lookup returns present, genuinely absent, or unmeasured. If the resolver fails, the check retries over HTTPS; if that fails too, the report says the lookup did not complete and names the reason instead of claiming the record is missing.

Questions

I use Google Workspace or Microsoft 365. Isn't this handled for me?

Partly. Your provider generates the values, but the records are published in your domain's DNS, at your registrar or DNS host, and that step is often skipped or half-done. It is also what quietly breaks when you change provider, add a newsletter tool, or start sending invoices from new software — the old entry stays and the new sender is not covered. An audit reads what is published today, not what was intended.

Will fixing these get my email out of spam?

It removes one of the common reasons, and one of the few you can fix in an afternoon. It is not the only input: sending history, complaint rates, list quality and the content itself all count, and no honest audit can promise inbox placement. What we can tell you is exactly what your domain publishes now and where it is weak.

Do you need access to my DNS or my mailbox?

No. SPF, DKIM and DMARC records are public by design — receiving mail servers have to read them, so we read them the same way. Nothing is installed, nothing is changed, and we see no mail.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.