Email was designed in an era when nobody expected anyone to lie about who they were. Anyone can still send a message claiming to be from your domain, and the only reason that does not happen constantly is that domain owners now publish records saying who is genuinely allowed to. Those records are SPF, DKIM and DMARC. They look cryptic and they are not complicated.
SPF — the list of who may send
SPF is a public list of the servers permitted to send mail using your domain name. It lives in a DNS record, and any receiving server can read it before deciding what to do with a message.
When mail arrives claiming to be from you, the receiver checks which machine actually sent it and looks for that machine on your list. Not on the list, and the message is suspect.
The single most common mistake is forgetting a sender. Your mail provider is on the list, but the invoicing system, the newsletter tool and the contact form on your own website each send mail too — and each needs to be included, or its perfectly legitimate messages start failing.
DKIM — the seal that proves nothing was altered
DKIM puts a cryptographic signature on every message your server sends. The matching public key sits in your DNS, so any receiver can verify two things at once: that the message genuinely came from your domain, and that nobody changed it in transit.
It is the stronger of the two checks, because it survives forwarding. A message that is passed along by a mailing list often fails SPF through no fault of yours; the DKIM signature travels with the message and still verifies.
DMARC — what to do when a check fails
SPF and DKIM report a result. DMARC is where you say what should happen next, and it is the record most domains are missing.
You publish a policy: do nothing, put it in the spam folder, or reject it outright. You can also ask receiving providers to send you reports about mail claiming to be from your domain — which is how you discover both the forgeries and the legitimate sender you forgot to authorise.
Start at "do nothing" with reporting switched on. Read the reports for a couple of weeks, fix whatever they reveal, and only then tighten the policy. Publishing "reject" on day one is how a company stops its own invoices from being delivered.
The order that works
Add SPF first, listing every system that sends on your behalf. Then turn on DKIM with your mail provider and publish the key. Then add DMARC with a do-nothing policy and reporting.
Wait, read the reports, correct the gaps, and tighten DMARC last. Each step is independent and none of them breaks existing mail if you do them in this order.
How to get this right without becoming an expert
If your domain uses our nameservers, the mail records can be applied for you in one step from your account — all three, with the values matched to the mail service you are actually using.
If your domain is managed elsewhere, we will give you the exact records to paste and then verify them for you. It is worth doing once, properly, rather than repeatedly wondering why a customer says your reply never arrived.