Dutch email deliverability: DMARC, SPF and BIMI traps

It is 23:00 on a Tuesday. The accounts lead at a Utrecht studio fires the weekly invoice reminder batch through the outbound agent. SendGrid logs all 312 messages as delivered. Two days later, half the @kpnmail.nl and @ziggo.nl customers still have not paid. Their reminders sat in spam. The agent did not break. The DNS did.

We see this pattern often enough that it is worth writing down. Dutch outbound email lives in a specific corner of the deliverability world: a lot of @kpnmail.nl, @ziggo.nl, @xs4all.nl, and @planet.nl receivers, plus the usual Gmail and Outlook stack, plus government and bank domains running internet.nl-graded policies. Three traps catch most teams. Here is what they look like and what to do about each.

The DMARC alignment trap

SPF green on mxtoolbox is the comfort blanket that gets every team in trouble. SPF only checks the Return-Path domain, also called the envelope-from or bounce address. Your customer never sees it. They see the From: header, which reads info@yourcompany.nl. When you send through SendGrid, Postmark, or Mailchimp, the Return-Path is something like bounces+xyz@em1234.sendgrid.net. SPF passes for that ESP domain. Your customer's mail server, when it runs DMARC, asks whether the SPF-passing domain and the From: domain share an organisational root. They do not. DMARC fails.

This is alignment. SPF on its own is not enough. You need either SPF alignment (custom Return-Path on your domain) or DKIM alignment (DKIM signature using a selector under your domain). DKIM alignment is the more reliable lever because it survives forwarding through mailing lists and corporate gateways.

The diagnosis lives in the headers. Pull a test message into Gmail, hit "Show original", and read the Authentication-Results line:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@sendgrid.net header.s=s1;
       spf=pass (google.com: domain of bounces+xyz@em1234.sendgrid.net
                 designates 167.89.x.x) smtp.mailfrom=bounces+xyz@em1234.sendgrid.net;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourcompany.nl

Two passes and a fail. The fail is the one that matters. dmarc=fail on header.from=yourcompany.nl with dkim=pass header.i=@sendgrid.net tells you DKIM signed the right thing but with the wrong domain. Fix: set up a CNAME like s1._domainkey.yourcompany.nl to your ESP, sign with that selector, and the next test reads dkim=pass header.i=@yourcompany.nl. Now you have alignment, and DMARC turns green.

The SPF 10-lookup ceiling

SPF has a hard cap of 10 DNS lookups during evaluation, set by RFC 7208 section 4.6.4. Every include:, a, mx, exists, and redirect mechanism counts. Some includes nest other includes, which also count. Cross 10 and SPF returns PermError. PermError is treated as a fail by DMARC unless DKIM alignment carries the message home.

The Dutch SMB stack hits this almost by accident. Google Workspace's _spf.google.com is four lookups on its own. Add a transactional ESP (SendGrid: two), a marketing ESP (Mailchimp: one), a CRM such as ActiveCampaign or HubSpot (one to three), Postmark for receipts (one), and a calendar tool. You have passed 10 without noticing.

Count yours from the terminal:

dig +short TXT yourcompany.nl | grep -i spf
# then paste the record into a lookup counter, e.g.:
# https://www.kitterman.com/spf/validate.html

The cleaner fix is to delegate. Send marketing from news.yourcompany.nl, transactional from mail.yourcompany.nl, and corporate mail from the root. Each subdomain gets its own SPF and DKIM. The root stays clean and the marketing department cannot accidentally break your invoice agent next quarter.

The BIMI rule that surprised us

BIMI puts your logo next to the sender name in Gmail, Apple Mail, and Yahoo. It needs three things: a DMARC policy of p=quarantine or p=reject with pct=100, a logo in SVG Tiny PS 1.2 format, and (for Gmail and Apple Mail) a Verified Mark Certificate from DigiCert or Entrust. The VMC runs about €1,200 to €1,500 per year and requires a registered trademark.

The surprise for us was the trademark side. We assumed any Benelux Office for Intellectual Property registration would do. BOIP coverage exists in the VMC chain, but the trademark image has to match the SVG you submit. A lot of Dutch SMBs have a wordmark registered ("Yourcompany" as text) and a logo that is a stylised figurative mark. The wordmark trademark does not unlock a figurative-mark BIMI. You either re-register the figurative mark (slow, costs €240 minimum for one class at BOIP) or you submit a wordmark-only SVG, which usually looks worse than no logo at all.

Second surprise: Apple Mail's BIMI requires the VMC explicitly. Gmail at one point allowed Common Mark Certificates for unregistered marks, and the rollout there has been patchy. The BIMI Group implementation guidance changes faster than most ops teams check it.

A fifteen-minute audit you can run today

This is the check we run on every new client domain before we wire an outbound agent to it. Open a terminal.

# 1. SPF record. Count the include: directives.
dig +short TXT yourcompany.nl | grep -i spf

# 2. DMARC policy. Look for p= and rua=.
dig +short _dmarc.yourcompany.nl TXT

# 3. DKIM selector (replace s1 with your ESP's selector).
dig +short s1._domainkey.yourcompany.nl TXT

# 4. Send a test to a third-party verifier.
# https://www.mail-tester.com/ gives you a one-off address.
# Forward your outbound to it, read the score.

For the Dutch context specifically, run your domain through internet.nl. It is government-backed, free, and grades you against SPF, DKIM, DMARC, DANE, TLS, and a handful of standards that Dutch government and bank domains do enforce. A score under 80 means at least one of your customers' inboxes is filtering you on policy grounds.

Finally, turn on DMARC aggregate reports. Add rua=mailto:dmarc-reports@yourcompany.nl to your DMARC record. The reports are XML, ugly, and they will tell you within a week which sender is failing alignment and from which IP. You do not have to read them daily. You have to have them when something breaks.

The agent inherits the DNS

An outbound agent that chases invoices, schedules meetings, or sends shipping notifications inherits all three traps from the domain it sends from. The agent code is usually fine. What we see is that the domain's SPF was set up in 2019 for the original web hosting, never touched, and a third ESP was added six months ago by marketing. The agent's first batch tips the lookup count past 10, the marketing emails were already failing DMARC alignment for the previous quarter, and nobody noticed because marketing reads open rates not bounce reports.

When we built the invoice-chasing agent for a Rotterdam logistics client last quarter, the first week ran a 19% open rate. Inbox placement at @ziggo.nl was 31%. Once we sorted the alignment and pruned the SPF record back to four includes, the next batch ran at 64% open with @ziggo.nl placement above 90%. The agent code did not change. The DNS did. This is what the boring half of AI agents actually looks like: the infrastructure under the smart-looking bot.

Pick one of the three traps. Run the dig command. If the answer surprises you, the next thirty minutes of your day just got more useful than the meeting you were going to.