Microsoft 365: MX, SPF, DKIM und DMARC richtig umstellen

Microsoft 365 · Domain und E-Mail-Zustellung

Bei einer Domainumstellung müssen Empfang, automatische Kontoeinrichtung und Absenderauthentifizierung zusammenpassen. Der MX-Eintrag lenkt neue E-Mails zu Microsoft 365. Autodiscover hilft Outlook bei der Einrichtung. SPF, DKIM und DMARC machen legitime Absender prüfbar und erschweren den Missbrauch der eigenen Domain. Eine belastbare Umstellung erfasst deshalb zuerst alle sendenden Systeme und ändert DNS erst nach einem vollständigen Zielplan.

Die Kurzantwort: Erst alle Absender kennen, dann den Mailfluss umstellen

Ein Unternehmen versendet selten nur aus Outlook. Websiteformulare, Scanner, Buchhaltungssoftware, Newsletterdienste und Fachanwendungen können dieselbe Domain verwenden. Werden sie beim SPF-, DKIM- und DMARC-Konzept vergessen, geraten legitime Nachrichten nach der Umstellung in Quarantäne oder werden abgewiesen.

Aufgabe der wichtigsten DNS- und Authentifizierungsbausteine
Baustein	Aufgabe	Häufiges Missverständnis
MX	Bestimmt, zu welchen Mailservern andere Systeme neue E-Mails für die Domain zustellen.	Der MX-Eintrag steuert nicht, welche Systeme im Namen der Domain senden dürfen.
Autodiscover	Hilft unterstützten Clients, das Exchange-Online-Konto automatisch zu konfigurieren.	Autodiscover transportiert keine Nachrichten und ersetzt keinen MX-Eintrag.
SPF	Veröffentlicht zulässige Versandquellen für die technische Absenderdomain des SMTP-Dialogs.	Mehrere SPF-Einträge ergänzen sich nicht; sie verursachen einen permanenten Auswertungsfehler.
DKIM	Signiert wichtige Bestandteile ausgehender Nachrichten kryptografisch.	Die sichtbare Absenderdomain ist erst durch passende Ausrichtung für DMARC entscheidend.
DMARC	Prüft die Ausrichtung der sichtbaren From-Domain mit SPF oder DKIM und veröffentlicht eine Richtlinie.	Eine strenge Richtlinie wird nicht blind gesetzt, bevor legitime Absender ausgewertet und korrigiert sind.

Die Einträge werden in einer festgelegten Reihenfolge vorbereitet: Domain in Microsoft 365 bestätigen, Zielpostfächer anlegen, Versandquellen erfassen, DKIM-Werte abrufen, SPF konsolidieren, DMARC zunächst beobachtbar machen und erst zum geplanten Zeitpunkt den MX-Eintrag ändern. Danach folgen Tests über mehrere externe Empfänger und eine Auswertung der Nachrichtenkopfzeilen.

1. Die Domain ist Teil mehrerer Geschäftsprozesse

Vor einer Änderung wird die aktive DNS-Zone exportiert und jede Abhängigkeit erfasst. Nicht nur Mailkonten, sondern alle Systeme mit der Domain im Absender oder in einer technischen Zieladresse gehören in die Bestandsaufnahme.

Die DNS-Zone wird gesichert und Zuständigkeit geklärt

Domainregistrar und DNS-Hoster können verschiedene Anbieter sein. Der Zugang zum Kundenportal allein beweist deshalb nicht, dass dort die aktive Zone liegt. Maßgeblich sind die autoritativen Nameserver. Vor dem Projekt werden Registrar, DNS-Anbieter, Zugang, Mehrfaktorauthentifizierung, berechtigte Personen und Wiederherstellungsdaten geprüft.

Die aktuelle Zone wird als Datei oder vollständige Dokumentation gesichert. MX-, TXT-, CNAME-, A-, AAAA- und gegebenenfalls SRV-Einträge bleiben mit TTL und Priorität nachvollziehbar. Diese Sicherung verhindert, dass beim Bearbeiten vermeintlich unwichtige Website-, Verifizierungs- oder Anwendungsrecords verloren gehen.

Jede legitime Versandquelle erhält einen technischen Eigentümer

Outlook und Exchange Online sind nur eine Quelle. Die Website kann Kontaktbestätigungen senden, die Buchhaltung Rechnungen zustellen, ein CRM Serienmails auslösen und ein Multifunktionsgerät gescannte Dokumente verschicken. Für jede Quelle werden Absenderdomain, technischer Übertragungsweg, Anbieter, zuständige Person und erwartete Menge erfasst.

Unbekannte Einträge werden nicht vorsorglich dauerhaft autorisiert. Ein altes include: im SPF-Record kann zu einem nicht mehr genutzten Newsletteranbieter gehören und erweitert dennoch den Kreis möglicher Absender. Die Fachseite bestätigt, ob ein Dienst noch gebraucht wird. Erst dann bleibt er erhalten oder wird kontrolliert entfernt.

Empfangsadressen werden vor dem MX-Wechsel vollständig angelegt

Personenpostfächer, freigegebene Postfächer, Aliase, Verteiler und technische Empfänger erhalten vor der Umschaltung ihr Ziel in Microsoft 365. Weiterleitungen werden auf Notwendigkeit und Datenschutz geprüft. Catch-all-Konfigurationen werden nicht ungeprüft nachgebaut, weil sie Tippfehler und unerwünschte Nachrichten annehmen und die tatsächliche Adressstruktur verschleiern können.

Besondere Aufmerksamkeit benötigen Adressen, die nur selten verwendet werden: Bewerbungen, Rechnungen, Datenschutz, Störungsmeldungen oder Gerätebenachrichtigungen. Ein erfolgreicher Test der persönlichen Hauptadresse beweist nicht, dass diese betrieblich relevanten Nebenwege funktionieren.

Absenderinventar für ein kleines Unternehmen

Microsoft 365 und persönliche Outlook-Postfächer
Website, Kontaktformulare, Shopsystem und Transaktionsmails
CRM, Newsletter-, Termin- und Marketingplattformen
Buchhaltung, Warenwirtschaft und branchenspezifische Fachanwendungen
Scanner, Drucker, Alarmanlagen, NAS und Überwachungssysteme
Hostingserver, Monitoring, Ticketsysteme und automatisierte Skripte
Externe Dienstleister, die mit einer Adresse der Unternehmensdomain senden
Parkende und ungenutzte Domains oder Subdomains, die ausdrücklich nicht senden sollen

2. MX und Autodiscover lösen verschiedene Teile der Umstellung

Der Mailfluss und die Clientkonfiguration werden getrennt geplant. So kann die Domain früh in Microsoft 365 vorbereitet werden, ohne neue Nachrichten bereits dorthin zu leiten.

Die Domainbestätigung verändert den Mailfluss noch nicht

Microsoft stellt für die Eigentumsprüfung einen individuellen TXT-Wert bereit. Dieser Eintrag bestätigt, dass das Unternehmen die DNS-Zone kontrolliert. Er kann gesetzt werden, während der bisherige MX-Eintrag unverändert bleibt. Damit lassen sich Benutzer, Adressen und DKIM-Vorbereitung frühzeitig erledigen.

Die Bestätigungswerte werden direkt aus dem Admin Center übernommen. Beispiele aus Anleitungen dienen nur dem Verständnis und werden nie für eine echte Domain kopiert. Das gilt besonders für MX-Ziele und DKIM-CNAMEs, die mandanten- und domainspezifische Bestandteile enthalten.

Der MX-Eintrag bestimmt den Eingang neuer Nachrichten

Sendende Mailserver fragen den MX-Record der Empfängerdomain ab und wählen anhand der Priorität ein Ziel. Beim Wechsel wird das von Microsoft angezeigte Exchange-Online-Ziel mit der vorgesehenen Priorität eingetragen. Alte MX-Ziele bleiben nur während eines bewusst geplanten Übergangs erhalten und werden anschließend entfernt, damit Zustellung nicht zufällig zum früheren Anbieter ausweicht.

Die TTL wird rechtzeitig vor dem Umschalttag reduziert. Bereits zwischengespeicherte Antworten behalten ihre bisherige Gültigkeit, bis deren alte TTL abläuft. Deshalb hat eine Senkung wenige Minuten vor dem Wechsel kaum Wirkung. Nach stabiler Abnahme kann die TTL wieder auf einen üblichen Betriebswert erhöht werden.

Autodiscover führt unterstützte Clients zum richtigen Dienst

Der Autodiscover-CNAME verweist für die Domain auf den von Microsoft vorgesehenen Dienst. Outlook und andere unterstützte Clients können dadurch anhand der E-Mail-Adresse die erforderlichen Kontoeinstellungen finden. Das reduziert manuelle Eingaben und hilft, neue Exchange-Online-Profile korrekt anzulegen.

Alte Autodiscover-Einträge, lokale Exchange-Hinweise, zwischengespeicherte Profile und mobile Konten können trotzdem auf die frühere Umgebung zeigen. Deshalb gehört die Clientumstellung in den Projektplan. Ein DNS-Eintrag allein entfernt keine alten Profile und migriert keine lokalen Daten.

Änderungsplan statt DNS-Sammlung

Vorbereitung: Zone sichern, Domain bestätigen, Empfänger anlegen, Absender erfassen und TTL rechtzeitig senken.
Authentifizierung: Einen konsolidierten SPF-Record vorbereiten, domainspezifische DKIM-CNAMEs veröffentlichen und DMARC-Berichte einrichten.
Umschaltung: MX und Autodiscover zum vereinbarten Zeitpunkt setzen, alte Zustellung beobachten und Clients neu verbinden.
Abnahme: DNS extern auflösen, Mailfluss und Header prüfen, DMARC-Berichte auswerten und erst danach Altsysteme abbauen.

3. SPF, DKIM und DMARC werden als ein System geplant

Keines der drei Verfahren löst Absenderschutz allein. SPF bewertet die Versandquelle, DKIM die Signatur, DMARC verbindet mindestens einen bestandenen Mechanismus mit der sichtbaren From-Domain und einer veröffentlichten Richtlinie.

SPF veröffentlicht zulässige Versandquellen

Der SPF-TXT-Record einer Domain beginnt mit v=spf1, enthält die autorisierten Quellen und endet mit einer Bewertungsregel. Für Microsoft 365 wird gewöhnlich include:spf.protection.outlook.com benötigt. Weitere Dienste werden nur aufgenommen, wenn sie nachweislich im Namen derselben technischen Absenderdomain senden.

Pro Domain oder Subdomain darf es nur einen SPF-Record geben. Zwei getrennte TXT-Einträge mit v=spf1 werden nicht addiert, sondern führen zu permerror. Bestehende Quellen werden deshalb in einem Record konsolidiert. Die Regeln werden von links nach rechts ausgewertet und die Reihenfolge kann beeinflussen, wann eine passende Quelle gefunden wird.

SPF erlaubt höchstens zehn auswertungsrelevante DNS-Lookups. Verschachtelte include:-Mechanismen zählen mit; weniger als zehn sichtbare Includes garantieren daher noch keinen gültigen Record. IP-Adressen lösen dieses Lookup-Budget nicht aus, dürfen bei dynamischen Cloudplattformen aber nicht aus einer Momentaufnahme „geflattet“ werden. Microsoft rät ausdrücklich davon ab, das eigene Microsoft-365-Include durch statische IP-Listen zu ersetzen.

DKIM signiert Nachrichten mit der eigenen Domain

Microsoft 365 erzeugt für eine benutzerdefinierte Domain zwei Selektoren. In der öffentlichen DNS-Zone werden die im Defender-Portal oder per Exchange Online PowerShell angezeigten CNAME-Ziele veröffentlicht. Microsoft verwaltet die zugehörigen privaten Schlüssel und verwendet jeweils einen Selektor aktiv; der zweite ermöglicht eine spätere Schlüsselrotation.

Die Zielwerte dürfen nicht aus einem älteren Blogbeitrag abgeleitet werden. Microsoft verwendet für neuere Domains ein aktualisiertes CNAME-Format mit dynamischen Bestandteilen, während bestehende Domains ältere Zielmuster haben können. Maßgeblich sind immer Selector1CNAME und Selector2CNAME der konkreten Domain.

Nach der DNS-Erkennung wird die DKIM-Signierung für die benutzerdefinierte Domain aktiviert. Eine externe Testnachricht muss anschließend eine gültige Signatur mit ausgerichteter d=-Domain zeigen. Dass Microsoft bereits mit der ursprünglichen onmicrosoft.com-Domain signiert, reicht für die DMARC-Ausrichtung der sichtbaren Unternehmensdomain nicht in jedem Fall aus.

DMARC beurteilt die sichtbare From-Domain

DMARC besteht, wenn SPF oder DKIM erfolgreich ist und die dabei verwendete Domain ausreichend mit der sichtbaren From-Adresse ausgerichtet ist. Dadurch kann ein Angreifer nicht allein mit einem beliebigen bestandenen SPF-Ergebnis einer fremden technischen Domain die sichtbare Unternehmensadresse legitimieren.

Die Richtlinie wird unter _dmarc.beispiel.de als TXT-Record veröffentlicht. Ein kontrollierter Einstieg verwendet p=none mit einer Adresse für aggregierte Berichte. Diese Berichte zeigen, welche Systeme im Namen der Domain senden und ob SPF, DKIM und Ausrichtung bestehen. Die Berichtadresse muss Nachrichten annehmen und die XML-Daten sinnvoll auswertbar machen; ein unbeobachtetes Postfach erfüllt den Zweck nicht.

Nach Bereinigung legitimer Quellen wird die Richtlinie schrittweise auf Quarantäne und anschließend, soweit fachlich vertretbar, auf Ablehnung gestellt. Jeder Schritt wird über Berichte und echte Sendetests kontrolliert. Dauerhaftes p=none liefert Sichtbarkeit, fordert Empfänger aber nicht auf, nicht authentifizierte Nachrichten abzuweisen.

Drittanbieter senden besser über eine abgegrenzte Subdomain

Newsletter-, Marketing- und Massendienste liegen außerhalb der direkten Kontrolle des Unternehmens. Eine Subdomain wie mail.beispiel.de oder news.beispiel.de trennt deren technische Reputation und Authentifizierung von der Hauptdomain der persönlichen Geschäftskommunikation. Der Anbieter erhält nur die für diese Subdomain benötigten SPF- und DKIM-Einträge.

Die sichtbare Gestaltung und Antwortadresse können dennoch zur Marke passen. Entscheidend ist, dass Versanddomain, DKIM-Signatur und DMARC-Ausrichtung bewusst konfiguriert sind. Ein Dienst, der nur einen beliebigen Envelope-Absender verwendet und die Kundendomain nicht korrekt signieren kann, wird vor Einsatz kritisch bewertet.

Was bei nicht sendenden Domains gilt

Eine geparkte Domain oder Subdomain, die niemals E-Mail versendet, benötigt keine DKIM-Schlüssel. Ein SPF-Record ohne erlaubte Quellen und eine DMARC-Richtlinie mit Ablehnung können den beabsichtigten Nichtversand ausdrücken. Für nicht definierte Subdomains lässt sich außerdem die DMARC-Vererbung beziehungsweise eine eigene Subdomain-Richtlinie berücksichtigen. Die genaue Konfiguration wird je Domain dokumentiert, statt ungenutzte Namen ungeschützt zu lassen.

4. Die Umschaltung braucht ein definiertes Rückfallfenster

DNS lässt sich schnell bearbeiten, aber nicht überall gleichzeitig aktualisieren. Das Altsystem bleibt deshalb erreichbar, bis neue Zustellung, Nachsynchronisation und alle Absenderwege bestätigt sind.

Der Cutover beginnt mit einem unveränderten Sollprotokoll

Vor dem ersten Eingriff werden alter Wert, neuer Wert, TTL, ausführende Person, Prüfschritt und Rückfallwert für jeden Record festgehalten. Eine zweite Person kontrolliert besonders MX, SPF und DKIM-Ziele auf fehlende Zeichen, vertauschte Domains und automatisch ergänzte Hostnamen im DNS-Portal.

Manche Portale erwarten bei „Name“ nur den linken Teil, andere einen vollständigen Domainnamen. Ein Eintrag für selector1._domainkey kann bei falscher Eingabe versehentlich doppelt um die Zone ergänzt werden. Nach dem Speichern zählt daher nicht die Portalansicht, sondern die Antwort der autoritativen Nameserver.

Alte und neue Zustellung werden parallel beobachtet

Nach dem MX-Wechsel können einzelne sendende Systeme noch den früheren Wert zwischengespeichert haben. Das alte Hosting wird deshalb nicht sofort gekündigt. Eingehende Nachrichten werden nachsynchronisiert oder kontrolliert weitergeleitet, ohne Schleifen oder doppelte Zustellung zu erzeugen.

Ein Rückfall auf den alten MX-Eintrag wird nur bei klar definierten Fehlern ausgelöst. Da auch der Rückfall DNS-Verzögerungen hat, ersetzt er keine sorgfältige Vorbereitung. Probleme einzelner Clients oder eines externen Absenders rechtfertigen nicht automatisch eine globale Rückschaltung des gesamten Mailflusses.

Website und Geräte werden als eigene Versandprojekte behandelt

Ein Webserver sollte nicht allein deshalb im SPF der Hauptdomain bleiben, weil dort ein Kontaktformular läuft. Je nach Anwendung sind authentifizierter Versand über einen geeigneten Dienst, ein transaktionaler Anbieter oder eine getrennte Subdomain belastbarer. Kennwörter werden nicht im Quelltext oder in allgemein zugänglichen Pluginfeldern dokumentiert.

Scanner und Altgeräte unterstützen häufig nur veraltete Authentifizierung oder TLS-Verfahren. Vor der Abschaltung des alten SMTP-Servers wird geklärt, ob direkter Versand, SMTP-Relay, ein interner Relayhost oder ein moderner Geräteaustausch sinnvoll ist. Eine pauschale Ausnahme von Sicherheitsvorgaben wird nicht zum Dauerbetrieb.

5. Die Abnahme prüft DNS, Zustellung und Authentifizierung getrennt

Ein Test an die eigene Adresse kann intern zugestellt werden, ohne den öffentlichen Weg vollständig zu durchlaufen. Abgenommen wird deshalb mit externen Absendern und Empfängern sowie anhand der tatsächlichen Nachrichtenkopfzeilen.

Öffentliche DNS-Antworten werden unabhängig abgefragt

MX, Autodiscover, SPF, DKIM-Selektoren und DMARC werden gegen autoritative Nameserver und mehrere rekursive Resolver geprüft. Erwartet werden ein eindeutiges Exchange-Online-MX-Ziel, der korrekte Autodiscover-CNAME, genau ein syntaktisch gültiger SPF-Record, zwei erreichbare DKIM-CNAMEs und der dokumentierte DMARC-Record.

Prüfwerkzeuge liefern Hinweise, aber ihre Ampelfarbe ersetzt keine Interpretation. Ein SPF-Record kann syntaktisch gültig sein und trotzdem einen legitimen Absender vergessen. Ein DKIM-CNAME kann auflösbar sein, während Microsoft die Signierung noch nicht aktiviert hat. DNS- und Nachrichtenprüfung gehören zusammen.

Nachrichtenkopfzeilen zeigen das tatsächliche Ergebnis

Für Microsoft 365, Website, Buchhaltung, CRM und jeden weiteren legitimen Dienst wird eine Nachricht an externe Testempfänger gesendet. Die Header werden auf SPF-Ergebnis, DKIM-Signatur, signierende Domain, DMARC-Ergebnis und Ausrichtung geprüft. Zusätzlich werden sichtbare From-Adresse, Envelope-Absender, Reply-To und Rückläuferverhalten kontrolliert.

Es genügt nicht, dass DMARC „pass“ meldet. Der Test muss zeigen, welcher Mechanismus besteht und ob das beabsichtigt ist. Ein Dienst, der nur über SPF ausgerichtet ist, kann bei Weiterleitungen scheitern. Eine gültige, ausgerichtete DKIM-Signatur erhöht die Robustheit, sofern zwischengeschaltete Systeme die signierten Bestandteile nicht verändern.

DMARC-Berichte begleiten den Übergang in den Regelbetrieb

Aggregierte Berichte werden über einen repräsentativen Zeitraum ausgewertet. Bekannte Quellen erhalten einen Sollstatus; unbekannte Quellen werden untersucht. Fehler können durch falsche Absenderdomains, fehlendes DKIM, nicht ausgerichtete Envelope-Adressen, Weiterleitungen oder eine unvollständige Anbieterintegration entstehen.

Erst wenn legitime Quellen stabil bestehen, wird die DMARC-Richtlinie verschärft. Änderungen werden datiert dokumentiert. Auch danach bleiben Berichte und Zustellungsprobleme Teil der regelmäßigen Kontrolle, weil neue Marketingdienste, Websites oder Fachanwendungen zusätzliche Versandwege schaffen können.

Abnahmeliste für die Domainumstellung

Alle vorgesehenen Empfänger sind in Microsoft 365 vorhanden und getestet.
Der öffentliche MX-Record zeigt ausschließlich auf die geplanten produktiven Ziele.
Autodiscover löst korrekt auf und neue Outlook-Profile finden Exchange Online.
Es existiert genau ein SPF-Record; Quellen und DNS-Lookups sind dokumentiert.
Microsoft 365 signiert ausgehende Nachrichten mit DKIM für die sichtbare Unternehmensdomain.
DMARC-Berichte treffen ein, werden ausgewertet und zeigen alle legitimen Versender.
Website, Scanner, Buchhaltung, CRM und weitere Systeme bestehen externe Versandtests.
Altsystem, Rückfallweg, TTL-Rücksetzung und spätere Kündigung sind terminiert.

6. Typische Fehler und ihre tatsächlichen Folgen

Fehlerbilder bei Microsoft-365-DNS-Umstellungen
Fehler	Folge	Korrektur
Zwei SPF-Records	SPF kann mit einem permanenten Fehler enden; legitime Nachrichten verlieren Authentifizierung.	Alle erforderlichen Mechanismen in einem einzigen Record konsolidieren.
Nur Microsoft 365 im SPF	Website, CRM oder Buchhaltung sind nicht mehr autorisiert.	Alle bestätigten Versandquellen aufnehmen oder auf getrennte Subdomains und geeignete Relays umstellen.
DKIM-Werte aus einer Vorlage	CNAMEs zeigen auf falsche oder nicht existente Schlüsselziele.	Selektorwerte der konkreten Domain aus Portal oder PowerShell abrufen.
DMARC sofort auf Ablehnung	Unentdeckte legitime Absender können bei Empfängern abgewiesen werden.	Berichte mit p=none auswerten, Quellen korrigieren und Richtlinie kontrolliert verschärfen.
Alten Mailserver sofort kündigen	Verzögert zugestellte oder noch nicht migrierte Nachrichten gehen verloren.	Übergangsfenster, Nachsynchronisation und fachliche Abnahme abwarten.

Häufige Fragen zu MX, Autodiscover, SPF, DKIM und DMARC

Kann die Domain vor dem eigentlichen Umzug in Microsoft 365 angelegt werden?

Ja. Die Eigentumsbestätigung per TXT-Record ändert den Mailfluss nicht. Benutzer, Zieladressen und Authentifizierung können vorbereitet werden, während der bestehende MX-Record weiter auf den bisherigen Anbieter zeigt.

Darf eine Domain mehrere SPF-Einträge haben?

Nein. Pro Domain oder Subdomain ist genau ein SPF-Record zulässig. Mehrere v=spf1-TXT-Einträge verursachen einen permanenten Auswertungsfehler. Alle legitimen Quellen müssen in einem Record zusammengeführt werden.

Reicht SPF ohne DKIM und DMARC aus?

Nein. SPF prüft die technische Absenderdomain und kann bei Weiterleitungen scheitern. DKIM signiert Nachrichten, DMARC verlangt die Ausrichtung mindestens eines erfolgreichen Mechanismus mit der sichtbaren From-Domain und veröffentlicht eine Empfängerrichtlinie.

Warum wird DMARC zunächst mit p=none eingerichtet?

Die Richtlinie ermöglicht zunächst Berichte, ohne Empfänger zur Quarantäne oder Ablehnung aufzufordern. So werden unbekannte legitime Versandquellen und Ausrichtungsfehler sichtbar. Nach deren Bereinigung kann die Richtlinie schrittweise verschärft werden.

Muss jede Anwendung direkt über Microsoft 365 senden?

Nein. Je nach Gerät und Anwendung kommen authentifizierter Microsoft-365-Versand, ein geeignetes Relay oder ein spezialisierter Transaktionsdienst infrage. Der gewählte Weg muss aktuell unterstützt, korrekt authentifiziert und in SPF, DKIM sowie DMARC eingeordnet sein.

Wann kann der alte MX-Eintrag entfernt werden?

Wenn der geplante Microsoft-365-MX aktiv ist, die Übergangszeit abgelaufen ist, neue Zustellung und Nachsynchronisation funktionieren und kein legitimer Prozess mehr das alte System benötigt. Ein alter MX bleibt nicht als dauerhafte vermeintliche Reserve bestehen.

Quellen und fachliche Grundlage

DNS-Zielwerte, Produktoberflächen und empfohlene Verfahren können sich ändern. Für jede Domain werden die aktuellen Werte direkt aus dem zugehörigen Microsoft-365-Mandanten und der jeweils gültigen Microsoft-Dokumentation verwendet.

Microsoft-365-Domainumstellung in Frankfurt

Mailfluss und Absenderauthentifizierung gemeinsam umstellen

fra.digital erfasst Empfänger und Versandquellen, erstellt einen überprüfbaren DNS-Änderungsplan und begleitet MX-Wechsel, DKIM-Aktivierung, DMARC-Einführung sowie die technische Abnahme als klar abgegrenztes Projekt.

Microsoft-365-Leistungen

Domainumstellung besprechen