SPF, DKIM and DMARC: A Guide to Stopping Email Spoofing

Right now, a stranger could sit at their keyboard, type your company domain into the “From” line, and send your finance team an email saying “our IBAN changed, please pay this account instead.” It lands in the recipient’s inbox with your name and your logo on it. The classic email protocol never checks who actually sent a message — writing the sender address is as easy as writing any return address on an envelope.

SPF, DKIM and DMARC are the three DNS records that close that gap. Together they say: “only these servers may send mail for this domain, and what they send can be verified.” The setup looks technical, but the logic is simple.

What each record actually solves

Each answers a different question:

Record	The question it answers	What it looks like in DNS
SPF	Which servers may send for this domain?	A TXT record listing authorised IPs/hosts
DKIM	Was the message altered in transit; is the signature valid?	A cryptographic signature (public key in TXT)
DMARC	If SPF/DKIM fail, what should happen and who gets reported?	A TXT record — policy plus a reporting address

SPF alone isn’t enough, because it breaks when mail is forwarded. DKIM carries a signature but leaves “what if an unsigned message arrives” unanswered. DMARC ties the two together: “the domain in the From line must line up with the domain SPF or DKIM verified — otherwise apply this rule.” That’s called alignment, and it’s the part that actually stops spoofing.

Why this matters right now

These records have existed for years, and most companies ignored them. Not a luxury anymore — a condition of delivery:

• Google and Yahoo, since February 2024, require anyone sending more than 5,000 messages a day to publish at least a p=none DMARC record and pass alignment. Mail that doesn’t comply isn’t delivered.
• Microsoft, from 5 May 2025, made SPF + DKIM + DMARC mandatory for anyone sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses. Non-compliant mail doesn’t even hit the junk folder — it’s rejected outright with a 550 5.7.15 Access denied error.

If you’re under the 5,000 threshold, don’t assume this skips you. The real prize isn’t deliverability — it’s your domain being hijacked. A domain set to DMARC reject can’t be used to send fake mail in your name. It’s the cheapest technical defence you have against fake payment-instruction fraud and executive-impersonation attacks — the cost is a few DNS records.

A note for international readers: Türkiye’s data protection law (KVKK) requires “appropriate technical measures” to secure personal data, and email authentication is squarely one of them — so for Turkish businesses this is a compliance point as well as a security one.

From p=none to reject: without rushing it

The most common mistake is pushing the domain straight to p=reject on day one and throwing legitimate mail (the invoicing system, the newsletter tool, the HR software) in the bin. The right path is gradual:

1. Monitor (p=none). Publish the DMARC record in reporting mode. Nobody is blocked, but you get a daily report of “who is sending mail in your name.” Two to four weeks of observation is usually enough.
2. Clean up. Add the legitimate senders the reports surface (Microsoft 365, accounting software, marketing tools) to SPF and DKIM. The ones you don’t recognise are the spoofers.
3. Quarantine (p=quarantine). Let unverified mail land in spam. Watch for a few more weeks.
4. Reject (p=reject). Now every unverified message is blocked completely. That’s the goal.

For a typical SME the whole process takes one to two months. The price of rushing it is a lost invoice email.

The three mistakes we see most in the field

Plenty of companies set these records up; few set them up correctly. We keep running into the same three snags:

• Multiple TXT records for SPF. A domain can have only one SPF record. Add a new service and open a second v=spf1 line, and you invalidate the first one too. They all have to be merged into a single line.
• Blowing past the 10-DNS-lookup limit in SPF. Every include: counts as a lookup. Between Microsoft 365, accounting software and marketing tools, once you hit the limit SPF silently returns a “permerror” and validation collapses. You have to prune the services you no longer use.
• Leaving DMARC stuck at p=none. The most common one. The record sits in monitoring mode for years and nobody reads the reports. p=none does not block a spoofer — it only sees them. Protection begins only when you move to reject.

There’s also the record published with no report address (rua) at all — then no one sends you reports and you’re flying blind. Small detail, but it’s these details that make the whole difference.

Frequently asked questions

Isn’t SPF alone enough? No. SPF breaks when mail is forwarded and doesn’t verify the “From” line. Real protection comes from all three working together with alignment.

I use Microsoft 365 — isn’t this all automatic? SPF and basic DKIM largely come ready, but you have to publish the DMARC record yourself. If you send from your own domain (@yourcompany.com), you also need to configure DKIM specifically for that domain.

If I set it up wrong, will my mail get cut off? Not while you start with p=none — at that stage nothing is blocked, only reported. You manage the risk as you move through the quarantine and reject steps.

Who reads the reports? The XML files are unreadable. DMARC reports arrive as raw XML and aren’t meant to be read by hand. Routing them to a report-processing tool, or to an IT partner who handles it, is the practical route.

If you don’t know what state your domain is in today, that’s where we start: we check your current SPF, DKIM and DMARC records and lay out a safe migration path. Get in touch and let’s look at your domain’s report card together.