Domain and email security baseline

Why a baseline helps

Most domain security problems are not exotic. They are missing or half-finished basics: a mail policy that was set to monitor and never tightened, a certificate nobody was watching, a DNS zone with records for services that were retired years ago. A baseline gives you a finite list to check, so you can tell the difference between a domain that is basically sound and one that needs work.

The baseline below is built from controls that an outside party can verify from public data, which is also what a DNS Tools assessment looks at. It does not cover internal security, which an external check cannot see.

Layer 1: DNS you can trust

Everything else relies on DNS being correct and under your control. Check that the domain has at least two nameservers, preferably on separate networks, and that the delegation at the registrar matches the NS records in the zone. Check the SOA record and make sure records you no longer need are removed, especially CNAMEs pointing at services you stopped paying for, since a dangling alias can let someone else claim the target.

DNSSEC is a worthwhile addition when your registrar and DNS host support it cleanly, but a broken DNSSEC setup makes a domain fail to resolve for validating resolvers, so it must be done carefully. Consider a CAA record, which tells certificate authorities which of them may issue for your domain.

• Two or more nameservers, with delegation matching the zone.
• No stale records pointing at decommissioned services.
• A CAA record listing the certificate authorities you actually use.
• DNSSEC enabled only if you can manage the key rollover.

Layer 2: email authentication

Three records work together. SPF lists which servers may send mail for your domain. DKIM adds a signature to messages that receivers verify against a public key you publish under a selector. DMARC tells receivers what to do when a message fails both, and where to send aggregate reports.

For a baseline, publish one SPF record that stays within the ten DNS-lookup limit and ends in a deliberate qualifier, sign outbound mail with DKIM for every service that sends as your domain, and publish a DMARC record. A DMARC policy of p=none only monitors. It is a legitimate first step, but it does not instruct receivers to act on spoofed mail, so a baseline aims for quarantine or reject once reports show your legitimate senders pass.

A domain that sends no mail should say so: publish an SPF record of v=spf1 -all, a DMARC policy of reject, and a null MX (0 .) so senders do not wait for mail that will never be read.

• One SPF record, under ten lookups.
• DKIM signing for each sending service.
• DMARC published, with a plan to move from monitoring to enforcement.
• Null MX and strict SPF and DMARC on non-sending domains.

Layer 3: encrypted mail transport

Mail between servers is encrypted opportunistically using STARTTLS, which means a network attacker can strip the offer and force plaintext. Your MX hosts should offer STARTTLS with a valid certificate. To go further, MTA-STS lets you publish a policy that tells sending servers to require TLS and to verify the certificate, and TLS-RPT gives you reports about failures.

Roll out MTA-STS in testing mode first and watch the reports before switching to enforce, because an enforced policy that does not match your MX hosts can cause legitimate mail to be refused.

Layer 4: the website

Serve the site over HTTPS with a certificate that is valid, covers the hostnames in use, and has a complete chain. Redirect HTTP to HTTPS, and consider HTTP Strict Transport Security (HSTS) once you are sure every subdomain can serve HTTPS, since browsers will remember the setting.

Add the common response headers that reduce browser-side risk: a Content-Security-Policy suited to your pages, X-Content-Type-Options: nosniff, a restrictive framing policy, and a Referrer-Policy. Publish a security.txt file so researchers know how to report problems.

• Valid certificate with a monitored expiry date.
• HTTP redirects to HTTPS.
• HSTS after testing subdomains.
• Content-Security-Policy, nosniff, framing and referrer headers.
• A security.txt contact.

Layer 5: exposure and lookalikes

Only services you intend to expose should answer on the public internet. Administrative and database ports such as RDP, SMB or database listeners should not normally be reachable from anywhere. A port check shows what answers, but it cannot tell you whether it should.

Lookalike domains, such as ones that swap a character or add a hyphen, are a common basis for phishing. You cannot stop others registering them, but you can know which exist and decide whether to register the most obvious ones yourself.

A sensible order of work

Do the work in an order that limits risk. Items early in the list are low-risk and unblock the later ones.

1. Inventory every service that sends mail as your domain.
2. Clean up DNS: remove stale records and confirm delegation.
3. Fix SPF, enable DKIM, publish DMARC at p=none with reporting.
4. Read DMARC reports for a few weeks and fix legitimate senders that fail.
5. Move DMARC to quarantine, then reject.
6. Add STARTTLS fixes, then MTA-STS in testing, then enforce.
7. Tighten website headers one at a time and re-test.
8. Re-run the assessment and keep the results to compare next time.

Limits of a baseline

Meeting a baseline means the public configuration looks sound. It does not mean your accounts are protected by strong authentication, your software is patched, or your staff will not be phished. It is one layer, and an honest assessment, including DNS Tools's, will say what it could not verify.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09