Module 4 · 4.1

English

Nederlands English Deutsch Français

Why mail ends up in spam

Module 4: Deliverability: SPF, DKIM and DMARC in practice · Reading time: 10 minutes

Learning objective: After this lesson you can name the four layers on which a recipient judges incoming mail, explain why "it arrives fine for me" proves nothing, and use a test to work out which layer a problem sits in.

Key concepts: deliverability, delivery vs. inbox placement, technical cleanliness, authentication (SPF, DKIM, DMARC), alignment, IP reputation, domain reputation, content, recipient behaviour (complaints, opens, deletions), per-recipient filters, Authentication-Results, test email, measurement tools

Delivered is not the same as arrived

If your server has handed over a mail to the recipient's server, and that server replied with 250 OK, the mail has been delivered. That doesn't yet tell you whether it's sitting in the inbox. The receiving server can still put it in the spam folder, in a "Promotions" tab, in quarantine, or even quietly discard it.

Deliverability is about that second step: does your mail end up where it should? And every recipient decides that for themselves. Gmail weighs things differently to Microsoft, and a company with its own spam filter differently again. There's no central rulebook. But the layers they judge on are roughly the same everywhere.

Layer 1: technical cleanliness

Before a filter looks at the content, it looks at the connection:

Does the sending server's IP address have a clean reverse DNS (PTR) that points back to the same address? (Lesson 5.1.)
Does the server introduce itself properly with a real name in EHLO?
Is the connection encrypted with TLS?
Does the server follow the rules of SMTP, and does it retry after a temporary rejection?

With a mailbox from a hosting company or a large mail service, this is almost always in order. It becomes an issue if you run your own server, such as a VPS that sends mail directly, or a printer or camera that sends mail by itself.

Layer 2: authentication

This is the layer where you, as the domain administrator, have the most influence, and what this module is about:

SPF (lesson 4.2): is this server allowed to send mail on behalf of the domain?
DKIM (lesson 4.3): is the mail signed, and is the signature valid?
DMARC (lesson 4.4): does the successful check belong to the domain in the From address (alignment), and what should the recipient do if it doesn't?

The basics of these three records are covered in the DNS course, module 4. Here it's about practice: getting a clear view of all the services that send mail on your behalf, and tightening the policy step by step.

If authentication is missing, the assessment drops. Since 2024 and 2025 it has also become a hard requirement at the major providers: Gmail, Yahoo and Microsoft want at least SPF or DKIM from everyone, and from bulk senders SPF, DKIM and DMARC with alignment. This is covered in detail in lesson 5.3.

Layer 3: reputation

A recipient remembers what it received from a sender before. It looks at:

IP reputation: what has come from this IP address before? With shared hosting and large mail services, many senders share one IP; a single bad sender can then affect everyone. A new IP with no history is treated cautiously.
Domain reputation: what has come from this domain before (the domain in the From address and the DKIM domain)? This carries more and more weight, precisely because DKIM and DMARC make a domain reliably recognisable. A good domain reputation travels with you if you switch servers.
Blocklists: public lists of IP addresses or domains that have sent spam (lesson 5.2).

Reputation is built up slowly and lost quickly.

Layer 4: content and behaviour

Only as a last step does a filter look at the mail itself, and at what recipients do with it:

Content: links to domains with a poor reputation, shortened links, nothing but a large image with no text, attachments with macros, a subject that has nothing to do with the content, broken formatting.
Recipient behaviour: this carries the most weight at the major mail services. If many recipients click "This is spam", your reputation drops. If your mails are opened, replied to, or rescued from the spam folder, it rises. Gmail wants fewer than 0.3% of recipients to mark your mail as spam, and preferably fewer than 0.1%.

The idea that individual "spam words" like free or offer block your mail is largely a myth. Modern filters weigh everything together. A newsletter containing the word free from a sender with good authentication and a good reputation arrives just fine; a perfectly polite text from an unknown server without SPF does not.

Why "it arrives fine for me" proves nothing

You send a test email to your own Gmail address and it lands in the inbox. So everything's fine? Not necessarily:

You've probably exchanged mail with that address before. A filter trusts a sender it has had contact with more.
One recipient isn't the same as another. Microsoft might reject a mail that Gmail accepts.
One mail isn't a thousand. A newsletter to a thousand addresses is judged differently from a single mail.

A test email is useful, but mainly for reading the header fields (lesson 1.5). They show exactly what the recipient found:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=x header.b=Ab12Cd34;
       spf=pass (google.com: domain of info@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=info@example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Here all three pass. If you see spf=softfail, dkim=none or dmarc=fail, you know which layer to look in. That way you pin down the problem instead of guessing.

A three-step approach

Check your DNS with a tool that looks at MX, SPF, DKIM, DMARC and blocklists. Examples: WebOké's Email check and Domain health, internet.nl, MXToolbox. These show what's in the DNS, but not how a real mail is actually judged.
Send a real test email to an address at Gmail and at Outlook.com, or to a testing service such as mail-tester, and read the header fields or the report. This shows whether the mail actually passes SPF, DKIM and DMARC in practice.
Look at reputation and behaviour if the technical side checks out: is your IP on a blocklist? Are you sending newsletters to people who asked for them? As a large-volume sender, you can also keep an eye on things via Google Postmaster Tools and Microsoft SNDS.

In practice: what this looks like in a panel

On the WebOké website you'll find the free Email check (www.weboke.lt/en/email-check): you enter a domain and see a score covering MX, SPF, DMARC and the blocklist check of the first mail server, with advice. In My WebOké, Domain health checks the same things for your own domains, with fix buttons. These are two tools among many; internet.nl and MXToolbox run comparable checks, and every provider has its own version. Use a few side by side: no single tool sees everything.

Summary

Delivered only means the receiving server has accepted the mail; whether it reaches the inbox is up to the recipient.
Recipients judge mail across four layers: technical quality, authentication, reputation and content/behaviour.
Authentication (SPF, DKIM, DMARC) is within your own control, and a hard requirement at the major providers.
Recipient complaints weigh more heavily than individual words in your text.
Read the Authentication-Results header field of a test email to see where things go wrong.

Quiz

Exercise

Exercise Z4.1: Running your domain through the email check. Enter your own domain (or, if you don't have one, internet.nl). The program checks MX, SPF, any DKIM selectors it can find, DMARC and the blocklist check of the first mail server. Then fill in for yourself: what SPF ending the domain has, what DMARC policy, and whether the first mail server is on a blocklist. The program places your answers next to the live result. Explain in one sentence which of the four layers your domain has the most room to improve in.

Verder lezen

The steps in these articles apply to WebOké's panels; with other providers it works in a similar way.

Cookies at WebOké

Cookie settings

Necessary

Marketing