Email Security Audit: How MSPs Should Check Client Domains

An email security audit checks whether a domain's mail is authenticated, encrypted and trusted. For an MSP, that means testing every client domain for SPF, DKIM and DMARC, then MTA-STS and TLS reporting, MX records, TLS support and blocklist status. Record the results the same way for every client, fix the gaps in order of risk, and repeat it on a schedule.

Most IT providers already know how to fix a broken SPF record. The harder part is doing it consistently across fifty client tenants, catching the domains nobody remembers owning, and explaining the results to a managing director who just wants to know whether fake invoices can be sent in their name. This guide gives you a repeatable audit, the order to run it in, and how to report it.

Why IT providers need a repeatable email security audit

Client domains drift. A marketing agency adds an include to SPF, a finance system starts sending invoices from the client's address, someone cancels an old host and the DKIM record goes with it. None of this raises a ticket until mail starts bouncing or a customer pays a fraudster.

There's also less outside help than there used to be. The NCSC retired its Mail Check and Web Check services on 31 March 2026, so organisations that relied on Mail Check findings now need another way to watch their DMARC and TLS settings. The NCSC points to its free email security check for one-off tests and to commercial tools for ongoing monitoring. In practice, for many UK small businesses that job now sits with their IT provider. Our write-up of the Mail Check retirement covers the background.

The big mailbox providers have raised the bar too. Google's sender guidelines require every sender to Gmail to use SPF or DKIM, send over TLS and have valid forward and reverse DNS. Anyone sending more than 5,000 messages a day to Gmail must also publish DMARC and align the From domain. Microsoft announced similar rules for high-volume senders to Outlook.com, Hotmail and Live addresses, starting in May 2025. Our guide to the Gmail, Yahoo and Microsoft sender requirements explains what each one asks for.

Before you start: build the domain inventory

An audit is only as good as the list of domains it covers. Ask for, or find:

• The primary mail domain used for mailboxes.
• Trading names and old brands that still have DNS, even if no one emails from them.
• Marketing and transactional subdomains such as news.client.com or mail.client.com.
• Parked and defensive domains, for example the .net or a country-code version such as .co.uk or .ca when the business trades on .com.
• Every service that sends as the domain: Microsoft 365 or Google Workspace, the CRM, accounting and invoicing software, the website's contact forms, helpdesk tools, payroll and booking systems.

Note who controls the DNS for each domain (registrar, old web host, Cloudflare, the client's own account) and whether you have access. Many fixes stall at this step, so capture it early.

Parked domains matter more than they look. A domain that never sends email can still be spoofed. Publish an SPF record of v=spf1 -all and a DMARC record at p=reject on every domain that shouldn't send mail at all.

The email security audit checklist

Run these checks in this order for each domain. Each item lists what you're looking for and what a fail usually means.

1. MX and where mail really goes

Start with an MX lookup. After a migration, it's common to find an old filtering service or previous host still listed at a lower priority, which splits incoming mail between two systems. A DNS lookup tool pulls every common record in one pass, which is the quickest way to document a new client.

2. SPF

Use the SPF checker to count DNS lookups and spot duplicate records. SPF is limited to ten DNS-querying mechanisms, and domains where several suppliers have each added an include often break it. The fix is usually removing services that no longer send, not flattening everything into IP addresses you'll then have to maintain. Our guide to too many SPF lookups walks through it.

3. DKIM

Check each sender with the DKIM checker. For Microsoft 365, DKIM for a custom domain stays off until the two selector CNAME records are published and signing is enabled in the admin centre. Google Workspace needs a key generated in the admin console and published as a TXT record. If you don't know the selector a service uses, you can read it from the DKIM-Signature header (the s= value) of a message the service sent.

4 and 5. DMARC and alignment

The DMARC checker shows the policy and where reports go. A DMARC record is only useful if someone reads the reports. Point the rua address at a mailbox or reporting tool you actually monitor. If a client's record still sends reports to the NCSC Mail Check address, replace it.

Then roll the policy forward: p=none while you find every legitimate sender, p=quarantine once the reports are clean, and p=reject when you're confident. The DMARC record generator builds a correct record at each stage, and our guide to reading DMARC reports explains what to look for.

6 and 7. MTA-STS and TLS-RPT

SPF, DKIM and DMARC protect against spoofing. MTA-STS protects mail in transit to the client by telling sending servers to require a valid, encrypted TLS connection. Under RFC 8461, it needs two things:

• A TXT record at _mta-sts.client.com that starts v=STSv1 and includes an id value you change whenever the policy changes.
• A policy file at https://mta-sts.client.com/.well-known/mta-sts.txt, served with a valid certificate for that hostname, listing the MX hosts and a mode of testing, enforce or none.

TLS-RPT (RFC 8460) is a TXT record at _smtp._tls that asks sending servers to report TLS failures. Deploy it alongside MTA-STS in testing mode, read the reports for a few weeks, then move to enforce. Our MTA-STS and TLS-RPT guide has example records.

The catch for MSPs is the policy host. It needs HTTPS on a subdomain, so someone has to own that certificate. Renewing it automatically is essential, especially as public certificate lifetimes get shorter.

8. Mail server and portal TLS

Use the TLS version checker on web portals, remote access pages and any mail server you host. Microsoft 365 and Google Workspace handle TLS for hosted mailboxes, but on-premise relays, scanners that send email and older NAS devices often lag behind. The SSL checker shows expiry dates and chain problems on the same hosts.

9. Blocklists

Run the blacklist checker on the domain and the sending IPs. If something is listed, find and secure the source first, usually a compromised mailbox or device, then follow each list's own removal process (our guide to checking whether a domain is blacklisted and getting delisted covers the main lists). Requesting removal before you've fixed the cause usually ends in relisting.

10. Check one real message

Finally, send a test message from each service to an external mailbox and paste the headers into the email header analyser. It shows whether SPF, DKIM and DMARC passed on a real message, which DNS checks alone can't prove.

How this fits with Cyber Essentials

Many clients ask their IT provider about Cyber Essentials because a customer or contract requires it. It's a UK scheme, so for clients elsewhere the same advice applies to whichever framework or security questionnaire they face. Be accurate about what it covers. The NCSC's Requirements for IT Infrastructure v3.3 organises the scheme under five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. It doesn't test DMARC or MTA-STS.

What it does say matters for email, though:

• Cloud services can't be excluded from scope. Hosted email such as Microsoft 365 or Google Workspace is in.
• MFA is mandatory for cloud services where it's available. The v3.3 wording is that "authentication to cloud services must always use MFA".
• High-risk and critical updates must be applied within 14 days of release, which includes on-premise mail servers and relays.

So an email security audit and a Cyber Essentials readiness check overlap rather than duplicate each other. Our summary of the 2026 Cyber Essentials changes covers v3.3 in more detail. If you support schools, the DfE's cyber security standards for schools and colleges take a similar line, asking IT support to check that email is set up to reduce the risk of imitation emails.

Reporting results to the client

Clients don't need DNS syntax. They need to know what could go wrong and what you're doing about it. A simple structure works:

1. One status line per domain: protected, partly protected or exposed to spoofing.
2. The three biggest risks in plain English, for example "Anyone can send email that looks like it comes from accounts@client.com."
3. What you'll change, in order, with any action the client must take, such as approving DNS access or confirming which systems send invoices.
4. What you'll monitor afterwards: DMARC reports, TLS reports and a monthly blocklist check.

Keep the raw results in your documentation platform so the next audit can show what changed. If you produce PDF packs for quarterly reviews, our free PDF merge tool combines them in the browser without uploading client network details.

The free tools for IT services page groups every check above in one place, and the free email deliverability checker gives a one-page summary of SPF, DKIM, DMARC, MX and blocklist status for a quick first look at a new client.

Running the audit on a schedule

A one-off audit decays. A sensible rhythm for most small business clients:

• At onboarding: the full checklist on every domain.
• Monthly: blocklist status, plus a skim of DMARC and TLS-RPT reports for unknown senders and failures.
• After any change: new sending service, mail migration, DNS host change or website rebuild.
• Quarterly: rerun the full checklist and report changes to the client.

This is also a natural place for automation. Make It Flow builds workflows that pull scheduled check results into a ticket or a client summary, while your engineers keep the decisions about what to change. If that would help your team, talk to us.

FAQ

What does an email security audit include?

It checks MX records, SPF, DKIM, DMARC policy and alignment, MTA-STS and TLS-RPT, TLS support on mail servers and portals, and blocklist status for every domain the organisation owns. A good audit also tests a real message's headers and lists every service that sends email as the domain.

How often should an MSP audit client email security?

Run a full audit at onboarding and at least quarterly, plus after any mail migration, DNS change or new sending service. Check blocklists and read DMARC and TLS reports monthly, because problems such as a compromised mailbox or a new unauthorised sender appear between quarterly reviews.

Is MTA-STS worth deploying for small businesses?

It's worth it where mail contains sensitive information, such as invoices or client data, because it stops downgrade attacks on mail in transit to the domain. Start in testing mode with TLS-RPT, review reports for a few weeks, then enforce. The main overhead is keeping the policy host's HTTPS certificate valid.

Does Cyber Essentials require DMARC?

No. Cyber Essentials v3.3 covers firewalls, secure configuration, security updates, user access control and malware protection. It doesn't test DMARC. It does bring hosted email into scope as a cloud service and requires MFA wherever it's available, so the two pieces of work complement each other.

What should replace NCSC Mail Check?

The NCSC retired Mail Check on 31 March 2026. It now points organisations to its free email security check for one-off tests and recommends commercial external attack surface management tools for ongoing monitoring. Many small businesses rely on their IT provider to read DMARC and TLS reports instead.

Should parked domains have DMARC?

Yes. A domain that never sends email can still be spoofed. Publish an SPF record of v=spf1 -all and a DMARC record with p=reject on every parked or defensive domain, so receiving servers reject any message that claims to come from it.