Eine sendende Anwendung und ein empfangendes Postfach können unterschiedliche Domains verwenden. Die Records, die Antworten routen, müssen nicht auf jeder Subdomain liegen, die zum Senden genutzt wird.
Wie nutzt ein sendender Server MX-Records?
Der sendende Server fragt die Domain des Empfängers ab, um die Server zu finden, die eingehende E-Mails annehmen.
Für person@example.org fragt er MX-Records für example.org ab. Jeder Record benennt einen Zielserver, dessen Hostname zu einer IP-Adresse aufgelöst wird.
RFC 5321 definiert diesen Abfrageprozess für SMTP.
Der sendende Server meldet einen Fehler, wenn die Empfängerdomain nicht existiert. Nach einem vorübergehenden Abfragefehler stellt er die Nachricht für einen späteren Versuch in die Warteschlange.
Was passiert, wenn eine Domain keinen MX-Record hat?
Wenn keine MX-Records existieren, behandelt SMTP die Domain selbst als Ziel und versucht deren Adresseinträge.
Dieser implizite MX hat den Präferenzwert Null. Es gibt keine explizite MX-Liste, die ihn übertreffen könnte, sodass die Zustellung an die eigene Adresse der Domain erfolgt, wenn diese nutzbar ist.
Dieser Fallback gilt für eine leere MX-Liste. Er rettet keine Domain, deren veröffentlichte MX-Records unbrauchbar sind.
Ein Null-MX ist eine andere Anweisung: RFC 7505 definiert einen expliziten Record, der erklärt, dass die Domain keine E-Mails annimmt. Ein fehlender Record erlaubt einen Fallback. Ein Null-MX verweigert die Zustellung.
Was bedeuten MX-Präferenznummern?
Niedrigere Präferenzwerte kennzeichnen die Ziele, die ein Absender zuerst versuchen soll.
Bei den Werten 10, 20 und 30 wird das Ziel mit 10 bevorzugt. Die anderen bieten Alternativen, wenn die Zustellung dort nicht möglich ist. Erhalten alle Ziele denselben Wert, ermöglicht das eine Verteilung unter gleichwertigen Zielen.
Gemäß RFC 5321 müssen sendende Server Ziele mit gleichem Präferenzwert zufällig anordnen, sofern es keinen eindeutigen Grund gibt, eines zu bevorzugen. Gleiche Präferenzwerte garantieren keine exakte Aufteilung des Datenverkehrs.
Verweisen Sie Ihren MX-Record auf einen Hostnamen, dessen Adresse Sie veröffentlichen, damit Absender sich verbinden können. Verwenden Sie einen A-Record für die IPv4-Adresse oder einen AAAA-Record für IPv6. Verwenden Sie keinen CNAME-Alias als Ziel. Der Alias verhindert, dass DNS die Adresse zusammen mit der MX-Antwort liefert. Das erzeugt zusätzliche Abfragen, wie RFC 2181 erläutert.
SMTP-Clients müssen das Ausprobieren alternativer Ziele unterstützen. Die Spezifikation empfiehlt, mindestens zwei Adressen zu versuchen, wenn verfügbar. Ein Fehler beim ersten Ziel muss dann nicht das Ende der Zustellversuche bedeuten.
Brauchen Sie einen MX-Record zum Senden?
SMTP erfordert keinen expliziten MX-Record auf Ihrer Domain, nur um eine Nachricht zu versenden.
Die Zustellabfrage verwendet die Empfängerdomain. Ihre Sendedomain benötigt weiterhin gültiges DNS und eine Authentifizierung, die den Anforderungen des Empfängers entspricht. Ein Empfänger kann eigene Prüfungen auf die Absenderdomain anwenden.
Ein fehlender MX-Record bedeutet daher nicht, dass eine unerreichbare Absenderdomain von jedem Empfänger akzeptiert wird.
Wohin gehen Zustellfehler?
Zustellfehler gehen an den Envelope-Absender, die Adresse, die während der SMTP-Zustellung für Fehlermeldungen angegeben wurde.
Wohin gehen Antworten?
Antworten verwenden normalerweise Reply-To, wenn vorhanden, andernfalls die sichtbare From-Adresse.
Eine Sendesubdomain muss nicht jedes Unternehmenspostfach hosten. Zum Beispiel kann news.example.com senden, während Antworten an eine funktionierende Adresse bei example.com gehen. Machen Sie diese Routingentscheidung in den Adressen der Nachricht explizit.
Wohin gehen operative Berichte?
Operative Adressen wie postmaster@ und abuse@ geben anderen Betreibern die Möglichkeit, Zustell- oder Missbrauchsprobleme zu melden.
Gemäß RFC 5321 muss ein SMTP-Server, der E-Mails weiterleitet oder zustellt, postmaster@ für seine bedienten Domains annehmen. Das stellt einen Kontakt für Probleme mit dem E-Mail-Dienst bereit.
RFC 2142 verlangt von Organisationen, Rollenpostfächer zu unterstützen, wenn die entsprechende Funktion existiert. Zum Beispiel muss ein Internetdienstanbieter abuse@ auf seiner Organisationsdomain unterstützen. Das leitet Beschwerden an das zuständige Team weiter.
Wie empfangen Sie E-Mails mit Bird?
Sie aktivieren den Empfang für eine Domain und veröffentlichen die MX-Records, die Bird zurückgibt.
Das inbound.enabled-Feld der API akzeptiert true zum Aktivieren des Empfangs oder false zum Deaktivieren. Das bloße Veröffentlichen der Records aktiviert die Funktion nicht.
Nach der Verifizierung werden an diese Domain adressierte E-Mails zu eingehenden Nachrichten. Verwenden Sie eine dedizierte Empfangssubdomain, da das Ersetzen der MX-Records Ihrer Unternehmensdomain ändert, wo deren bestehende E-Mails ankommen.
Der Return-Path-Record von Bird verarbeitet Zustellfehler-Benachrichtigungen getrennt von diesen eingehenden MX-Records. Der Empfangsleitfaden erläutert die Domain-Einrichtung. Der Bounce-Domain-Leitfaden erläutert die Fehlerbehandlung.
Kurz gesagt
MX-Records routen eingehende E-Mails.
Der sendende Server fragt die Empfängerdomain ab, um ein Ziel zu finden.
Fehlende MX-Records können auf Adresseinträge zurückfallen.
Wenn keine MX-Records existieren, kann der sendende Server die Adresseinträge der Domain verwenden.
Niedrigere Präferenzwerte werden zuerst versucht.
Ziele mit gleichem Präferenzwert werden zufällig verteilt, wenn es keinen Grund gibt, eines zu bevorzugen.
Senden und Empfangen erfordern getrennte Entscheidungen.
Ausgehende E-Mails erfordern weiterhin eine angemessene Behandlung von Zustellfehlern, Antworten und operativen Kontaktadressen.