DMARC, SPF and DKIM setup: how to stop criminals spoofing your email domain

Email was designed at a time when everyone trusted everyone: nothing stops a stranger from typing accounts@your-company.com into the “From” field. That is the basis of many phishingPhishingA scam that impersonates a trusted sender (a bank, a supplier, a colleague) by email, text message, phone call or QR code to trick the victim into clicking, handing over credentials or paying. campaigns and of fake supplier or CEO fraudCEO fraudA scam in which a fraudster poses as a senior executive, supplier or lawyer to get an employee to make an urgent, confidential bank transfer to an account the fraudster controls.: your customers receive a message that seems to come from you, with new bank details or a booby-trapped link.

Three DNS records, SPF, DKIM and DMARC, let mailbox providers check that an email really comes from you and reject the rest. They cost nothing, yet they are still poorly applied.

66%

Source: KrakenShield Barometer 2026

That figure, from our barometer of France’s 100 largest cities, shows that even large organisations leave their name open to any fraudster.

Why fraudsters want your domain name

A spoofed email works because it borrows the trust your customers, suppliers and staff place in you. The fraudster does not need to hack your mailbox: it is enough that nobody on the receiving end can check the sender.

The damage goes beyond the fraud itself: defrauded customers turning against you, a tarnished reputation, and your genuine emails landing in spam because your domain was used for junk.

SPF, DKIM, DMARC: three mechanisms, one goal

SPF: the list of authorised senders

SPF (Sender Policy Framework, RFC 7208) is a TXT record published on your domain. It lists the servers allowed to send email for you: your mail service, your newsletter tool, your invoicing software. The receiving server compares the sender’s IP address with that list.

An important limit: SPF checks the technical return address (the envelope, “MAIL FROM”), not the address the reader sees. On its own, it does not stop the displayed address being spoofed.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail, RFC 6376) adds a digital signatureDigital signatureA cryptographic mechanism that proves who signed a document or piece of software and guarantees it has not been altered since. to every email. Your server signs with a private key; the matching public key is published in your DNS under a name called a selector. The receiver checks that the message has not been altered and that it was signed by the domain it claims. Google recommends 2,048-bit keys (1,024 bits at the very least).

DKIM’s advantage: the signature survives forwarding through an intermediary (mailing list, redirect), where SPF often fails.

DMARC: the rules of the game, and the reports

DMARC, whose standard was updated in May 2026 (RFC 9989, replacing RFC 7489), does three things:

1. it requires SPF or DKIM to pass with a domain aligned to the visible “From” address;
2. it tells the receiver what to do with failing messages: none (no special treatment), quarantine (spam folder) or reject;
3. it has the providers that receive email in your name send you reports.

Alignment, the idea that changes everything

A fraudster can easily make SPF pass with their own technical domain while displaying yours in the “From” field. Alignment closes that door: DMARC only passes if the domain validated by SPF or DKIM matches the visible address.

In relaxed mode (the default), billing.example.com is aligned with example.com. In strict mode (adkim=s, aspf=s), the match must be exact.

What Gmail, Yahoo and Outlook.com require

The big mailbox providers have turned these good practices into delivery conditions:

Provider	Since	Who	Main requirements
Gmail	1 February 2024	All senders	SPF or DKIM, spam rate below 0.3%
Gmail	1 February 2024	More than 5,000 messages a day to Gmail	SPF, DKIM and DMARC (p=none accepted), alignment, one-click unsubscribe
Yahoo	February 2024	Bulk senders	SPF and DKIM, DMARC at least p=none, alignment, one-click unsubscribe
Outlook.com, Hotmail, Live	5 May 2025	5,000 or more messages to these consumer services	SPF and DKIM, aligned DMARC at least p=none; otherwise rejection (error 550 5.7.515)

These rules mostly target large senders, and they accept p=none. They improve your deliverability but do not protect your domain on their own: for that, you need to go to quarantine or reject.

Sample DNS records

Here are examples for the fictitious domain example.com, to adapt to your own services:

Mechanism	DNS name (TXT)	Sample value	Purpose
SPF	example.com	v=spf1 include:_spf.mailprovider.example ip4:203.0.113.10 -all	Authorises your mail service and one server, refuses the rest
DKIM	s1._domainkey.example.com	v=DKIM1; k=rsa; p=MIIBIjANBg…	Public key supplied by your sending service
DMARC (monitoring)	_dmarc.example.com	v=DMARC1; p=none; rua=mailto:dmarc@example.com	Blocks nothing, sends reports
DMARC (protection)	_dmarc.example.com	v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com	Rejects fakes, subdomains included

For a domain that never sends email (an old name, a brand domain), lock it down completely:

example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

Rolling out DMARC without blocking your own mail

Jumping straight to p=reject is the surest way to make your invoices or newsletter vanish. The right method is gradual.

Step 1: inventory. List everything that sends email in your name: mail service, website forms, newsletter, CRM, invoicing or payroll software, helpdesk, printers and copiers that email scans.

Step 2: SPF and DKIM everywhere. Add each service to your SPF record and enable DKIM with your domain (any serious provider supplies the records to publish).

Step 3: DMARC in monitoring mode. Publish p=none with a rua address. Mailbox providers will send you aggregate reports, usually daily, in XML: which IP addresses sent email in your name, how many messages, and with what SPF, DKIM and DMARC results. These files are unreadable by eye, so use a DMARC report analyser. If the rua address belongs to another domain (a provider’s), that domain must authorise it in its DNS; your provider usually takes care of this.

Step 4: fix. For each legitimate source that fails, fix SPF or DKIM. Whatever still fails and you do not recognise is spoofing: proof that the protection is worth it.

Step 5: quarantine, then reject. Once the reports have shown no failing legitimate mail for several weeks, move to p=quarantine, watch again, then move to p=reject.

Common pitfalls

• Two SPF records. When adding a service, people often create a second v=spf1 TXT record. The standard then requires a permanent error: SPF fails for all your messages. Merge everything into one record.
• More than 10 DNS lookups. SPF caps at 10 the mechanisms that trigger a DNS query (include, a, mx, ptr, exists, redirect), including those inside nested includes. Beyond that: permanent error. Remove abandoned services, replace what you can with ip4 or ip6, or give your newsletter its own subdomain.
• Forgotten subdomains. Without sp=, your subdomains follow the p policy. A subdomain that sends mail (for instance news.example.com) needs its own SPF and DKIM signature. The 2026 standard also adds np= for subdomains that do not exist, a favourite of fraudsters.
• Forgotten sending services. Newsletter, CRM, invoicing, recruitment, ticketing: any tool that sends with your address without aligned DKIM will be blocked as soon as you reach quarantine. DMARC reports exist precisely to flush them out.
• An over-permissive SPF. +all lets the whole planet send for you: never use it.

Checking your set-up

A checklist to run every quarter, and whenever you add a sending service:

• A single v=spf1 TXT record on the domain, ending in -all or ~all.
• Fewer than 10 DNS lookups in SPF, nested includes included.
• DKIM active for every sending service, signed with your domain, 2,048-bit key where possible.
• A _dmarc record with a rua address that actually receives reports.
• A quarantine or reject policy, with a target date if you are still on p=none.
• Dormant domains locked down (v=spf1 -all and p=reject).
• A real test: send an email to a Gmail or Outlook.com mailbox and view the original; the lines spf=pass, dkim=pass and dmarc=pass should appear.

For an outside view, KrakenShield’s privacy audit checks, among other things, whether your SPF and DMARC records exist and what policy they apply, with the fixes to make.

Your attack surfaceAttack surfaceAll the points through which an attacker can try to get into your information systems or extract data from them: internet-facing services, applications, accounts, devices, suppliers and people. is not limited to your servers: your domain name is part of it. A few well-placed DNS lines are enough to stop it being used as a weapon against your own customers.