← Frankys Web GitHub Contact
Frankys Web Mailtools

Check and understand email configurations

Domain Check

All email checks for a domain in one run: MX, SPF, DMARC, DKIM, MTA-STS and an SMTP connection test.

The Domain Check inspects a domain's email configuration in one run and sums up what has to work together for deliverability and spoofing protection. Instead of checking MX, SPF, DMARC, DKIM, MTA-STS and SMTP reachability one by one, it gives an overall picture with a traffic light per area. It is the right starting point for questions like why does our mail not arrive or is our domain protected against forgery.

What this tool checks

It calls six individual analyses in the same run: MX Lookup (responsible mail servers, their addresses and reverse DNS), SPF Check (record, syntax, the 10 lookup limit), DMARC Analyzer (policy, alignment, reporting), DKIM Lookup in probe mode (a list of common selectors), MTA-STS and TLS-RPT (policy fetch over HTTPS, comparison with the MX records) and an SMTP Test that connects to the MX servers on port 25 and checks STARTTLS. DANE is deliberately left out, there is a separate tool for it.

Reading the result

At the top there is a header with the worst level across all areas, below it a summary line per area with a traffic light: green means no findings, yellow a note or recommendation, red an error that impairs delivery or protection. Each area can be expanded and then shows exactly the findings and the resolved tree of the respective individual check. A failing sub-check (for example a timeout in the SMTP part) does not tip over the overall check, that area is then marked as not conclusively checked.

Background

The Domain Check bundles the standards of the individual checks: SPF per RFC 7208, DMARC per RFC 7489, DKIM per RFC 6376, the MX and SMTP layer per RFC 5321, MTA-STS per RFC 8461 and TLS-RPT per RFC 8460. It rates nothing anew, it runs the same logic as the individual tools, only bundled and with a stricter time and query budget.

Common problems and how to fix them

  • DKIM appears as not found. In the bundle, DKIM only runs in probe mode over common selectors. If the domain uses its own selector, that is not an error: take the selector from the DKIM-Signature header of a real message and run the DKIM Lookup individually with it.
  • SPF green, DMARC still red. Often the policy is at p=none or the rua address is missing. SPF says nothing about enforcement, that is DMARC's job.
  • The SMTP area reports an untrusted certificate. On port 25 TLS is opportunistic, so at first this is only a note. It becomes an error only once MTA-STS in enforce mode or DANE requires a valid certificate.
  • One area stays without a result. Usually a timeout under load (the SMTP part makes real outbound connections). Run the affected individual check on its own, it has more time budget.
  • Everything green, mail still does not arrive. The Domain Check covers configuration and reachability, not reputation. Also run the Blocklist Check on the sending IP and evaluate the DMARC aggregate reports.

Common questions

What is the Domain Check for?
For a quick overall view of a domain's email configuration: MX, SPF, DMARC, DKIM, MTA-STS and SMTP reachability in one run, with a traffic light per area. For detailed work on a single aspect, the individual tools are faster and more thorough.
Why does the Domain Check not find a DKIM selector?
Without a selector input it only tries a list of common selectors (default, google, selector1, s1 and others). If the domain uses a different selector, take the value from the s= field of the DKIM-Signature line of a real message and run the DKIM Lookup individually with it.
Why does the Domain Check take longer than the individual checks?
It runs all checks in the same call, including the DKIM selector search, the HTTPS fetch of the MTA-STS policy and real SMTP connections to the MX servers on port 25. That is why it runs in the background and the result appears automatically once everything is done.
What does the traffic light per area mean?
Green = no findings, yellow = a note or recommendation, red = an error that impairs delivery or protection. The header shows the worst level across all areas.
Why is DANE not part of the Domain Check?
DANE is so far not widely deployed and produces only noise for domains without TLSA records. Anyone who uses it checks it specifically with the DANE Check.
The Domain Check is green, yet mail lands in spam. Why?
Configuration and reachability are only part of deliverability. On top of that come IP and domain reputation (Blocklist Check), sending behaviour and content-based spam signals. The DMARC aggregate reports show how receivers actually rate your mail.