[GH-ISSUE #3944] Relative MX records produce false "Domain has no MX record" alarms #1940

New issue

Open

opened 2026-02-27 11:19:59 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 11:19:59 +03:00

Owner

Originally created by @utdream on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/3944

Impacted versions

OS Type: Debian/Ubuntu
OS Version: 24.04 LTS Minimal
Database Type: PostgreSQL
Database version: 16
Modoboa: 2.7.1
installer used: Yes
Webserver: Nginx

Steps to reproduce

Add a domain that uses Cloudflare and a relative mail server name (e.g. "mail" instead of "mail.domain.org")

Performing a "dig" on a domain with a relative MX record like this results in the "mail." domain being returned, which is also what Python gets in Modoboa's code.

Current behavior

All of my domains had relative domains in their MX records in Cloudflare. Cloudflare returns these relative domains with dots at the end (e.g. "mail.") which generally indicates a FQDN, but in reality it is a relative domain when entered into Cloudflare's UI.

When adding a domain configured in this way into Modoboa, its python code has trouble properly resolving these URL's, and raises false alarms of "Domain has no MX record".

I tracked this down to /srv/modoboa/env/lib/python3.12/site-packages/modoboa/admin/lib.py where it does get_domain_mx_list() and strips the trailing dot (line 257). It then tries to resolve the singular "mail" domain, which of course doesn't resolve, silently errors, then results in the false alarm.

mx_domain = dns_answer.exchange.to_unicode(
    omit_final_dot=True, idna_codec=IDNA_2008_UTS_46
)

The temporary fix is to use a FQDN in your MX record (e.g. "mail.domain.org" instead of just "mail") and Modoboa will resolve it properly.

Expected behavior

Seeing as the "mail." record is indeed a proper MX record and that mail continues to work with this DNS set up, I believe the most resilient solution is for Modoboa to also be able to resolve this kind of DNS MX record. Perhaps a secondary function where if the first attempt to resolve fails, then Modoboa tries to resolve it as a relative domain instead of a FQDN? So, try first as a standard FQDN then if that produces no results, try alternatively as a relative DNS entry.

Originally created by @utdream on GitHub (Feb 25, 2026). Original GitHub issue: https://github.com/modoboa/modoboa/issues/3944 # Impacted versions * OS Type: Debian/Ubuntu * OS Version: 24.04 LTS Minimal * Database Type: PostgreSQL * Database version: 16 * Modoboa: 2.7.1 * installer used: Yes * Webserver: Nginx # Steps to reproduce Add a domain that uses Cloudflare and a relative mail server name (e.g. "mail" instead of "mail.domain.org") Performing a "dig" on a domain with a relative MX record like this results in the "mail." domain being returned, which is also what Python gets in Modoboa's code. # Current behavior All of my domains had relative domains in their MX records in Cloudflare. Cloudflare returns these relative domains with dots at the end (e.g. "mail.") which generally indicates a FQDN, but in reality it is a relative domain when entered into Cloudflare's UI. When adding a domain configured in this way into Modoboa, its python code has trouble properly resolving these URL's, and raises false alarms of "Domain has no MX record". I tracked this down to `/srv/modoboa/env/lib/python3.12/site-packages/modoboa/admin/lib.py` where it does `get_domain_mx_list()` and strips the trailing dot (line 257). It then tries to resolve the singular "mail" domain, which of course doesn't resolve, silently errors, then results in the false alarm. ``` mx_domain = dns_answer.exchange.to_unicode( omit_final_dot=True, idna_codec=IDNA_2008_UTS_46 ) ``` The temporary fix is to use a FQDN in your MX record (e.g. "mail.domain.org" instead of just "mail") and Modoboa will resolve it properly. # Expected behavior Seeing as the "mail." record is indeed a proper MX record and that mail continues to work with this DNS set up, I believe the most resilient solution is for Modoboa to also be able to resolve this kind of DNS MX record. Perhaps a secondary function where if the first attempt to resolve fails, then Modoboa tries to resolve it as a relative domain instead of a FQDN? So, try first as a standard FQDN then if that produces no results, try alternatively as a relative DNS entry.