Your domain name is the front door of your business on the internet. Email goes out under it, customers type it into a browser, and attackers look at it too, because a domain with weak email settings is easy to impersonate. These five checks cover what attackers look at first. They cost nothing and need no special access, just a browser and, ideally, a terminal. On a Mac, open Terminal; on Windows, PowerShell has a Resolve-DnsName command that does the same job as dig. If you would rather not touch a command line, a free online lookup such as MXToolbox or Google's Admin Toolbox Dig will run every DNS check below.
1. SPF: who is allowed to send email as you
SPF is a text record in your DNS that lists the servers allowed to send email from your domain. Receiving mail servers check it when a message arrives. Run dig TXT yourdomain.co.uk +short and look for a line starting v=spf1. A healthy record names your email provider, for example include:spf.protection.outlook.com for Microsoft 365 or include:_spf.google.com for Google Workspace, plus anything else that sends on your behalf such as your invoicing or newsletter tool, and ends with -all or ~all.
A fail is no record at all, two SPF records (which cancels both, since only one is allowed), or a record ending +all, which means anyone can send as you. If SPF fails, anyone can send email that looks like it came from your firm, and the receiving server has nothing to compare it against.
2. DKIM: is your email signed
DKIM adds a cryptographic signature to each outgoing message, and the public key sits in your DNS under a selector. Microsoft 365 uses selector1 and selector2; Google Workspace uses google by default. Run dig TXT selector1._domainkey.yourdomain.co.uk +short (swap the selector for yours) and look for a record containing v=DKIM1. The quicker check is to send yourself an email, open the message headers (Show original in Gmail, View message source in Outlook) and look for dkim=pass.
A fail is no record, or dkim=fail or dkim=none in the headers. It means your mail is unsigned, so it is more likely to land in spam, and DMARC below cannot do its job properly.
3. DMARC: what happens when a check fails
DMARC ties SPF and DKIM together and tells receiving servers what to do with mail that fails: deliver it anyway, quarantine it, or reject it. It also sends you reports on who is sending as your domain. Run dig TXT _dmarc.yourdomain.co.uk +short and look for a single record starting v=DMARC1. The p= value is the policy: none means monitor only, quarantine sends failures to spam, reject blocks them. A rua= address is where the reports go.
A fail is no record, a policy of none that has been left there for years, or two DMARC records. The second is a common mistake when two people or two tools each add one, and it invalidates both. Without a working DMARC policy, a spoofed invoice from your domain is delivered to your clients and you never hear about it. The sensible path is to start at none with reporting on, fix whatever the reports show, then move to quarantine and finally reject.
4. The HTTPS redirect and the certificate
Type your domain into a browser with http:// at the front, not https://, and see where you land. It should redirect to the https:// version with a padlock and no warnings. From a terminal, curl -I http://yourdomain.co.uk should return a 301 or 308 status and a Location header starting https://. Check both the bare domain and the www version, because they are often configured separately. Then click the padlock and look at the certificate: it should be issued to your domain and not be close to expiry.
A fail is a Not secure label, a certificate warning, an expired certificate, or the http:// version simply loading without redirecting. It means anything a visitor types on your site, including a contact form, can be read or altered in transit, and browsers and search engines mark you down for it.
5. security.txt: how someone tells you about a problem
security.txt is a small text file that lives at https://yourdomain.co.uk/.well-known/security.txt, defined in RFC 9116. It tells security researchers how to report a vulnerability to you. Open that address in a browser. A good file has a Contact line with an email address or a form, an Expires line with a date in the future, and ideally a Preferred-Languages line.
A fail is a 404 page. It is the least dangerous fail on this list, but it matters: a researcher who finds a problem with your site and cannot find a way to tell you may give up, or post it publicly. This is a five-minute fix, and the file can be written by hand.
What to do with a fail
Fix the email checks first if you send any email from your domain, because impersonation is the most common way small firms are attacked through their domain. Almost every fix on this list is a DNS record you or your IT provider can add in an afternoon, and none of them cost money. Then run the checks again, and put a reminder in the diary to repeat them every few months, because DNS records get changed when tools are added and nobody rechecks.
