Wichtige Erkenntnisse
Seit Februar 2024 schreibt Gmail für Massenversand einen veröffentlichten DMARC-Eintrag für jede Domain vor, die E-Mails über 100 £ versendet. 5,000 E-Mails pro Tag für Gmail-Nutzer. Yahoo wendet die gleiche Regel unter ihren Best Practices für Absender. Ab Mai 2025Microsoft hat damit begonnen, nicht konforme E-Mails von Absendern mit hohem E-Mail-Aufkommen an Outlook-, Hotmail- und Live-Postfächer zurückzuweisen.
DMARC ist für jeden Microsoft 365-Mandanten, der in großem Umfang betrieben wird, von optional zu obligatorisch geworden, und aktuell E-Mail-Spam-Statistiken Der Grund dafür ist klar: Die Anbieter verschärfen die Authentifizierungsregeln, weil nicht authentifizierte E-Mails ein Risiko für Absender und Empfänger darstellen.
Deshalb ist es wichtig zu lernen, wie man DMARC in Office 365 richtig einrichtet – von der Bestätigung der Voraussetzungen und dem Erstellen des Eintrags bis hin zur Veröffentlichung im DNS, der Auswahl einer sicheren Ausgangsrichtlinie, der Überprüfung ihrer Funktionsfähigkeit und dem Übergang zur vollständigen Durchsetzung, ohne legitime E-Mails zu blockieren.
DMARC ist kein eigenständiges Protokoll. Es ist eine Richtlinienschicht, die über … liegt. SPF und DKIM Das weist empfangende Mailserver an, wie sie vorgehen sollen, wenn diese Prüfungen fehlschlagen. Sind SPF oder DKIM falsch konfiguriert oder nicht korrekt ausgerichtet, greift DMARC ein, sobald Sie den Wert „p=none“ überschreiten.
Bitte bestätigen Sie alle vier unten aufgeführten Voraussetzungen, bevor Sie Ihren DMARC-Eintrag veröffentlichen:
Die fünf nachfolgenden Schritte benötigen 10–15 Minuten aktive Arbeitszeit, zuzüglich der DNS-Propagationszeit (die je nach DNS-Anbieter und TTL-Einstellungen zwischen wenigen Minuten und 48 Stunden variieren kann).
Die DMARC-Konfiguration erfolgt vollständig im DNS, nicht im Microsoft Defender-Portal. Microsoft 365 führt eingehende DMARC-Prüfungen automatisch über Exchange Online Protection durch. Es gibt jedoch keine Einstellung im Defender-Portal, um ausgehende DMARC-Verbindungen für Ihre benutzerdefinierte Domäne zu konfigurieren. Dieser Eintrag befindet sich in Ihrer DNS-Zone.
Senden Sie eine Test-E-Mail von Ihrer benutzerdefinierten Domain an eine externe Gmail- oder Yahoo-Adresse. Öffnen Sie die E-Mail und sehen Sie sich die vollständigen Nachrichtenkopfzeilen an (in Gmail: Drei-Punkte-Menü → „Original anzeigen“).
Bestätigen Sie im Header „Authentication-Results“ Folgendes:
Wenn eines der beiden Ergebnisse „Fehlgeschlagen“ oder „Neutral“ lautet, brechen Sie hier ab und beheben Sie zuerst das Authentifizierungsproblem. Das Veröffentlichen eines DMARC-Eintrags über fehlgeschlagenes SPF oder DKIM führt dazu, dass legitime E-Mails unter Quarantäne gestellt oder abgewiesen werden, sobald Sie die Richtlinie über „p=none“ hinaus ändern.
Beginnen Sie bei jeder neuen DMARC-Implementierung mit p=none. Diese Richtlinie erfasst aggregierte DMARC-Berichte, ohne die E-Mail-Zustellung zu beeinträchtigen. Fehlgeschlagene Nachrichten werden weiterhin zugestellt, aber die empfangenden Mailserver melden die Authentifizierungsergebnisse an die in Ihrem rua=-Tag angegebene Adresse zurück. Diese Daten zeigen Ihnen, welche Absenderadressen vor der Durchsetzung der Richtlinie übereinstimmen und welche nicht.
Das direkte Überspringen der DMARC-Richtlinien p=quarantine oder p=reject ist die häufigste Ursache für den Verlust legitimer E-Mails während der DMARC-Einführung. Wenn eine Drittanbieter-Versandplattform noch nicht konfiguriert ist, werden echte E-Mails von dieser Quelle aufgrund einer strikten Richtlinie sofort unter Quarantäne gestellt oder zurückgewiesen. Die p=none-Phase dient genau diesem Zweck.
Der grundlegende DMARC-Eintrag für eine neue Bereitstellung sieht folgendermaßen aus:
v=DMARC1; p = keine; rua=mailto:[E-Mail geschützt] ; Prozent=100;
Hier die Bedeutung der einzelnen Tags:
Die vollständige Tag-Referenz, einschließlich optionaler Tags wie ruf (forensische Berichte), sp (Subdomain-Richtlinie), adkim und aspf, finden Sie hier: DMARC.orgoffizielle Protokolldokumentation.
Melden Sie sich beim DNS-Anbieter Ihrer Domain an. Erstellen Sie einen neuen TXT-Eintrag mit den folgenden Werten:
Speichern Sie den Eintrag. Die DNS-Propagation ist in der Regel innerhalb weniger Stunden abgeschlossen, kann aber bis zu 48 Stunden dauern. Während dieses Zeitraums ist der Eintrag möglicherweise nicht für alle Resolver gleichzeitig sichtbar.
Sobald der Datensatz verbreitet wurde, überprüfen Sie ihn auf zwei Arten:
Die ersten DMARC-Aggregatberichte treffen innerhalb von 24–72 Stunden nach der Veröffentlichung des Datensatzes im rua=-Postfach ein. Prüfen Sie die erste Charge sorgfältig, bevor Sie eine Verschärfung der Richtlinie in Erwägung ziehen.
Jede erfolgreiche DMARC-Implementierung durchläuft alle drei Richtlinienphasen über Wochen oder Monate. Werden Phasen übersprungen, besteht die Gefahr, dass legitime E-Mails abgewiesen werden, bevor alle Absenderquellen korrekt konfiguriert sind. Mit diesem stufenweisen Ansatz schützen Sie den E-Mail-Verkehr und bereiten gleichzeitig die vollständige Durchsetzung vor.
v=DMARC1; p = keine; rua=mailto:[E-Mail geschützt] ; Prozent=100;
Bei p=none erfassen die empfangenden Mailserver die DMARC-Ergebnisse und senden sie an Ihre rua=-Adresse zurück. Fehlgeschlagene Nachrichten werden jedoch weiterhin normal zugestellt. Es werden keine Nachrichten in Quarantäne verschoben oder abgewiesen.
Bleiben Sie mindestens 2–4 Wochen im Status „p=none“. Nutzen Sie diese Zeit, um die aggregierten Berichte zu lesen und sicherzustellen, dass alle legitimen Absenderquellen, wie z. B. Microsoft 365, Marketingplattformen, Transaktionsabsender und CRM-Systeme, die DMARC-Konformität erfüllen. Alle Quellen mit Fehlern müssen korrigiert werden, bevor die Richtlinie verschärft wird.
Wechseln Sie erst dann in den Quarantänemodus (p=Quarantäne), wenn die Berichte über mehrere Meldezyklen hinweg konstant Erfolgsquoten von über 95 % für alle legitimen Absender aufweisen.
v=DMARC1; p=Quarantäne; rua=mailto:[E-Mail geschützt] ; Prozent=100;
Bei aktivierter Quarantäne-Funktion (p=quarantine) leiten empfangende Mailserver fehlerhafte Nachrichten in den Spam- oder Junk-Ordner statt in den Posteingang weiter. Legitime, aber nicht korrekt zugeordnete E-Mails kommen weiterhin an, nur eben an einem weniger priorisierten Ort, wo sie von den Empfängern seltener gesehen werden.
Diese Richtlinienphase dient als nützlicher Zwischenschritt. Sie greift bei falsch zugestellten E-Mails, ohne die durch p=reject verursachten harten Bounces. Bleiben Sie für weitere 2–4 Wochen in dieser Phase und überwachen Sie die Berichte sorgfältig, um festzustellen, ob legitime E-Mails fehlgeleitet wurden.
Wechseln Sie erst dann zu p=reject, wenn DMARC-Berichte eine konsistente Ausrichtung über alle Quellen hinweg bestätigen und keine legitimen E-Mails unter Quarantäne gestellt werden.
v=DMARC1; p=ablehnen; rua=mailto:[E-Mail geschützt] ; Prozent=100;
Bei der Einstellung p=reject lehnen empfangende Mailserver Nachrichten, die die DMARC-Konformität nicht erfüllen, sofort ab. Solche Nachrichten werden an den Absender zurückgesendet und erreichen den Empfänger gar nicht erst.
Dies ist das Ziel jeder DMARC-Implementierung. Die vollständige Durchsetzung von p=reject bietet umfassenden Schutz vor Domain-Spoofing und erfüllt die Anforderungen von Gmail, Yahoo und Microsoft für Absender mit hohem E-Mail-Aufkommen. Sie schützt außerdem Ihre Domain- und IP-Reputation indem verhindert wird, dass unbefugte Absender Ihren Domainnamen zum Zustellen von E-Mails verwenden.
Überwachen Sie weiterhin DMARC-Berichte bei p=reject. Neue Absenderquellen, einschließlich neuer Anbieter, Marketing-Tools und Integrationen, können weiterhin Ausrichtungsfehler verursachen und müssen vor der Live-Schaltung mit eingerichteter Authentifizierung eingebunden werden.
Die meisten DMARC-Fehler in Microsoft 365-Umgebungen sind auf Ausrichtungsprobleme und nicht auf Protokollfehler zurückzuführen. Das bedeutet, dass der Eintrag technisch gültig ist, die gesendete E-Mail jedoch nicht mit der DKIM-Signaturdomäne oder den SPF-autorisierten IP-Adressen übereinstimmt.
Diagnostizieren: Die rua=-Mailboxadresse ist falsch, die Mailbox blockiert eingehende Berichte, oder die Domain sendet nicht genügend Datenvolumen, als dass große Anbieter bereits Berichte generiert hätten.
Fix: Prüfen Sie, ob das Postfach rua= existiert, externe E-Mails empfängt und nicht durch eine strenge Spam-Regel gefiltert wird. Senden Sie einige Test-E-Mails von der Domain an Gmail- und Yahoo-Adressen; diese Anbieter generieren in der Regel innerhalb von 24–48 Stunden Berichte, sofern DMARC korrekt konfiguriert ist.
Diagnostizieren: Eine Drittanbieter-Versandplattform ist nicht korrekt konfiguriert. Die häufigste Ursache ist ein Marketing-Tool, ein CRM-System oder ein Anbieter für Transaktions-E-Mails, der nicht zum SPF hinzugefügt oder für die Signierung mit DKIM für die benutzerdefinierte Domain konfiguriert wurde.
Fix: Prüfen Sie die aggregierten DMARC-Berichte, um die fehlerhafte Quelle zu identifizieren. Fügen Sie die Quelle entweder Ihrem SPF-Eintrag hinzu (include:thirdparty.com), konfigurieren Sie die DKIM-Signierung für diese Quelle über die Plattformeinstellungen oder setzen Sie die Richtlinie vorübergehend auf p=none zurück, bis die Ausrichtung korrigiert ist. Belassen Sie die Richtlinie niemals auf p=reject, solange bekannte Quellen Fehler aufweisen.
Diagnostizieren: Weitergeleitete E-Mails führen häufig zu einem Fehler bei der SPF-Authentifizierung, da die IP-Adresse des weiterleitenden Servers nicht im SPF-Eintrag des ursprünglichen Absenders enthalten ist. DKIM bleibt beim Weiterleiten in der Regel erhalten, sodass in diesem Fall oft nur noch die DKIM-Authentifizierung relevant ist.
Fix: Stellen Sie sicher, dass DKIM die E-Mails korrekt für den ursprünglichen Absender signiert. DKIM-konforme E-Mails bestehen DMARC-Prüfungen auch dann, wenn SPF aufgrund der Weiterleitung fehlschlägt. Schlägt DKIM nach der Weiterleitung ebenfalls fehl, verändert das weiterleitende System den Nachrichteninhalt und beschädigt so die DKIM-Signatur. In diesem Fall ist in der Regel die Unterstützung von ARC (Authenticated Received Chain) durch den weiterleitenden Server erforderlich.
Diagnostizieren: Tippfehler im DMARC-TXT-Eintrag können die gesamte Richtlinie ungültig machen. Häufige Probleme sind ein fehlendes Präfix „v=DMARC1“, fehlende Semikolons zwischen den Tags oder eine fehlerhafte Aufteilung des Eintrags auf mehrere DNS-Einträge.
Fix: Prüfen Sie den veröffentlichten Eintrag mit dem DMARC-Validator von MXToolbox und vergewissern Sie sich, dass er korrekt geparst und gültig ist. Stellen Sie sicher, dass der Eintrag als einzelner TXT-Eintrag unter _dmarc.yourdomain.com vorliegt und nicht auf zwei Einträge aufgeteilt ist, und dass die einzelnen Tags durch ein Semikolon getrennt sind.
Die Einrichtung von DMARC ist einfacher, wenn Sie die Schritte der Reihe nach befolgen. Überprüfen Sie SPF und DKIM, erstellen Sie den Eintrag, veröffentlichen Sie ihn im DNS und gehen Sie jede Richtlinienphase sorgfältig durch. Nehmen Sie sich ausreichend Zeit, die Berichte zu lesen und Ausrichtungsprobleme zu beheben, bevor Sie die Durchsetzung verschärfen.
Da DMARC die letzte Ebene der E-Mail-Authentifizierung darstellt, ist es darauf angewiesen, dass SPF und DKIM korrekt funktionieren. Sind diese Einträge falsch konfiguriert oder nicht korrekt ausgerichtet, kann die DMARC-Durchsetzung legitime E-Mails blockieren, anstatt die Domain vor Spoofing zu schützen.
Die Authentifizierung löst jedoch nicht jedes Zustellbarkeitsproblem. Eine ordnungsgemäß authentifizierte Domain, die an eine Liste mit ungültigen, Wegwerf- oder inaktiven Adressen sendet, generiert dennoch Hard Bounces, und diese Bounces beeinträchtigen Ihre Reputation des E-Mail-Absenders unabhängig davon, wie sauber Ihr DMARC-Eintrag ist.
Laden Sie vor Ihrer nächsten Kampagne Ihre Liste in DeBounce hoch und führen Sie einen vollständigen Validierungsdurchlauf durch. Validierung der E-Mail-ListeDie Authentifizierung bestätigt, dass die E-Mail von Ihnen stammt, während die Überprüfung der Adressliste sicherstellt, dass sie an einen echten Empfänger geht. Beides ist notwendig, um jeder Kampagne eine höhere Chance zu geben, im Posteingang anzukommen.
Nein. Microsoft 365 prüft eingehende DMARC-Anfragen automatisch über Exchange Online Protection, ausgehende DMARC-Anfragen für benutzerdefinierte Domänen müssen jedoch manuell konfiguriert werden, indem ein TXT-Eintrag im DNS der Domäne veröffentlicht wird.
In den ersten 2–4 Wochen sollte immer p=none eingestellt sein. Dadurch werden aggregierte Berichte erfasst, ohne die Zustellung zu beeinträchtigen. So erhalten Sie die Daten, um Ausrichtungsfehler zu erkennen und zu beheben, bevor sie sich negativ auf die tatsächliche Zustellung im Posteingang auswirken.
Die DNS-Propagation ist innerhalb weniger Stunden bis zu 48 Stunden abgeschlossen. Die ersten aggregierten Berichte treffen in der Regel innerhalb von 24 bis 72 Stunden nach der Veröffentlichung des Eintrags ein, vorausgesetzt, die Domain versendet aktiv E-Mails an große Anbieter.
Die häufigste Ursache ist eine nicht konfigurierte Drittanbieter-E-Mail-Quelle: eine Marketingplattform, ein CRM-System oder ein Anbieter für Transaktions-E-Mails, der nicht in SPF eingetragen oder für die DKIM-Signatur der benutzerdefinierten Domain konfiguriert wurde. Überprüfen Sie die aggregierten Berichte, um die fehlerhafte Quelle zu identifizieren.
Ja. SPF und DKIM authentifizieren zwar einzelne Nachrichten, geben den empfangenden Servern aber keine Anweisung, wie sie bei einem Authentifizierungsfehler reagieren sollen. Ohne DMARC können gefälschte E-Mails, die SPF und DKIM nicht bestehen, trotzdem den Posteingang erreichen, da keine Richtlinie existiert, die den Empfänger anweist, auf den Fehler zu reagieren.
Hier finden Sie schnelle Antworten auf Ihre Fragen zu unseren Preisen und Tarifen.
Automatisiertes E-Mail-Marketing ist unglaublich praktisch und wirkungsvoll. Wie alles im Leben erfordert es jedoch etwas Arbeit, um es richtig einzurichten und den Erfolg aufrechtzuerhalten. Leider können E-Mail-Listen schnell unübersichtlich werden...
Catch-All-E-Mail-Adressen akzeptieren Nachrichten, die an jede Adresse innerhalb einer Domäne gesendet werden, selbst wenn das spezifische Postfach nicht existiert, wodurch Bounces aufgrund von... verhindert werden.
Spamfallen sind echte Postfächer, die erstellt oder wiederverwendet werden, um unseriöse E-Mail-Listenpraktiken aufzudecken. Das Öffnen einer solchen Falle kann die Reputation des Absenders und die Platzierung Ihrer E-Mails im Posteingang beeinträchtigen.
E-Mail-Tracking hilft Marketern zu verstehen, wie Empfänger mit Kampagnen interagieren, doch seine Genauigkeit hängt davon ab, wie die Daten erfasst und interpretiert werden. E-Mail-Tracking…
Spamfallen helfen E-Mail-Anbietern und Anti-Spam-Organisationen, Absender zu identifizieren, die Adressen durch unlautere Methoden erlangen. Es gibt drei Haupttypen von Spamfallen:...
Eine saubere E-Mail-Liste entfernt unzustellbare, Wegwerf- und risikoreiche Adressen, bevor diese die Bounce-Rate erhöhen, Kennzahlen verfälschen und die Absenderreputation schädigen. Listen veralten regelmäßig.
