0800 71 20000
Kontakt
...
Mail-Sicherheit

SPF, DKIM und DMARC: drei Prüfungen, die nur zusammen schützen

Ein Authentication-Results-Header, sechs Bestandteile und vier typische Fehler, dazu die Anforderungen von Google, Yahoo und Microsoft bis p=reject.

Passende Kurse ansehen Persönlich beraten lassen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer

Kurz gesagt

SPF prüft, ob der einliefernde Server für die Domäne im Umschlag senden darf, DKIM prüft, ob eine Signatur der Domäne zur Nachricht passt, und DMARC entscheidet anhand beider, was mit einer Mail geschieht, deren sichtbarer Absender zur Domäne gehört. Erst DMARC verbindet die Prüfungen mit dem Absender, den der Empfänger sieht, und schickt dir Berichte, wer in deinem Namen sendet. Seit 2024 verlangen Google, Yahoo und Microsoft diese drei Einträge von jedem, der in Masse an ihre Nutzer schreibt.

Stand dieser Seite: 04.10.2026

01 Worum es geht

Rechnungen in eurem Namen, Newsletter im Spam, und niemand weiß, warum

Die Lage im Betrieb hat zwei Gesichter. Das erste: Kunden rufen an, weil sie eine Rechnung mit eurer Absenderadresse und einer fremden Bankverbindung bekommen haben. Der Angreifer hat nur eure Domäne benutzt, denn ohne SPF, DKIM und eine DMARC-Richtlinie, die etwas verbietet, darf jeder Server der Welt eure Domäne in das Absenderfeld schreiben. Der Preis ist ein Zahlungsausfall beim Kunden, ein Vertrauensverlust bei euch und, wenn die Mail personenbezogene Daten enthielt, die Prüfung, ob eine Meldung an die Aufsichtsbehörde nötig ist.

Das zweite Gesicht: Eure eigenen Mails kommen nicht mehr an. Seit Februar 2024 verlangen Google und Yahoo von Absendern, die in großer Zahl an ihre Nutzer schreiben, SPF und DKIM, eine DMARC-Richtlinie und einen Absender, der zu einer der beiden Prüfungen passt. Microsoft setzt seit dem 5. Mai 2025 dieselben Anforderungen für Outlook.com, Hotmail und Live durch: Nicht konforme Mails von Domänen mit mehr als 5.000 Nachrichten am Tag landen im Junk-Ordner, und Microsoft hat angekündigt, sie demnächst mit dem Fehler 550 5.7.515 abzulehnen. Newsletter und Rechnungsmails landen dann im Spam oder kommen zurück, und die Fachabteilung fragt die IT, was sie geändert hat. Die Antwort lautet meist: nichts, und genau das war das Problem.

Dazwischen liegt eine leisere Schwierigkeit. In vielen Häusern existieren alle drei Einträge, aber sie passen nicht zusammen: Der Newsletterdienst signiert mit seiner eigenen Domäne, und SPF erlaubt einen längst gekündigten Dienstleister. DMARC steht seit Jahren auf p=none ohne Berichtsadresse, sodass niemand sieht, was in eurem Namen gesendet wird. Die Prüfungen laufen, aber keine greift. Der Weg heraus beginnt damit, den Header zu lesen, den jeder empfangende Server in eure Mails schreibt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

02 Der Aufbau im Detail

Ein Header, in dem alle drei Ergebnisse stehen

Jeder empfangende Server schreibt das Ergebnis der Prüfungen in den Authentication-Results-Header der Nachricht. Diese Zeile zeigt, welche Prüfung bestanden wurde, gegen welche Domäne sie lief und ob die Domänen zueinander passen.

Der Aufbau

Authentication-Results: mx.empfaenger.example; spf=pass smtp.mailfrom=news.firma.example; dkim=pass header.d=firma.example header.s=selector1; dmarc=pass header.from=firma.example
  1. 01 Die Zeile, die der Empfänger schreibt Authentication-Results

    Diesen Header fügt der empfangende Server hinzu, nachdem er die Prüfungen durchgeführt hat; der Name nach dem Doppelpunkt ist der Server, der das Ergebnis verantwortet. Du findest ihn in den Kopfzeilen jeder eingegangenen Mail. Für die Fehlersuche an eurer Domäne schickst du eine Mail an ein Postfach bei einem großen Provider und liest dort diese Zeile. Vertraue nur der Zeile eures eigenen Servers; Angreifer können den Header in eingehenden Mails fälschen.

  2. 02 SPF: Darf dieser Server für diese Domäne senden? spf=pass

    SPF nach RFC 7208 prüft die IP-Adresse des einliefernden Servers gegen den TXT-Eintrag der Domäne, die im Umschlag als Absender steht. Das Ergebnis ist pass, fail, softfail bei einem Eintrag mit Tilde, neutral, none ohne Eintrag, temperror oder permerror bei einem fehlerhaften Eintrag oder mehr als zehn DNS-Abfragen. SPF sagt nichts über den Absender, den der Empfänger sieht, und es zerbricht bei jeder Weiterleitung, weil dann ein fremder Server mit eurer Umschlagadresse einliefert.

  3. 03 Die geprüfte Domäne aus dem Umschlag smtp.mailfrom=news.firma.example

    Hier steht die Domäne, gegen die SPF geprüft wurde: die Adresse im Umschlag, in der Rückmeldungen über Unzustellbarkeit landen. Für DMARC zählt sie nur, wenn sie zur Domäne im sichtbaren Absender ausgerichtet ist: entspannt über dieselbe Organisationsdomäne, strikt nur bei Gleichheit. Ein Dienstleister mit eigener Domäne im Umschlag liefert ein spf=pass, das für eure DMARC-Prüfung wertlos ist.

  4. 04 DKIM: Passt die Signatur zur Domäne? dkim=pass header.d=firma.example

    DKIM nach RFC 6376 prüft eine kryptografische Signatur über ausgewählte Kopfzeilen und den Inhalt. Der öffentliche Schlüssel liegt im DNS der Domäne aus dem Feld d= der Signatur, und genau diese Domäne steht hier. Besteht die Prüfung, hat ein System mit dem privaten Schlüssel dieser Domäne signiert, und die signierten Teile sind unverändert. DKIM überlebt Weiterleitungen, solange der Inhalt gleich bleibt, und ist deshalb für DMARC die wichtigere Prüfung; Mailinglisten, die Fußzeilen anhängen, brechen es.

  5. 05 Der Selector: welcher Schlüssel benutzt wurde header.s=selector1

    Der Selector benennt den DNS-Eintrag mit dem öffentlichen Schlüssel: selector1._domainkey unterhalb der signierenden Domäne. Exchange Online arbeitet mit selector1 und selector2; beide sind CNAME-Einträge, die auf Einträge zeigen, die Microsoft verwaltet. Microsoft erzeugt Schlüssel standardmäßig mit 1024 Bit und bietet 2048 Bit über den Parameter KeySize von New-DkimSigningConfig und Rotate-DkimSigningConfig; Google nennt 1024 Bit als Minimum und empfiehlt 2048 Bit.

  6. 06 DMARC: Was passiert mit dem sichtbaren Absender? dmarc=pass header.from=firma.example

    DMARC prüft die Domäne aus dem sichtbaren Absenderfeld From und holt deren Richtlinie aus dem TXT-Eintrag unter _dmarc. Bestanden ist DMARC, wenn SPF oder DKIM bestanden haben und die geprüfte Domäne zu dieser ausgerichtet ist. Scheitert das, greift die Richtlinie aus p=: none für nur beobachten, quarantine für den Spamordner, reject für Ablehnung. Die Neufassung RFC 9989 vom Mai 2026 hebt DMARC auf den Standards Track, ersetzt pct durch den Testmodus t und ermittelt die Organisationsdomäne über einen DNS-Baumlauf statt über eine öffentliche Suffixliste.

Wenn es nicht funktioniert

Das siehst du

SPF liefert permerror, obwohl der Eintrag syntaktisch korrekt aussieht, und seit einigen Wochen landen Mails an Provider im Spam.

Warum

Der Eintrag überschreitet das Limit von zehn DNS-Abfragen aus RFC 7208. Jeder include eines Dienstleisters zieht dessen eigene includes nach. DMARC behandelt permerror wie einen Fehlschlag, sodass nur noch DKIM die Mail retten kann.

Was hilft

Zähle die Abfragen mit einem SPF-Prüfwerkzeug, entferne gekündigte Dienstleister und ersetze Mechanismen, die Abfragen kosten, durch direkte Adressen, wo diese stabil sind. Massenversender gehören auf eigene Subdomänen, weil deren Abfragebudget getrennt zählt. Prüfe den Eintrag nach jeder Änderung eines Dienstleisters erneut.

Das siehst du

Der Newsletter zeigt dkim=pass und spf=pass im Header, aber dmarc=fail, und seit der Umstellung auf p=quarantine liegt er im Spamordner.

Warum

Beide Prüfungen laufen gegen die Domäne des Dienstleisters: Die Signatur trägt dessen Domäne im Feld d=, und die Umschlagadresse gehört ihm ebenfalls. Nichts davon ist zu eurer Domäne im sichtbaren Absender ausgerichtet. Technisch ist alles in Ordnung, nur für den falschen Absender.

Was hilft

Lass den Dienstleister mit eurer Domäne signieren; dafür stellt er dir einen Selector und einen öffentlichen Schlüssel oder CNAME-Einträge, die du im DNS einträgst. Stell zusätzlich die Umschlagadresse auf eine Subdomäne von euch um. Prüfe im Bericht, dass die Quelle jetzt als ausgerichtet erscheint, bevor du weiter verschärfst.

Das siehst du

Mails aus Exchange Online bestehen DKIM, aber die Signatur nennt eine onmicrosoft.com-Domäne, und DMARC schlägt bei Weiterleitungen fehl.

Warum

DKIM für die eigene Domäne wurde in Exchange Online nie eingeschaltet. Microsoft signiert dann mit der Ausgangsdomäne des Mandanten, und die passt nicht zum sichtbaren Absender. Solange SPF besteht, fällt das nicht auf; bei jeder Weiterleitung bleibt keine ausgerichtete Prüfung übrig.

Was hilft

Trage im DNS der Domäne die beiden CNAME-Einträge für selector1._domainkey und selector2._domainkey ein, deren Zielwerte das Defender-Portal oder Get-DkimSigningConfig nennt, und schalte DKIM für die Domäne ein. Neue Domänen bekommen seit Mai 2025 ein anderes Zielformat als bestehende. Rotiere danach mit Rotate-DkimSigningConfig auf 2048 Bit.

Das siehst du

Mails an Adressen bei Outlook.com, Hotmail und Live kommen mit dem Fehler 550 5.7.515 zurück, obwohl kleine Mengen früher ankamen.

Warum

Microsoft verlangt seit dem 5. Mai 2025 von Domänen, die mehr als 5.000 Mails am Tag an seine Verbraucherdienste senden, SPF, DKIM und eine DMARC-Richtlinie mit mindestens p=none, bei der der sichtbare Absender zu SPF oder DKIM ausgerichtet ist. Fehlt eines davon, sortiert Microsoft die Mails bisher in den Junk-Ordner und hat die Ablehnung mit genau diesem Code angekündigt; sobald sie greift, kommen die Mails mit 550 5.7.515 zurück. Die Schwelle ist an einem Aktionstag schnell überschritten.

Was hilft

Richte alle drei Einträge für die sendende Domäne ein und prüfe die Ausrichtung im Authentication-Results-Header einer Testmail an ein Outlook.com-Postfach. Beachte die weiteren Empfehlungen von Microsoft: gültige Antwortadresse, funktionierender Abmeldelink, saubere Verteiler.

03 Was du mitnimmst

Was du einrichtest, damit die drei Prüfungen ineinandergreifen

Fünf Festlegungen bringen SPF, DKIM und DMARC in Einklang. Keine ist schwer, aber jede setzt voraus, dass du weißt, wer in eurem Namen Mails versendet.

Was jede Prüfung ansieht

  1. 01 SPF: Absender im Umschlag
  2. 02 DKIM: Signatur der Domäne
  3. 03 Alignment: passt zum sichtbaren Absender
  4. 04 DMARC: Richtlinie und Berichte
  5. 05 Provider: Annahme oder Ablehnung

Alle Versender inventarisieren, nicht nur den Mailserver

Mails mit eurer Domäne im Absender kommen aus Exchange Online oder dem eigenen Server, aus Newsletterwerkzeug, ERP, Ticketsystem und CRM, von Multifunktionsdruckern, aus der Überwachung und aus Cloud-Diensten, die im Namen eurer Beschäftigten einladen. Jeder davon braucht einen Platz im SPF-Eintrag oder eine DKIM-Signatur mit eurer Domäne. Die DMARC-Berichte vervollständigen die Liste um die Versender, von denen niemand weiß.

SPF schlank halten und das Limit kennen

SPF ist ein TXT-Eintrag an eurer Domäne, der die erlaubten Quellen für den Absender im Umschlag auflistet. RFC 7208 erlaubt bei der Auswertung höchstens zehn DNS-Abfragen für Mechanismen wie include, a, mx und redirect; wer darüber liegt, bekommt einen permerror, den DMARC wie einen Fehlschlag behandelt. Räume gekündigte Dienste heraus und lagere Massenversender auf Subdomänen mit eigenem SPF-Eintrag aus.

DKIM mit eurer Domäne signieren, je Versender ein Selector

DKIM nach RFC 6376 signiert Kopfzeilen und Inhalt mit einem privaten Schlüssel; der öffentliche Schlüssel liegt im DNS unter einem Selector. Entscheidend ist das Feld d= in der Signatur: Es muss eure Domäne nennen, nicht die des Dienstleisters, sonst zählt die Signatur für DMARC nicht. In Exchange Online signiert Microsoft eigene Domänen erst, wenn du DKIM dafür einschaltest und zwei CNAME-Einträge setzt.

DMARC mit Berichtsadresse beginnen, nicht mit Verbot

Der DMARC-Eintrag liegt als TXT unter _dmarc an eurer Domäne. Starte mit p=none und einer rua-Adresse für die aggregierten Berichte und lass einen Berichtsdienst daraus eine Tabelle machen. Nach zwei bis vier Wochen siehst du, welche Quellen in eurem Namen senden, welche SPF oder DKIM bestehen und welche ausgerichtet sind. Erst daraus folgt, was du reparierst, bevor du p=quarantine setzt.

Alignment verstehen, denn dort scheitert es

DMARC gilt nur als bestanden, wenn SPF oder DKIM bestehen und die geprüfte Domäne zur Domäne im sichtbaren Absender passt. Ob dafür dieselbe Organisationsdomäne reicht oder die Domänen identisch sein müssen, legst du mit dem entspannten oder dem strikten Modus fest. Ein Newsletterdienst mit eigener Signatur und eigener Umschlagadresse besteht beide Prüfungen und scheitert trotzdem an DMARC.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was jede der drei Prüfungen prüft, und was nicht

SPF, DKIM und DMARC sind drei Antworten auf drei Fragen. SPF fragt, ob der einliefernde Server von der Domäne im Umschlag autorisiert ist; es kennt weder den Inhalt noch den Absender, den ein Mensch liest. DKIM fragt, ob jemand mit dem privaten Schlüssel einer Domäne die Nachricht signiert hat und ob sie seitdem unverändert ist; es kennt den einliefernden Server nicht. DMARC fragt, ob eine der beiden Prüfungen für genau die Domäne bestanden wurde, die im sichtbaren Absender steht.

Daraus folgen die typischen Lücken. SPF allein schützt den sichtbaren Absender nicht, weil ein Angreifer eine eigene Domäne in den Umschlag schreiben und eure in das Absenderfeld setzen kann. DKIM allein schützt ebenfalls nicht, weil eine fehlende Signatur nur none ergibt und niemand sie vermisst, solange keine Richtlinie sie verlangt. Erst DMARC verbindet die Prüfungen mit dem Absenderfeld; ohne DMARC sind SPF und DKIM Hinweise, mit DMARC sind sie eine Regel.

Die Grenzen bleiben auch dann. DMARC schützt eure Domäne vor Fälschung, nicht eure Beschäftigten vor Mails von ähnlich aussehenden Domänen, die der Angreifer selbst registriert und sauber authentifiziert. Dagegen helfen Erkennung am Gateway, Schulung und ein Meldeweg; die Seite zu KI-geschriebenen Phishing-Mails in unserem KI-Bereich beschreibt, woran sie erkennbar sind. Und keine der drei Prüfungen sagt etwas über Verschlüsselung auf dem Transportweg; dafür verlangt Google TLS auf der SMTP-Verbindung als eigene Anforderung.

Alignment: warum DKIM pass nicht DMARC pass heißt

Der häufigste Irrtum lautet, dass eine Mail mit spf=pass und dkim=pass zwangsläufig DMARC besteht. Sie tut es nur, wenn die geprüfte Domäne zur Domäne im sichtbaren Absender ausgerichtet ist: bei SPF die Domäne im Umschlag, bei DKIM die Domäne im Feld d= der Signatur. Dienstleister verwenden für beides gern ihre eigene Domäne und liefern dann zwei bestandene Prüfungen, die für eure Richtlinie nichts zählen.

DMARC kennt zwei Modi der Ausrichtung. Im entspannten Modus, der Vorgabe, genügt dieselbe Organisationsdomäne; eine Signatur mit news.firma.example passt zu einem Absender firma.example. Im strikten Modus, den du mit adkim=s und aspf=s setzt, müssen die Domänen exakt gleich sein. Der strikte Modus ist sicherer, weil eine kompromittierte Subdomäne dann nicht für die Hauptdomäne spricht, aber er bricht jede Konstruktion mit Subdomänen für Dienstleister. Viele Häuser bleiben bei SPF entspannt und werden bei DKIM strikt.

Wie der Empfänger die Organisationsdomäne ermittelt, hat sich mit RFC 9989 geändert. Bisher diente dafür die öffentliche Suffixliste; die Neufassung verwendet einen DNS-Baumlauf, der von der Subdomäne nach oben nach einem DMARC-Eintrag sucht, mit einer Obergrenze an Abfragen gegen Missbrauch. Die neuen Tags np für nicht existierende Subdomänen und psd für Domänen an der Grenze zum öffentlichen Suffix geben dir mehr Steuerung als bisher.

Was Google, Yahoo und Microsoft seit 2024 verlangen

Google hat die Regeln zum 1. Februar 2024 verbindlich gemacht. Für alle Absender gelten SPF oder DKIM, ein gültiger Reverse-DNS-Eintrag, TLS auf der SMTP-Verbindung und eine Spamrate im Postmaster-Werkzeug unter 0,3 Prozent. Für Absender, die sich der Grenze von 5.000 Nachrichten am Tag an Gmail-Adressen nähern, kommen SPF und DKIM zusammen hinzu, eine DMARC-Richtlinie mindestens auf none, die Ausrichtung des sichtbaren Absenders und eine Abmeldung mit einem Klick in Marketing- und Abonnementmails. Yahoo stellt gleichlautende Anforderungen an Massenversender.

Microsoft folgte für Outlook.com, Hotmail und Live mit Wirkung zum 5. Mai 2025: Domänen mit mehr als 5.000 Mails am Tag brauchen SPF, DKIM und eine DMARC-Richtlinie mit mindestens p=none, ausgerichtet zu SPF oder DKIM, bevorzugt zu beiden. Nicht konforme Nachrichten kündigte Microsoft zunächst für den Junk-Ordner und anschließend für die Ablehnung an; der Fehlercode lautet 550 5.7.515 mit dem Hinweis, dass die sendende Domäne das verlangte Authentifizierungsniveau nicht erfüllt.

Die Grenze von 5.000 Nachrichten klingt nach Marketing, trifft aber jeden mittelgroßen Betrieb an einem Rechnungslauf oder einer Störungsmeldung an alle Kunden, und die Provider zählen je Domäne, nicht je System. Die praktische Konsequenz: die drei Einträge für jede Domäne pflegen, von der jemals Mails ausgehen, und für Massenmails eigene Subdomänen verwenden.

Von p=none zu p=reject: der Weg über die Berichte

Die aggregierten Berichte, die Empfänger an die Adresse aus rua= senden, sind XML-Dateien mit einer Zeile je sendender IP-Adresse und Tag: wie viele Mails, welche Prüfung bestanden, ob ausgerichtet, welche Richtlinie angewandt. Ein Berichtsdienst oder ein eigenes Werkzeug macht daraus eine Tabelle nach Quellen. Nach zwei bis vier Wochen kennst du eure Versender vollständig, einschließlich der Quellen, die niemand angemeldet hat, und der Angreifer, die eure Domäne bereits fälschen.

Aus der Tabelle folgt die Arbeit: Jede legitime Quelle bekommt einen Platz im SPF-Eintrag oder eine Signatur mit eurer Domäne, besser beides, und jede unbekannte Quelle wird abgeschaltet oder als Fälschung erkannt. Erst wenn die Berichte über mehrere Wochen keine legitimen Fehlschläge mehr zeigen, gehst du auf p=quarantine, beobachtest erneut und setzt dann p=reject; RFC 9989 bietet dafür den Testmodus t=y, der eine Richtlinie ankündigt, ohne sie durchzusetzen. Mit sp=reject schließt du Subdomänen, über die niemand sendet, und mit np auch Subdomänen, die nicht existieren.

Am Ende steht ein Nutzen über die Sicherheit hinaus. Mit einer durchgesetzten Richtlinie, also quarantine oder reject ohne Einschränkung, erfüllt eure Domäne die Voraussetzung für BIMI, das Verfahren, mit dem Mailprogramme ein geprüftes Logo neben eurem Absender anzeigen; Google verlangt dafür zusätzlich ein Zertifikat für das Markenzeichen.

Dazu passende Kurse

Wenn die DMARC-Berichte bei euch ungelesen im Postfach liegen, bringen Security-Kurse zu Mailsystemen, Absenderprüfung und Phishing-Abwehr die Auswertung in den Alltag.

Für den Teil, der nach bestandener Prüfung bleibt, also die Erkennung am Gateway, stehen bei cmt Fortinet-Kurse zum Betrieb von FortiMail als Mail-Gateway bereit.

04 Konkrete Kurse

Wo du genau das übst

Weitere Kurse aus diesem Bereich

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle IT-Security-Schulungen mit Terminen.

Stimmen aus den Kursen

Was Teilnehmende über die Kurse in diesem Bereich sagen

Sehr guter Dozent, spannend erklärt und mit vielen Praxisbeispielen!
Business Continuity Management gemäß BSI-Standard 200-4 & ISO 27001
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Monitoring mit Prometheus und Grafana - Grundkurs
Super Dozent mit vielen Praxisbeispielen so dass ich mich gleich für den folge Kurs interessiere.
Certified SOC-Analyst (CSA)

05 Fragen

Häufige Fragen

Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.

Brauchen wir DMARC, wenn wir keine Newsletter verschicken?
Ja, aus zwei Gründen. Erstens schützt DMARC eure Domäne vor Fälschung, unabhängig davon, wie viel ihr sendet; Rechnungsbetrug in eurem Namen braucht keinen Newsletter. Zweitens zählen die Provider je Domäne und je Tag, und die Grenze von 5.000 Nachrichten ist auch ohne Marketing schnell erreicht. Ein Eintrag mit p=none und rua kostet eine Viertelstunde und liefert ab dann Berichte.
Was bedeutet der Fehler 550 5.7.515 genau?
Microsoft lehnt die Nachricht ab, weil die Domäne im sichtbaren Absender die verlangten Anforderungen nicht erfüllt: SPF, DKIM und eine DMARC-Richtlinie mit mindestens p=none, bei der SPF oder DKIM zum sichtbaren Absender ausgerichtet sind. Der Code ist für Domänen angekündigt, die mehr als 5.000 Mails am Tag an Outlook.com, Hotmail oder Live senden; bis die Ablehnung vollständig greift, landen solche Mails im Junk-Ordner. Prüfe den Authentication-Results-Header einer Testmail und repariere die Prüfung, die dort nicht als ausgerichtet erscheint.
Warum scheitert SPF, wenn ein Empfänger unsere Mail weiterleitet?
Weil nach der Weiterleitung nicht mehr euer Server einliefert, sondern der des Weiterleitenden, und dessen IP-Adresse in eurem SPF-Eintrag fehlt. Das ist Bauart von SPF, kein Fehler eurer Konfiguration. DKIM überlebt die Weiterleitung, solange der Inhalt unverändert bleibt, und deshalb reicht für DMARC eine bestandene, ausgerichtete DKIM-Prüfung. Sorge dafür, dass alle Versender mit eurer Domäne signieren, dann sind Weiterleitungen kein Problem mehr.
Reicht ein SPF-Eintrag mit ~all, oder brauchen wir -all?
Für DMARC ist der Unterschied klein: Sowohl fail als auch softfail gelten als nicht bestanden, und die DMARC-Richtlinie entscheidet, was geschieht. Die Tilde ist während der Einführung sinnvoll, weil Empfänger ohne DMARC-Auswertung eine Mail mit softfail eher annehmen. Wichtiger ist, dass der Eintrag vollständig ist und unter zehn DNS-Abfragen bleibt. Sobald DMARC auf reject steht, kannst du auf -all wechseln, ohne dass sich für die großen Provider etwas ändert.
Was ist BIMI, und lohnt es sich?
BIMI zeigt euer Logo neben dem Absender in Mailprogrammen, die das Verfahren unterstützen. Voraussetzung ist eine durchgesetzte DMARC-Richtlinie; Google verlangt zusätzlich ein Zertifikat, das euer Markenzeichen bestätigt, und das kostet Geld und eine eingetragene Marke. Der Nutzen ist Wiedererkennung im Postfach; der eigentliche Gewinn liegt davor, denn eine Domäne, die BIMI darf, ist bereits gegen Fälschung geschützt.

Passt thematisch dazu

DMARC stoppt gefälschte Absender, nicht ähnlich klingende Domänen; für diese zeigt eine Seite im KI-Bereich, woran KI-geschriebene Phishing-Mails trotz sauberer Authentifizierung erkennbar sind.

Google verlangt TLS auf der SMTP-Verbindung, und die Automatisierung von TLS-Zertifikaten für Serverdienste sorgt dafür, dass das Zertifikat des Mailservers nicht mehr unbemerkt abläuft.

Quellen

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Security-Programm den passenden Kurs für deinen Stand zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

0800 71 20000 E-Mail

Die drei Prüfungen an echten Headern durchgehen

Im Kurs zu Internet Security bei cmt liest du Authentication-Results-Header echter Mails, baust SPF, DKIM und DMARC für eine Übungsdomäne auf, wertest Berichte aus und siehst, an welcher Stelle ein Dienstleister die Ausrichtung bricht. Die Trainer verantworten Mailsysteme im Betrieb.

Alle Kurse und Termine Frage stellen

Verwandte Themen

Alle Themen zu IT-Security