Three DNS Records That Decide Whether Anyone Can Send Email As You

Email was designed in the early 1980s among people who all knew each other. Nothing in the original protocol verifies that a message came from who it claims to have come from. The From field is, at the protocol level, a text field. Anyone can type anything into it.

Three DNS records were added over the following decades to patch that hole. Together they determine whether a stranger can send email that appears to come from your company — to your customers, your vendors, and your staff.

The companion piece covered how business email compromise actually works and the $3.05 billion it cost US businesses last year. This one covers the technical layer, in plain language, with an honest account of what it does and does not solve.

The Three Records, Briefly

The critical detail, and the one most often missed: SPF and DKIM do nothing on their own. They produce a pass or fail result that receiving servers are free to ignore. DMARC is the record that tells them what to do about it — and without DMARC set to an enforcing policy, the other two are largely advisory.

SPF: The Authorised Sender List

SPF (Sender Policy Framework) is a DNS record listing which mail servers may send on your domain’s behalf. Your email provider, your invoicing platform, your CRM, your newsletter tool.

A receiving server checks the sending server’s IP against that list. Not on the list, SPF fails.

The common failure: SPF has a hard limit of ten DNS lookups. Every service you authorise consumes at least one. Businesses that accumulate services over the years — email provider, then a booking tool, then a marketing platform, then an accounting system — quietly cross that limit. Past ten, the record becomes invalid and SPF stops working entirely.

There is no warning. Mail still flows, mostly. The protection simply stops.

The second failure, subtler: SPF validates the envelope sender, which is invisible to your recipient. It does not validate the From: address they actually see. A message can pass SPF and still display a From address belonging to your company. On its own, SPF does not stop the thing most people assume it stops.

DKIM: The Tamper-Evident Seal

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message. The public key lives in your DNS. A receiving server verifies the signature against it.

A valid signature proves two things: the message was signed by someone holding your private key, and the signed portions were not modified in transit.

The common failure: DKIM is enabled at the provider but the DNS record was never published, or was published with a typo, or the key was rotated and the record was not updated. Signing appears active in the admin panel while verification fails at every recipient.

The limitation: like SPF, DKIM proves something narrow. It says a message carrying this signature is legitimate. It says nothing about what should happen to a message without one — an attacker simply sends unsigned mail.

DMARC: The Instruction

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two things nothing else does.

First, it introduces alignment: it requires that the domain validated by SPF or DKIM actually matches the domain in the visible From: address. This is what closes the gap described above.

Second, it publishes a policy — an instruction to receiving servers:

• p=none — Take no action. Report only.
• p=quarantine — Send failures to spam.
• p=reject — Refuse failures outright.

The gap that matters

Here is the finding that reframes the whole subject, and the reason this article exists.

Adoption surveys disagree substantially on the exact numbers — published 2026 figures for global DMARC adoption range from roughly 30% to 58% depending on which domains were sampled and how. We are not going to pretend to a precision the data does not support.

But every source agrees on the shape: a large majority of domains that have DMARC are sitting at p=none.

EasyDMARC’s 2026 adoption report found 937,931 domains with valid DMARC records, of which 525,996 — more than half — remain at p=none. Independent scans reach the same conclusion by different routes.

p=none provides zero protection against spoofing. It is a monitoring mode. It generates reports and blocks nothing.

This is the trap. A business asks whether they have DMARC, gets told yes, and reasonably concludes they are protected. The record exists. It is doing nothing. Publishing p=none and stopping there is the email-security equivalent of installing a smoke detector and never connecting the alarm.

The gap is widest exactly where it hurts most. Fortune 500 domains reach roughly 93% DMARC adoption with around 63% at enforcement. Smaller organisations publish records at similar rates but reach enforcement far less often — the Inc. 5000 sits near 15% at p=reject.

Why p=none Is Still the Right Place to Start

Having criticised it, an important qualification: you should not jump straight to p=reject.

Set enforcement before you know every legitimate source of mail for your domain, and you will block your own invoices, your booking confirmations, and your newsletter. The staged path exists for good reason:

1. Publish p=none with aggregate reporting enabled. Reports arrive showing every server sending as your domain. Almost every business finds a surprise here — a forgotten service, a shadow tool a department signed up for.
2. Fix what should pass and does not. Authorise legitimate senders properly. Resolve SPF lookup overruns. Verify DKIM is actually signing.
3. Move to p=quarantine. Failures go to spam rather than the inbox. Recoverable if something was missed.
4. Move to p=reject once reports are clean.

A reasonable timeline is 90 days to quarantine and 180 to reject. The failure mode is not starting at p=none — it is stopping there. The record gets published, the reports go unread, and two years later the business believes it is protected.

What This Protects, and What It Does Not

Worth being precise, because this is routinely oversold.

These records protect your domain from being impersonated. Someone cannot easily send mail that appears to come from @yourcompany.com to your customers.

They do not protect you from:

• A compromised mailbox. If an attacker logs into a real account, their mail is genuinely from your domain and passes every check. This is why MFA matters more than DNS records.
• Lookalike domains. yourcompany-inc.com is a different domain. Your DMARC policy has no authority over it. It has its own records and can be perfectly authenticated.
• Inbound fraud generally. These are outbound-reputation controls. They protect your recipients from fake mail claiming to be you; they do not filter what arrives in your inbox.

That second point deserves emphasis, because it is the honest limit of the whole exercise. Full DMARC enforcement does not stop business email compromise. It closes one specific avenue — exact-domain spoofing — while attackers move to lookalike domains and compromised accounts, which are now the more common approaches.

DMARC is genuinely worth doing. It is not the answer to BEC. Anyone selling it as one is overstating the case.

The Deliverability Argument

There is a second reason to do this that has nothing to do with security.

Google and Yahoo introduced authentication requirements for bulk senders in February 2024, and Microsoft followed in May 2025. Google escalated to SMTP-level rejection of non-compliant mail in November 2025.

The thresholds nominally target high-volume senders, but the drift is unmistakable: authentication is becoming a precondition for inbox placement rather than a bonus. Businesses whose invoices land in spam frequently have an authentication problem rather than a content problem.

Checking Your Own Configuration

You can assess this yourself in about ten minutes.

1. Look up your records. Any public DMARC or SPF checker will show what your domain currently publishes for all three.
2. Read the DMARC policy tag. Find p=. If it reads p=none, you have monitoring, not protection. If there is no DMARC record at all, you have neither.
3. Count your SPF lookups. Most checkers report this. Above ten and the record is invalid.
4. Confirm DKIM verifies. Send yourself a message at a different provider and inspect the headers for a DKIM pass.

If all four come back clean and you are at p=reject with reporting enabled, you are in the minority — fewer than 1 in 11 analysed domains meet that bar. Nothing here needs your attention.

The Summary

Email has no built-in identity verification. Three DNS records add it. Most businesses have some of them, partly configured, at a policy level that instructs receiving servers to do nothing.

The work is not difficult and does not take long. It does require someone to read the reports and finish the job — which is the step that gets skipped, and the reason half a million domains are sitting at p=none believing they are covered.

If you would like us to check what your domain currently publishes and tell you where you actually stand, we will look and give you the plain answer — including if it is that you are already fine.