Anyone can send email as your domain, until you publish these records

A domain name carries no built-in proof that a message came from it. SMTP moves mail between servers that agree to cooperate; it verifies nothing about the author, so anyone can put your address in the From line and the receiver has no statement from you to test it against. SPF, DKIM and DMARC are that statement. Until they exist, your domain is a name anyone may borrow.

Why can anyone send email as your domain?

Because the protocol separates the claim from the credential. The address mail is delivered from — the envelope sender — is a value the sending server declares; the From line the reader sees is a header the sender writes. Neither is checked by SMTP. A receiver can only ask your domain, in DNS, what it expects and what to do with the rest. There is no certificate authority in this path.

What does SPF actually prove?

SPF lists the servers allowed to send for a domain, and the receiver compares the connecting server against that list. One TXT record, v=spf1, mechanisms such as include: and ip4:, ending in -all or ~all, is the whole of it.

It proves the path, not the message: a pass means this server was permitted, not that the content is intact. Two consequences follow. SPF breaks on forwarding, because the forwarder becomes the sender and is not on your list. And it has a lookup budget — exceeding it returns an error that most receivers read as no SPF at all.

Why can a name have only one SPF record?

Because the specification permits one, and two do not merge: they invalidate each other. Two TXT records beginning v=spf1 leave the receiver no rule for choosing between them, and the result is an error.

It usually happens in a migration — the old host's record stays and the new one is added beside it. The fix is one record holding every mechanism, and the includes count against the same budget. A single record with eleven includes still fails.

What does DKIM add that SPF cannot?

DKIM signs the message. The sender hashes selected headers and the body, signs that hash with a private key, and attaches the signature; the public key is published in DNS under a selector, and the receiver verifies against it.

That proves the message was signed by a system holding your key, and that the signed content did not change in transit. It also survives forwarding, because the signature travels with the message. Selectors exist so keys can be rotated without a day when nothing verifies.

What does DMARC do when the first two fail?

DMARC ties the results to the domain the recipient sees. It requires alignment: whichever of SPF or DKIM passed must match the From domain. A message that passes SPF for a mailing provider's domain while claiming your From address is not aligned, and counts as a failure.

It then states a policy for mail that fails both, and asks for reports. RFC 7489 is explicit that this is a request: receivers apply their own judgement, and a published policy is a statement of intent that large receivers generally honour.

What actually changes between p=none and p=reject?

The policy tag is the only difference a recipient acts on, and it is the difference between a report and a barrier.

Policy	What the receiver is asked to do	What it is for
p=none	Deliver as usual, send reports	Discovery: seeing every sender first
p=quarantine	Treat failing mail as suspect	Transition, often at partial percentage
p=reject	Refuse failing mail outright	Once every sender authenticates

p=none protects nothing: spoofed mail still arrives, and the value is entirely in the reports, which list the hosts sending as your domain. That is the phase where you find the invoice system on a host nobody remembered. p=reject is where forgery stops, and where a missed sender becomes an outage — your invoices and password resets start disappearing, and the first report comes from a customer.

In what order do you roll it out?

1. Inventory every sender. The contact form, the accounting system that emails invoices, the newsletter, the CRM, the ticketing tool, the payment provider, the alerts, and the script on a VPS from 2021. Ask each system which address it sends from.
2. Publish one SPF record covering them, and count the DNS lookups it needs. Near the limit, move a sender to a subdomain with its own record rather than adding another include.
3. Turn on DKIM wherever the sender supports it, and record each selector. Signing is per-system: the provider that signs your newsletter does not sign your invoices.
4. Publish DMARC at p=none with a mailbox you will actually open, and leave it for several weeks. Add sp= if subdomains send mail.
5. Fix what the reports show. A legitimate source that fails is missing from SPF, not signing, or sending through a provider that rewrites the From domain; the last is the provider's configuration, not yours.
6. Move to quarantine, then reject, reading the reports after each step. Keep reading afterwards: a tool added in six months can break alignment quietly.

Where this goes wrong

• Two SPF records after a migration. Configured to the eye, an error to the receiver.
• An include chain past the lookup limit. The failure is silent until mail stops arriving.
• DKIM on the main domain only, while invoices leave from a subdomain.
• p=reject in one step on a Friday. Enforcement before discovery turns your own transactional mail into a support queue.
• Nobody reads the aggregate reports, which arrive as XML attachments, so the policy is published blind.
• Confusing this with lookalike domains. DMARC stops forgery of your domain; it says nothing about a domain one character away, which is how invoice fraud arrives.
• Assuming the mailbox is protected. Mail from a genuinely compromised account passes all three checks, because it did come from your system.

What this does not cover

This is authentication, not content security: a message can pass all three checks and still be fraudulent in what it asks for. It encrypts nothing, stops no compromised mailbox, and does not cover lookalike domains or display-name tricks. Enforcement is receiver discretion, and publishing assumes control of DNS — sometimes held by whoever built the website. We published these records on our own domain, and the discovery phase found a sender we had forgotten. They make forgery hard, not impossible.

We build the mail path and its DNS records together, because a domain that cannot state who sends for it is a domain anyone can borrow.