Microsoft 365 DNS-Einträge: MX, SPF, DKIM, Autodiscover und DMARC

Schritte

1. Domain hinzufügen und verifizieren. Fügen Sie die Domain im Microsoft 365 Admin Center hinzu und veröffentlichen Sie den angezeigten TXT-Record zur Verifizierung (er beginnt mit MS=).
2. Postfächer anlegen und Lizenzen zuweisen. Jede Adresse, die E-Mails empfangen soll, braucht ein Postfach, ein freigegebenes Postfach, eine Gruppe oder einen Alias, bevor der MX umgestellt wird.
3. MX-Record veröffentlichen. Kopieren Sie den MX-Host aus dem Admin Center. Er wird aus Ihrem Domainnamen abgeleitet und endet auf mail.protection.outlook.com oder, bei Domains mit DNSSEC-geschütztem E-Mail-Eingang, auf mx.microsoft. Priorität 0 und keine weiteren MX-Records.
4. SPF veröffentlichen. Legen Sie einen TXT-Record am Apex an: v=spf1 include:spf.protection.outlook.com -all. Weitere Absender nehmen Sie in denselben Record auf.
5. DKIM einschalten. Veröffentlichen Sie die beiden CNAME-Records selector1._domainkey und selector2._domainkey mit den Zielen, die das Defender-Portal für Ihre Domain anzeigt, warten Sie, bis sie auflösen, und aktivieren Sie dann das Signieren für die Domain.
6. Autodiscover und DMARC ergänzen, dann prüfen. Veröffentlichen Sie den Autodiscover-CNAME, damit Outlook das Postfach findet, legen Sie einen DMARC-Record mit p=none an und führen Sie dann die Prüfungen auf dieser Seite aus.

DMARC

DMARC ist bei jedem Anbieter gleich: ein TXT-Record unter _dmarc.example.com. Beginnen Sie mit p=none und einer Berichtsadresse, damit Sie Berichte erhalten, ohne die Zustellung zu beeinflussen.

Lesen Sie die Berichte einige Wochen lang. Wenn jeder legitime Absender SPF oder DKIM mit passender Domain (Alignment) besteht, wechseln Sie zu p=quarantine und danach zu p=reject. Die Umstellung auf reject, bevor DKIM für alle Absender aktiv ist, ist der übliche Grund dafür, dass legitime E-Mails verloren gehen.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Optional: MTA-STS, TLS-RPT und BIMI

MTA-STS weist sendende Server an, bei der Zustellung an Sie TLS zu verlangen. Nötig sind ein TXT-Record und eine Policy-Datei, die über HTTPS unter mta-sts.example.com ausgeliefert wird; die Policy muss die MX-Hosts Ihres Anbieters exakt aufführen.

TLS-RPT bittet Absender, TLS-Zustellfehler an eine von Ihnen gewählte Adresse zu melden. Ein TXT-Record, keine Auswirkung auf die Zustellung.

Mit BIMI können manche Postfach-Anbieter Ihr Logo anzeigen. Voraussetzung ist DMARC mit quarantine oder reject, und die meisten Anbieter verlangen zusätzlich ein Verified Mark Certificate.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

E-Mail-Programme: Autodiscover und Autoconfig

Outlook findet das Postfach über den CNAME-Record autodiscover.example.com → autodiscover.outlook.com. Ohne ihn fragt Outlook auf dem Desktop unter Umständen nach Servereinstellungen oder verbindet sich mit einem alten lokalen Server, der unter diesem Namen noch antwortet.

Hinweise zur TTL

Bevor Sie MX-Records einer Domain ändern, die bereits E-Mails empfängt, senken Sie deren TTL auf 300 Sekunden und warten Sie, bis die alte TTL abgelaufen ist. Resolver übernehmen die neuen Records dann innerhalb von Minuten.

Läuft die neue Einrichtung seit einigen Tagen, erhöhen Sie die TTL wieder: 3600 Sekunden sind ein gängiger Wert. SPF-, DKIM- und DMARC-Records ändern sich selten und sind mit 3600 gut bedient.

Wie lange dauern die Änderungen?

Ihre autoritativen Nameserver antworten mit dem neuen Record, sobald Ihr DNS-Anbieter ihn veröffentlicht hat. Ein Resolver, der die alte Antwort im Cache hat, behält sie, bis die alte TTL abläuft; ein Name, der vorher nicht existierte, kann für die Dauer des negativen Cachings aus Ihrem SOA-Record als nicht vorhanden gemerkt bleiben.

Es gibt keinen Moment, in dem eine Änderung überall zugleich gilt. Das Propagation-Tool zeigt, was eine feste Auswahl öffentlicher Resolver zum Zeitpunkt der Prüfung antwortet, angegeben als Anzahl wie „9 von 12 Resolvern“, und nicht mehr als das.

Anbieter prüfen Ihre Records nach ihrem eigenen Zeitplan erneut. Eine Verifizierungsschaltfläche im Panel kann deshalb noch eine Weile rot bleiben, obwohl das DNS bereits stimmt.

Häufige Fehler

• Den MX-Host oder die DKIM-Ziele von Hand zusammenbauen. Ein einziges abweichendes Zeichen genügt, damit die Verifizierung scheitert.
• DKIM aktivieren, bevor beide CNAME-Records auflösen: Das Portal lehnt ab, und E-Mails bleiben mit der onmicrosoft.com-Domain signiert, die für DMARC nicht ausgerichtet ist.
• Zwei SPF-Records. Eine Domain darf nur einen TXT-Record haben, der mit v=spf1 beginnt; ein zweiter lässt SPF mit einem permanenten Fehler scheitern. Führen Sie die include:-Mechanismen in einem Record zusammen.
• Die MX-Records des alten Anbieters neben den neuen stehen lassen. E-Mails werden dann je nach Priorität und Zufall bei dem einen oder dem anderen zugestellt.
• Den vollständigen Namen in ein Host-Feld eintragen, das die Domain selbst anhängt; das ergibt google._domainkey.example.com.example.com. Fragen Sie den Record nach dem Speichern ab.
• Ein halbierter DKIM-Schlüssel. Lange TXT-Werte müssen in Zeichenketten in Anführungszeichen mit höchstens 255 Zeichen aufgeteilt werden; die meisten DNS-Anbieter erledigen das für Sie, manche nicht.
• Mehr als zehn DNS-Abfragen im SPF, nachdem mehrere include:-Mechanismen hinzugekommen sind. Der SPF-Check zählt sie.
• Ein MX-Record, der auf einen CNAME oder auf eine IP-Adresse zeigt. Er muss auf einen Hostnamen zeigen, der A- oder AAAA-Records hat.