MX-Record: Erklärung des DNS-Eintrags

Der MX-Record (Mail Exchange Record) ist ein DNS-Eintrag, der angibt, welcher Mail­ser­ver für den Empfang von E-Mails einer Domain zuständig ist. Er sorgt dafür, dass ein­ge­hen­de E-Mails korrekt an den richtigen Server wei­ter­ge­lei­tet werden.

MX-Record erklärt – mit Beispiel

DNS-Records befinden sich in Zo­nen­da­tei­en – das sind einfache Text­da­tei­en, die alle Einträge zu einer Zone bündeln, für die der ent­spre­chen­de Server ver­ant­wort­lich ist. Stellt ein Client eine Anfrage, erhält der ant­wor­ten­de Server seine In­for­ma­tio­nen aus eben dieser Datei. Die un­ter­schied­li­chen Typen von Einträgen haben ver­schie­de­ne Funk­tio­nen. Die Abkürzung MX steht für Mail Exchange und gibt somit schon einen Hinweis darauf, was mit dem Eintrag erreicht wird: Über den MX-Record erhält ein Client via DNS die In­for­ma­ti­on, unter welcher Domain ein Mail­ser­ver zu erreichen ist.

Zu einer Domäne gehören in der Regel ver­schie­de­ne Server. Neben dem Webserver, der die Website be­reit­stellt, gibt es bei­spiels­wei­se oft auch FTP-Server und eben auch einen oder gar mehrere Mail­ser­ver. Alle sind über ver­schie­de­ne Sub­do­mains zu erreichen. Wie diese Subdomain lautet, lässt sich über den MX-Record erfragen. Dies erledigt der Mail­ser­ver, von dem aus die E-Mail versendet wird, in der Regel au­to­ma­tisch.

Felder und Syntax der Einträge

DNS-Records bestehen grund­sätz­lich aus mehreren In­for­ma­tio­nen, un­ter­ge­bracht in ver­schie­de­nen Feldern. Neben der In­for­ma­ti­on, wie der Mail­ser­ver einer be­stimm­ten Domäne heißt, können so weitere Details über­tra­gen werden:

• <name>: Das erste Feld enthält den Namen der Domain
• <ttl>: Time to live gibt an, wie lange die In­for­ma­tio­nen ga­ran­tiert ihre Gül­tig­keit behalten
• <class>: Das Klas­sen­feld spe­zi­fi­ziert die Netz­werk­art
• <type>: Der DNS-Record-Type ist in diesem Fall MX
• <priority>: Je kleiner der Wert ist, umso höher ist auch die Priorität des Mail­ser­vers
• <rdata>: Resource Data definiert den Namen des Mail­ser­vers

Do­main­na­men werden in allen Record-Typen immer in der Form der Fully Qualified Domain Names (FQDN) angegeben. Das bedeutet, dass grund­sätz­lich der Inhalt jedes Feldes mit einem Punkt ab­ge­schlos­sen wird. Tat­säch­lich bilden FQDN den kom­plet­ten Pfad ab, von der kleinsten Einheit ganz links zur größten ganz rechts – dem Root­ser­ver. Die höchste Ebene ist al­ler­dings unbenannt, weshalb nach dem ihr vor­an­ge­gan­ge­nen Punkt nichts mehr steht.

Die Time to live gibt an, wie lange der An­fra­gen­de die In­for­ma­ti­on in seinem Cache halten und nutzen kann. Das soll ga­ran­tie­ren, dass keine ver­al­te­ten Einträge verwendet werden. Ist die Zeit ab­ge­lau­fen, muss der Client den Record erneut vom Name­ser­ver anfragen. Die Angabe der TTL erfolgt in Sekunden. Häufig taucht dieses Feld nicht im ei­gent­li­chen Eintrag auf. Statt­des­sen wird die Zeit am Anfang der Zo­nen­da­tei für die komplette Zone definiert.

Das Klas­sen­feld ist optional, da in­zwi­schen ohnehin nur noch das Internet infrage kommt. Bei Ein­füh­rung der Resource-Records waren al­ler­dings auch noch die beiden Klassen Hesiod (HS) und Chaos (CH) möglich. Beide Netzwerke sind aber heute nicht mehr in Betrieb. Deshalb bleibt das Feld entweder leer oder enthält aus­nahms­los das Kürzel IN.

Das Feld bezüglich der Priorität ist eine Be­son­der­heit für MX-Records. Viele Ad­mi­nis­tra­to­ren – ins­be­son­de­re die größerer Projekte – lassen mehrere Mail­ser­ver parallel laufen. Damit lassen sich Ausfälle und Be­las­tungs­spit­zen aus­glei­chen und die E-Mail-Kom­mu­ni­ka­ti­on droht nicht, plötzlich aus­zu­fal­len. Dabei soll aber die Ver­tei­lung nicht unbedingt gleich­mä­ßig erfolgen. Aus diesem Grund vergibt man Prio­ri­tä­ten. Der Server mit dem ge­rings­ten Wert hat die höchste Priorität und wird demnach als Erstes an­ge­steu­ert. Ist er nicht verfügbar, wird der Server mit dem nächst­hö­he­ren Wert aus­ge­wählt.

Das Data-Feld schließ­lich enthält den Namen des Mail­ser­vers. Auch dieser wird in Form des FQDN angegeben. Im Eintrag folgen alle Felder innerhalb einer Zeile auf­ein­an­der. Man beendet den Eintrag nicht durch ein be­stimm­tes Zeichen – ein Zei­len­um­bruch genügt.

MX-Record-Beispiel

Als Beispiel nutzen wir den fiktiven Mail­ser­ver von example.com. Eine passende E-Mail-Adresse dazu wäre bei­spiels­wei­se user@example.com. Der Webserver des Ab­sen­den­den würde seine DNS-Anfrage also zur Domain example.com senden. Die ent­spre­chen­den Einträge in der Zo­nen­da­tei des Name­ser­vers sähen dann fol­gen­der­ma­ßen aus:

$TTL 1200
example.com.	IN	A		93.184.216.34
example.com.	IN	MX	10	mail1.example.com.
example.com.	IN	MX	10	mail2.example.com.
example.com.	IN	MX	50	mail3.example.com.

Wie man hier sehen kann, gilt die Halt­bar­keit der In­for­ma­tio­nen für die komplette Zone. In die einzelnen Einträge braucht das Feld daher nicht mehr in­te­griert zu sein. In diesem Beispiel haben wir zunächst einen A-Record, der die Domain mit einer IP-Adresse verknüpft. Dann folgen drei MX-Records. Man erkennt, dass sich diese nur in den Sub­do­mains un­ter­schei­den.

Die ersten beiden Mail­ser­ver haben in diesem Beispiel die gleichen Prio­ri­täts­stu­fen (10). Also werden die Aufgaben gleich­mä­ßig auf beide verteilt. Mail­ser­ver 3 wird erst dann an­ge­spro­chen, wenn die anderen beiden die Last – zum Beispiel aufgrund eines Ausfalls – nicht mehr be­wäl­ti­gen können.

Si­cher­heits­aspek­te beim Ein­rich­ten von MX-Einträgen

Beim Erstellen von MX-Records sollten Sie Wert auf Si­cher­heit und Feh­ler­ver­mei­dung legen. So dürfen MX-Records niemals direkt auf IP-Adressen verweisen, sondern immer auf voll­qua­li­fi­zier­te Do­main­na­men, die ih­rer­seits über A- oder AAAA-Records aufgelöst werden. Außerdem ist es nicht erlaubt, einen CNAME-Eintrag als Ziel eines MX-Records zu verwenden, da diese Praxis gegen DNS-Standards verstößt und daher zu Zu­stel­lungs­pro­ble­men führen kann. Die Ziel-Mail­ser­ver müssen korrekt über DNS auflösbar und er­reich­bar sein, an­dern­falls kommt es zu Feh­ler­mel­dun­gen oder dem Verlust von E-Mails.

Um Spam und Spoofing zu ver­hin­dern, sollten ergänzend SPF-, DKIM- und DMARC-Einträge gesetzt werden, die die Echtheit der Absender-Domain absichern. Hierbei handelt es sich um E-Mail-Si­cher­heits­me­cha­nis­men:

• SPF sorgt dafür, dass nur au­to­ri­sier­te Server E-Mails im Namen einer Domain versenden dürfen.
• DKIM stellt sicher, dass die E-Mails digital signiert und vor Ma­ni­pu­la­ti­on geschützt sind.
• DMARC gibt den Emp­fän­ge­rin­nen und Emp­fän­gern Regeln vor, wie mit nicht au­then­ti­fi­zier­ten Mails um­ge­gan­gen werden soll.

MX-Records ein­rich­ten

Wenn Sie Ihre ge­schäft­li­che E-Mail-Kom­mu­ni­ka­ti­on über Google Workspace oder Microsoft 365 abwickeln möchten, ist das Ein­rich­ten eines korrekten MX-Eintrags in der DNS-Zone Ihrer Domain Pflicht. Nur so wird si­cher­ge­stellt, dass ein­ge­hen­de E-Mails zu­ver­läs­sig an die Mail­ser­ver des je­wei­li­gen Anbieters zu­ge­stellt werden.

Ein­rich­tung eines MX-Eintrags bei Google Workspace

Wenn Sie E-Mails über das Col­la­bo­ra­ti­on-Tool Google Workspace empfangen möchten, müssen Sie den of­fi­zi­el­len Google-Mail­ser­ver als MX-Record in der DNS-Zone Ihrer Domain eintragen. Dies geht mit folgenden Schritten ganz einfach:

1. Entfernen Sie alle be­stehen­den MX-Einträge.

2. Fügen Sie folgenden MX-Eintrag für den Mail­ser­ver von Google hinzu:

@	IN	MX	1	smtp.google.com.

3. Loggen Sie sich in der Google Admin-Konsole mit Ihrem Admin-Account ein und na­vi­gie­ren Sie über die Account-Ein­stel­lun­gen zu Ihren Domains. Ak­ti­vie­ren Sie bei der Domain, deren MX-Eintrag Sie ak­tua­li­sie­ren möchten, Gmail. Es kann bis zu 72 Stunden dauern, bis der MX-Eintrag wirksam wird.

Ein­rich­tung eines MX-Eintrags bei Microsoft 365

Auch mit Microsoft 365 können Sie ganz einfach einen MX-Record ein­rich­ten, der dafür sorgt, dass die Mails an Personen, die die Domain verwenden, an Microsoft 365 gesendet werden. Die Anleitung ähnelt der bereits be­schrie­be­nen:

1. Entfernen Sie alle be­stehen­den MX-Einträge.

2. Loggen Sie sich im Microsoft 365 Admin-Center ein. Klicken Sie nach­ein­an­der auf „Alle anzeigen“ -> „Ein­stel­lun­gen“ -> „Domänen“. Hier finden Sie den zu ver­wen­den­den MX-Record.

3. Kopieren Sie den MX-Eintrag, legen Sie ihn bei Ihrem Hosting-Anbieter an und speichern Sie die Än­de­run­gen.

MX-Record checken: So geht’s!

Um einen MX-Record-Lookup durch­zu­füh­ren, kann man auf ver­schie­de­ne Web­diens­te zu­rück­grei­fen. Sehr kom­for­ta­bel und einfach zu bedienen ist Public DNS von Google. Auf der Start­sei­te gibt man jene Domain ein, deren MX-Records man checken möchte. Auf der folgenden Seite muss dann der Record-Type von A auf MX geändert werden. Die beiden Optionen EDNS Client Subnet und DNSSEC braucht man nicht ändern. Erstere soll die Be­reit­stel­lung von DNS-In­for­ma­tio­nen be­schleu­ni­gen, letztere ga­ran­tiert, dass die In­for­ma­tio­nen nicht durch einen kri­mi­nel­len Dritten ma­ni­pu­liert wurden.

Close

In der Bei­spiel­su­che erkennt man unter „Answer“ den Mail­ser­ver. Der FQDN, unter dem dieser zu erreichen ist, findet man unter dem Punkt „Data“. Dort ist auch die Priorität angegeben: Der Eintrag in diesem Aus­schnitt hat eine Priorität von 10. Unter „Typ“ befindet sich die Zahl 15. Dies ent­spricht einem MX-Record. Die Internet Assigned Numbers Authority (IANA) hat nämlich jedem DNS-Record-Typ einen Wert zu­ge­ord­net und die Ein­trags­ar­ten auf diese Weise durch­num­me­riert.