Email for a domain depends on half a dozen DNS records and a mail server that has to speak TLS correctly. When you inherit a domain, onboard a customer or simply want to know whether everything is in order, checking each piece separately takes time, and it is easy to forget one, such as the TLS-RPT record nobody remembers adding.
The Email Health Check runs the core checks for a domain in one go: MX, SPF, DMARC, DKIM (with a selector you provide), MTA-STS, TLS-RPT and an SMTP/STARTTLS test of the primary mail server. The result is a table with one row per check and the findings behind each, with no invented score. Use it as the first step of an audit, then open the individual tools for details.
What is an email health check?
In simple terms
An email health check is a checkup for a domain's mail setup. It asks: can the domain receive mail, does it say who may send for it, can receivers verify signatures, does it tell receivers what to do with fakes, and is mail to it encrypted? Each answer is a pass, a warning or a problem, with a short explanation.
Technical background
The report combines checks based on these standards:
| Check | Standard | What it covers |
|---|---|---|
| MX | RFC 5321, RFC 7505 | Where inbound mail is delivered |
| SPF | RFC 7208 | Authorized sending servers, 10-lookup limit |
| DMARC | RFC 7489 | Policy for unauthenticated From domains, reporting |
| DKIM | RFC 6376 | Public signing key for a selector |
| MTA-STS | RFC 8461 | Policy requiring verified TLS for inbound mail |
| TLS-RPT | RFC 8460 | Reports about TLS delivery failures |
| SMTP / TLS | RFC 5321, RFC 3207 | Reachability, STARTTLS and certificate of the MX |
Each row is produced by the same server operation as the dedicated tool, so the findings match what you see in the MX Lookup, SPF Lookup, DMARC Lookup, DKIM Lookup, MTA-STS Lookup, TLS-RPT Lookup and SMTP Test.
Why use an email health check?
- Audit a domain quickly when you take over its administration.
- Catch forgotten pieces such as a missing DMARC record or TLS-RPT.
- Spot transport problems: an MX without STARTTLS or with a certificate mismatch.
- Before and after changes: run it before a provider migration and again afterwards.
- Explain findings to non-specialists with plain-language rows and evidence.
Who should use it?
- Mail and system administrators responsible for one or many domains.
- MSPs and consultants onboarding customers.
- Security teams reviewing anti-spoofing and transport encryption.
- Small business owners who want a structured overview before calling their provider.
How the email health check works
The report runs in the browser as a sequence of calls to the NetTools.tech server, one after another (the server allows only a few parallel requests per visitor):
- MX for the domain via the public resolvers 1.1.1.1 and 8.8.8.8.
- SPF: record, include tree and lookup count.
- DMARC: record at
_dmarc, with fallback to parent domains and report authorization checks. - MTA-STS: TXT record at
_mta-stsand, if present, the policy file fromhttps://mta-sts.<domain>/.well-known/mta-sts.txt, compared with the MX hosts. - TLS-RPT: TXT record at
_smtp._tls. - DKIM, only if you entered a selector.
- SMTP: one connection to the first (lowest priority) MX host on the selected port (587 by default, or 25 or 465), with banner, EHLO, STARTTLS and QUIT.
Each row's level is the worst finding of that check: any error makes it "Problem", any warning "Warning", otherwise "Pass" or "Info". If a check fails entirely (for example a DNS timeout), the row is "Problem" with "Check failed" and the reason. A refused connection on port 587 or 465 is reported as "Info", because MX hosts usually receive on port 25 only.
A Blocklists row is always shown as "Not checked": blocklist checks are not part of this report yet. The whole report has a 60-second limit.
How to use the NetTools.tech Email Health Check
- Open Email Health Check.
- Enter the domain in Domain, for example
example.com. - Optionally enter a DKIM Selector (the
s=value from a DKIM-Signature header; the Email Header Analyzer shows it). - Choose the SMTP Port:
587(default),25to test inbound delivery to the MX, or465. - Press Run Email Health Check. The report takes a few seconds because the checks run in sequence.
- Read the summary line and the table, then expand each check's findings. Copy puts the report in your clipboard; Open in terminal runs
/email-health example.com --selector selector1in the web terminal.
Understanding the results
The report starts with a summary: "All checked items pass.", "No problems; N warnings." or "N problems and M warnings found." Then one row per check:
| Result | Meaning | What to look for |
|---|---|---|
| MX | "N mail servers" or "Null MX — accepts no email" | Problem if an MX host has no address |
| SPF | "N/10 lookups" or "No record" | Multiple records, +all, over 10 lookups |
| DMARC | "p=none/quarantine/reject" or "No record" | p=none is a warning; missing rua as well |
| DKIM | "N-bit key at selector._domainkey…", "No usable key" or "Add --selector to check a DKIM key" | Keys under 2048 bits are a warning |
| MTA-STS | "mode enforce/testing", "Record without valid policy" or "Not published" | MX hosts not covered by the policy |
| TLS-RPT | "Published" or "Not published" | Not published is a warning |
| SMTP / TLS (port N) | Host and TLS version with "valid certificate" or "certificate problem", or "no TLS" | Certificate problems matter for MTA-STS |
| Blocklists | Always "Not checked" for now | Use the blacklist tools separately |
| Pass / Info / Warning / Problem / Not checked | Row level from the real findings | Expand the row to see the evidence |
The report ends with a note that results come from public DNS and one SMTP connection, and that no email was sent.
Example: a typical small business domain
Illustrative report for a hypothetical domain example.com with selector selector1 and the default port 587:
1 problem and 3 warnings found.
Check Result Summary
MX Pass 2 mail servers
SPF Problem 5/10 lookups
DMARC Warning p=none
DKIM Warning 1024-bit key at selector1._domainkey.example.com
MTA-STS Info Not published
TLS-RPT Warning Not published
SMTP / TLS (port 587) Info The mail server does not accept connections on port 587
Blocklists Not checked Not included yet (DNS blocklist access is not set up)The SPF summary looks harmless, but the row is Problem: expanding it shows "_spf.old.example.net: no SPF record", an include left over from a former provider. A row's level is always the worst of its findings, so always expand rows rather than reading the summary column alone. Fix list: repair the SPF include, rotate DKIM to 2048 bits, publish TLS-RPT, move DMARC towards quarantine after reviewing reports, and run the check again with Port 25 to test the MX's STARTTLS on the delivery port.
Common use cases
- First look at a new customer's or newly acquired domain.
- Pre- and post-migration checks when changing email providers.
- Periodic reviews of a portfolio of domains.
- Preparing for mailbox-provider sender requirements, together with the Email Provider Compliance Check.
- Producing a quick written summary for a ticket or a customer.
Troubleshooting
A row says "Check failed: …"
That individual check could not run, usually because of a DNS timeout, SERVFAIL from the domain's name servers, or the rate limit. The other rows are still valid. Run the dedicated tool for that row to see the full error.
"Rate limit reached"
The report runs several server checks in a row. Wait about a minute and try again.
SMTP row is "No MX to test"
The MX check found no MX host (missing MX or null MX), so there was nothing to connect to.
SMTP shows "certificate problem"
TLS works but the certificate is not trusted or does not match the MX host name. Expand the row, then check details with the SMTP Test or the SSL Certificate Checker.
DKIM shows "No usable key"
The selector is wrong or the key is not published, revoked or undecodable. Confirm the selector from a real message's headers and check with the DKIM Lookup.
Common mistakes
- Reading "Not checked" as "fine". DKIM and Blocklists are only covered when you check them.
- Leaving the port at 587 and concluding the MX is unreachable; test inbound delivery on 25.
- Treating "Pass" across the board as a deliverability guarantee. Content, volume and sender reputation also matter.
- Running the report repeatedly while fixing one record, which burns rate limit; use the single tool instead.
Limitations
- Only the primary MX host is tested over SMTP, from one location.
- DKIM needs a selector you provide; only one selector per run.
- Blocklists are not part of the report.
- No overall score, and no checks that need a real message (alignment of an actual message, List-Unsubscribe, spam rates).
- DNS results come from public resolvers and may lag behind just-published changes.
- The underlying limits of each tool apply (for example the SMTP per-server limit of three tests per ten minutes).
Security & privacy
The domain and optional selector are sent to the NetTools.tech server, which queries public DNS, fetches the public MTA-STS policy over HTTPS and makes one SMTP connection to the primary MX. Those systems see the NetTools.tech server's address, not yours. Results are not stored; each underlying check writes a tool log entry with the tool name, the target and your shortened IP address, kept for 30 days (see the privacy policy). No email is sent and no passwords or credentials are needed.
Related tools
- MX Lookup (guide), SPF Lookup (guide), DMARC Lookup (guide) and DKIM Lookup (guide) – the individual DNS checks.
- SMTP Test – full session details for any MX host and port (guide).
- MTA-STS Lookup and TLS-RPT Lookup – transport security records (guide, guide).
- Email Provider Compliance Check – bulk-sender requirements (guide).
- Email Blacklist Check – the blocklist part this report leaves out (guide).
Summary
The Email Health Check gives one structured overview of a domain's mail setup: routing, sender authentication, policy, transport encryption and reporting, each backed by the same checks as the dedicated tools. It reports only what those checks found, marks what it did not check, and never invents a score. Use it to find the weak spots, then fix and verify them with the individual tools.
Frequently asked questions
What does the Email Health Check test?
It runs the MX, SPF, DMARC, MTA-STS and TLS-RPT checks for a domain, the DKIM check if you supply a selector, and one SMTP/STARTTLS test against the primary MX host. Each becomes one row with Pass, Info, Warning, Problem or Not checked, and expandable findings.
Is there an overall score?
No. The report counts problems and warnings and lists the evidence for each check, but it never invents a score or grade. A summary line only says how many problems and warnings the real checks found.
Does it check DKIM automatically?
No. DKIM keys live under selectors that cannot be listed from DNS, so the check runs only when you enter a selector. Without one, the DKIM row shows Not checked with a hint to add the selector.
Does the Email Health Check include blocklists?
Not at the moment: the report shows a Blocklists row marked Not checked. Use the Email Blacklist Check or MultiRBL Check for the mail server's IP address.
Why does the SMTP row say the server does not accept connections on port 587?
The SMTP test defaults to port 587 on the primary MX host, and many MX servers only receive on port 25 while submission runs elsewhere. That case is reported as information, not as a problem; choose port 25 to test inbound delivery.
Does the check send any email?
No. All checks are DNS lookups plus one SMTP connection that stops after EHLO and STARTTLS with QUIT. No message, sender or recipient is transmitted and no credentials are used.
Why do I get a rate limit error?
The report runs up to seven server checks one after another, and each consumes part of your per-visitor rate limit. Wait a minute before running it again, or run the individual tools for the parts you are fixing.