What is inside

39 tools across five groups: Infrastructure, Domain & Email, Generators, Security & Web, and Local Utilities. Examples include:

• SPF, DKIM and DMARC - analyzers to inspect your existing records, plus generators to create new ones correctly
• MX and blacklist lookups - the blacklist check queries 7 public DNS blocklists, and every result shows its source and what was not tested
• DNS propagation check - see how a record resolves from different locations
• Subdomain finder - list the subdomains of a domain
• SSL and WHOIS - certificate and registration details

No account needed

Every check runs without signing in. You open the tool, enter a domain, and get the result.

A free account exists only for saving things: the free plan saves 3 domains with daily monitoring. A Pro plan ($29/month) covers 50 domains with 6-hour scans, alerts, API access and 12-month history.

Why I built it

The standard tools in this space work, but using them means jumping between several sites with dated interfaces. I wanted one calm place with the same kind of checks and a cleaner design, so I built it.

What I would love feedback on

1. Is a better design enough of a reason to switch tools you already use?
2. Which tool is missing that would make you bookmark it - bulk checks, an API, something else?
3. If you work in a technical niche like this, what growth path has worked for you?

It is early, and I am sure there are gaps I am too close to see. Try it here: thenetworktools.com - happy to answer anything in the comments.

Step 1: Check SPF first

SPF is a TXT record on your domain that lists which servers may send mail for it.

dig +short TXT example.com | grep spf1

Common failures:

• Two SPF records. A domain must have exactly one record starting with v=spf1. Two records gives a permerror. Merge them into one.
• More than 10 DNS lookups. include, a, mx, ptr and redirect each count, and nested includes count too. Past 10 you get a permerror. Remove unused includes or flatten them.
• The real sender is missing. If your newsletter tool or CRM sends as your domain, its include must be in the record.
• Wrong ending. -all rejects everything not listed, ~all soft-fails. Use ~all while you are still finding senders, then tighten it.

Also remember that SPF checks the envelope sender (Return-Path), not the visible From address. That matters for DMARC alignment, below.

Step 2: Check DKIM

DKIM signs each message. The public key lives in DNS at selector._domainkey.example.com. You need the selector, which is in the DKIM-Signature header of a message you sent (s=).

dig +short TXT selector1._domainkey.example.com

Common failures:

• Wrong or missing selector record. The signature points at a selector that does not exist in DNS.
• Key split badly. Long keys are split into several quoted strings inside one TXT record. Some DNS panels break them or add stray spaces.
• Body changed after signing. Mailing list footers, link rewriting and disclaimers added after signing break the signature.
• Weak key. Use 2048-bit keys if your provider supports them.

Step 3: Check DMARC and alignment

DMARC is a TXT record at _dmarc.example.com.

dig +short TXT _dmarc.example.com

A starter record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DMARC passes when SPF or DKIM passes and aligns with the From domain. Aligned means the domain that passed matches the From domain (exact match in strict mode, same organizational domain in relaxed mode, which is the default). This is the part people miss: SPF can pass for your email provider's bounce domain and DKIM can pass for the provider's own domain, and DMARC still fails because neither matches your From address. The fix is to set up a custom DKIM signing domain or custom return-path with your provider.

Step 4: Read the headers of a failing message

In Gmail, open the message, choose "Show original", and look at the Authentication-Results header:

spf=pass smtp.mailfrom=bounce.provider.com
dkim=pass header.d=provider.com
dmarc=fail header.from=example.com

That example shows the alignment problem exactly: both pass, DMARC fails, because neither domain is example.com.

Step 5: Roll out the DMARC policy slowly

1. Start with p=none and collect the rua aggregate reports for a couple of weeks.
2. Fix every legitimate sender that fails.
3. Move to p=quarantine, optionally with pct=25 first.
4. Move to p=reject once reports are clean.

Jumping straight to p=reject is how legitimate invoices end up bounced.

Tools I use

dig and nslookup cover most of it. If you want a web page that runs the lookups and flags the common errors above (duplicate SPF, lookup count, missing selector, DMARC policy), I run The Network Tools, which has SPF, DKIM and DMARC analyzers along with MX, DNS propagation and blacklist checks. There is a free plan. MXToolbox and Google Admin Toolbox do similar jobs, so use whichever you prefer.

If you have a failure that does not match any of the above, paste the Authentication-Results header (with your own domain names removed if you like) in the comments.