Getting Started

Ten checks on one hub page can look like a lot, especially if SPF, DKIM and DMARC aren't already familiar terms. They don't all matter equally, and you don't need to understand all ten to get real value out of this - this page is a short, plain-language map before you dive into any of them.

Start here: the three that matter most

If you only do three things, do these. Together they're what stops someone else from sending e-mail that convincingly claims to be from your domain - increasingly expected by large mail providers, not just good practice.

SPF - a list of which servers are allowed to send mail for your domain.
DKIM - a digital signature proving a message wasn't altered in transit.
DMARC - tells receiving servers what to do when a message fails the two checks above, and gives you reports on what's actually happening.

Set up in that order, each one building on the last. None of them require touching your mail server itself - they're all DNS records your hosting provider or domain registrar lets you add.

Worth adding once the basics are solid

These build on SPF/DKIM/DMARC rather than replacing them. Nothing breaks if you skip them for now - they close specific, narrower gaps.

MTA-STS - forces incoming mail to use verified encryption, closing a gap where that encryption can otherwise be silently stripped.
TLS-RPT - the reporting side of MTA-STS (and DANE): without it, a failure caused by either is invisible.
BIMI - a verified logo next to your messages in supporting mail clients. Purely cosmetic, and requires DMARC enforcement first.

DNS-level protections

These aren't only about mail - they protect the domain itself, including (but not limited to) how it sends and receives e-mail.

DNSSEC - cryptographically signs your DNS records so they can't be tampered with in transit. Several other checks here (DANE especially) depend on this being in place first.
DANE - pins your website's and mail server's certificate in DNS, so a forged certificate from another certificate authority won't be trusted. Needs DNSSEC to mean anything.
CAA - names which certificate authorities are allowed to issue a certificate for your domain at all.

Your website itself

Headers - a handful of HTTP response headers that tell a visitor's browser to defend itself (refuse plain HTTP, restrict where scripts can load from, and similar). Nothing to do with e-mail - this one's about the website.

A closing thought

None of this needs to happen in one sitting. Publishing a DNS record, waiting for it to take effect, and checking the result again is normal, expected back-and-forth - not a sign something's going wrong. Start with SPF, and come back to the rest whenever you're ready.