Check a domain's email security.

MX records. 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. 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. 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. 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.

DMARC. 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. 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. 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. 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. 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. 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.