Domain security

Domain security

Someone can send email as you.

Unless your domain says otherwise, anyone can put your address in the From field and receiving servers have no grounds to refuse it. Invoice fraud in your name starts here.

Who can change this
Whoever operates your DNS. All three are TXT records, and publishing them is minutes of work.
Who decides
You, and only you — enforcement depends on knowing every system that sends mail as your domain, which no provider can know for you.

What the three records do

They answer different questions, and a receiving server needs all three to act confidently.

  • SPF lists the servers allowed to send using your domain.
  • DKIM signs outgoing messages, so a receiver can verify they were not altered and genuinely came from your platform.
  • DMARC ties the two to the address the reader actually sees, and tells receivers what to do when a message fails — plus sends you reports about who is sending as you.

Why p=none protects nobody

A DMARC record can be published at p=none, which means: check this message, tell me what you found, and deliver it either way. It is the correct place to start and a bad place to stop.

Plenty of domains have sat at p=none for years. The owner believes DMARC is "done" because a record exists. Forged mail in their name still arrives, because nothing has ever been instructed to reject it.

Getting to enforcement without breaking your own mail

This is the part that takes weeks, and the part that cannot be skipped. The risk is not technical failure — it is blocking your own invoices.

  1. Publish p=none with a rua= address. Nothing changes about delivery; reports start arriving.
  2. Read them for a few weeks. They will name senders you had forgotten: the accounting system, the newsletter tool, a form plugin, a CRM, something somebody connected last year.
  3. Bring each legitimate sender into alignment, through SPF or DKIM, until the reports show nothing failing that should pass.
  4. Move to p=quarantine, then p=reject. Only once the reports are clean.

Watch the SPF lookup limit while you do this. SPF permits ten DNS lookups; each service you add usually costs one. Past ten, SPF fails for every message you send — silently. Connecting an AI assistant to a mail service is a common eleventh; see AI agents.

The half nobody mentions

Publishing DMARC protects other people from mail forged in your name. It does very little for your own inbox.

What protects you is your mail platform acting on other domains' policies — rejecting or quarantining inbound mail that fails their authentication, rather than delivering it with a small warning nobody reads. Both halves are worth doing, and they are different settings in different places.

What enforcement will never stop

DMARC at p=reject stops someone sending from your exact domain. It does nothing about:

  • Lookalike domains. A name one character off yours, or with a different extension, is a different domain — correctly authenticated, owned by an attacker.
  • Display-name spoofing. The name shown on a phone is often all a reader sees, and it can say anything regardless of the address behind it.
  • A real account being compromised and used to send genuine mail.

So enforcement removes the free, no-skill attack and leaves the ones that take effort. That is worth doing, and it is not the same as being safe.

Check your domain

It reports this alongside everything else your domain publishes. Free, and no email address is required.