What your DNS exposes: email, web and attack surface

Why this information is public

For email to work between strangers, every mail server in the world needs to find out three things about your domain without asking you: where to deliver your mail, which servers may send it, and what to do when a message fails those checks. DNS is the only shared directory, so you publish the answers there, and anyone can look them up.

This post covers your email, website and exposed systems. A companion post, What your DNS reveals about the software you use, covers the SaaS tools that show up in your records.

That's by design, and it's useful for you. Reading your own records shows you your email setup as the rest of the internet sees it, including leftovers you forgot about. This post goes through the records worth knowing, using our own domain, globalsoc.com.au, as the example.

MX: who receives your email

MX (Mail eXchanger) records tell the world which servers accept mail for your domain. The host name usually says who runs the mailbox:

What to do with this

• Check it matches what you pay for. If you bought a gateway but your MX still points straight at Microsoft, attackers can skip the gateway entirely by delivering to the Microsoft address directly. The fix is to restrict inbound mail at Microsoft to your gateway's addresses.
• Look for a dead MX. An old host that no longer exists means mail to you can bounce, and an unregistered domain there could be registered by someone else and receive your email.
• If you don't use email on a domain, publish a null MX (MX 0 .) so nothing is delivered.

SPF and DKIM: who may send as you

SPF lists the allowed sending servers

Your SPF record is a list of everything permitted to send email as your domain. Each include: is a service the business uses, which makes it a handy inventory of your email-sending tools: accounting, CRM, marketing, helpdesk, HR. (More on reading these in What your DNS reveals about the software you use.) Ours is:

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com include:spf.protection.outlook.com -all

Read it left to right: Cloudflare, Google (our Gmail "Send mail as") and Microsoft (the Azure service that sends our alerts) may send as globalsoc.com.au, and -all means everyone else is rejected.

• Remove anything you no longer use. An old marketing tool's include: is an open door. Anyone who gets into that account can send as you.
• Mind the 10-lookup limit. Each include:, a, mx and exists: costs one DNS lookup, nested ones included. Over 10 and SPF stops working for all your mail. Our DNS Audit counts them for you.
• End with -all or ~all, never +all (which allows the whole internet).

DKIM is a signature, and its selector names the signer

DKIM signs each message with a private key. The matching public key sits in DNS under a selector, at selector._domainkey.yourdomain. The selector name usually shows which service does the signing:

• Every service that sends as you should have its own DKIM key. A service without one will fail DMARC alignment the moment you enforce a strict policy.
• Use 2048-bit keys. 1024-bit keys are still common and are being phased out.
• Know that selectors can't be listed. Only the sending service and you know the exact names, so a scan can only guess common ones. That's why "no DKIM found" is a prompt to check an email's headers, not proof it's missing.

DMARC: the policy, and who reads the reports

DMARC ties SPF and DKIM together and tells receivers what to do with email that fails. Two parts say the most about how seriously a domain treats email fraud. (Our earlier post explains how DMARC works in depth.)

MTA-STS, TLS-RPT and DANE: protecting email in transit

SPF, DKIM and DMARC are about who sent it. These three are about whether the message is encrypted on the way to you. Ordinary email between servers will quietly fall back to plain text if encryption fails, which lets an attacker on the network path read or alter it.

Few small businesses use any of these yet, so having them is a sign of a careful email setup, and adding them is cheap.

The web side: CDN, certificates and headers

A visit to your website tells a browser (and a security reviewer) how it's hosted and how carefully it's protected:

Our own domain is a good example. GitHub Pages can't set security headers, so globalsoc.com.au scores lower on that check than we'd like. The fix is to put Cloudflare in front and add the headers there, which is the kind of finding we'd flag for any client in the same position.

Your attack surface: subdomains and certificate logs

Every public HTTPS certificate is recorded in open certificate transparency logs, which means a list of your subdomains is available to anyone, including people with bad intentions. Looking at that list yourself is one of the most useful things you can do, because it often includes systems nobody remembers:

For each hostname on your own list, ask three questions: Do we still need it? Who owns it? Is it patched and behind multi-factor authentication? If any answer is "no" or "don't know", retire it or lock it down.

From findings to fixes

Most DNS review findings follow the same pattern: something visible, the business risk it creates, and a defined fix. Here are the common ones:

Why different sectors care

What should be public, and what shouldn't

Some DNS information has to be public for the internet to work with you. Other information ends up there by accident and gives away more than it should. A good rule: publish what other organisations need in order to deal with you safely, and nothing that describes your inside.

Two practical habits help: use split-horizon DNS so internal names live only on your internal DNS servers, and put a review of your DNS zone on the calendar every six months, with the same urgency as renewing insurance.

What DNS can't tell you

• Published isn't deployed. A gateway in the MX record doesn't prove it's configured well, or that Microsoft's front door is locked behind it.
• It can't show internal controls such as multi-factor authentication, patching, backups or staff training. Those matter more than any DNS record.
• Records go stale. Leftover includes and verification records often outlive the services they were for. That's a cleanup list, not a failure.
• It says nothing about intent or quality. A missing record might be an oversight, or a deliberate choice for a domain that sends no email.

That's why we only ever present DNS findings as a checklist for the domain owner, and never as a score for someone else's business.

Good practice when reviewing a domain

Whether you're checking your own domain or an adviser is checking it for you, a few rules keep everyone on the right side of the law and of common courtesy:

• Own domain, or written permission. Reading public DNS records is fine. Going further, such as port scanning, trying to log in, attempting zone transfers or running vulnerability tests, needs the owner's written authorisation. Unauthorised testing can fall under the Criminal Code.
• Say what you saw, not what you assume. Use "appears" or "indicates", never "you are vulnerable". DNS shows the outside of a business; it can't show the controls inside.
• Be helpful, never alarming. A message that leads with serious-sounding findings and a demand to get in touch urgently reads like a shake-down. Describe the finding, the risk in plain words and the fix.
• Mind the Spam Act 2003. Anyone contacting a business about their email security must identify themselves, give a valid contact and include a way to opt out.

Check your own domain in two minutes

These commands work on any Windows laptop. Replace the domain with your own:

Resolve-DnsName globalsoc.com.au -Type MX                                  # who receives mail
Resolve-DnsName globalsoc.com.au -Type TXT | Select -Expand Strings        # SPF, verification records
Resolve-DnsName _dmarc.globalsoc.com.au -Type TXT | Select -Expand Strings # DMARC policy and reports
Resolve-DnsName _mta-sts.globalsoc.com.au -Type TXT                        # MTA-STS
Resolve-DnsName _smtp._tls.globalsoc.com.au -Type TXT                      # TLS-RPT

Or skip the commands: our free DNS Audit checks all of the above and 40 more settings in about 10 seconds, explains each finding in plain English and gives you the exact records to paste. It only works on domains you type in; it never contacts anyone's systems beyond the standard, lightweight checks described on the page.