New Forgejo tool validates email security protocols for self-hosted servers

The Sig-I/O team at Forgejo has released a new open-source utility called mailcheck, designed specifically for system administrators managing their own email infrastructure. Published on October 5, 2026, this command-line tool allows operators to validate critical email security protocols including SPF, DKIM, DMARC, and TLSA without the risk of sending test messages. It provides a lightweight way to diagnose configuration errors that often lead to deliverability issues or security vulnerabilities in self-hosted environments.

What happened

The release introduces a specialized diagnostic tool that performs DNS-policy checks and SMTP connectivity tests. Unlike full-scale mail authentication simulators, mailcheck focuses on validating the syntax and existence of DNS records that govern how other servers treat incoming mail from your domain. It checks Sender Policy Framework (SPF) records for syntax validity and lookup limits, verifies DomainKeys Identified Mail (DKIM) public key encoding, and inspects Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies.

For transport security, the tool examines Transport Layer Security Authentication (TLSA) records, which are part of the DNS-based Authentication of Named Entities (DANE) protocol. It connects to the target mail server’s port 25 to verify SMTP availability and STARTTLS support. The tool separates certificate verification from the TLS handshake, allowing it to inspect certificates that are not publicly trusted but may be valid within a DANE context. This distinction is crucial for administrators who rely on DANE for authentication rather than traditional Certificate Authorities.

The utility outputs results using standard Nagios exit codes, making it easy to integrate into existing monitoring stacks. A status of 0 indicates OK, 1 is WARNING, 2 is CRITICAL, and 3 is UNKNOWN. The overall status reflects the most severe result found during the check. For example, if SPF is valid but no TLSA record exists, the tool returns a WARNING status with detailed metrics such as connection duration in milliseconds.

Key details

• The tool uses the github.com/miekg/dns library (v1.1.70) for DNS queries, supporting EDNS0 and DNSSEC-related features.
• SPF checks validate record syntax and the ten-DNS-lookup limit but do not simulate every possible sender IP recursively.
• DKIM validation requires manual selector input, as DNS does not provide a universal method to enumerate all selectors.
• DMARC checks validate record tags and fall back to the organizational domain’s record if none exists for the specific subdomain.
• TLSA matching supports usages 2 and 3, treating records as secure only if the MX lookup was also DNSSEC-secure.
• The default minimum TLS version is 1.2, causing servers supporting only legacy versions like 1.0 or 1.1 to fail the check.

Background

Email security relies heavily on DNS records to prevent spoofing and ensure encrypted transmission. SPF tells receiving servers which IP addresses are authorized to send mail for a domain. DKIM adds a digital signature to emails, allowing receivers to verify that the message was not altered in transit. DMARC combines these two, telling receivers what to do if an email fails SPF or DKIM checks, such as rejecting it or marking it as spam.

DANE and TLSA take this further by binding TLS certificates to DNS records. This prevents man-in-the-middle attacks where an attacker might present a valid but unauthorized certificate. However, DANE relies on DNSSEC (Domain Name System Security Extensions) to ensure the DNS records themselves have not been tampered with. Mailcheck reports DNSSEC status based on the Authenticated Data (AD) bit returned by the recursive resolver, meaning it trusts the resolver’s validation rather than performing its own complete DNSSEC chain validation.

Why it matters

For teams running self-hosted software, email deliverability is a common pain point. Misconfigured SPF records can cause legitimate notifications to land in spam folders, while missing DMARC policies leave domains vulnerable to phishing attacks. Traditional testing methods often involve sending actual emails to external services like Gmail or Outlook, which is slow, imprecise, and can trigger rate limits or abuse filters. Mailcheck offers a deterministic way to validate configurations locally before deploying changes to production DNS zones.

Furthermore, the separation of certificate verification from the TLS handshake is significant for internal or private mail servers. Administrators often use self-signed or private CA certificates for internal communication. Standard tools might flag these as errors, but mailcheck allows inspection of these certificates against TLSA records, supporting secure internal architectures that do not rely on public trust chains. This makes it a valuable asset for hybrid environments where some mail flow is public and some is private.

What you can do

• Install mailcheck from the Forgejo repository and run it against your domain to baseline your current email security posture.
• Use the --dkim flag with known selectors to verify that your public keys are correctly published and properly formatted.
• Integrate the tool into your CI/CD pipeline or monitoring system using its Nagios-compatible exit codes for automated alerts.
• Point the --dns flag to a trusted validating recursive resolver if you require accurate DNSSEC status reporting for DANE.
• Test your SMTP server’s TLS configuration by ensuring it supports at least TLS 1.2, as older versions will fail the check.
• Review the suggested future extensions list to understand current limitations, such as the lack of full recursive SPF evaluation.