Eigene Domain zu Microsoft 365 hinzufügen: Warum die DNS-Verifikation klappt, aber SMTP-Fehler wie 550 5.7.54 auftreten

Was beim Domain-Hinzufügen technisch passiert: DNS-Besitzprüfung, Tenant-Konfiguration und Accepted Domain in Exchange Online

Das Hinzufügen einer eigenen Domain zu Microsoft 365 wirkt im Admin Center wie ein einzelner Assistent, technisch ist es jedoch eine Kette aus unabhängigen Teilschritten: Zuerst muss Microsoft verlässlich feststellen, dass der Tenant die Kontrolle über die Domain besitzt (DNS-basierte Besitzprüfung). Danach wird die Domain tenantweit in mehreren Diensten registriert und intern repliziert (Directory- und Service-Konfiguration). Erst wenn Exchange Online die Domain als Accepted Domain führt und diese Information in der Transport- und Frontend-Schicht verfügbar ist, akzeptiert Microsoft 365 E-Mails für diese Domäne als legitimes Ziel.

1) DNS-Besitzprüfung: Warum der TXT-Record nur der Anfang ist

Bei der Besitzprüfung verlangt Microsoft 365 typischerweise einen TXT-Eintrag im öffentlichen DNS. Dieser Eintrag enthält einen eindeutigen Token, der im Assistenten generiert wird. Entscheidend ist: Microsoft prüft nicht „irgendeinen“ Nameserver, sondern validiert über rekursive Resolver und gegen die tatsächlich delegierten autoritativen Nameserver der Domain. Dadurch können Konfigurationsfehler sichtbar werden, die in lokalen DNS-Tools zunächst unauffällig bleiben (z. B. Caching, Split-DNS, falsche Delegation oder DNSSEC-Probleme).

Die Prüfung ist eine reine Kontrollabfrage: Sie beweist Eigentum/Verfügungsgewalt über die Zone, konfiguriert aber noch keinen Mailfluss. Selbst wenn der TXT-Record korrekt auflösbar ist, heißt das nicht, dass Exchange Online bereits Empfängeradressen dieser Domain annimmt. Genau diese zeitliche und logische Trennung ist später wichtig, um SMTP-Fehler während der Übergangsphase korrekt zu interpretieren.

2) Tenant-Konfiguration und interne Replikation: Was Microsoft nach „Überprüft“ noch tun muss

Sobald die Domain als „überprüft“ markiert ist, wird sie im Tenant als verifizierte Domäne geführt und in die Konfiguration mehrerer Microsoft-365-Dienste übernommen. Das geschieht nicht atomar, sondern über interne Workflows und Replikationsmechanismen. In der Praxis bedeutet das: Zwischen „Domain ist verifiziert“ und „Domain ist überall nutzbar“ kann Zeit vergehen, auch wenn externes DNS bereits vollständig korrekt ist.

Diese interne Replikation betrifft insbesondere die Pfade, über die Exchange Online eingehende Nachrichten annimmt und Empfänger validiert. Je nach Zeitpunkt und Cache-Stand einzelner Komponenten kann die Domain bereits im Admin Center sichtbar sein, während der Frontend-Transport sie noch nicht als zustellbar behandelt. Das führt zu typischen Missverständnissen: Administratoren suchen den Fehler im DNS, obwohl die Ursache eine noch nicht durchgelaufene interne Aktivierung ist.

3) Accepted Domain in Exchange Online: Autoritativ, Relay und die Empfängerprüfung

In Exchange Online wird jede E-Mail-Domain, für die der Dienst E-Mails annehmen soll, als Accepted Domain geführt. Damit ist festgelegt, ob Exchange Online für diese Domäne als Authoritative (Zielpostfächer liegen in Exchange Online) oder als Internal Relay (Koexistenz/Split-Delivery zu einem anderen System) agiert. Diese Eigenschaft steuert nicht nur das Routing, sondern auch die Empfängerakzeptanz beim SMTP-Eingang.

Für autoritative Domains gilt: Exchange Online erwartet, dass Empfängerobjekte existieren (Mailbox, MailUser, MailContact, Gruppen etc.). Bei fehlenden Empfängern ist eine Ablehnung plausibel. Für Relay-Szenarien ist zusätzlich entscheidend, dass ein definierter Ausleitungspfad (Connector) existiert, andernfalls kann Exchange Online zwar annehmen, aber nicht zielgerichtet weiterleiten. Die häufige Fehlinterpretation besteht darin, Relay-Anforderungen mit „Domain verifiziert“ zu verwechseln: Verifizierung schafft noch keinen Connector und macht die Domain nicht automatisch „zustellbar“ für beliebige Empfänger.

• Autoritativ (Standardfall): Exchange Online nimmt für Empfänger an, die im Tenant existieren; die Domäne ist als Accepted Domain konfiguriert und Empfängerprüfung greift (Directory-basiert).
• Internal Relay (Koexistenz): Exchange Online akzeptiert die Domäne, kann aber für unbekannte Empfänger an ein anderes Mailsystem weiterleiten; dafür sind Routing-Objekte und in der Regel ein Connector erforderlich.
• Externes DNS vs. Accepted Domain: Ein korrektes MX-Target oder ein verifizierter TXT-Record ersetzt nicht die Exchange-Konfiguration; SMTP-Entscheidungen erfolgen primär anhand der Accepted-Domain-Liste und Empfängerobjekte, nicht anhand von SPF/DMARC oder des Verifikations-TXT.

4) Warum SMTP-Fehler während der Übergangszeit auftreten können – ohne dass DNS „falsch“ ist

SMTP-Fehler in der Phase unmittelbar nach dem Domain-Hinzufügen sind häufig keine Aussage über die Richtigkeit der DNS-Zone, sondern über den Zustand der Microsoft-internen Annahmelogik. Ein typisches Beispiel ist „550 5.7.54 Unable to relay recipient in non-accepted domain“. Diese Meldung bedeutet im Kern: Die Ziel-Domäne wird von der gerade angesprochenen Exchange-Online-Frontend-Schicht nicht als Accepted Domain behandelt (noch nicht repliziert, noch nicht aktiv, falscher Accepted-Domain-Typ oder falscher Tenant), daher verweigert der Dienst die Weiterleitung/Annahme.

Wichtig ist die Einordnung: Der Fehler kann auch dann erscheinen, wenn der Verifikations-TXT bereits korrekt auflösbar ist oder wenn im Admin Center der Status „Überprüft“ angezeigt wird. Die SMTP-Entscheidung passiert zur Verbindungszeit in Transportkomponenten, die ihre Konfiguration nicht zwingend synchron zum Portal aktualisieren. Umgekehrt kann DNS-Propagation (TTL, Caching bei Resolvern, verzögerte Zonenauslieferung) ebenfalls zu Übergangsproblemen führen, aber das äußert sich meist anders: Dann erreichen sendende Server weiterhin das alte MX-Ziel oder bekommen inkonsistente Antworten, während Exchange Online selbst nicht „halb akzeptiert“. Die Fehlermeldung „non-accepted domain“ zeigt typischerweise auf einen Exchange-seitigen Zustand, nicht auf SPF/DMARC oder reine MX-Erreichbarkeit.

Technisch sauber wird die Trennung, wenn man zwei Fragen auseinanderhält: „Wohin wird zugestellt?“ (DNS/MX) und „Nimmt das Ziel die Domain an?“ (Accepted Domain + Replikation + Empfängerobjekte). Erst wenn beide Ebenen konsistent sind, stabilisiert sich die Zustellung ohne intermittierende Ablehnungen.

Praxisablauf im Admin Center: TXT-Verifikation setzen, Zeitverhalten von DNS-Propagation und Microsoft-Replikation realistisch einschätzen

Domain im Microsoft 365 Admin Center hinzufügen: was genau angestoßen wird

Im Microsoft 365 Admin Center wird eine Domain zunächst als neues, zu verifizierendes Objekt im Tenant angelegt. In diesem Zustand ist die Domain noch nicht produktiv für E-Mail-Routing nutzbar; sie ist insbesondere noch keine „Accepted Domain“ in Exchange Online. Das ist wichtig, weil viele Symptome in dieser Phase (z. B. SMTP-Fehler beim Zustellversuch) nicht auf „falsche DNS-Einträge“ hinweisen, sondern schlicht auf einen Zwischenstatus in der Microsoft-internen Verarbeitung.

Beim Klick auf „Domain hinzufügen“ wird der Verifikationsworkflow gestartet. Microsoft generiert dabei einen eindeutigen Token, der als TXT-Record in der öffentlichen DNS-Zone der Domain veröffentlicht werden muss. Erst wenn Microsoft diesen Token über öffentliche DNS-Abfragen zuverlässig sieht, gilt die Besitzprüfung als bestanden. Ab diesem Zeitpunkt kann die Domain für Dienste (typischerweise Exchange Online, Teams, Intune/MDM, SharePoint) aktiviert werden, wobei Exchange Online im Hintergrund zusätzlich eine interne Replikation benötigt, bevor die Domain als empfangsberechtigt betrachtet wird.

TXT-Verifikation korrekt setzen: Details, die in der Praxis zählen

Im Admin Center wird für die Verifikation in der Regel ein TXT-Record vorgeschlagen. Technisch relevant ist nicht das UI-Label, sondern dass der TXT-Record im autoritativen DNS der Domain exakt unter dem erwarteten Namen veröffentlicht wird und der Wert unverändert bleibt. Abweichungen entstehen häufig durch DNS-Provider, die die Eingabe „@“/„(leer)“ unterschiedlich interpretieren oder automatisch Anführungszeichen setzen. Beides kann die Verifikation verhindern, obwohl der Record „irgendwo sichtbar“ wirkt.

Für die Fehlersuche zählt ausschließlich, was autoritative Nameserver der Domain ausliefern. Rekursive Resolver (z. B. Unternehmens-DNS, ISP-Resolver) können veraltete Werte aus dem Cache liefern und dadurch die Wahrnehmung verzerren. Zusätzlich kann der Provider interne Zonen-Replikation haben: Der Record ist dann im Web-Panel sichtbar, wird aber noch nicht von allen autoritativen Nameservern beantwortet.

• Record-Name präzise treffen: Je nach Vorgabe im Admin Center wird der Host als Root veröffentlicht (oft als @ bzw. leer) oder als spezifischer Subdomain-Name; nicht „frei interpretieren“, sondern exakt nach Provider-Konvention abbilden.
• Wert unverändert übernehmen: Den Token exakt kopieren; keine zusätzlichen Leerzeichen. Falls der Provider automatisch Anführungszeichen setzt, ist das meist unkritisch, sofern der TXT-Inhalt logisch identisch bleibt.
• TTL bewusst wählen: Für Einrichtungsphasen ist ein niedriger TTL (z. B. 300 Sekunden) sinnvoll, sofern der Provider das unterstützt; der TTL beeinflusst Cache-Dauer rekursiver Resolver, nicht die Geschwindigkeit, mit der autoritative Nameserver den Record übernehmen.
• Autoritativ prüfen statt „irgendein DNS-Check“: Gegen die autoritativen Nameserver der Domain abfragen, z. B. nslookup -type=txt example.tld ns1.provider.tld
dig @ns1.provider.tld TXT example.tld
• Split-DNS berücksichtigen: Bei internen DNS-Zonen für dieselbe Domain kann die Verifikation scheitern, wenn Admins nur intern testen; relevant ist die öffentliche Zone, die Microsoft aus dem Internet abfragt.

Zeitverhalten realistisch planen: DNS-Propagation vs. Microsoft-interne Replikation

„Propagation“ ist ein Sammelbegriff für mehrere, voneinander unabhängige Zeiten. Erstens: die Übernahme des Records im autoritativen DNS-Cluster des Providers (kann sofort bis hin zu deutlich verzögert sein, je nach Provider-Prozessen). Zweitens: die Cache-Dauer rekursiver Resolver, die den alten Zustand noch ausliefern können (gesteuert durch TTL und bestehende Caches). Drittens: Microsofts eigene Verarbeitung nach erfolgreicher Verifikation, insbesondere die Replikation in Exchange Online, damit die Domain als akzeptiert und zustellbar behandelt wird.

In der Praxis führt genau diese dritte Komponente zu Fehlinterpretationen: Der TXT-Record ist korrekt, Microsoft bestätigt die Domain-Verifikation im Admin Center, aber Exchange Online behandelt die Domain kurzzeitig noch nicht vollständig als „Accepted Domain“ für eingehende Empfänger. In dieser Zeit können Tests über SMTP oder externe Zustellungen fehlschlagen, obwohl DNS objektiv korrekt ist.

Typische Übergangsbeobachtungen beim Klicken auf „Überprüfen“

Beim Verifikationsschritt im Admin Center wird Microsoft den TXT-Record nicht „permanent“ beobachten, sondern in Abständen abfragen. Wenn der Record gerade erst gesetzt wurde, kann es vorkommen, dass die erste Prüfung noch einen NXDOMAIN oder einen alten TXT-Satz sieht. Hier hilft es nicht, den Token mehrfach zu ändern; zielführend ist die autoritative Verifikation und etwas Zeit, bis die autoritativen Nameserver konsistent antworten.

Nachdem „Verifiziert“ angezeigt wird, ist der richtige Zeitpunkt gekommen, die weiteren DNS-Einträge zu planen (z. B. MX, SPF, Autodiscover, DKIM/DMARC). Für diesen Kapitelabschnitt entscheidend: Ein sofortiger Versand-/Empfangstest darf nicht automatisch als „DNS ist falsch“ bewertet werden, solange die Microsoft-interne Replikation noch läuft. Die Signale unterscheiden sich: Wenn autoritative DNS-Abfragen den TXT sauber liefern und das Admin Center verifiziert, ist der Besitznachweis erledigt; verbleibende SMTP-Auffälligkeiten sind dann mit hoher Wahrscheinlichkeit kein TXT-Problem mehr.

• „TXT nicht gefunden“ trotz Eintrag: Häufig zeigt der Provider-Editor den Record, aber die autoritativen Nameserver antworten noch nicht konsistent; prüfen mit dig @authoritative-ns TXT example.tld.
• Mehrere TXT-Sätze am Root: Parallel existierende TXT-Records sind grundsätzlich zulässig; problematisch wird es, wenn der Provider Werte automatisch zusammenführt oder abschneidet (Längen-/Formatregeln), sodass der Microsoft-Token nicht mehr exakt auslesbar ist.
• Verifiziert, aber E-Mail-Tests schlagen fehl: Besitzprüfung ist abgeschlossen, Exchange Online kann jedoch noch nicht überall repliziert sein; in dieser Zeit Tests nicht als endgültige Aussage über MX/SPF interpretieren.
• Tests über falschen Zielhost: Ein SMTP-Test gegen smtp.office365.com ist kein Test für eingehenden Empfang; für eingehende Zustellung ist das MX-Ziel (nach Umstellung) relevant, nicht der Submission-Endpunkt.

Typische Übergangsfehler einordnen: 550 5.7.54, Relaying, falsche Connectoren – plus Testzustellung und bewusstes MX-Umschalten

Während der Domain-Einbindung treten SMTP-Fehler häufig genau in der Phase auf, in der DNS-Einträge bereits „richtig aussehen“, Microsoft 365 die Domain aber intern noch nicht vollständig als zustellfähig behandelt. Entscheidend ist die Unterscheidung zwischen (a) öffentlicher DNS-Sichtbarkeit (authoritative DNS, TTL, Caches), (b) Microsoft-interner Verarbeitung (Domain-/Exchange-Konfiguration, Directory- und Transport-Replikation) und (c) der tatsächlichen Mailfluss-Architektur (MX zeigt wohin, Connectoren steuern wie). Die folgenden Beispiele helfen, Fehlermeldungen korrekt einzuordnen, ohne voreilig an falschen Stellen zu „reparieren“.

SMTP 550 5.7.54 „Unable to relay recipient in non-accepted domain“ – was wirklich dahintersteckt

Der Fehler 550 5.7.54 Unable to relay recipient in non-accepted domain kommt aus Exchange Online (oder einem Exchange-System davor), wenn der empfangende Transportdienst die Empfängerdomain nicht als „Accepted Domain“ für eingehende Zustellung akzeptiert. Das ist kein DNS-Fehler im engeren Sinn, sondern eine transportseitige Ablehnung: Der Server will für diese Domain nicht als Ziel fungieren und würde bei Annahme als Relay missbraucht werden können.

Typische Übergangssituationen: Die Domain wurde zwar im Tenant hinzugefügt und per TXT verifiziert, aber Exchange Online hat die Domain noch nicht (oder noch nicht überall) als Accepted Domain aktiv. Alternativ existiert eine Konfiguration, in der eingehende Nachrichten über einen Connector erwartet werden, die tatsächliche Zustellung aber bereits direkt versucht wird (oder umgekehrt). In Hybrid- oder Third-Party-Szenarien kommt hinzu, dass ein vorgelagerter Mailgateway die Domain weiterhin als „nicht lokal“ behandelt und Relaying unterbindet.

Relaying vs. „falsches Ziel“: häufige Denkfehler bei MX, Accepted Domain und Connectoren

Ein häufiger Denkfehler lautet: „Wenn der MX auf Microsoft 365 zeigt, muss Exchange Online die Domain automatisch annehmen.“ In der Praxis hängt die Annahme zusätzlich davon ab, ob die Domain im Tenant korrekt als Accepted Domain geführt wird und ob Connectoren oder Hybrid-Konfigurationen eingreifende Routingregeln setzen. Connectoren können beispielsweise erzwingen, dass eingehende Mail nur über definierte Quell-IP-Adressen akzeptiert wird, oder dass bestimmte Domains als „Internal Relay“ in Richtung On-Premises weitergeleitet werden sollen.

Gerade in Übergangsphasen entstehen widersprüchliche Zustände: DNS zeigt bereits auf Microsoft 365, aber die Organisation erwartet weiterhin, dass das vorgelagerte Gateway zustellt (oder signiert, filtert, journalt). Dann erreicht die Mail Exchange Online ohne den erwarteten Connectorpfad, wird nicht als autorisierter Inbound erkannt und kann abgewiesen werden. Umgekehrt kann ein Gateway bereits an Microsoft 365 übergeben, während der Tenant die Domain noch nicht als final zustellfähig behandelt.

• Accepted Domain fehlt/noch nicht aktiv: Prüfen, ob die Empfängerdomain in Exchange Online als akzeptierte Domäne geführt wird und ob die Replikation abgeschlossen ist; administrativ ist das typischerweise in der Exchange-Admin-Oberfläche ersichtlich, technisch auch per Get-AcceptedDomain.
• Inbound-Connector greift unerwartet: Wenn ein Connector „nur von diesen IPs“ erwartet, führt direkte Zustellung an Microsoft 365 (z. B. nach MX-Umschaltung) zu Ablehnungen. Prüfen, ob ein Connector für eingehende Mails existiert und ob Quell-IP- und Partnerdefinitionen noch zum tatsächlichen Pfad passen; relevant sind z. B. IP-Bereiche/Partnerzuordnung und gegebenenfalls die Einschränkung auf bestimmte Absenderdomänen.
• Hybrid-/Internal-Relay-Routing: Bei „Internal Relay“ kann Exchange Online für unbekannte Empfänger weiterleiten (z. B. On-Premises). Wenn der On-Premises-Pfad nicht erreichbar oder falsch ist, entstehen NDRs, die auf den ersten Blick wie „DNS stimmt nicht“ wirken. Prüfen, wohin der Connector routet und ob die Zielsysteme erreichbar sind.
• Falscher Sendeweg aus Applikationen: Anwendungen, die bisher gegen ein lokales Relay gesendet haben, nutzen nach Umstellung oft smtp.office365.com ohne Auth oder mit falscher Absenderdomäne. Das erzeugt Relay- bzw. Auth-Fehler, die nicht durch MX/TXT lösbar sind. Technische Prüfung: SMTP-Client-Authentifizierung, TLS, korrekte Credentials, erlaubte Absenderdomänen.

Testzustellung ohne Risiko: valide Prüfungen trotz Übergangszustand

Tests sollten so gestaltet sein, dass sie DNS-Propagation und Microsoft-interne Replikation nicht verfälschen. Ein reiner „Ping auf MX“ ist bedeutungslos; entscheidend sind die tatsächliche SMTP-Zustellung und die Nachrichtennachverfolgung. Außerdem ist zu beachten, dass externe Absender unterschiedliche Resolver nutzen und daher in den ersten Stunden durchaus unterschiedliche MX-Ziele sehen können.

• DNS-Sichtbarkeit separat prüfen: MX und TXT direkt an den autoritativen Nameservern validieren, nicht nur über lokale Caches; für schnelle Checks eignen sich Abfragen wie nslookup -type=mx domain.tld ns1.provider.tld und nslookup -type=txt domain.tld ns1.provider.tld.
• Gezielte Mailflussprüfung: Testmails von einem externen System senden, das sicher „frische“ DNS-Abfragen macht (z. B. ein Cloud-Mailkonto), und parallel im Exchange Admin Center die Message Trace für Empfänger und Zeitfenster auswerten. So lässt sich trennen, ob die Mail Exchange Online erreicht und dort abgewiesen wurde oder gar nicht ankommt.
• Header-/NDR-Analyse: Bei Bounces die vollständigen Statuscodes und die „Receiving server“-Angabe auswerten. Relevant ist, ob der ablehnende Hop tatsächlich Exchange Online ist oder ein vorgelagertes Gateway. Statuscode 550 5.7.54 ist ein starkes Indiz für „nicht akzeptierte Domain/Relay“ am Empfangssystem.

Bewusstes MX-Umschalten: wann warten sinnvoll ist und wie Parallelbetrieb kontrolliert bleibt

Das MX-Umschalten ist ein Eingriff in den produktiven Zustellpfad und sollte nicht mit der reinen Domain-Verifikation verwechselt werden. Solange die Domain zwar verifiziert ist, aber die Exchange-seitige Annahme oder Connector-Logik noch nicht verlässlich steht, ist es häufig sinnvoll, den MX beim bisherigen Mailgateway zu belassen. So bleibt die eingehende Zustellung stabil, während intern die Microsoft-365-Konfiguration fertiggestellt und getestet wird.

Ein kontrollierter Übergang bedeutet: niedrige TTL vor dem Umschaltfenster, klare Entscheidung für einen „Cutover“-Zeitpunkt und ein Plan für Rückfall (Rollback). Parallelbetrieb entsteht automatisch, weil externe Sender MX-Daten cachen; daher muss das alte Ziel während der Übergangszeit weiterhin zustellen können (z. B. per Smarthost/Connector zu Microsoft 365), sonst führt jeder Absender mit altem Cache zu sporadischen NDRs.

• MX erst umstellen, wenn die Annahme eindeutig steht: Vor dem Cutover sicherstellen, dass Exchange Online die Domain akzeptiert und keine Connector-Beschränkung „ins Leere“ läuft; im Zweifel mit Get-AcceptedDomain und einer realen externen Testzustellung gegen den zukünftigen Pfad validieren.
• TTL- und Cache-Effekte einplanen: TTL vorab reduzieren (sofern organisatorisch möglich) und beim Umschalten einkalkulieren, dass alte MX-Informationen weiter genutzt werden. Das bisherige Ziel muss in dieser Phase Mails für die Domain weiterhin korrekt weiterleiten können.
• Fehlermeldungen zeitlich einordnen: Treten 550 5.7.54-Bounces direkt nach MX-Umschaltung auf, ist häufig nicht „der TXT falsch“, sondern der neue Empfangspfad noch nicht konsistent (intern) oder nicht passend zu Connectoren (architektonisch). Priorität hat dann die Klärung des tatsächlichen Empfangshosts und der aktiven Richtlinien, nicht das erneute Setzen derselben DNS-Records.