SPF, DKIM and DMARC: Why Unauthenticated Email No Longer Gets Delivered

Most businesses think of email security as filtering what comes in. Just as important is proving what goes out. Email authentication is how you stop criminals from sending mail that pretends to be you, and it has quietly become a condition of getting your legitimate mail delivered at all.

Anyone can put your name on an email

The protocol that moves email around the internet was designed decades ago, and on its own it does not check that a sender is who they claim to be. Unless you tell the world otherwise, anyone can send a message with your domain in the From address.

Criminals use this constantly. A spoofed invoice that appears to come from your accounts address, sent to a customer who has paid you before, is one of the most reliable fraud techniques there is. The customer loses money, and you lose the relationship, even though your own systems were never touched.

The big mailbox providers stopped asking nicely

For years, authentication was a best practice that many businesses ignored. That has changed.

Google and Yahoo began enforcing authentication requirements for bulk senders in early 2024. Microsoft followed: since 5 May 2025, senders of high volumes of mail to Outlook.com, Hotmail and Live addresses must pass SPF, DKIM and DMARC checks, and non-compliant messages can be rejected outright rather than landing in junk.

The thresholds target bulk senders, but the direction of travel affects everyone. Mailbox providers increasingly treat unauthenticated mail as suspicious by default, so quotes, statements and password resets from a domain with no authentication records are more likely to be filtered or silently dropped. Deliverability is now a business issue, not a technical footnote.

What the three records actually do

All three are DNS records, published once for your domain and checked automatically by every receiving mail server.

SPF

The Sender Policy Framework record lists the servers and services that are allowed to send email on behalf of your domain. If a message arrives from anywhere else, the receiver knows something is off.

DKIM

DomainKeys Identified Mail adds a cryptographic signature to each outgoing message. The receiver uses your published key to confirm the message really came from an authorised system and was not altered in transit.

DMARC

DMARC is the policy that ties the other two together. It tells receiving servers what to do when a message fails the checks: do nothing, send it to junk, or reject it. Crucially, at least one of SPF or DKIM must also match the domain shown in the From address, which is what stops an attacker from passing checks with their own domain while displaying yours. DMARC also sends you reports showing who is sending mail as your domain, legitimate or not.

Roll it out in stages, not in one go

The most common mistake is jumping straight to a strict policy and breaking your own mail flow. The second most common is publishing a monitoring-only policy and never tightening it. A sensible path looks like this:

1. Inventory your senders. Microsoft 365 is rarely the only system sending as your domain. Accounting and payroll platforms, marketing tools, CRMs, ticketing systems and even scan-to-email copiers all count.
2. Publish SPF and enable DKIM for each legitimate service, using the settings each vendor provides.
3. Start DMARC in monitoring mode (a policy of none) and review the reports for a few weeks. This shows you legitimate senders you forgot about, and any abuse already happening.
4. Tighten gradually. Fix the legitimate senders that fail, move to quarantine, confirm nothing breaks, then move to reject.

At reject, mail that fails authentication is refused before it ever reaches an inbox. That is the point where spoofing your exact domain stops working.

What DMARC will not do

A strict DMARC policy stops criminals from using your exact domain. It does not stop lookalike domains, where an attacker registers a near-identical name and builds their own valid records, and it does not help if one of your real mailboxes is compromised. Those risks are addressed by multi-factor authentication, monitoring and staff awareness. Authentication is one layer in a stack, not a silver bullet.

Why this matters in SA, the UK and Europe

Under POPIA and GDPR, businesses are expected to take reasonable, appropriate measures to protect personal information, and email is where much of it travels. Beyond compliance, DMARC status is increasingly asked about in supplier questionnaires, tenders and cyber insurance applications. It is one of the few controls an outsider can verify from the outside, which means your customers and partners may already be checking yours.

The takeaway

Three DNS records decide whether the world can trust email from your domain, and whether mailbox providers will keep delivering it. If you do not know what your DMARC policy is today, that is the first question worth asking, and moving from no policy to reject is a measured project rather than a leap. It is exactly the kind of work a security-focused IT partner can run for you with monitoring in place from day one.