No MX-Record

Es ist eigentlich kein Spamfilter aber für Anti-Spam-Produkte ein leichtes, über dieses Verfahren bestimmte Mails zu unterbinden. Wenn eine Domäne auch Mails empfangen will, sollte der Betreiben einen MX-Record anlegen, der auf den oder die Mailserver verweist. Ohne MX-Record kann eine Domäne aber dennoch Mails empfangen. Die meisten Mailserver schauen dann einfach nach, ob es einen A-Record für die Domäne gibt.

Warum ein "Null-MX"?

Es kann durchaus gewollt sein, dass eine Domäne für technische Dienste oder für den Zugriff per Webbrowser genutzt wird aber eben weder Mails versendet noch Mails empfangen soll. Nur war dieser Fall nicht explizit definiert und so haben Mailserver beim Empfang keinen sicheren Weg gehabt, diese Information vom Betreiber einer Domäne zu erhalten. Wenn selbst ohne MX-Record war als Fallback der A oder AAAA-Record für den Namen hinter dem "@" zu nutzen. Das führte zu zwei Problemstellungen:

  • "gefälschte Mails" werden angenommen
    Wenn ein Mailserver eine Mail von so einer Domäne bekommt, dann kann er diese nicht von vorne herein ablehnen. Nur wenn es die Domäne gar nicht geben sollte, also kein SOA/NS-Eintrag vorhanden ist, könnte man dies als Ablehnungsgrund ansehen. Das ist aber gerade in privaten Netzwerken gerne mal ein Problem, wenn Hosts mit "crm.local" oder "webserver1.firma.intern" senden, zu denen Sie sicher keine DNS-Zonen angelegt haben.
  • Ausgehende Mails in der Queue
    Wenn ein Mailserver eine Nachricht an so eine Domäne senden will, dann kann er diese erst ein mal nicht zustellen. Viele Server halten die Mail dann aber in einer Queue und versuchen es z.B.: bis zu drei Tage wieder, ehe Sie die Mail dann als Unzustellbar zurückweisen. Das kostet zum einen etwas Speicherplatz und zusätzliche Wiederholungsversuche. Viel störender ist aber, dass der Absender seinen Fehler nicht sofort, sondern erst nach Tagen bemerken kann. Das ist in unserer schnelllebigen Zeit nicht mehr zu vermitteln.

Wenn eine Domäne also wirklich keine Mails empfangen soll, dann ist es eine gute Idee, dies allen Mailservern der Welt auch entsprechend mitzuteilen., damit diese es gar nicht mehr versuchen und möglichst schnell dem Anwender Bescheid geben.

RFC 7505

Genau dies beschreibt nun das Verfahren, welches in der RFC7505 dokumentiert wurde. Interessant, dass dieses Thema so lange noch nicht aufgefasst wurde. Aber besser später als nie und es wird sicher noch einige Zeit dauern, bis die Mailserver der Welt diese erweiterte Definition auch übernommen haben. Die RFC 7505 ist sehr kurz gefasst.

Internet mail determines the address of a receiving server through the DNS, first by looking für an MX record and then by looking für an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

Das ist eine allgemeine Beschreibung, dass ein Mailserver zuerst die MX-Records absuchen sollte und nur wenn diese nicht vorhanden sind, auf die A/AAAA-Records für den Hostnamen umsteigen. Und dieses Verfahren wird derart erweitert, dass es einen "Null MX"-Eintrag geben kann. Eine sehr einfacher DNS-Zone könnte dann so aussehen:

     @                  1800  IN  SOA ns1.example.com. admin.example.com. (
                                         2015081701   ; Seriennummer
                                                300   ; Refresh Time
                                                100   ; Retry Time
                                                6000  ; Expire Time
                                                600   ; negative Caching Zeit
                                               )
     @                  1800  IN  NS     ns1.example.com.
     @                  1800  IN  MX 0   .
     www.example.com.   1800  IN  A      192.168.1.2

Der MX-Eintrag ist vorhanden, aber verweist

Provider und Null-MX

Es ist aber aktuell noch gar nicht so einfach, einen "Null-MX" bei den verschiedenen Providern einzutragen. Die meisten Provider "unterstützen" ihre Anwender bei der manuellen Eingabe von DNS-Einträgen und verhindern ihrer Ansicht nach falsche Angaben. Das ist in den meisten Fällen auch wichtig, da ja nicht jeder Webadmin zugleich DNS-Experte ist. Entsprechend ist es aktuell nicht einfach einen "Null-MX" bei Providern zu pflegen:

Hinweis:
Die meisten Provider erlauben aber, dass sie beim Provider nur die Webseiten, Postfächer etc. hosten aber die DNS-Dienste durch einen anderen Server bereitstellen lassen. Diese Lösung betrachte hier hier aber nicht.

Provider
Datum
Status Letzter Check

Hosteurope.de
11. Aug. 15

Nein, HostEurope erwartet sowohl einen Hostname als auch eine Priorität von 1-99.

Man kann allerdings die DNS-Zone auf einen anderen DNS-Server delegieren

11. Aug 2015

1und1.de
11. Aug. 15

Nein, 1und1 verhindert einen "Null-Wert" beim Hostname. Die Priorität 0 scheint hier nicht zu stören.

11. Aug 2015

OVH.de
11. Aug. 15

Nicht über den Assistenten.

Allerdings erlaubt OVH auch die direkte Pflege und Import des "Zone-Datei".

Hierüber kann ich sehr wohl auch diesen Eintrag anlegen und die Datei importieren. Allerdings scheint dies noch nicht zu funktionieren.

11. Aug 2015

Domain Factory
2. Sep. 15


Danke an Daniel Wydler für den Hinweis und das Update, dass mittlerweile eine andere Fehlermeldung kommt.

 

Core Networks

NullMX ist möglich

14. Ap 18

Strato
(Aug 2022)

Strato erlaubt nicht die Eingabe eines "nullMX"s. Die Priorität ist ein Dropdown, in dem aber z.B. "0" nicht eingestellt werden kann

 

Hezner

Bei Hetzner gibt es zwei Wege/Plattformen wie man Domains erwerben kann:

  • Über die DNS-Console / Robot kann man im Text-Editor manuell einen NULL-MX Record setzen

  • Bei Domains die über die KonsoleH erworbenen wurden kann man einen NULL-MX Record setzen.

 

??

Weitere Provider habe ich noch nicht getestet

 

Ich kann nur die Provider prüfen, bei denen ich einen Vertrag habe. Ich bin daher auf ihre Mithilfe angewiesen, wenn diese Liste wachsen soll.

Negative Auswirkungen

Zwar sind in den verschiedenen RFCs die gültigen Einträge und die Reaktion darauf beschrieben, aber ich bin sicher, dass der ein oder andere Mailserver durcheinander kommen könnte. Die Priorität bestimmt, welche Einträge zuerst genutzt werden und der Eintrag "0" ist definitiv der höchste Eintrag.

Damit ist aber nicht sichergestellt, dass alle Mailsender auch mit dem Wert "0" und dem "Leerstring" richtig umgehen. Es könnte auch sein, dass ein Versender zwar zuerst den MX-Eintrag mit der höchsten Priorität nutzt aber natürlich so die Mail nicht zustellen kann.

Aber anstatt dann direkt aufzuhören, könnte er natürlich einfach den nächsten MX-Eintrag nutzen, sofern dieser definiert wäre. Natürlich sollte es neben neben so einem MX-Eintrag keine weiteren Einträge geben.

Positive Auswirkungen

Wenn sich dann aber die Mailserver darauf eingestellt und immer mehr Firmen die entsprechenden Domains durch solche Einträge für Mails "deaktiviert" haben, dann können Eingangsfilter und Spamfilter diese Information natürlich heranziehen, um Mails mit diesen Absendern gleich abzulehnen. Wenn auf eine Mail nicht geantwortet werden kann, muss Sie ja auch nicht angenommen werden.

Einen weiteren Vorteil werden natürlich all die Mailserver und Betreiber sehen, bei denen viele Mails an solche Domains ohne Mailservice die Queues verstopfen oder Kunden erst verspätet mit NDRs behelligt werden. Idealerweise kann der Mailserver auch hier schon dem Absender ein "Nein Danke" mitgeben, so dass die Mail gar nicht erst angenommen und in die Queue gestellt wird.

Die Spam-Erkennungsraten werden sich durch diesen Kniff aber sicher nicht verbessern. Insofern sind NoMX-Einträge ein kleiner Baustein in einem Gesamtkunstwerk aber nicht entscheidend.

Weitere Links