Nothing in SMTP stops a stranger from putting your domain in the From header.
Three DNS records are what make that fail, and they only work together.
What SecScan checks
| Check | Severity | Why |
|---|---|---|
| SPF record present | High (Medium with no MX) | No list of authorised senders |
SPF uses +all | Critical | Explicitly authorises every sender on the internet |
SPF uses ?all | Medium | Neutral — no assertion either way |
| SPF exceeds 10 DNS lookups | Low | Record silently stops evaluating |
| DMARC record present | High | Nothing tells receivers what to do on failure |
DMARC policy is p=none | Medium | Monitoring only; failures still deliver |
| DKIM records present | Low | Probed across 30 common selectors |
| DNSSEC enabled | Info | Answers are not authenticated |
Lookups go through Cloudflare DNS-over-HTTPS, so this module needs no account and no access to your registrar.
SPF
SPF lists the hosts allowed to send mail for your domain. One TXT record on the apex, and only one — two SPF records is a permanent error, not a merge.
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The last mechanism is the whole point:
-all— hard fail. Anything not listed is unauthorised.~all— soft fail. Suspicious, usually still delivered. A reasonable place to sit while you confirm you have listed every sender.?all— neutral. States nothing, which is what SecScan flags at Medium.+all— authorises the entire internet. This is worse than having no SPF record, because it looks deliberate. Almost always a typo for-all.
The 10-lookup limit
Each include:, a, mx, ptr and redirect costs a DNS lookup, and nested
includes count too. Past ten, evaluation stops and returns permerror — which
most receivers treat as no SPF at all. Three or four SaaS senders is enough to
blow the budget. Remove vendors you no longer use, and flatten includes if you
must, accepting that a flattened record needs re-flattening when the vendor
changes their IPs.
DKIM
DKIM signs outgoing mail with a private key; the public key lives in DNS at
<selector>._domainkey.yourdomain.com. Your mail provider generates the pair and
tells you the selector — SecScan probes 30 common ones, so a provider using an
unusual selector may not be detected even when DKIM is working.
DKIM matters more than its Low severity suggests: it survives forwarding, which SPF does not. A mailing list that relays your message breaks SPF alignment but leaves the DKIM signature intact.
DMARC
DMARC ties the other two together: it requires that a passing SPF or DKIM result
be aligned with the visible From: domain, and tells receivers what to do when
neither is. Publish at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
Start at p=none. It changes no delivery behaviour but turns on the aggregate
reports, which are the only way to discover the legitimate senders you forgot
about — the billing system, the CRM, the ticketing tool nobody documented.
Read reports for two to four weeks, fix what is failing, then move to
p=quarantine, then p=reject. SecScan flags p=none at Medium precisely
because it is so often where a domain stops: the record exists, the checklist
passes, and spoofed mail still lands.
A domain that sends no mail still needs records. Parked and marketing-only
domains are attractive precisely because nobody is watching them. Publish
v=spf1 -all and v=DMARC1; p=reject; on anything that should never send.
Last reviewed 2026-09-07