Security guide
SPF, DMARC and DNSSEC, explained
Security headers protect the people who visit your website. These four DNS records protect everyone who receives mail that claims to come from you, and the visitors who trust your domain name to resolve to your server.
01 Why it matters
Your domain is an identity anyone can borrow
Nothing in the mail protocol stops a stranger writing your domain into the sender field. Without a published policy, a receiving server has no way to tell your invoice from a forged one, and the recipient sees your name either way. That is how supplier fraud works: a message that looks like it came from a company someone already trusts, asking for a changed bank account.
DNSSEC covers the layer underneath. It signs your DNS answers so a resolver can prove that the address it received for your domain is the one you published, rather than one injected on the way. Mail authentication tells the world who may write in your name; DNSSEC makes sure the lookup that finds your servers cannot be quietly rewritten.
02 The records
Four records, one chain
They build on each other and only the last one has teeth. SPF and DKIM each answer a narrow question, DMARC turns those answers into a policy a receiver can act on, and DNSSEC protects the lookups the other three depend on.
SPF
What it does. Publishes the list of servers allowed to send mail for your domain. A receiver compares the connecting server against that list and gets a pass or a fail.
Why it matters. It is the cheapest record to publish and the easiest to get subtly wrong. End the record with -all rather than ~all once you are confident the list is complete, and keep an eye on the ten-lookup limit: every include costs one, and a record that exceeds it fails as a whole rather than degrading.
example.com. IN TXT "v=spf1 include:_spf.your-provider.example -all" DKIM
What it does. Signs each outgoing message with a private key and publishes the matching public key in DNS, so a receiver can verify that the body and headers were not altered in transit.
Why it matters. Unlike SPF, a DKIM signature survives forwarding, which is what makes DMARC workable in practice. Your mail provider generates the key pair and hands you the record to publish; the selector in the record name lets you rotate keys without a gap.
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..." DMARC
What it does. Tells receivers what to do with a message that fails both SPF and DKIM, and where to send aggregate reports about what they saw.
Why it matters. This is the only one of the three that changes an outcome. Without a DMARC policy, a failing SPF check is a note in a header that nobody acts on. With p=reject, a forged message is refused before it reaches an inbox.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s" DNSSEC
What it does. Signs the records in your zone so a validating resolver can prove that an answer really came from you and was not modified on the way.
Why it matters. Every record above depends on a DNS lookup being honest. Without DNSSEC, an attacker who can influence a resolver can serve their own SPF or DKIM record and the whole chain agrees with them. It is also the record most often blocked by the registrar rather than by effort.
example.com. IN DS 12345 13 2 49FD46E6C4B45C55D4AC...03 Rolling it out
Start at p=none and read the reports
The order matters and the mistake is always the same: publishing p=reject before knowing who sends mail in your name. Newsletter tools, ticket systems, invoicing software and the printer in the back office all send as your domain, and every one of them that you forget is mail that silently stops arriving. Publish SPF and DKIM first, then a DMARC record on p=none, which changes nothing but asks receivers to report.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"Give the reports a few weeks, add the senders you had forgotten, then move to p=quarantine and finally p=reject. The aggregate reports arrive as XML and are unpleasant to read by hand; any of the common DMARC report services will turn them into a list of senders, which is the only thing you need from them.
04 Questions
What people ask about mail authentication
We do not send mail from this domain. Do we still need this?
Yes, and it is simpler for you than for anyone else. A domain that never sends mail should publish an SPF record that authorises nobody and a DMARC record on p=reject. That combination tells every receiver to refuse anything claiming to come from you, which is exactly right for a domain used only for a website.
Does DMARC break our newsletter?
Only if the newsletter tool was never authorised. That is precisely what the p=none phase is for: the reports name every server sending as you, including the ones nobody remembered. Move to a stricter policy once the list has stopped surprising you.
Is DNSSEC risky to switch on?
The failure mode is real but narrow: if the signatures expire or the DS record at the registrar stops matching your zone, validating resolvers stop resolving your domain entirely rather than falling back. Providers that manage signing and rotation for you remove almost all of that risk. What you cannot do is switch it on and forget where the keys live.
Our registrar does not offer DNSSEC. What then?
Then it is genuinely not available to you, and no amount of configuration on your side changes that: the DS record has to be published by the registrar in the parent zone. The only remedies are moving DNS to a provider that supports it or moving the domain. Treat it as a procurement question rather than a technical one.
05 In depth
Related security topics
Mail and DNS are the half of your domain that no browser shows. These guides cover the other half.
HTTP security headers
What each response header does, which ones your site should send and how to configure them correctly.
Content Security Policy
The strongest defence against cross-site scripting: which directives to set, how to roll a policy out in report-only mode and how to reach an enforcing policy without breaking your site.
HSTS
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
Cookie security
Secure, HttpOnly and SameSite: the cookie attributes that keep a session out of reach of scripts and cross-site requests, with the settings for a typical stack.
Clickjacking and X-Frame-Options
How an invisible overlay turns a visitor click into an action on your site, and the two headers that stop it: X-Frame-Options for older clients, frame-ancestors for everything else.
Referrer-Policy
Which part of your URLs travels to other sites when a visitor clicks away: the five policy values that matter, what each one gives up and the one to set by default.
Permissions-Policy
Switch off camera, microphone, geolocation and payment for your site and everything it embeds: the allow-list syntax, and why a feature you did not name is not a feature you turned off.
security.txt
The file that tells a researcher where to report a vulnerability. Two mandatory fields, ten minutes of work, and the difference between a private report and a public one.
Monitoring security headers
A header that is right today can be gone after the next deploy. Three ways to notice: a cron job with curl, a check in your CI pipeline and a scheduled scan, with what each of them catches and misses.
Detecting CSP changes
How a policy changes quietly through deploys, plugins and CDN rules, and how to catch it: a header diff, violation reports through report-to, and what a scan comparison can and cannot show.
Keep reading
More guides
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
See which records your domain publishes
Our free Quickscan reads SPF, DMARC and DNSSEC for your domain alongside your security headers, and explains every finding in plain language.