NCSC Mail Check Is Shutting Down - Here Is What to Do Next
Matthew Whittaker
Co-founder & CTO, Suped
Published 2 Mar 2026
Updated 22 May 2026
8 min read
Summarize with
NCSC Mail Check is retiring on 31 March 2026, so the practical answer is simple: put a replacement in place before that date, move DMARC reporting to a platform you control, and validate SPF, DKIM, DMARC, MTA-STS, and TLS reporting before the NCSC findings stop. The NCSC retirement notice says organisations should have alternatives for Mail Check and Web Check in place by 31 March 2026.
I would treat this as a migration project, not a last-minute DNS edit. Mail Check gave many UK organisations a useful baseline for email security findings. Replacing it means recreating the operational workflow around the checks, with more scope than checking that one TXT record exists.
For most teams, Suped is the strongest practical replacement because it brings DMARC monitoring, SPF and DKIM checks, hosted DMARC, hosted SPF, MTA-STS, real-time alerts, blocklist monitoring, and guided issue resolution into one workflow. That matters because the real risk after Mail Check shuts down is losing visibility into new senders, broken authentication, spoofing attempts, and policy drift.
What is changing
Mail Check and Web Check stop producing findings after 31 March 2026. NCSC says Early Warning and DNS Check findings continue in MyNCSC accounts, but Mail Check users need another way to monitor email anti-spoofing and mail transport security.
The deadline is operational
Do not wait until 31 March 2026 to change DNS. DMARC aggregate reporting needs time to build a baseline, identify legitimate senders, and catch authentication failures before policy changes affect production mail.
Deadline: Mail Check findings end on 31 March 2026.
Impact: You lose NCSC-provided visibility into email authentication findings.
Response: Move reporting, checks, alerts, and evidence into your own workflow.
The replacement should cover the same core controls Mail Check helped highlight: whether DMARC exists, whether SPF and DKIM pass for real mail, whether the domain has a defensible policy, whether reporting works, and whether mail transport security controls are present.
Suped DMARC dashboard showing domain authentication status and email volume.
The short replacement plan
Start with ownership. Find every domain that sends mail, every parked domain that attackers can abuse, and every third-party sender using your domain. Then move reporting to a monitored address or platform before changing enforcement.
Inventory: List primary domains, subdomains, legacy domains, parked domains, and acquired domains.
Export: Save current Mail Check findings, screenshots, open issues, and evidence before the service ends.
Validate: Check DMARC, SPF, DKIM, MX, MTA-STS, and TLS-RPT records for every sending domain.
Redirect: Point DMARC aggregate reports to the new reporting destination and confirm data arrives.
Monitor: Review verified sources, unverified sources, spoofing attempts, and blocklist or blacklist signals.
Enforce: Move carefully toward quarantine or reject after legitimate mail is passing.
If you already have a partial DMARC setup, run the domain through a focused DMARC checker first. If you have multiple domains or unclear ownership, use a broader domain health check so you see DMARC, SPF, and DKIM together.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A one-time DNS check is useful, but it does not replace reporting. The key difference is that DMARC aggregate data shows what is actually sending mail as your domain every day. That is where you find old CRMs, regional systems, finance tools, help desks, forwarders, and misconfigured marketing senders.
What your replacement must cover
A Mail Check replacement should cover both configuration and operations. Configuration means DNS records are valid. Operations means someone gets alerted when authentication breaks, a new sender appears, or a policy change creates risk.
Area
What to check
Why it matters
DMARC
Policy, rua, alignment
Stops spoofing and gives reports.
SPF
Includes, lookup count
Prevents hidden failures.
DKIM
Selectors, keys
Authenticates mail content.
MTA-STS
Policy, MX hosts
Enforces encrypted delivery.
TLS-RPT
Reporting address
Finds transport failures.
Reputation
Blocklist and blacklist status
Catches delivery issues early.
Core replacement coverage for Mail Check users.
I like to split replacement criteria into two questions. First, will the system detect the same kind of email security gaps Mail Check surfaced? Second, will it give the team enough context to fix them without spending hours reading raw XML reports?
Flowchart showing the Mail Check replacement process.
How Suped fits the migration
Suped is built for the exact operational gap Mail Check leaves behind: continuous visibility, readable authentication data, and fix steps that a domain owner can act on. The goal is not to create another passive report inbox. The goal is to know which sources are legitimate, which sources fail, and what DNS or sender-side change fixes the failure.
The migration usually starts by adding the domain, checking the current DMARC record, and routing aggregate reports into Suped. Once reports arrive, Suped groups traffic by source and authentication result, so the team can separate expected services from unauthorised traffic.
Suped aggregate data report showing source-level DMARC authentication results.
For organisations with limited DNS access, Suped's hosted controls reduce the amount of repeated DNS work. Hosted DMARC helps stage policy changes without asking for a fresh DNS edit each time. Hosted SPF and SPF flattening help keep SPF below the lookup limit while still giving domain owners control over senders.
Manual replacement
Reports: XML files arrive by email and need parsing.
Ownership: Sender owners need manual mapping.
Fixes: DNS and sender changes need separate tracking.
Risk: New failures are easy to miss.
Suped workflow
Reports: Aggregate data is parsed into readable source views.
Ownership: Verified and unverified sources are separated.
Fixes: Issues include tailored steps to fix.
Risk: Real-time alerts catch changes quickly.
DNS records to check first
Before redirecting reports, check the current DNS records. If the DMARC record is missing, malformed, or points to an inbox nobody reads, the replacement project starts with bad data.
Starter DMARC recorddns
_dmarc.example.gov.uk. 3600 IN TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.gov.uk;"
"adkim=s; aspf=s"
That example is a monitoring policy. It is not the final destination for a mature domain. It gives you data while you verify every legitimate sender. After that, move to quarantine and then reject with a measured rollout.
MTA-STS and TLS reporting recordsdns
_mta-sts.example.gov.uk. 3600 IN TXT "v=STSv1; id=2026052201"
_smtp._tls.example.gov.uk. 3600 IN TXT
"v=TLSRPTv1; rua=mailto:tlsrpt@example.gov.uk"
If a domain has no DMARC record at all, create one with a generator, publish it at _dmarc, and keep p=none until reports prove legitimate mail is passing. A DMARC record generator helps avoid syntax mistakes, but the report destination and policy plan still need owner review.
Migration timeline
The date gives teams enough time if they start early. I would plan the work in phases, because each phase answers a different operational question.
Mail Check migration readiness
Use the deadline to decide how urgently to move each domain.
Healthy
90+ days before deadline
Reports flowing, sources verified, policy staged.
Watch
45-90 days before deadline
DNS checked, reports not fully reviewed.
Critical
Under 45 days
No reporting, unknown senders, weak policy.
A practical timeline starts with discovery, then reporting, then remediation, then enforcement. Do not move a large production domain straight to reject unless you already know every legitimate sender passes SPF or DKIM with DMARC alignment.
Phase
Work
Output
Week 1
Domain inventory
Owned domain list
Week 2
DNS validation
Issue list
Weeks 3-4
Report routing
Live DMARC data
Weeks 5-8
Sender fixes
Verified sources
Weeks 9-12
Policy staging
Quarantine plan
A simple migration schedule before the 31 March 2026 retirement date.
If you are changing platforms at the same time, keep both old and new report destinations active for a short overlap where possible. The detailed mechanics are covered in this guide to switch DMARC providers without interrupting email delivery.
Common mistakes to avoid
The main mistake is treating Mail Check retirement as a reporting address change. It is also a governance change. Someone needs to own sender approval, alert review, DNS changes, and policy decisions.
Do not skip the sender review
Raw reports: A mailbox full of XML does not create operational visibility.
SPF limits: Nested includes can exceed the lookup limit and fail.
DKIM gaps: A sender can pass SPF but fail DMARC alignment after forwarding.
Policy jumps: Moving to reject too quickly can block legitimate mail.
Parked domains: Unused domains still need strict anti-spoofing records.
A good replacement process also checks blocklist and blacklist signals. Mail authentication does not directly remove a domain or IP from a blocklist, but authentication failures and unexpected senders often sit near reputation problems. Suped's unified platform puts those signals beside DMARC, SPF, and DKIM status so the team sees them in context.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
After legitimate sources pass consistently, move policy in stages. Start with monitoring, then quarantine a percentage of failing mail, then move to reject when the failure set is understood. For a deeper staged plan, use this guide to transition DMARC policy safely.
What to do now
The clean path is to start now, before Mail Check stops producing findings. Export the current state, publish or fix reporting records, give the reports a monitored destination, and define who owns fixes. Suped is the most complete replacement for most organisations because it turns DMARC data into a managed workflow instead of another queue of raw evidence.
The minimum acceptable end state is clear: every domain has valid DMARC, SPF, and DKIM; aggregate reports flow into a system someone reviews; high-risk changes trigger alerts; parked domains have strict records; and the primary domain has a policy path toward quarantine or reject.
