SPF, DKIM and DMARC: An SMB Setup Guide

Email phishing remains, by the Dutch National Cyber Security Centre's own account, the single most common way attackers get into an organisation's systems or steal data from it. A large share of that starts with something deceptively simple: a message that appears to come from a domain the recipient already trusts — a supplier, a colleague, or your own company's address on an invoice. Without any authentication in place, nothing stops an attacker from putting your domain in the From address of a message you never sent, and a client who trusts that address is exactly the client who pays a fraudulent invoice without a second thought. Three DNS-based standards close that gap: SPF, DKIM and DMARC. None of them are new, but two things have sharpened the case for setting them up properly. First, Google and increasingly Microsoft now refuse or spam-flag mail from domains that don't meet a published authentication bar, which affects ordinary business email, not just mass marketing. Second, NCSC treats missing email authentication as a real security gap for any organisation, not a technicality reserved for large enterprises. This guide explains what each standard actually checks, where the legal line sits in the Netherlands, and how to roll all three out without breaking your own mail flow.

What SPF, DKIM and DMARC actually check

The three standards work together, but they check different things:

• SPF (Sender Policy Framework) lets a domain publish a DNS record listing exactly which mail servers are allowed to send email on its behalf. A receiving server checks the IP address a message actually arrived from against that list.
• DKIM (DomainKeys Identified Mail) has the sending server attach a digital signature to each outgoing message, generated with a private key. The receiving server fetches the matching public key from DNS to confirm the message really came from an authorised server and wasn't altered in transit.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It publishes a policy telling receiving mail servers what to do with a message that fails SPF and DKIM against your domain — accept it anyway, mark it as spam, or refuse it — and it can email you regular reports of what passed and what didn't.

Why all three, and not just one? SPF checks a technical sender field a recipient never actually sees; the address a person reads in their inbox is separate, and SPF alone does nothing to protect it. DKIM's signature proves a message wasn't tampered with, but a forged message from outside your domain simply won't carry your signature, so DKIM alone doesn't force a receiving server to reject it either. DMARC is what ties authentication back to the address a person actually sees and gives receiving servers an instruction for what to do when it fails. SPF and DKIM without DMARC is verification machinery with no instructions attached.

Why this now affects ordinary business email, not just bulk mail

Since 1 February 2024, every domain sending mail to personal Gmail addresses (@gmail.com and @googlemail.com) has had to have SPF or DKIM configured, regardless of volume. Domains sending 5,000 or more messages a day to Gmail addresses face a stricter bar on top of that:

Messages that don't meet the applicable bar can be rejected outright with error code 5.7.26, or routed to spam without warning. Google also sets a minimum DKIM key length of 1024 bits for mail to personal Gmail accounts, and recommends 2048 bits wherever your domain provider supports it. NCSC's own guidance confirms the same direction from the other large providers: Yahoo has matched Google's bulk-sender requirements since 2024, and Microsoft tightened its own checks on Outlook mail further during 2025.

Most Dutch SMEs never personally hit 5,000 messages a day from their own mail client. But that count includes your invoicing system, CRM or marketing platform, and helpdesk tool — anything configured to send as your domain. A small company running a newsletter tool and an invoicing platform alongside normal staff email can cross that line without anyone noticing, and the fix, once you know which service is responsible, is usually a five-minute DNS change.

Is this a legal requirement in the Netherlands?

Not for a private company, and it's worth being precise rather than assuming otherwise. NCSC's own guidance draws a clear line: for government organisations, SPF, DKIM and DMARC are mandatory, and Forum Standaardisatie runs periodic measurements to check compliance. For every other organisation, including every Dutch SME, NCSC's own language is a "dringend advies" — an urgent recommendation, not a legal duty. There is no general Dutch law requiring a private business to authenticate its outgoing email.

That distinction shouldn't change what you actually do, though. Gmail and Outlook already enforce their own version of it for their users, and your customers overwhelmingly use one of the two. A recommendation two of the world's largest mail providers back with an actual rejection code is, in practice, close enough to mandatory that the legal distinction is mostly academic for a business that wants its invoices to arrive.

Setting it up in an order that doesn't break your mail flow

The single most common way this goes wrong is publishing a strict DMARC policy before you know everything that legitimately sends mail as your domain. Work through it in this order instead:

• 1. List every system that sends email as your domain. Not just your mail server — invoicing software, marketing or newsletter platform, helpdesk tool, accounting package, CRM, and anything internal like a scanner that emails documents. Missing one here is the single biggest cause of legitimate mail breaking later.
• 2. Publish an SPF record listing all of them. A domain's SPF record is one DNS TXT entry naming the servers and third-party services authorised to send on its behalf — for example, a domain using Google Workspace and one invoicing platform might publish something close to: v=spf1 include:_spf.google.com include:[invoicing platform's own SPF include] -all. Every sender from your inventory needs to appear here.
• 3. Turn on DKIM signing for each sending system that supports it. Google Workspace, Microsoft 365 and most invoicing or marketing platforms have a DKIM setup step in their own admin settings, which publishes the public key to your DNS and starts signing mail automatically.
• 4. Publish a DMARC record starting at the loosest policy, "none." Nothing about delivery changes at this setting, but you start receiving the aggregate reports DMARC generates, showing exactly what's passing and failing before you touch enforcement.
• 5. Read the reports for a few weeks and fix what they reveal. This is what the order above exists for: it surfaces a forgotten sending source while it still costs nothing to fix.
• 6. Move the policy from "none" to "quarantine," then eventually "reject" once every legitimate sender in your inventory is passing consistently.

Mistakes that break mail flow

• Forgetting a legitimate sender in the SPF record. A newsletter tool or invoicing platform left out starts having its mail marked as spam or bounced, and because the platform itself isn't broken, this often gets misdiagnosed as the tool's fault rather than the DNS record's.
• Jumping straight to a "reject" DMARC policy. Skipping the monitoring period in step 4 all but guarantees you'll block something legitimate, and you'll usually hear about it from an angry customer rather than a report.
• Treating DKIM as sufficient on its own. A forged message from outside your domain won't carry your DKIM signature — that's expected. The actual gap is that without DMARC, nothing tells the receiving server that mail failing SPF and DKIM should be treated with suspicion at all.
• Only protecting the domains you actively send from. NCSC's guidance is explicit that every domain name your organisation owns should carry SPF, DKIM and DMARC records, including a parked domain you never send mail from, because an attacker can spoof mail "from" an inactive domain just as easily as an active one.

FAQ

Is DMARC mandatory in the Netherlands? Only for government organisations, where NCSC and Forum Standaardisatie treat it as a requirement with periodic compliance checks. For private companies, including SMEs, it's an urgent recommendation from NCSC rather than a legal duty, though Gmail and Outlook enforce their own versions of it regardless of what Dutch law says.

What's the actual difference between SPF, DKIM and DMARC? SPF authorises which servers can send mail for your domain. DKIM cryptographically signs outgoing mail so tampering can be detected. DMARC ties both back to the address a recipient actually sees and tells receiving servers what to do with mail that fails — which is why all three are needed together.

What happens if I don't have SPF or DKIM set up? For mail sent to personal Gmail addresses, Google requires at least one of the two as of 1 February 2024. Mail that doesn't meet this can be marked as spam or rejected outright with error code 5.7.26, regardless of your sending volume.

Do I need to jump straight to a DMARC "reject" policy? No, and you shouldn't. Start with "none" so you can see what the aggregate reports reveal about your actual mail flow before you risk blocking anything legitimate.

Does setting this up cost anything? The standards themselves are free DNS records. The real cost is the time to inventory every system sending mail as your domain and configure DKIM on each one — usually a few hours of focused work, though a domain sending from many platforms takes longer to get right.

Get your domain properly protected

Getting SPF, DKIM and DMARC right takes an accurate inventory of everything that sends mail as your domain and a DNS change for each one — exactly the kind of task that's easy to defer until a client complains an invoice never arrived. Our Cybersecurity & Identity service covers this as part of a wider email and domain security review, including the DMARC monitoring period and moving your policy to full enforcement safely. If your mail runs through Microsoft 365, our guide to setting up MFA in Microsoft 365 covers the other side of protecting that same mailbox from compromise. And if you'd rather have your whole IT environment looked at together, our Managed IT Support team can fold DNS and email security into routine upkeep rather than a one-off fix.