Health Tools

Healthy email delivery depends on two sides: your domain's DNS records (MX, SPF, DKIM, DMARC) must give the outside world the right information, and the DeepFilter server must talk to the internet with the right identity and connection settings. A mistake in these settings — a backup MX record that bypasses the filter, a DKIM key that has not reached DNS, outbound port 25 closed by the service provider — often surfaces only through a delivery complaint.

The Monitor → Health Tools screen checks these settings from the panel, as the outside world sees them. It has two tabs: the Domain tab checks the domain's DNS records, and the Server tab checks this DeepFilter server's connection to the internet and its identity.

note

Health Tools is available only to the global administrator. Accounts with the domain administrator and viewer roles do not see this page in the menu.

Reading the Results

Each check is shown as a card. The card header shows the name of the check and the question it answers (for example MX Record — "Where is mail for this domain delivered?"). The body of the card is split into three columns:

• Current state — the value found in DNS or on the server; the record text can be taken with the Copy button.
• Is it correct? — whether the value found breaks delivery or security.
• Can it be hardened? — whether a setting that works correctly can be made more secure. Each suggestion has a Required, Recommended or Optional level; when there is no suggestion, the card reads "No further hardening needed."

Each card has a status:

• Correct — the setting is as expected.
• Can be hardened — it works, but a more secure setting is possible.
• Faulty — there is a problem that affects delivery or security.
• Info — an informational result, not an assessment.
• No record / Not defined — the record in question is not published. For optional records this status does not count as an error.
• Not tested — the test could not run because a precondition of the check was not met.
• Check failed — an error occurred during the check; the result is incomplete.

The summary bar at the top of the tab gathers the result into a single line: the number of checks without errors appears in a ring, and below it the number of faulty, can-be-hardened and correct checks. If there is a critical issue, the headline reads "… critical issues affect delivery or security"; if there is none, it reads "No critical issues, hardening suggestions available" or "All checks are correct".

Some cards have shortcuts to the related settings screen: DKIM settings (see Outbound Email, DKIM Signing section), Server hostname setting and SSL settings (see General Settings), DNS settings (see System, DNS section), RBL Monitor (see Blacklist (RBL) Monitor) and DMARC Management (see DMARC Management).

Domain Tab

The Domain tab checks the email-related DNS records of the domain you select. Queries are sent separately to the external resolvers 1.1.1.1 and 8.8.8.8 instead of the server's own DNS, so the result reflects the picture a sending server on the internet sees. If the two resolvers give different answers, the card shows a "Resolver answers differ" warning — this usually points to a record that was changed recently and has not yet propagated everywhere.

If the server cannot reach external DNS over 53/UDP, queries are made over HTTPS (DoH) and the results still reflect the outside world. If the external resolvers cannot be reached at all, queries go through the server's own DNS; in that case a warning on the screen states that the results may reflect the internal DNS view.

Step by step

1. Open the Monitor → Health Tools screen; the Domain tab is selected.
2. In the Domain field, pick a domain from the list or type a domain name. Next to the field, an Internal domain / External domain badge shows whether the domain is defined on the system.
3. If you want to check DKIM for a specific selector, fill in the DKIM selector field. This field is optional: if DKIM is defined on the system for the domain, the selector is taken from there.
4. Press Check. The cards fill in one by one.

For a domain without a DKIM definition on the system, the screen suggests that you enter the selector you use, or scan the commonly used selectors with the Try common selectors button.

Core records

The four records required for delivery and authentication are checked in this group and are included in the health summary:

• MX Record — Checks whether the domain's MX targets point to DeepFilter, whether their names resolve, and their PTR records. For internal domains the most important finding is the warning about an MX that bypasses the filter: email arriving at a target that does not point to DeepFilter reaches the mail server unscanned, and spammers deliberately write to low-priority MX records. In a high-availability setup, a target that points to another DeepFilter server does not trigger this warning. The bypass check does not apply to external domains.
• SPF Record — Checks whether there is a single, syntactically valid SPF record, whether the number of DNS lookups stays below the limit of 10, and whether the DeepFilter outbound IP is authorized in the record. +all, the ptr mechanism and the use of ~all instead of -all are shown as hardening suggestions.
• DKIM Signature — Checks whether the key published in DNS is exactly the same as the key on the system, the key length, and whether signing is turned on. If the key does not match, the ready-made DNS record is in the DKIM settings.
• DMARC Policy — Checks the DMARC record's policy (none, quarantine, reject), the enforcement percentage and the aggregate report address (rua). The suggestions follow a gradual transition: monitoring mode (p=none) first, quarantine as long as reports stay clean, and reject last. You follow the content of the reports and whether you are ready for the transition on the DMARC Management screen. While the policy is none, the quarantine suggestion for internal domains comes from the same decision as the Policy transition readiness card in DMARC Management (report data of the last 30 days); the two screens do not give different advice. If report collection is not enabled for the domain, the suggestion is Before tightening the policy, enable report collection in Monitor › DMARC Management. If the report data is not yet sufficient for the transition (or there is no verified legitimate traffic), no ready-made record is given and you are asked to wait for the card's recommendation. When the data is ready, the suggested record follows the card's recommendation: quarantine with pct=25, or quarantine directly. For external domains the general staged transition advice is shown, without a ready-made record.

Advanced

Transport security and brand records are checked in this group. These records are optional and do not affect the health score; the summary bar shows the number of defined ones separately.

• MTA-STS — Checks the policy that asks sending servers to deliver to this domain only over an encrypted connection: the _mta-sts TXT record, whether the policy file can be downloaded and is valid, the policy mode (testing, enforce, none), and whether the MX records match the list in the policy. In enforce mode, no delivery is made to an MX that is not on the list. The suggestion is to publish in testing mode first and move to enforce once TLS-RPT reports stay clean.
• TLS-RPT — Checks the presence and validity of the record that defines the address where encrypted delivery problems are reported.
• DNSSEC — Checks whether the domain zone is signed and whether the signature validates.
• BIMI — Checks the record that lets recipients show your brand's logo in their mailbox. The prerequisite for BIMI is a DMARC policy of at least quarantine.

Helper tools

The Domain tab has three helper tools:

• SPF IP Test — Answers the question "If email is sent on behalf of this domain from this IP, what will the receiving server decide?" Enter a sending IP (or select DeepFilter outbound IP) and press Test; the result (Pass, Fail, SoftFail, Neutral, None, PermError, TempError) is shown together with the evaluation steps. Each step is marked matched, no match or not evaluated: because SPF stops at the first matching rule, the steps after the matching rule appear as not evaluated.
• SPF Generator — As you select the sources that send email on behalf of the domain (DeepFilter outbound IP, MX servers, A record, additional IPs and additional includes), the suggested record is built live and the number of DNS lookups is shown. The Extra includes (comma-separated) field also accepts targets that start with an underscore, such as _spf.mailgun.org. Includes in the existing record (for example spf.protection.outlook.com for Microsoft 365 or _spf.google.com for Google Workspace) appear in this field and stay in the record unless you remove them from the field. Other existing terms that the generator does not manage are kept in the record as they are.
• DMARC Generator — Builds the suggested DMARC record with the policy, enforcement percentage (pct), subdomain policy (sp), aggregate report address (rua) and alignment settings. Existing tags that the form does not manage are kept in the record as they are. To collect DMARC reports in DeepFilter, enter the domain's dmarc-rapor@<domain> address in the rua field (see DMARC Management).

caution

The generators only suggest the record; they do not write it to DNS. Enter the suggested record at your DNS provider in place of the existing record. Adding a second SPF record to a domain invalidates SPF.

Server Tab

The Server tab checks this DeepFilter server's connection to the internet and the identity it presents to the outside. The test starts automatically the first time the tab opens; to run it again, press Start Test. The top of the tab shows the Server name (HELO), Public IPv4 and Public IPv6 information. The public IPv4 is detected automatically; if the correct address cannot be detected behind NAT, you can type it into the field.

Flow diagram

The diagram at the top of the tab shows three lanes between the server and the internet:

• Inbound · 25/TCP (Internet → Server) — whether outside mail servers can reach this server.
• DNS · PTR / FCrDNS — whether the server's IP resolves back to its own name.
• Outbound · 25/TCP (Server → Internet) — whether the server can connect to outside mail servers.

Each lane is shown in the Open / correct, Can be hardened, Blocked / faulty or Not tested color. The tags on the lane (TLS, Greeting, RBL, Resolver, DANE, Public IP, Relay, External probe) take you to the related check card.

Server checks

• Public IP and NAT — Shows which IP the server uses to reach the internet and whether it is behind NAT. The PTR, SPF and RBL checks are made against this public IP.
• Local DNS Resolver — Checks that DeepFilter's built-in resolver answers and that blacklist (RBL) queries are not refused.
• Outbound 25/TCP — Checks that outside mail servers can be reached on port 25. If the port is closed, the suggestion is to allow outbound 25/TCP on the firewall or to ask the service provider to lift the block; if the block cannot be lifted, a smart relay (relayhost) can be defined for outbound email.
• PTR and HELO — Checks the PTR record of the public IP, forward-confirmed reverse DNS (FCrDNS) and whether the PTR name is the same as the HELO name; if there is IPv6 egress, it also checks the IPv6 PTR. The PTR record is defined by your service provider.
• STARTTLS and Certificate — Checks that encryption is offered on inbound connections, that the certificate is trusted, valid and matches the HELO name, and whether old TLS versions are enabled.
• SMTP Greeting — Checks that the server name in the greeting message is the same as the HELO name.
• Blocklist (RBL) — Shows the latest result of the Blacklist (RBL) Monitor screen.
• DANE / TLSA — Checks the presence of a TLSA record. It is optional and requires the zone to be signed with DNSSEC.
• Inbound 25/TCP (external) — Checks whether the server's port 25 can be reached from the internet, the greeting seen from outside, and whether STARTTLS and the certificate are altered by a device along the path.
• Open Relay — Checks from outside whether the server relays email for foreign recipients. An open relay quickly gets the server onto blacklists. The test does not send any email; it only evaluates the response given to the relay request.

External probe

Inbound port 25 and open relay cannot be tested reliably from the server itself: a connection made from the internal network is already authorized, and in a NAT setup it does not reflect traffic coming from outside. These two checks are made through DeepFilter's external probe on the internet, which connects to the server's public IPv4 address.

When the external probe cannot be reached, these checks are shown as Not tested; this does not count as an error. In that case the screen shows how you can run the same test by hand from a machine outside.

note

When the external probe connects to an address other than the server's public IP, the result is shown as "Not tested — different IP": the server may be reaching the internet with a different IP, and the measured result may not belong to this server.

Points to Note

• Checks cannot be repeated at short intervals. When many checks are run back to back, or the server test was run a short while ago, the screen shows after how many seconds you can try again.
• DNS changes may not show up immediately. If the resolvers give different answers right after you change a record, wait for the record to propagate and run the check again.
• Switching tabs does not stop a check. Results are kept when you move between the Domain and Server tabs; when you leave the page, a running check stops.