Just the Facts · Article
Anyone can send email as you
The finding furthest from "website" in most people's minds, and the one with the most immediate real-world cost: invoices from your domain that you didn't send, and your own mail landing in spam. Three DNS records, one afternoon, permanent.
By default, the email system lets anybody claim to be anybody. Nothing stops a stranger sending a message that appears to come from your domain — to your customers, your suppliers, or your accounts department, with your name on it.
Three DNS records fix that. They are not a website change, they cost nothing, and once set they keep working.
The three records, in plain terms
- SPF is a published list of who is allowed to send email using your domain — your mail provider, your newsletter tool, your invoicing system.
- DKIM adds a cryptographic signature to each message so a receiving server can confirm it really came from you and wasn't altered on the way.
- DMARC is the one that matters most and the one almost everyone gets wrong. It tells receiving servers what to do when a message fails the first two — and it's where you'll also start getting reports about who is sending mail as you.
The mistake nearly everyone makes
DMARC has three settings: none, quarantine, and reject. "None" means monitor only — it explicitly tells every receiving server in the world to take no action when a message fails. A domain sitting at "none" looks configured, passes a superficial check, and provides no protection whatsoever. That is where the large majority of small-business domains sit, usually because someone set it up years ago intending to review the reports and never did.
We can show you this from the inside
While writing this we checked our own four sending domains. They sat at four different levels of maturity, and the progression is the article:
- One domain was at full enforcement — failing mail rejected outright, reports flowing to three collectors, alignment settings explicit. That one had earned it: it went to enforcement only after months of reports came back clean.
- A second sat one notch below, at quarantine, with the same reporting.
- A third — the domain this very website runs on — was at monitor-only with a single report address. Correctly signed, properly authenticated, and telling the world to do nothing about failures anyway.
- The fourth was the weakest: a bare monitor-only record with no reporting address at all, and no sender list published on the main domain.
Same owner, same registrar, same email provider, four different postures. That's not negligence — it's what happens when records get set up at different times for different reasons and nobody goes back. It's almost certainly true of your domains too.
How to do it without breaking your own mail
The risk in tightening DMARC is real and worth naming: if some legitimate sender you've forgotten about isn't properly listed — an old newsletter tool, a form handler, a billing system — moving straight to "reject" starts silently killing its mail.
- Start at monitor-only with a real reporting address, and actually read the reports for a few weeks. They tell you every system sending as you, including ones you'd forgotten.
- Fix whatever the reports surface — usually one or two legitimate senders missing from your list.
- Move to quarantine. Failing mail goes to spam rather than the inbox, so a mistake is recoverable.
- Once quarantine is quiet, move to reject. That's the finish line, and getting there in three steps rather than one is the whole trick.
If you take one thing from this: go and look at whether your DMARC record says p=none. If it does, you have the appearance of email security and none of the substance — and you're in the majority.
Technical guidance, not legal advice. Tightening a DMARC policy can affect delivery of mail from senders that are not correctly authorised — follow the staged approach above rather than jumping to enforcement.
Sources
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 7208 — Sender Policy Framework (SPF)
- RFC 6376 — DomainKeys Identified Mail (DKIM)
- CISA — Enhance Email and Web Security guidance
- Our own four sending domains, read from live DNS, August 2026
More from Just the Facts
- Is Any of This Actually Real?
- How Real Is the Threat? A By-the-Numbers Risk Assessment
- Who's Really Suing — CIPA Website-Wiretap Filers
- When the Court Reins One In: the Vivek Shah Vexatious-Litigant Ruling
- The Demand-Letter Economy
- Verifying Licensed Images, Fonts & Video
- Copied Content: Plagiarism, Copyright & the Hidden SEO Risk
- Passwords, Backups & VPNs: the security that decides whether a breach sinks you
- Website accessibility is the most-sued thing on the internet
- Your cookie banner probably isn't doing anything
- The instructions your website isn't giving the browser
- Three real demand letters, eighteen years apart
- The privacy signal your site is ignoring
- Code you didn't write, running on your site tonight
- Three documents nearly every site gets wrong
- What an accessibility statement is actually for
- Cookies without locks