Eleven terms that decide whether someone can send email pretending to be you. Each one says what it is, what the risk actually is, and what a correct setting looks like. No jargon that isn't defined here.
Want to see what your own domain publishes? Run the checker.
MX records
What it is
MX records name the servers that receive email for a domain. They are how the rest of the internet knows where to deliver your mail.
Risk
Missing or incorrect MX records can prevent incoming email from being delivered. A null MX may intentionally indicate that the domain does not receive email.
Recommended
At least one MX record if the domain receives mail. If it does not, publish a null MX record (0 .) so senders are told so immediately.
SPF
What it is
SPF is a public list of the servers allowed to send email using your domain name. Receiving servers check the sender against that list.
Risk
Missing or overly permissive SPF can make spoofing easier. Multiple SPF records or excessive DNS lookups can cause SPF to fail. SPF may also break during forwarding, so it should be used with DKIM and DMARC.
Recommended
Exactly one record, listing every service that sends mail for you, ending in ~all or -all. Never +all.
SPF lookup limit
What it is
Evaluating SPF costs the receiving server a DNS query for each include, a, mx, exists or redirect term. The standard permits ten.
Risk
Past ten lookups a receiver stops and returns an error, and SPF fails for every message — including your legitimate mail. Records drift over this limit quietly as services are added.
Recommended
Stay comfortably under ten. Remove senders you no longer use before adding new ones.
DKIM
What it is
DKIM adds a cryptographic signature to each message you send. The matching public key is published in DNS so receivers can verify the message was authorised and not altered in transit.
Risk
Without DKIM, recipients have less assurance that a message was authorized and unchanged. A DNS key alone does not prove that outgoing messages are being signed.
Recommended
A published key of at least 1024 bits, ideally 2048 — then confirm signing from a real message: Gmail → Show original → look for dkim=pass. Do this for each system that sends as you, not just your main mailbox.
DKIM selector
What it is
A DKIM selector identifies the public key used by an email provider. If the selector is unknown, this checker cannot conclusively determine whether DKIM exists.
Risk
DNS offers no way to list a domain’s selectors, so a missing result may mean the key is absent, or simply that we asked for the wrong name. The two look identical from outside.
Recommended
Get the selector from your email provider and enter it above. Google Workspace usually uses "google"; Microsoft 365 uses "selector1" and "selector2".
DMARC
What it is
DMARC ties SPF and DKIM to the address recipients actually see, and tells receiving servers what to do when a message fails. It also asks them to send you reports.
Risk
Without DMARC the domain does not tell recipients how to handle messages that fail authentication alignment. SPF and DKIM can both be configured and spoofing still succeed.
Recommended
A single record with a policy and an rua= reporting address. Start at p=none to observe, then tighten.
DMARC policy
What it is
The p= tag is the instruction to receiving servers: none, quarantine, or reject.
Risk
p=none is monitoring only — reports may be collected, but recipients are not asked to quarantine or reject failures. p=quarantine means failing messages may be placed in spam, and misconfigured legitimate email could be quarantined too. p=reject is strong protection against direct spoofing, but legitimate email may be rejected if SPF or DKIM alignment is misconfigured.
Recommended
p=reject eventually — but only after the aggregate reports show every legitimate sender is passing. Moving early blocks your own invoices.
DMARC alignment
What it is
Alignment requires that the domain which passed SPF or DKIM matches the domain in the visible From address. Relaxed alignment allows a subdomain to match; strict requires an exact match.
Risk
SPF or DKIM can technically pass while DMARC fails because the authenticated domain does not align with the visible From domain. This is the most common reason a domain that looks correctly configured still fails.
Recommended
Relaxed alignment suits most organisations. Choose strict only when you control every sending system.
DNSSEC
What it is
DNSSEC lets resolvers verify DNS answers cryptographically. Without it, answers cannot be cryptographically validated. DNSSEC does not encrypt DNS traffic.
Risk
An attacker who can tamper with DNS answers can redirect mail or issue certificates. DNSSEC makes that tampering detectable.
Recommended
Enabled at your registrar. Take care during nameserver changes — a broken chain takes the whole domain offline, which is why it is worth doing deliberately.
MTA-STS
What it is
MTA-STS requires trusted TLS when other mail servers deliver email. Without it, some SMTP connections may be more exposed to downgrade or interception. Missing MTA-STS does not mean email is always unencrypted.
Risk
Mail delivery normally uses opportunistic encryption, which an attacker in the middle can strip. MTA-STS removes that option.
Recommended
Publish it alongside TLS-RPT, which reports failures back to you. MTA-STS without TLS-RPT is deployed blind — a misconfiguration can silently block mail.
CAA
What it is
CAA restricts which certificate authorities may issue TLS certificates. It is supplementary domain security, not an email-authentication control.
Risk
Without CAA, any of the hundreds of trusted authorities can issue a certificate for your domain. With it, only those you name may.
Recommended
Name the authorities you actually use, and add an iodef address so you are told when someone else tries.
