Free Domain Security Checks: DMARC, TLS and Exposed Assets in One Afternoon

You can check a domain’s email and web defences in one afternoon with free tools and no account. This playbook starts with a free DMARC checker command and adds seven more checks, ending with certificate logs. Each one comes with the command, what a good answer looks like and what a weak one looks like.

We ran every command on our own domain, brandefense.io, on 28 October 2026. Seven checks passed and one did not. The results are in the table near the end, gap included.

What You Need Before You Start

You need a terminal with dig, openssl and curl. They come with macOS. On many Linux systems, install the dnsutils or bind-utils package to get dig. On Windows, nslookup -type=TXT does the same job as dig.

Replace example.com with your own domain in every command.

Run the checks only on domains you own or are allowed to test. Every check below reads public data: DNS records, a TLS handshake, response headers and public certificate logs. None of them sends an attack.

1. DMARC Checker: Is DMARC Published, and at What Policy?

DMARC tells receiving mail servers what to do with mail that fails SPF and DKIM checks for your domain. Our glossary explains what DMARC is and how it works with SPF and DKIM. The record lives in one TXT entry at _dmarc.

dig +short TXT _dmarc.example.com

Our answer was v=DMARC1;p=quarantine; rua=mailto:(report address). That is a working policy with aggregate reports switched on. Read the result this way:

• Good: one record, p=quarantine or p=reject, and a rua= address that someone reads.
• Weak: p=none left in place for years, or no rua=, so nobody sees who sends as you.
• Broken: no record at all, or two DMARC records, which receivers treat as no policy.

Since 1 February 2024, Google requires DMARC from anyone sending more than 5,000 messages a day to Gmail accounts. A policy of p=none is enough to meet that rule. Yahoo asks bulk senders for the same minimum.

For US federal agencies, CISA’s Binding Operational Directive 18-01 set p=reject as the goal. The original DMARC standard, RFC 7489, is now marked obsolete by RFC 9989, so check which one a tool’s advice is based on.

2. Does SPF Stay Under Ten DNS Lookups?

SPF lists the servers allowed to send mail for your domain. It sits in a TXT record at the domain itself.

dig +short TXT example.com | grep spf1

We found one record with four include: entries, ending in -all. A short script that follows each include counted 4 DNS lookups in total. RFC 7208 sets a limit of 10. Above that, the check returns a permanent error and SPF stops protecting you.

• Look for exactly one record that starts v=spf1.
• -all says other senders are not allowed. ~all is a soft fail, and receivers should not reject on it alone.
• Every marketing or ticketing tool you add brings another include, so recount after each new sender.

3. Can Receivers Find Your DKIM Key?

DKIM signs outgoing mail with a key whose public half sits in DNS at selector._domainkey.example.com. You cannot list selectors from outside, so take one from a real message. Open the headers of an email you sent and find s= in the DKIM-Signature line.

dig +short TXT selector1._domainkey.example.com

Our selector pointed to the mail provider and returned a v=DKIM1; k=rsa key. An empty answer means the selector is wrong or the key was never published. Check every service that sends as you, because each one signs with its own selector.

4. Is Mail Encrypted on the Way In? (MTA-STS and TLS-RPT)

This is the check our domain failed. MTA-STS (RFC 8461) tells other mail servers to deliver to you only over verified TLS. TLS-RPT (RFC 8460) asks them to send you a report when that fails.

dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com

Both came back empty for brandefense.io. Without MTA-STS, a sending server that cannot set up TLS may fall back to plain text, and nobody tells you. The fix has three parts:

1. Publish a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt with your MX hosts and mode: testing.
2. Add the TXT record v=STSv1; id=20261028 at _mta-sts, and change the id each time the policy changes.
3. Add v=TLSRPTv1; rua=mailto:tls-reports@example.com at _smtp._tls, read the reports for a few weeks, then switch to mode: enforce and change the id again.

5. Does the Website Refuse Old TLS Versions?

RFC 8996 deprecates TLS 1.0 and 1.1. NIST SP 800-52 Rev. 2 asks US government servers to support TLS 1.2 and, since 1 January 2024, TLS 1.3. Test each version on its own:

openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
curl -sI https://example.com | grep -i strict-transport

On our domain, TLS 1.0 and 1.1 were refused and TLS 1.2 and 1.3 were accepted. A handshake error on the old versions is the result you want. If the error says “no protocols available” at once, your own OpenSSL blocks TLS 1.1, so test from another machine.

The last command shows the HSTS header, which tells browsers to use HTTPS only. Ours reads max-age=31536000; includeSubDomains; preload, which is one year.

6. Who May Issue Certificates for You? (CAA)

A CAA record names the certificate authorities allowed to issue for your domain (RFC 8659). Any other authority must refuse the request.

dig +short CAA example.com

We have 10 CAA records covering five authorities, with issue and issuewild for each. No answer means any public authority may issue for you. If you also add an iodef tag, authorities can report refused requests to you. We have not set one yet.

7. What Do Certificate Logs Say About Your Subdomains?

Public certificates are written to public Certificate Transparency logs, and anyone can search them. This is often how attackers find forgotten subdomains, such as an old test site that still points to a cloud service you no longer use.

curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

For brandefense.io the logs held 410 certificate entries since January 2022, covering 26 unique names, four of them wildcards. Go through the list and ask one question per name: do we still run this, and does its DNS still point somewhere we control? A name that points to a deleted cloud resource is the classic subdomain takeover. Our misconfiguration and subdomain takeover playbook covers how to fix one.

8. Can a Researcher Reach You? (security.txt)

RFC 9116 defines a plain text file at /.well-known/security.txt so that people who find a flaw know where to report it. Contact and Expires are the two required fields.

curl -s https://example.com/.well-known/security.txt

Ours answered with two contact addresses, a disclosure policy link and an expiry date in October 2027. Check that date once a year. An expired file tells researchers the contact may be dead.

Our Results, Gap Included

Here is what the eight checks returned for brandefense.io on 28 October 2026.

A security company with one open item is a useful reminder. These checks drift as teams add mail tools, subdomains and certificates, so a clean result in spring says little about autumn.

What to Fix First

If your own run finds several gaps, fix them in the order that stops the most harm. Spoofed mail from your domain is the base of most business email compromise attempts, so mail checks come first.

DMARC only protects your exact domain. It does nothing against typosquatting and lookalike domains that an attacker registers to look like you. Those need watching from the outside, which is the job of External Attack Surface Management.

For a quick outside view of your domain, try our free domain scanner, which opens the Atlas domain scanner. It is our own tool, so compare its answers with the commands above.