Was das E-Mail-Modul an Ihrer Absender-Identität prüft: SPF, DKIM, DMARC (RFC 9989), BIMI, MTA-STS und TLS-RPT – warum jeder Record zählt und wie bewertet wird.
Jetzt Domain prüfen →
Sie müssen einen dieser Records erst anlegen? Das kostenlose Record Studio erzeugt SPF, DKIM, DMARC, BIMI, MTA-STS und TLS-RPT.
Stand: September 2026 · 28 Checks dokumentiert
Bewertete Domain (www → Apex) #
E-Mail-Authentifizierung (MX, SPF, DKIM, DMARC, MTA-STS) wird an der Domain selbst konfiguriert; www. ist lediglich der Website-Alias und versendet oder empfängt praktisch nie Mail. Eine direkte Prüfung von www würde überwiegend bedeutungslose „fehlt“-Findings erzeugen.
BewertungNur informativ (Gewicht 0), und nur dann sichtbar, wenn wirklich umgeschrieben wurde: Beginnt die Eingabe mit www. UND ist sie nicht selbst die registrierbare Domain, wird genau dieses eine Label entfernt und die übergeordnete Domain bewertet. Die zweite Bedingung ist nötig – www.de ist eine echte Domain, und ein Entfernen würde den Scan auf die blanke TLD zusammenfallen lassen. Die registrierbare Domain stammt aus der Public Suffix List; lässt sie sich nicht bestimmen, wird nichts umgeschrieben. Andere Subdomains werden NICHT umgeschrieben – sie können legitim eine eigene Mail-Identität betreiben und erhalten stattdessen die hostspezifische Bewertung. Keine Norm definiert dieses Umschreiben; es folgt daraus, wo die Records liegen: SPF, DKIM, MX und MTA-STS werden am exakten Namen nachgeschlagen, eine Bewertung von www. meldete also das Fehlen von Records, die dort nie hingehörten. DMARC ist die Ausnahme: Sein Tree Walk (RFC 9989 §4.10) fände die geerbte Policy ohnehin.
BehebungNichts zu beheben – dies ist ein Transparenzhinweis, auf welche Domain sich die E-Mail-Ergebnisse beziehen.
SPF-Record vorhanden #
SPF (Sender Policy Framework) legt fest, welche Server im Namen der Domain senden dürfen, und ist eine der Grundlagen gegen E-Mail-Spoofing.
Bewertungpass, sobald ein v=spf1-Record gefunden wird (Gewicht 2, bei der Hostname-ohne-MX-Ausnahme weiter unten Gewicht 1 – sie senkt das Gewicht unabhängig davon, ob ein Record existiert); ob es der EINZIGE ist, bewertet gesondert Genau ein SPF-Record, und bei mehreren Records zeigt die Wertzeile den ersten. fail, wenn keiner gefunden wird. Ein TXT-Record, der mit v=spf1 beginnt, aber nicht durch ein Leerzeichen abgeschlossen ist – v=spf1-all –, ist gar kein SPF-Record (RFC 7208 §4.5); das Finding benennt diesen Beinahe-Treffer, statt stillschweigend „kein SPF“ zu melden. Eine fehlgeschlagene DNS-Abfrage gilt als nicht prüfbar und fällt aus der Bewertung, statt einen fehlenden Record zu behaupten. Existiert ein Record, der nicht auswertbar ist, bleibt diese Zeile pass – ein Record IST veröffentlicht – und sagt es dazu: Empfänger liefern einen PermError (RFC 7208 §4.6). Ein PermError ist nicht dasselbe wie gar kein SPF: Ohne Record hat ein Empfänger schlicht keine Information (§8.1), während §8.7 vorsieht, dass die Nachricht deswegen in der SMTP-Transaktion abgewiesen wird, mit Antwortcode 550 (siehe SPF-Syntax gültig). Ausnahme: Ein Hostname ohne MX, dessen Organisationsdomain ein anderer Name ist, erhält nur ein warn (Gewicht 1) – die Sende-Policy liegt bei dieser Organisationsdomain; v=spf1 -all auf dem Host ist optionale HELO-Härtung. Die Organisationsdomain stammt aus der Public Suffix List; lässt sie sich nicht bestimmen, greift die Ausnahme nicht. Der Drilldown listet jeden Term des Records mit seiner Bedeutung in Klartext auf und färbt drei Sorten Term: den blanken all – grün bei -all und ~all, gelb bei ?all, rot bei +all und bei all ohne Qualifier – dazu gelb einen Mechanismus hinter all und ein redirect=, das ein all-Mechanismus außer Kraft setzt. Die all-Farben folgen den Zeilen, die das gesondert bewerten, damit diese Tabelle ihnen nicht widersprechen kann. Ein MECHANISMUS hinter all wird nicht als autorisierend beschrieben, sondern als nie ausgewertet gekennzeichnet, denn RFC 7208 §5.1 verlangt von Empfängern, danach aufgeführte Mechanismen zu ignorieren. Ein Modifier ist ein anderer Fall und wird getrennt beurteilt (§4.6.1 macht einen Term entweder zum Mechanismus oder zum Modifier): Ein redirect= wird ebenso gekennzeichnet, aber aus einem anderen Grund — §5.1 lässt Empfänger es ignorieren, sobald der Record einen all-Mechanismus enthält, „regardless of the relative ordering of the terms“, Umstellen hilft also nicht —, während ein exp= dort sehr wohl ausgewertet und normal beschrieben wird: §6.2 berechnet den Erklärungstext gerade dann, wenn ein Mechanismus wie -all den Fehlschlag erzeugt hat, und §6 verlangt Modifier „after all mechanisms“.
BehebungEinen SPF-TXT-Record veröffentlichen, der alle legitimen sendenden Hosts auflistet, z. B. v=spf1 include:… ~all (Softfail, mit DMARC empfohlen) oder -all.
SPF-Syntax gültig #
Ein Syntaxfehler an irgendeiner Stelle des Records macht den GANZEN Record unbrauchbar, nicht nur den fehlerhaften Term. RFC 7208 §4.6 sagt es ausdrücklich: „The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result 'permerror', without further interpretation or evaluation.“ Jeder sorgfältig eingetragene Mechanismus wird dann ignoriert, und ein abschließendes -all schützt nichts – der Record wirkt eingerichtet und autorisiert niemanden. Bemängelt werden hier: eine unmögliche Adresse (ip4:999.1.1.1), eine Präfixlänge außerhalb von 0–32 für IPv4 bzw. 0–128 für IPv6 (§5.6) oder mit führender Null, ein Term, der weder bekannter Mechanismus noch Modifier ist, ein all mit Argument, ein zweites redirect=, eine CIDR-Länge an einem Mechanismus, der keine annimmt, sowie weitere fehlerhafte Terme wie ein leeres redirect=, ein zweites exp= oder ein nicht parsbares Makro – die Liste ist nicht abgeschlossen.
Bewertungfail mit Gewicht 2, kein eigener Notendeckel. Die Zeile erscheint nur, wenn ein SPF-Record existiert und die Prüfung über den gesamten Record einen Fehler findet; eine Domain ohne SPF-Record behandelt stattdessen SPF-Record vorhanden. Der Wert trägt den internen Fehlercode und bei einigen Fehlerklassen den beanstandeten Term dazu; das Detail sagt in Worten, was falsch ist. Die Prüfung stoppt beim ERSTEN Fehler, ein Record kann also mehrere haben. Geprüft wird nur der Record der geprüften Domain – ein defekter Record bei einem include:-Ziel erscheint unter SPF-include/redirect-Ziele gültig. Solange dieses Finding steht, treten die Zeilen zurück, die die WIRKUNG des Records beschreiben: Standardverhalten, DNS-Lookups und include-Ziele werden informativ mit Gewicht 0, weil ein konformer Empfänger PermError zurückgibt „without further interpretation or evaluation“ (RFC 7208 §4.6) — was der Record sagt, kann also keine Wirkung haben. Die Catch-all-Zeile behält ihr Urteil, sagt aber dazu, dass das Loch noch nicht scharf ist.
BehebungDen genannten Term korrigieren, neu veröffentlichen und erneut scannen: Die Prüfung stoppt beim ersten Fehler, ein zweiter kann danach sichtbar werden. Solange der Record nicht parst, hat diese Domain überhaupt keine funktionierende SPF-Policy – Empfänger liefern einen PermError, und §8.7 sieht dafür die Abweisung der Nachricht in der SMTP-Transaktion vor, was schlechter ist, als gar nichts zu veröffentlichen (§8.1).
Kein Catch-all-IP-Bereich #
Ein /0-Präfix passt auf jede Adresse seiner Familie: RFC 7208 §5.6 vergleicht nur die von der CIDR-Länge benannten höherwertigen Bits, und eine Länge von null benennt keine. Mit Pass-Qualifier – ip4:0.0.0.0/0, +ip6:::/0 oder derselbe Term ganz ohne Qualifier, der standardmäßig + ist (§4.6.2) – autorisiert so ein Term jeden Host im Internet dieser Adressfamilie, im Namen Ihrer Domain zu senden. Ein abschließendes -all hebt das für diese Absender nicht auf: Mechanismen werden von links nach rechts ausgewertet, und der erste Treffer beendet die Auswertung (§4.6.2) – Absender dieser Adressfamilie erreichen den all-Term nie. Absender der anderen Familie erreichen ihn sehr wohl, denn ein ip4:-Term kann keine IPv6-Adresse enthalten (§5.6). Syntaktisch ist das völlig korrekt, die Syntaxprüfung oben kann es also nicht sehen, und nach Migrationen bleibt es leicht stehen. Ein verbietender Qualifier auf demselben Bereich (-ip4:0.0.0.0/0) wird nicht bemängelt; ~ und ? ebenfalls nicht, sie machen den all-Term aber genauso unerreichbar, worauf die Standardverhalten-Zeile hinweist.
Bewertungfail mit Gewicht 2 und einem Notendeckel C – derselbe Deckel wie bei +all, denn beides ist dieselbe Policy in anderer Schreibweise, und eine mildere Bewertung würde Verschleierung belohnen. Der Wert listet die beanstandeten Terme auf. Zwei Folgen sind im Bericht zu erwarten: Die Zeile SPF-Standardverhalten tritt zurück – informativ, Gewicht 0, ohne Deckel –, weil der all-Mechanismus hinter so einem Bereich für dessen Adressfamilie nicht mehr erreicht wird und derselbe Fehler nicht zweimal zählen darf; und hat der Record ZUSÄTZLICH einen Syntaxfehler — oder veröffentlicht die Domain mehr als einen v=spf1-Record —, entfällt der Deckel, weil Empfänger dann überhaupt niemanden autorisieren. Das Finding selbst bleibt und sagt, dass eine reine Syntaxreparatur das Loch scharf schalten würde.
BehebungDen /0-Bereich durch die Netze ersetzen, die tatsächlich für Sie versenden. War wirklich gemeint, alles zu autorisieren, sagt v=spf1 +all das ehrlich – schaltet SPF als Schutz aber ab und wird genauso bewertet.
SPF-Standardverhalten (all) #
Der abschließende all-Mechanismus bestimmt, wie mit nicht autorisierten Absendern umgegangen wird. +all ist gefährlich. Für versendende Domains empfiehlt Mailhardener ~all (Softfail) statt -all, weil Weiterleitungen SPF brechen, und RFC 9989 §7.1 nennt einen unabhängigen Grund zur Vorsicht beim Hard Fail: Manche Empfänger-Architekturen könnten SPF vor DMARC auswerten, sodass eine Nachricht, die über eine ausgerichtete DKIM-Signatur DMARC bestanden hätte, früh in der SMTP-Transaktion abgewiesen wird – und eine vor der DATA-Phase abgewiesene Nachricht taucht in keinem Aggregat-Report auf, weil die From-Domain nie offengelegt wird. -all zusammen mit DMARC bleibt korrekt; die Wahl ist eine Abwägung, keine Regel. Bei geparkten Domains ist der Fall eindeutig: dort ist -all richtig.
Bewertungpass mit -all sowie mit ~all auf einer tatsächlich sendenden Domain; warn mit ~all auf einer geparkten/nicht sendenden Domain (dort ist -all richtig), mit ?all und wenn gar kein all-Mechanismus vorhanden ist. +all – auch ein bloßes all, dessen Qualifier standardmäßig + ist – ist fail und deckelt die Modulnote auf C. Gewicht 2. Zwei Dinge zeigt die Wertzeile: Hat der Record keinen all-Term, aber ein auflösbares redirect=, stammt der Standardwert vom ersten all-Term des redirect-Ziels und wird als „(über redirect=…)“ gekennzeichnet (RFC 7208 §6.1); eine Domain ohne MX, ohne erlaubte Absender und ohne redirect= wird als „geparkt“ markiert — ein Record, der seine Policy per redirect= delegiert, ist das Gegenteil von geparkt, unabhängig davon, ob sich das Ziel lesen ließ. Die redirect=-Kette wird über die erste Ebene hinaus verfolgt – bis zu zehn Sprünge, dasselbe Budget, das Empfänger nach dem 10-Lookup-Limit aus §4.6.4 haben –, denn §6.1 hält fest, dass „the newly queried domain can itself specify redirect processing“. Die Zeile tritt zurück – informativ, Gewicht 0, kein Deckel – in fünf Fällen, in denen der all-Term nicht das ist, was Empfänger anwenden: hinter einem Catch-all-Bereich mit Pass-Qualifier (bewertet von Kein Catch-all-IP-Bereich), solange der Record einen Syntaxfehler hat (bewertet von SPF-Syntax gültig), wenn mehr als ein v=spf1-Record veröffentlicht ist – §4.5 lässt bereits die AUSWAHL des Records scheitern, Empfänger werten also keinen davon aus (bewertet von Genau ein SPF-Record) – wenn ein redirect=-Ziel keinen SPF-Record veröffentlicht, was §6.1 zu einem PermError statt zu „none“ macht – das Ergebnis ist damit auch nicht neutral, und wenn die redirect=-Kette im Kreis läuft, was Empfänger nach Überschreiten des 10-Lookup-Limits aus §4.6.4 mit einem PermError beantworten. Zu einem skip wird sie, wenn dieser Scanner das redirect-Ziel gar nicht lesen konnte: Das Standardverhalten ist dort definiert und wurde damit nicht gemessen. Ein ~/?-Bereich auf /0 ändert die Note nicht, wird aber benannt: Auch er beendet die Auswertung für diese Adressfamilie vor dem all-Term. Ohne SPF-Record ist diese Zeile fail mit Gewicht 2; auf einem Hostnamen ohne MX entfällt sie ganz.
BehebungSendende Domain: ~all oder -all (mit DMARC) verwenden. Geparkte Domain: -all. Niemals +all.
Genau ein SPF-Record #
Mehrere v=spf1-Records sind verboten (RFC 7208 §3.2) und lassen check_host() einen PermError liefern (§4.5) – SPF schlägt dann vollständig fehl. Ein PermError ist nicht dasselbe wie gar kein SPF: Ohne Record hat ein Empfänger schlicht keine Information (§8.1), während ein PermError eine defekte Konfiguration anzeigt und §8.7 ausdrücklich vorsieht, dass die Nachricht deswegen in der SMTP-Transaktion abgewiesen wird, mit Antwortcode 550.
Bewertungfail + Cap C bei mehr als einem SPF-Record (PermError – keine wirksame SPF-Policy). Gewicht 2.
BehebungAlle SPF-Records zu einem einzigen zusammenführen.
Veralteter ptr-Mechanismus #
Der ptr-Mechanismus ist langsam und unzuverlässig; RFC 7208 rät ausdrücklich von ihm ab.
Bewertungwarn, wenn der Record den ptr-Mechanismus ODER das %{p}-Makro verwendet. RFC 7208 §4.6.4 stellt beide gleich („When evaluating the ‚ptr' mechanism or the %{p} macro“), und §5.5 nennt den Mechanismus veraltet; die Zeile benennt, welches von beiden gefunden wurde. Gewicht 1.
BehebungDen ptr-Mechanismus aus dem SPF-Record entfernen.
Veralteter SPF-Record-Typ (99) #
SPF hatte neben der TXT-Form einmal einen eigenen DNS-Record-Typ, SPF (Typ 99). RFC 7208 §3.1 hat das beendet: SPF-Records „MUST be published as a DNS TXT (type 16) Resource Record (RR) only“, und §14.1 sagt über Typ 99: „its use is no longer appropriate for SPF version 1; implementations are not to use it“. Ein aus dieser Zeit übrig gebliebener Typ-99-Record wird von Empfängern nie ausgewertet – und sobald er vom TXT-Record abweicht, dokumentiert er eine Policy, die niemand durchsetzt, und führt in die Irre, wer die Zone liest. RFC 6686 Anhang A hält fest, wie das Experiment mit zwei Typen endete.
Bewertungwarn (Gewicht 1), wenn die Domain einen oder mehrere Records vom Typ 99 veröffentlicht, unabhängig vom Inhalt; die Zeile sagt, ob der Inhalt zur TXT-Policy passt, von ihr abweicht oder ohne v=spf1-TXT-Record allein steht. Nicht angezeigt, wenn kein Typ-99-Record existiert; eine fehlgeschlagene Abfrage behauptet nichts.
BehebungDie Typ-99-Records beim DNS-Provider löschen und die Policy nur im TXT-Record führen. Ist der Typ-99-Record die einzige SPF-Policy, sie zuerst als TXT veröffentlichen.
SPF-DNS-Lookups (Limit 10) #
SPF erlaubt höchstens 10 Terme, die DNS-Abfragen auslösen. RFC 7208 §4.6.4 nennt sie: die Mechanismen include, a, mx, ptr und exists sowie den Modifier redirect – all, ip4, ip6 und exp zählen nicht. Werden mehr benötigt, tritt ein PermError auf und SPF gilt als nicht bestanden. Derselbe Abschnitt kennt weitere Grenzen, die dieses Finding nicht zählt, darunter ein SHOULD von höchstens zwei „Void Lookups“ (Abfragen ohne Daten oder mit NXDOMAIN); die wertet der Live-Sendetest aus.
Bewertungpass bei 10 oder weniger, fail darüber (Gewicht 1). Die Zahl entsteht durch rekursives Auflösen der include-/redirect-Kette, gezählt pro Pfad – ein über zwei Zweige erreichtes Ziel zählt zweimal, weshalb die Zahl von global zählenden Werkzeugen abweichen kann. Ziele mit %-Makros werden mitgezählt, lassen sich aber nicht expandieren und werden nicht verfolgt. Zwei Zustände trägt die Zahl selbst: Ein angehängtes „+“ heißt, die Auflösung wurde am Limit abgebrochen; ein „≥N“ mit skip heißt, sie ist nicht innerhalb der 15-Sekunden-Grenze fertig geworden – dann ist die wirkliche Zahl unbekannt und es wird kein selbstsicheres pass behauptet. Solange der Record einen Syntaxfehler hat, ist die Zeile informativ mit Gewicht 0: Empfänger brechen ohnehin vor dem ersten Lookup ab.
BehebungIncludes reduzieren/konsolidieren. SPF-Flattening vermeiden – es führt zu veralteten IPs.
SPF-include/redirect-Ziele gültig #
Ein include: oder redirect=, das auf eine Domain zeigt, die keinen SPF-Record veröffentlicht, verursacht laut RFC 7208 einen PermError – Empfänger behandeln dann die gesamte SPF-Policy als defekt. Das passiert typischerweise, wenn ein früherer Mail-Provider gekündigt wurde, sein Include aber im Record verbleibt.
Bewertungfail, wenn mindestens ein include-/redirect-Ziel nachweislich keinen SPF-Record veröffentlicht (Gewicht 2). Die Zeile schweigt bewusst, sobald kein Urteil möglich ist – ihr Fehlen ist also kein Beleg dafür, dass alle Ziele in Ordnung sind: Ziele mit %-Makros lassen sich ohne konkrete Absenderidentität nicht expandieren und werden übersprungen; ein Ziel, dessen eigene Abfrage fehlschlägt (SERVFAIL oder Timeout), ist ein temporärer Fehler und kein fehlender Record, über ihn wird nichts behauptet; und läuft die gesamte Auflösung in ihre 15-Sekunden-Grenze, entfällt das Finding ganz. Endete die Auflösung stattdessen am Lookup-Limit, wird die Liste als Untergrenze ausgewiesen. Solange der Record einen Syntaxfehler hat – oder die Domain mehr als einen v=spf1-Record veröffentlicht –, ist die Zeile informativ mit Gewicht 0: In beiden Fällen gibt ein konformer Empfänger PermError zurück, bevor ein Ziel überhaupt abgefragt wird (§4.6 beim Syntaxfehler, §4.5 bei der Record-Auswahl selbst), ihr Zustand kann das Ergebnis also nicht ändern. Beim Syntaxfehler sagt sie zusätzlich, dass daraus ein eigener PermError wird, sobald die Syntax stimmt.
BehebungVerwaiste Includes aus dem SPF-Record entfernen oder den SPF-Record bei der Ziel-Domain wiederherstellen.
DMARC-Record vorhanden #
DMARC verknüpft SPF und DKIM mit einer Policy und teilt empfangenden Servern mit, was mit gefälschten Mails geschehen soll – plus Reporting. Ohne DMARC ist der Spoofing-Schutz unvollständig.
Bewertungpass, wenn unter _dmarc ein v=DMARC1-Record existiert; sonst fail. Gewicht 3. Mehr als ein v=DMARC1-Record am geprüften Namen ist ebenfalls fail und deckelt die Modulnote auf C: Empfänger verwerfen sie alle (RFC 9989 §4.10 Schritt 2). Die Policy-Ermittlung läuft von dort im Baum weiter, ein geerbter Record kann also trotzdem greifen und die Policy-Zeile sogar ein pass sein – am geprüften Namen greift aber nichts, und der Deckel bleibt. Schlägt schon die DNS-Abfrage fehl, meldet die Zeile „nicht prüfbar“ und fällt aus der Bewertung, statt einen fehlenden Record zu behaupten. Der Drilldown listet jedes Tag des geltenden Records mit einer Bedeutung in Klartext auf und färbt die Policy-Tags (grün bei reject, rot bei none, sonst gelb); ein Tag, das der Standard nicht kennt, erscheint als unbekannt und wird von Empfängern schlicht ignoriert. Hat der geprüfte Name selbst keinen Record, klettern Empfänger über nacheinander kürzere Namen bis zur TLD — der ganze Walk ist auf acht DNS-Abfragen gedeckelt, und diese Zahl schließt die Abfrage am geprüften Namen ein, es werden also höchstens sieben kürzere Namen versucht (DNS-Tree-Walk, RFC 9989 §4.10; psd=-Tags steuern, wo die Organisationsdomain liegt, und beenden den Walk) —, und eine geerbte Policy zählt. Der v-Wert ist case-sensitiv – ein Record wie v=dmarc1 wird vollständig ignoriert und hier als defekt gemeldet.
BehebungDMARC veröffentlichen, zunächst mit v=DMARC1; p=none; rua=mailto:…, und dann schrittweise verschärfen.
DMARC-Policy (p=) #
p=none bittet Empfänger, gegen nicht authentifizierte Mail nichts zu unternehmen. RFC 9989 §3.2.12 nennt diesen Zustand nur dann „Monitoring Mode“, wenn die Policy für die Organisationsdomain und jede Subdomain darunter p=none lautet UND der Domain-Inhaber dafür Aggregate-Reports empfängt – ohne rua DÜRFEN Empfänger diese Reports nicht erzeugen (§4.7), ein solcher Record schützt also weder, noch beobachtet er. Nur p=quarantine (Spam) oder p=reject (Abweisung) erreichen Enforcement (RFC 9989 §3.2.9: die Organisationsdomain und alle ihre Subdomains stehen nicht auf none – ein sp=none bricht es) und machen Spoofing für Empfänger behandelbar. Auch p=reject ist keine Garantie: Empfänger dürfen nicht allein deswegen abweisen (§7.4), und gefälschte Anzeigenamen deckt DMARC nicht ab (§11.4). Ein Record ganz ohne p-Tag oder mit einem ungültigen p-/sp-/np-Wert überlebt nur als p=none, wenn eine gültige rua-URI existiert – ohne sie wenden Empfänger gar kein DMARC an. Die Bedingung in §4.10.1 lautet „does not contain a valid ‚p‘ tag, or contains an ‚sp‘ or ‚np‘ tag that is not valid“ und deckt damit auch ein fehlendes p ab; §4.7 liest ein fehlendes p zwar als implizites p=none und verweist für die Behandlung auf §4.10.1. Dieser Scanner folgt §4.10.1.
BewertungBenotet wird die für den geprüften Namen WIRKSAME Policy, nicht das p-Tag im Wortlaut: Bei einem geerbten Record ist das sp, wenn gesetzt, sonst p – die Wertzeile sagt, welches. Eine Subdomain unter einer Organisationsdomain mit p=reject; sp=none wird also wie none bewertet. (Liegt der Record am geprüften Namen selbst, wird p benotet, und ein schwaches sp bemängelt gesondert Subdomain-Policy.) pass mit reject; warn mit quarantine; none (explizit, implizit oder als §4.10.1-Rückfall) → fail + Cap C; ein unwirksamer Record (kein p-Tag oder ungültige Werte, und kein rua) → fail + Cap C. Gewicht 3. Ist die wirksame Policy reject, wurde aber unter den gängigen Selektoren kein brauchbarer DKIM-Schlüssel gefunden, trägt dieses Finding einen zusätzlichen Hinweis – RFC 9989 §7.4 verlangt, dass sich Domains mit reject nicht allein auf SPF verlassen.
BehebungStufenweise gemäß RFC 9989 §7.4 anheben: p=none mit Reports mindestens einen Monat, p=quarantine ähnlich lange, dann p=reject – und mehr einplanen, denn das Abarbeiten der Reports kann viele Monate dauern (§5.1.7). Domains mit p=reject dürfen sich nicht allein auf SPF verlassen – ausgehende Mail mit DKIM signieren (§7.4/§8); zu einem Fall wird derselbe Abschnitt deutlich: Es sei „critical“, dass Domains, deren Nutzer möglicherweise auf Mailinglisten posten, p=reject NICHT veröffentlichen sollten, und wer es dennoch tut, soll zuvor die genannten Stufen durchlaufen und seine Nutzer darauf hinweisen, dass ihre Teilnahme an Listen beeinträchtigt sein kann.
DMARC-Testmodus (t=) #
RFC 9989 hat das Tag t=y als Nachfolger von pct=0 eingeführt: Empfänger wenden die veröffentlichte Policy eine Stufe schwächer an – reject wirkt wie quarantine, quarantine wie none; das Reporting bleibt unberührt, und eine Policy none ändert sich nicht. Nützlich während des Rollouts, aber solange es gesetzt ist, schützt p=reject nicht vollständig vor Spoofing.
Bewertungwarn (Gewicht 2), wenn t=y eine quarantine/reject-Policy abschwächt; info (Gewicht 0), wenn die Policy none ist und das Tag keine Wirkung hat.
BehebungSobald die Aggregate-Reports sauber aussehen, t=y entfernen, damit die Policy voll greift.
DMARC-Abdeckung (pct=) #
Mit pct<100 wenden Empfänger auf altem Spezifikationsstand die Policy nur auf einen Teil der Mail an. Das Tag wurde in RFC 9989 (DMARCbis) entfernt und ist als historic registriert (§9.3, dort definiert als „the tag is considered deprecated and is not expected to be in use in any current implementation“): Empfänger, die die aktuelle Spezifikation umsetzen, ignorieren es vollständig, Empfänger auf RFC-7489-Stand werten es weiterhin aus. Das Tag erzeugt damit nur noch eine Spaltung zwischen beiden – eine, die weder beobachtbar noch steuerbar ist.
BewertungWird nur bewertet, wenn das Tag wirklich vorhanden ist, und danach benotet, wie weit aktuelle und alte Empfänger AUSEINANDERLAUFEN. pass bei 100 % (Gewicht 1) und warn bei einem syntaktisch ungültigen Wert (Gewicht 1) – pct ist keines der Tags, die RFC 9989 definiert (§4.7-Tagliste, §4.8 Tabelle 2), und ist als historic registriert (§9.3); Empfänger auf aktuellem Stand ignorieren es also, was immer darin steht. Empfänger auf RFC-7489-Stand sollen einen fehlerhaften Wert zugunsten des dortigen Defaults 100 verwerfen (RFC 7489 §6.3, ein SHOULD). Ein kaputter Wert bewirkt damit nichts, was ein fehlender nicht auch bewirkte. info mit Gewicht 0, außerhalb der Bewertung, wenn die wirksame Policy none ist: Es gibt keine Durchsetzung, aus der gesampelt werden könnte. fail mit Gewicht 2 bei pct=0 auf einer durchsetzenden Policy – der Record liest sich wie Monitoring, während Empfänger auf RFC-9989-Stand p=quarantine/reject bereits voll anwenden; bewusst ohne Notendeckel, denn angewandt wird die Policy selbst. warn mit Gewicht 2 bei einer Teilquote (1–99) auf einer durchsetzenden Policy, die Ihre Empfänger in zwei Verhaltensweisen teilt. t=y wird vorher eingerechnet: Es senkt die Policy um eine Stufe und kann einen durchsetzenden Fall damit in den Gewicht-0-Fall verwandeln. Benotet wird der Record, der GILT – bei einem geerbten Record der der Organisationsdomain.
BehebungDas Tag entfernen (seit RFC 9989 obsolet) – dabei die Reihenfolge beachten, denn mit dem Löschen gehen Empfänger auf RFC-7489-Stand auf volle Durchsetzung: Bei einer Teilquote zuerst p/sp festlegen und jeden legitimen Versandweg ausrichten, dann löschen. Ein bewusstes pct=0 sollte stattdessen t=y werden – RFC 9989 (App. A.6) führt das t-Tag als Nachfolger genau zweier pct-Werte ein: t=y für pct=0 und t=n für pct=100; eine Teilquote hat kein Nachfolge-Tag.
DMARC-Aggregate-Reports (rua) #
Ohne rua-Adresse erhält man keine Auswertung, wer im Namen der Domain sendet – die Grundlage, um gefahrlos zu p=reject überzugehen. E-Mail ist der einzige definierte Report-Transport: Eine rua-Liste ohne mailto:-URI stellt nie etwas zu (RFC 9990 §3.5).
Bewertungpass, wenn rua gesetzt ist und eine mailto:-Adresse enthält; warn, wenn es fehlt oder keine mailto:-URI enthält. Gewicht 1. Ausnahme: Bei einer No-Mail-Domain (Null MX + SPF ohne erlaubte Absender) ist ein fehlendes rua nur info (Gewicht 0) – dort kann niemand legitime Mail zustellen, Reports würden höchstens Spoofing-Versuche zeigen.
BehebungEine rua=mailto:…-Adresse ergänzen (z. B. einen DMARC-Reporting-Dienst).
Externe Report-Empfänger autorisiert #
Zeigt rua/ruf auf eine Domain in einer anderen Organisationsdomain (per Tree Walk ermittelt – Geschwister-Subdomains unter derselben Organisationsdomain gelten nicht als extern), muss dieses Ziel die Annahme über einen <domain>._report._dmarc.<target>-TXT-Record autorisieren – sonst verwerfen Empfänger die Reports. Failure-Reports (ruf) brauchen dieselbe Autorisierung (RFC 9991 §5). Was diese Prüfung misst: RFC 9990 §4 formuliert die Regel für den Host-Teil jeder Report-URI – der Einleitungssatz spricht von „the host part of the authority component of a [RFC3986]“, und mailto kommt in §4 nur in einem Beispiel vor –, deshalb löst diese Zeile jetzt jede URI in rua/ruf auf: den Host einer mailto:-Adresse oder den Authority-Host jedes anderen Schemas. Geprüft werden davon höchstens die ersten acht verschiedenen Hosts. Zu beachten: mailto: ist das einzige Transport-Schema, das ein Empfänger umsetzen muss (RFC 9989 §4.7), und URIs mit nicht unterstützten Schemata werden ignoriert – die Autorisierungsregel selbst unterscheidet aber nicht. Über die Externalität entscheidet ein Tree Walk; ist das DNS-Budget des Scans dafür erschöpft, fällt er auf einen reinen Suffix-Vergleich zurück, der eine Geschwister-Domain falsch einordnen kann.
Bewertungpass, wenn jedes externe rua/ruf-Ziel autorisiert ist; warn, wenn der Autorisierungs-Record fehlt, der Prüfname das DNS-Längenlimit überschreitet (die Verifikation kann dann nie gelingen) oder das Ziel rua/ruf mit einem fremden Host überschreibt (Empfänger stellen dann an keine der Adressen zu). DNS-Fehler bei der Verifikation werden als nicht prüfbar gemeldet, nicht als fehlend. Gewicht 1.
BehebungBei der Ziel-Domain einen TXT-Record <domain>._report._dmarc.<target> mit v=DMARC1 veröffentlichen.
Subdomain-Policy (sp=/np=) #
Ein schwaches sp (z. B. none) untergräbt ein strenges p: Subdomains lassen sich dann weiterhin fälschen. RFC 9989 definiert zusätzlich np= für nicht existierende Subdomains – wertvoll, weil Fälscher gern Hosts wie rechnung.example.com erfinden, die gar keine DNS-Records haben. Beide Tags wirken nur im Record der Organisationsdomain: Die Policy-Ermittlung liest sie aus tiefer liegenden Records nie aus – RFC 9989 §4.7 sagt das für sp; für np folgt es aus der Policy-Ermittlung in §4.10.1.
Bewertungwarn, wenn p strikt ist, aber sp=none oder np=none; sonst info. Gewicht 0–1. sp/np in einem Record unterhalb der Organisationsdomain werden als wirkungslos markiert (info).
Behebungsp/np auf mindestens quarantine/reject setzen oder entfernen – dabei die Erbfolge beachten: Fehlt sp, folgt es p; fehlt np, folgt es sp, sofern ein sp gesetzt ist, und erst sonst p (RFC 9989 §4.7). np zu löschen, während sp=none stehen bleibt, lässt nicht existierende Subdomains also ungeschützt. Beide gehören in den Record der Organisationsdomain.
DMARC-Record-Syntax #
Über die Policy hinaus hat RFC 9989 das Record-Format verschärft: Ein Syntaxfehler MUSS jetzt zugunsten des Defaults – sofern es einen gibt – verworfen oder ganz ignoriert werden (§4.8; RFC 7489 §6.3 sagte nur SHOULD). Unverändert seit RFC 7489, aber wichtig: Doppelte Tags machen die gesamte Tag-Liste des Records ungültig – DMARC übernimmt die DKIM-Tag-Value-Syntax (RFC 9989 §4.7), und RFC 6376 §3.2 sagt „if a tag name does occur more than once, the entire tag-list is invalid“, unbedingt; was Empfänger tatsächlich damit tun, geht auseinander, weil §4.8 für Fehler innerhalb eines Records in die andere Richtung zieht, und schon das ist Grund genug, kein Duplikat zu veröffentlichen. fo= hat harte Einschränkungen (0 und 1 schließen sich aus, d/s höchstens einmal, ohne ruf ganz wirkungslos), ungültige Tag-Werte fallen still auf ihre Defaults zurück, und die Tags ri=/rf= stehen – wie pct= – in der DMARC-Tag-Registry auf „historic“ (§9.3), während das !size-URI-Suffix in der Grammatik nur noch als veraltete Syntax steht, die Reporter ignorieren sollen (§4.8).
BewertungErscheint nur, wenn etwas auffällt. warn – und dann Gewicht 1 – bei doppelten Tags, bei kaputten fo=-Werten und bei einem psd=y auf einem Namen, der nicht auf der Public Suffix List steht: Empfänger, die das Tag beachten, halten den Tree Walk dort an (RFC 9989 §4.10, Schritte 2/6), und für Mail aus jeder Subdomain darunter – wo der Record nicht mehr der Startname des Walks ist – verschiebt Regel 2 aus §4.10.2 die Organisationsdomain auf den Namen ein Label darunter; Alignment und Subdomain-Policy ändern sich damit für den ganzen Baum. Den Namen selbst zur Organisationsdomain zu erklären, ist die Wirkung von psd=n (§4.7, §4.10.2 Regel 1). info mit Gewicht 0 für alles, was Empfänger schlicht ignorieren: aus dem Standard entfernte Tags (ri, rf, das !size-URI-Suffix), ungültige Werte, die stillschweigend auf ihr Default zurückfallen (t, psd, adkim, aspf), ein fo= ohne ruf, auf das es wirken könnte, ein ruf ohne mailto:-URI und ein ruf auf einem psd=y-Record, das Report-Generatoren ohne eine ausdrückliche Absprache zwischen den Beteiligten nicht beachten dürfen (RFC 9991 §2).
BehebungDen Record bereinigen: veraltete (ri, rf, pct, !size) und doppelte Tags entfernen, ungültige Werte korrigieren.
DKIM-Schlüssel auffindbar #
DKIM signiert ausgehende Mails kryptographisch, sodass Empfänger Authentizität und Integrität prüfen können. Geprüft werden gängige Selektoren.
Bewertungpass, wenn mindestens einer der abgefragten gängigen Selektoren einen BRAUCHBAREN Schlüssel veröffentlicht. Vier veröffentlichte Zustände zählen nicht als brauchbarer Schlüssel: ein LEERES p= (widerrufen, RFC 6376 §3.6.1), ein Record ganz OHNE p=-Tag (§3.6.1 macht es zur PFLICHT, und §6.1.2 Punkt 5 lässt Verifizierer einen solchen Record als Syntaxfehler verwerfen), ein Record, der irgendein Tag MEHR ALS EINMAL veröffentlicht (§3.2: „if a tag name does occur more than once, the entire tag-list is invalid“ – ihn last-wins zu lesen ließ die REIHENFOLGE der Doppelungen über das Urteil entscheiden), und eine s=-Service-Type-Liste, die nach dem Verwerfen unbekannter Typen weder email noch * nennt (§3.6.1: „Verifiers for a given service type MUST ignore this record if the appropriate type is not listed“ — der Alltagsauslöser ist der Tippfehler s=mail). Zum Widerruf: Sind alle gefundenen Selektoren widerrufen, ist die Zeile warn und sagt das auch – es lässt sich derzeit keine Signatur dieser Domain prüfen. warn, wenn gar kein Selektor traf (der Selektor kann abweichen; Selektoren lassen sich im DNS nicht aufzählen, eine Abwesenheit ist hier also ein Hinweis, kein Beweis – der Drilldown nennt jeden abgefragten Selektor, mit und ohne Treffer). skip, wenn kein Selektor traf, aber mindestens eine Abfrage nicht auflöste: Der echte Selektor könnte genau eine der fehlgeschlagenen Sonden sein, es wird also keine Abwesenheit behauptet. Gewicht 2. Bei einem Hostnamen ohne MX werden fehlende Selektoren übersprungen (nicht bewertet) – die Mail-Identität liegt bei der Organisationsdomain. Ebenso übersprungen bei einer No-Mail-Domain (Null MX plus die leere SPF-Policy v=spf1 -all, die ausdrückliche No-Mail-Erklärung nach RFC 7505 §4.2): Eine Domain, die nie versendet, braucht keine Signaturschlüssel. Ein Softfail (~all), ein SPF mit erlaubten Absendern oder ein Record mit Syntaxfehler lässt die reguläre Prüfung laufen – ein PermError deklariert nichts, und nur eine bewusste Erklärung „diese Domain versendet nicht“ rechtfertigt die Ausnahme.
BehebungDKIM beim Mail-Provider aktivieren und den veröffentlichten Selektor im DNS ergänzen. Bei einer No-Mail-Domain gibt es nichts zu beheben. Hat die Domain früher signiert, lassen sich ihre alten Selektoren per Wildcard-Record *._domainkey → v=DKIM1; p= widerrufen – ein leeres p= heißt „Schlüssel widerrufen“ (RFC 6376 §3.6.1). Zu beachten: Eine Wildcard antwortet nur für Namen ohne eigenen Record und erreicht nichts, was bereits gecacht ist; explizit veröffentlichte Selektor-Records haben Vorrang und sollten gelöscht werden. Der unten verlinkte M3AAWG-Parked-Domains-BCP geht für eine geparkte Domain den anderen Weg und zieht es vor, gar keinen DKIM-Record zu veröffentlichen – ein fehlender öffentlicher Schlüssel lässt jede gefälschte Signatur bereits scheitern.
DKIM-Schlüssellänge #
Ein zu kurzer DKIM-Schlüssel schwächt die Signatur nicht nur – RFC 8301 §3.2 verlangt von Empfängern, sie zu verwerfen: „Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.“ Signierende MÜSSEN mindestens 1024 Bit verwenden und SOLLTEN mindestens 2048 nehmen; Verifizierer müssen nur Schlüssel bis 4096 Bit beherrschen, länger ist also nicht automatisch interoperabler. Ed25519 (RFC 8463) ist die moderne Alternative, aber als Ergänzung, nicht als Tausch: Ein Selektor trägt genau einen Schlüssel, also den RSA-Selektor behalten und Ed25519 unter einem zweiten veröffentlichen, bis jeder relevante Empfänger ihn verifiziert.
BewertungWird je Algorithmus beurteilt, ein Ed25519-Schlüssel (256 Bit) neben RSA-2048 löst also kein Urteil „schwacher RSA-Schlüssel“ aus. Die Zweige werden in dieser Reihenfolge geprüft, und der erste zutreffende entscheidet: fail, wenn ein RSA-Schlüssel kürzer als 1024 Bit ist – verglichen wird der KÜRZESTE gefundene RSA-Schlüssel, ein schwacher Selektor fällt die Zeile also auch neben einem starken; warn, wenn ein veröffentlichter Selektor einen p=-Wert trägt, der sich überhaupt nicht als öffentlicher Schlüssel lesen lässt – damit signierte Mail scheitert überall dort, wo der Schlüssel nicht gelesen werden kann, und die Lösung ist, den Wert neu zu veröffentlichen, nicht den Schlüssel zu verlängern (RFC 6376 §3.6.1 nennt PKCS#1-RSAPublicKey; Errata 3017, Status „Held for Document Update“, ergänzt, dass er in einem SubjectPublicKeyInfo enthalten sein DARF, und Errata 7001, Status „Reported“, verlangt SPKI direkt und begründet das damit, dass die RFC-Form „is not what is used either in the wild, or in the examples in this RFC“ — SPKI ist die Form, die diese Prüfung liest); warn bei jedem RSA-Schlüssel unter 2048 Bit — RFC 8301 §3.2 macht 1024 zum harten Minimum („Signers MUST use RSA keys of at least 1024 bits“) und 2048 zur Empfehlung („SHOULD use RSA keys of at least 2048 bits“); 1536 Bit erfüllt das Minimum und verfehlt die Empfehlung genauso wie 1024. Der Zweig prüfte früher auf genau 1024 und ließ alles zwischen 1025 und 2047 durchgehen; info, wenn ein RSA-Schlüssel länger als 4096 Bit ist — §3.2 verpflichtet Verifizierer auf 1024 bis 4096 Bit und stellt alles darüber frei („MAY“), ein überlanger Schlüssel ist also ein Interoperabilitätsrisiko und kein Mangel; warn, wenn ein Selektor einen Schlüsseltyp veröffentlicht, den die IANA-Registry „DKIM Key Type“ nicht führt – dort stehen heute genau zwei Einträge, rsa (registriert von RFC 6376 §7.6, wofür die Registry inzwischen RFC 8017 nennt) und ed25519 (ergänzt von RFC 8463 §8.1) – UND sein p= weder ein RSA- noch ein Ed25519-Schlüssel ist: Nach §3.6.1 ignorieren Verifizierer einen unbekannten Typ, es gilt der rsa-Default, das Material passt nicht dazu, und nach §6.1.2 Punkt 8 scheitert dann jede Signatur dieses Selektors; info, wenn alle gefundenen Selektoren widerrufen sind (es gibt keine Schlüssellänge zu bewerten, und das ist die Erklärung der Domain selbst und keine Messlücke); info, außerhalb der Bewertung, wenn für keinen Selektor eine Schlüssellänge ermittelbar war – das IST eine Lücke unserer Messung, keine Aussage über Ihren Schlüssel; sonst pass. Gewicht 1. Widerrufene Selektoren (leeres p=) entscheiden den Status nicht – sie bewertet DKIM-Schlüssel auffindbar –, erscheinen aber weiterhin im Wert.
BehebungDen DKIM-Schlüssel auf RSA-2048 (oder Ed25519) erneuern. Bei Microsoft 365 / Exchange Online werden DKIM-Schlüssel standardmäßig noch mit 1024 Bit erstellt, bestehende Selektoren (selector1/selector2) müssen daher in der Regel manuell umgestellt werden: in der Exchange Online PowerShell Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048 ausführen (die -Identity ist der Domainname, keine GUID). Der neue Schlüssel signiert erst nach ~4 Tagen (96 h) – bis dahin signiert der alte 1024-Bit-Schlüssel weiter – danach also erneut testen. Rechnen Sie mit zwei Rotationen statt einer: Laut Microsoft wirkt die geänderte Schlüssellänge bei der ersten Rotation nur auf den nächsten aktiven Selektor, der andere erreicht 2048 Bit erst bei der folgenden; eine bereits laufende Rotation blockiert die nächste. Weil dieser Check den kürzesten gefundenen RSA-Schlüssel bewertet, bleibt die Warnung stehen, bis kein Schlüssel mehr bei 1024 Bit liegt. Mit Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1KeySize,Selector2KeySize,RotateOnDate verifizieren. Der Button Rotate DKIM keys im Defender-Portal behält die aktuelle Schlüssellänge bei, das Upgrade auf 2048 Bit erfordert daher PowerShell.
DKIM-Schlüsselattribute #
t=y kennzeichnet einen Testschlüssel: RFC 6376 §3.6.1 – „Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify.“ Die Signatur schützt die Domain damit nicht vor Missbrauch. Das h=-Tag ist eine Liste zulässiger Hash-Algorithmen, und ein fehlendes h= erlaubt alle; nur eine Liste, die sha1 nennt und keinen aktuellen Algorithmus, legt den Schlüssel auf einen Hash fest, den RFC 8301 §3.1 zurückgezogen hat („rsa-sha1 MUST NOT be used for signing or verifying“, und die IANA führt sha1 als historic). h=sha1:sha256 erlaubt weiterhin sha256 und wird nicht bemängelt.
Bewertungwarn (Gewicht 1), und die Zeile erscheint nur, wenn eines von dreien zutrifft: ein t=y-Testflag, eine h=-Liste, die sha1 erlaubt und nichts Aktuelles, oder eine h=-Liste, die überhaupt keinen brauchbaren Hash nennt (die beiden h=-Zustände sind disjunkt — eine Liste aus unbekannten Namen ist der zweite, nie der erste). Es bleibt ein warn und kein fail, weil der Record allein nicht belegt, dass der Selektor benutzt wird: Diese Prüfung liest den SCHLÜSSEL-Record, und ein über eine Kandidatenliste gefundener Selektor kann veraltet oder ungenutzt sein. Wird er BENUTZT, steht die Folge außer Frage — nach RFC 6376 §6.1.2 Schritt 6 gibt ein Verifizierer PERMFAIL zurück für jede Signatur, deren Hash das h=-Tag nicht führt. Der Wert nennt die betroffenen Selektoren.
BehebungDas Test-Flag t=y entfernen; die h=-Einschränkung streichen oder sha256 mit aufnehmen und mit a=rsa-sha256 signieren.
BIMI (Markenlogo) #
BIMI zeigt das Markenlogo (und mit VMC ein verifiziertes Badge) im Posteingang an – ein Vertrauenssignal, das nur mit einer durchgesetzten DMARC-Policy funktioniert: p=quarantine/reject und sp nicht none gemäß BIMI-Entwurf (Revision 14) §7.1, und – dem Implementierungsleitfaden der BIMI Group folgend – kein pct unter 100. Bei p=none wird das Logo nie angezeigt. Dieser Check wertet zusätzlich t=y als Blocker: Nach RFC 9989 §4.7 BITTET der Domain-Inhaber damit darum, dass Empfänger die Policy eine Stufe unter der veröffentlichten anwenden, quarantine mit t=y wirkt also erwartungsgemäß wie none, und bei none verbietet der Entwurf BIMI. Der Entwurf ist durchgehend gegen RFC 7489 geschrieben und erwähnt dieses Tag nirgends – dass wir es als Blocker werten, ist unsere Lesart und keine Vorgabe der Spezifikation. Existiert ein Record mit Logo, validiert der Check ihn wie ein Mail-Anbieter: Das SVG wird abgerufen (SVG-Tiny-PS-Profil, kein aktiver Inhalt), das Mark-Zertifikat (a=) wird verifiziert – BIMI-Kennzeichnung, Gültigkeitszeitraum und eine Zertifikatskette, die bei einer der von der BIMI Group gelisteten Mark Verifying Authorities endet (DigiCert, GlobalSign, SSL.com) – zentral zertifiziert wird dabei niemand, die BIMI Group schreibt, sie „does not certify an MVA to issue certificates for BIMI“, und überlässt die Anerkennung jedem Mailbox-Anbieter, geprüft wird also gegen die veröffentlichte Liste, mit der auch die Anbieter arbeiten – und das ausgelieferte Logo muss dem Bild entsprechen, das die CA im Zertifikat hinterlegt hat (RFC-9399-Logotype, früher RFC 3709). Über avp=personal kann ein Record Provider außerdem bitten, den persönlichen Avatar des Absenders dem Logo vorzuziehen – der Check zeigt diese Präferenz an. Wird nur angezeigt, wenn ein BIMI-Record existiert.
Bewertungfail, wenn der Record überhaupt nichts anzeigen kann, egal was sonst stimmt: mehr als ein v=BIMI1-Record unter default._bimi, ein Record ohne l=-Tag, eine l=-URL, die nicht https ist (der einzige vom Entwurf unterstützte Transport für das Logo), oder ein leeres l= neben einem veröffentlichten Mark-Zertifikat – das ist kein Opt-out, sondern ein defekter Record, denn die Indicator Discovery scheitert dann (§7.3), oder ein Versions-Tag, das nicht exakt v=BIMI1 lautet — Schreibweisen-Fehler dürfen Empfänger nach §4.3 nicht korrigieren. info bei einem bewussten Verzicht, also einem leeren l= mit leerem oder fehlendem a= (§4.3.1/§7.5): Ein ausdrücklicher Opt-out ist eine gültige Konfiguration und wird nie wegen DMARC abgewertet. skip, wenn schon die DNS-Abfrage fehlschlug. warn bei einem Record, der funktionieren KÖNNTE, aber nicht verifiziert: Logo nicht abrufbar, SVG mit aktivem Inhalt, Logo nicht im SVG-Tiny-PS-Profil, kein Mark-Zertifikat (a=), a= nicht https oder nicht abrufbar, Zertifikat unlesbar/abgelaufen/ohne Kette zu einer gelisteten Mark Verifying Authority/ohne BIMI-Kennzeichnung, ein ausgeliefertes Logo, das vom Bild im Zertifikat abweicht, oder ein ungültiger avp=-Wert: Der Entwurf lässt Empfänger den Wert selbst ignorieren, erlaubt einem Mailbox-Anbieter in §4.3 aber auch, eine ungültige Präferenz als fehlgeschlagenen Record zu behandeln — dann erscheint das Logo gar nicht. info, wenn Logo und Zertifikat im Scan nicht abrufbar waren: Zehn der vierzehn Prüfungen darunter hängen an diesem Abruf, die Zeile sagt dann, dass nur der Record selbst geprüft wurde — eine Grenze dieses Laufs, keine Aussage über die Konfiguration. good nur, wenn all das verifiziert. Ist BIMI gesetzt, DMARC aber nicht durchgesetzt, wird diese Aussage an das ANGEHÄNGT, was die Zeile bereits gefunden hat – sie ersetzt die eigene Diagnose nie – und sie hebt das Gewicht NICHT an: Die Tatsache, die sie meldet (DMARC wird nicht durchgesetzt), bewertet bereits die DMARC-Policy-Zeile mit Gewicht 3, und sie ein zweites Mal zu buchen bedeutete, dass eine Domain mit tadellosem BIMI-Record und gültigem Mark-Zertifikat schlechter abschnitt als eine sonst gleiche Domain ganz ohne BIMI. Jeder Ausgang trägt Gewicht 0: Ein Logo ist Kosmetik, keine Sicherheit; diese Zeile prägt also den Text des Berichts, nicht die Modulnote. Der Drilldown nennt den Record, der geantwortet hat – mit einem Vermerk, wenn er von der Organisationsdomain geerbt statt vom abgefragten Namen veröffentlicht wurde –, und das Ergebnis der Logo-Prüfung. Die Prüfung des Mark-Zertifikats und die Bindung des Logos an das Zertifikat erscheinen nur bei einem Record mit a=-Tag: Ohne dieses Tag gibt es kein Zertifikat abzurufen, und zwei leere Zeilen legten eine Prüfung nahe, die nie stattgefunden hat.
BehebungEinen BIMI-Record default._bimi mit SVG-Tiny-PS-Logo (l=) und einem VMC/CMC einer von der BIMI Group gelisteten Mark Verifying Authority (a=) veröffentlichen; exakt die zertifizierte Logo-Datei ausliefern und zuvor DMARC auf quarantine/reject bringen, ohne t=y und ohne sp=none; ein noch vorhandenes pct-Tag entfernen. Beim pct widersprechen sich die Quellen: Der BIMI-Entwurf (Revision 14) verlangt pct=100 nur bei p=quarantine und akzeptiert p=reject „mit jedem Prozentwert“ (im Original: „with any percentage value“), während der Implementierungsleitfaden der BIMI Group ein pct unter 100 gar nicht akzeptiert („‘None’ policies or ‘pct’ less than 100 percent are not accepted“). Dieser Check folgt der strengeren Anforderung. Das Tag zu entfernen ist die Lösung, und zwar in dieser Reihenfolge: Empfänger auf aktuellem Stand ignorieren es bereits, Empfänger auf RFC-7489-Stand wenden die Policy aber nur auf einen Teil der Mail an — vor dem Löschen also jeden Versandweg ausrichten.
BIMI-Logo über IPv4/IPv6 #
Der BIMI-Entwurf erlaubt für das in l= genannte Logo genau einen Transport: „The only supported transport is HTTPS“ (§4.3). Jeder Mail-Anbieter, der Ihr Logo anzeigt, ruft diese Datei selbst ab. Dieser Scan holt sie deshalb zweimal – einmal über IPv4, einmal über IPv6, jede Anfrage auf eine Adresse festgenagelt – statt das Betriebssystem wählen zu lassen: Ein einzelner Abruf würde für einen Host, der genau über eine Familie kaputt ist, „funktioniert“ melden und den Defekt verdecken, den die Prüfung finden soll. Ein nur über IPv6 ausgeliefertes Logo verifiziert einwandfrei und erscheint bei keinem reinen IPv4-Anbieter je – das kann keine DNS-Prüfung zeigen. Diese Zeile geht um die Erreichbarkeit der Logo-Datei; über den Record selbst und das Mark-Zertifikat urteilt BIMI darüber.
BewertungErscheint nur, wenn die l=-URL https ist und es wirklich etwas zu sagen gibt. warn, wenn der Logo-Host nur einen AAAA-Record veröffentlicht; warn, wenn er beide Familien veröffentlicht, eine die Datei aber nicht ausliefert – die Zeile unterscheidet eine Familie, die mit einem Status außerhalb 2xx geantwortet hat, von einer, die gar nicht geantwortet hat; warn, wenn beide Familien unterschiedlichen Inhalt liefern, was sich nach einem gefolgten Redirect nicht mehr feststellen lässt. skip („nicht prüfbar“), wenn dieser Scanner selbst keine Route zu einer Familie hat oder sein HTTP-Client die Antwort als fehlerhaft verworfen hat – beides ist nie eine Aussage über Ihren Host. Gewicht 0 in jedem Fall, und zwar aus demselben Grund wie beim BIMI-Befund selbst: Ein Logo ist Kosmetik, keine Sicherheit. Bewusst NICHT der Grund des MTA-STS-Zwillings — der tritt zurück, weil sein Elternbefund dieselbe Messung benotet; der BIMI-Befund misst die Adressfamilie dagegen gar nicht, diese Zeile ist also die einzige Stelle, an der ein IPv6-only-Logo-Host überhaupt sichtbar wird. Gar nichts erscheint bei einem funktionierenden Dual-Stack-Host, im gewöhnlichen IPv4-only-Fall und wenn gar keine Adresse geprobt werden konnte – was auch den Fall abdeckt, dass unsere eigene Adressabfrage fehlschlug. Geholt wird je Familie nur die erste öffentliche Adresse.
BehebungFür den Logo-Host zusätzlich zum AAAA- einen A-Record veröffentlichen oder das Logo von einem Dual-Stack-Host ausliefern; antworten beide Familien unterschiedlich, ist ein Origin veraltet – die Datei muss byte-identisch sein, denn das Mark-Zertifikat bindet den Hash genau eines Bildes. Sagt die Zeile „nicht prüfbar“, gibt es nichts zu beheben.
Null MX (RFC 7505) #
Ein MX 0 . signalisiert explizit, dass die Domain keine E-Mail empfängt – korrekt für Web-only-/geparkte Domains und verhindert Zustellversuche.
BewertungDie Zeile erscheint, sobald die MX-RRset keinen nutzbaren Mail-Host nennt. pass, wenn ein MX 0 . der EINZIGE Record ist – das ist die korrekte Form. warn in drei Ausprägungen, jeweils Gewicht 1: ein MX 0 . neben regulären MX-Records (RFC 7505 §3: „A domain that advertises a null MX MUST NOT advertise any other MX RR“), ein MX 0 . neben einem zweiten Record mit Ziel DNS-Wurzel – entweder mit einer anderen Priorität als 0 oder als doppelter MX 0 . – und ein solches fehlerhaftes Root-Ziel allein. Die Folgen unterscheiden sich: Nur in der ersten Ausprägung hat die Domain noch einen Mail-Host, MTA-STS, TLS-RPT und DKIM werden dort wie für eine empfangende Domain bewertet; in den anderen beiden kann nichts zugestellt werden, MTA-STS und TLS-RPT entfallen ohne Gewicht, und nur DKIM bleibt bewertet.
BehebungFür Domains, die weder senden noch empfangen, MX 0 . plus v=spf1 -all und DMARC p=reject setzen. Vor dem Zwischenfall warnt RFC 7505 §4.2 ausdrücklich: Eine Domain, die ihren Namen weiterhin in RFC5321.MailFrom- oder RFC5322.From-Adressen verwendet, sollte gar keinen Null MX veröffentlichen, weil sie riskiert, dass ihre Mail wegen der unzustellbaren Rückadresse abgewiesen wird – versendet die Domain also noch, ist das nicht die richtige Konfiguration für sie. Beim DKIM gehen die Quellen auseinander: Der unten verlinkte M3AAWG-BCP rät für eine geparkte Domain dazu, gar keinen DKIM-Record zu veröffentlichen, weil ein fehlender öffentlicher Schlüssel jede gefälschte Signatur bereits scheitern lässt; hat die Domain früher einmal signiert, spricht ein Wildcard-Widerruf *._domainkey → v=DKIM1; p= den Widerruf ausdrücklich aus (RFC 6376 §3.6.1: ein leeres p= bedeutet „Schlüssel widerrufen“). Eine Wildcard antwortet nur für Selektornamen, die keinen eigenen Record haben.
E-Mail-Anbieter #
Die MX-Records verraten, welche Plattform die Mail der Domain empfängt. Bei einem gehosteten Mailbox-Anbieter (Google Workspace, Microsoft 365, Zoho …) versendet dieselbe Plattform meist auch die Mail der Domain, daher ist der erkannte Anbieter ein starker Hinweis – aber nur ein Hinweis – auf den ausgehenden Absender. Vorgelagerte Security-Gateways (Mimecast, Proofpoint …) stehen vor der Mailbox; ihr MX-Eintrag belegt nicht, wer die Mail der Domain versendet — viele dieser Anbieter relayen auch ausgehend, andere Kunden setzen sie nur eingehend ein. Ein Gateway wird deshalb nicht als Absender gewertet.
BewertungRein informativ – Status info mit Gewicht 0, wirkt sich also nie auf die Note aus und deckelt sie nie. Der Anbieter wird anhand der MX-Hostnamen gegen eine gepflegte Liste erkannt; die Zuordnung stammt von uns, keine Norm definiert sie. Unterschieden werden vier Plattformarten; treffen mehrere zu, gewinnt das stärkste Signal für den Absender: Ein gehosteter Mailbox-Anbieter oder Freemail-Anbieter versendet meist auch die Mail der Domain; ein E-Mail-Versanddienst (ESP) taucht im MX auf, wenn eine dedizierte Versand- oder Newsletter-(Sub-)Domain Bounces und Antworten dorthin leitet, und ist für diesen Namen dann ein Absender; ein vorgelagertes Security-Gateway steht vor der Mailbox und sagt nichts über den Absender. Für die Arten, die selbst versenden, vergleicht das Finding den vom Anbieter dokumentierten Ausgangs-include: mit dem veröffentlichten SPF-Record und schlägt vor, ihn zu ergänzen, wenn er fehlt. Bei Anbietern mit austauschbaren regionalen Includes genügt einer davon. Die beiden Quellen unten nennen in ihren eigenen Bezeichnungen, welchen Teil davon sie abdecken; die Anbieterliste selbst trägt keine, weil es keine Norm gibt, auf die sich verweisen ließe.
BehebungFalls der erkannte Anbieter Mail für die Domain versendet, prüfen, ob sein dokumentierter SPF-include: im v=spf1-Record steht, und ihn andernfalls ergänzen – bietet der Anbieter austauschbare regionale Includes an, genügt einer davon. Weitere Absender (Newsletter, CRM, Transaktions-/ESP) sind in den MX-Records nicht sichtbar und müssen separat in SPF aufgenommen werden.
MTA-STS #
MTA-STS erzwingt TLS für die Mail-Zustellung und schützt vor Downgrade-/MITM-Angriffen. Geprüft werden der TXT-Record (inkl. des Pflichtfelds id= gemäß RFC 8461 §3.1), die Policy-Datei, mode, max_age – §3.2 setzt genau eine harte Obergrenze von 31557600 Sekunden (rund ein Jahr) und erwartet den Wert „typically ... in the range of weeks or greater“, weshalb hier alles unter einer Woche (604800 s) als zu kurz gilt: Das ist die Untergrenze dieses Checks, keine Zahl aus dem RFC – sowie, ob die mx-Einträge zu den tatsächlichen MX passen. Die Feldnamen und die Werte von version/mode werden dabei mit exakter Groß-/Kleinschreibung verglichen, so wie §3.2 sie schreibt.
BewertungWird nur bewertet, wenn die Domain einen MX hat: Ohne MX entfällt die Zeile mit Gewicht 0, und eine fehlgeschlagene MX-Abfrage wird als nicht prüfbar gemeldet, nicht als „kein MX“. Eine fehlgeschlagene _mta-sts-Abfrage gilt ebenso als nicht prüfbar, nicht als fehlender Record. fail bei mehr als einem v=STSv1-TXT-Record – Absender verhalten sich dann, als gäbe es keine Policy, und die Policy selbst wird nicht weiter geprüft. Sonst pass nur bei mode: enforce mit einer Policy, die eine gültige version: STSv1-Zeile trägt, einen mx-Satz hat, der jeden realen MX-Host abdeckt, ein max_age als reine Ziffernfolge nennt, und einem TXT-Record mit dem Pflichtfeld id=. Alles darunter ist warn: mode: testing oder mode: none, eine Policy ganz ohne mx-Zeile, AUSSER der Modus ist none — die ABNF in §3.2 verlangt mx „at least once, except when mode is ‘none’“, und §8.3 empfiehlt genau eine solche Policy für den Ausstieg; bei enforce und testing passt sie auf keinen Ihrer Hosts, Absender, die sie befolgen, können also nicht zustellen —, ein mx-Satz, der einen realen MX auslässt, ein fehlendes oder nicht rein numerisches max_age, ein max_age über den erlaubten 31557600 (die einzige Grenze, die RFC 8461 §3.2 nennt) oder unter einer Woche — 604800 Sekunden, eine Schwelle dieses Scanners, denn §3.2 nennt kein Minimum und erwartet lediglich Werte „in the range of weeks or greater“ —, eine fehlende version: STSv1-Zeile, ein Feldname oder ein version-/mode-Wert in falscher Groß-/Kleinschreibung (§3.2 definiert sie case-sensitiv, ein strenger Absender liest sie deshalb als unbekannte Felder), ein id=, das fehlt, als ID= geschrieben ist oder außerhalb der Grammatik 1*32(ALPHA / DIGIT) liegt, die RFC 8461 §3.1 dafür definiert — ein solcher Record ist syntaktisch ungültig, und §3.1 lässt Absender dann annehmen, die Domain habe überhaupt keine verfügbare Policy —, eine Policy-Datei mit einem anderen Medientyp als text/plain (§3.2 hält Absender an, ihn zu prüfen; Parameter wie charset werden ignoriert, ein fehlender Header sagt nichts), eine mx-Zeile, die kein ["*."] Domain ist und deshalb auf nichts passt, ein nur über IPv6 erreichbarer Policy-Host und eine nicht abrufbare Policy-Datei. fail zusätzlich, wenn der mx-Satz KEINEN der realen MX-Hosts abdeckt und der Modus enforce lautet: §5 sagt einem sendenden MTA, er „MUST NOT deliver the message to hosts that fail MX matching“, und §5.1 Schritt 2 geht nur dann zum nächsten Kandidaten, „if there is one“ — es bleibt also nichts übrig, wohin zugestellt werden könnte; das deckelt die Modulnote auf C. Teilweise Abdeckung bleibt warn, denn die abgedeckten Hosts empfangen weiterhin Mail. skip mit Gewicht 0, wenn die Policy-Datei größer ist als die 64 KB, die dieser Scanner herunterlädt: Ein abgeschnittener Body würde unsere eigene Grenze in fehlende mx- oder max_age-Zeilen verwandeln und sie als Ihre Konfiguration melden. Eine nicht abrufbare Policy nennt ihre Ursache: ein Host, der nur auf private/interne Adressen auflöst, gar keine A/AAAA-Records, ein HTTP-Status ungleich 200, ein Redirect (RFC 8461 §3.3 erlaubt nur 200 und verbietet Redirects), ein Timeout oder ein Host, der im öffentlichen DNS private und öffentliche Adressen mischt. Fehlt → warn. Gewicht 2.
BehebungTXT _mta-sts + eine Policy unter https://mta-sts.<domain>/.well-known/mta-sts.txt mit mode: enforce, korrekten mx-Zeilen und max_age ≥ 604800 veröffentlichen.
MTA-STS-Policy über IPv4/IPv6 #
Ein sendender MTA kann nur die Policy anwenden, die er auch abrufen kann – und RFC 8461 §3.3 sagt, was sonst passiert: „If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.“ Ein Policy-Host, der nur über eine Adressfamilie erreichbar ist, schwächt MTA-STS für die Absender der anderen Familie also nicht – er schaltet es für sie ab, stillschweigend, während der TXT-Record es weiterhin ankündigt. Dieser Scan holt die Policy über jede veröffentlichte Familie getrennt, jede Anfrage auf eine Adresse festgenagelt, statt das Betriebssystem wählen zu lassen: Ein einzelner Abruf würde ausgerechnet für den halb kaputten Host „funktioniert“ melden und damit den Defekt verdecken, den die Prüfung finden soll.
BewertungErscheint nur, wenn ein _mta-sts-TXT-Record existiert und es etwas zu berichten gibt. warn, wenn der Policy-Host nur einen AAAA-Record veröffentlicht; warn, wenn beide Familien veröffentlicht sind, eine die Policy aber nicht ausliefert – die Zeile unterscheidet eine Familie, die mit einem Status außerhalb 2xx geantwortet hat, von einer, die gar nicht geantwortet hat; warn, wenn beide Familien antworten, aber mit unterschiedlichem Policy-Text, denn welche Familie ein Absender wählt, kontrollieren Sie nicht. skip („nicht prüfbar“), wenn dieser Scanner keine Route zu einer Familie hat — oder wenn die Familie geantwortet hat und der HTTP-Client dieses Scanners die Antwort als fehlerhaft verworfen hat: Das ist unsere Einschränkung und nie eine Aussage über Ihren Host. Gewicht 1 in den warn-Fällen – die Hälfte des MTA-STS-Findings selbst, weil eine fehlende Familie eingrenzt, WER die Policy anwenden kann, statt sie zu entfernen – und Gewicht 0 bei skip. Gewicht 0 auch dann, wenn die Zeile MTA-STS darüber denselben IPv6-only-Host bereits abgewertet hat: Eine Tatsache wird einmal berechnet, und diese Zeile bleibt als Erklärung sichtbar. Gar nichts erscheint bei einem funktionierenden Dual-Stack-Host, im gewöhnlichen IPv4-only-Fall und wenn gar keine Adresse geprobt werden konnte – was auch unsere eigene fehlgeschlagene Auflösung abdeckt. Geholt wird je Familie nur die erste öffentliche Adresse.
BehebungFür mta-sts.<domain> zusätzlich zum AAAA- einen A-Record veröffentlichen oder die Policy von einem Dual-Stack-Host ausliefern – und sicherstellen, dass beide Origins byte-identischen Policy-Text zurückgeben. Sagt die Zeile „nicht prüfbar“, gibt es auf Ihrer Seite nichts zu beheben.
TLS-RPT (SMTP TLS Reporting) #
TLS-RPT liefert tägliche Reports über TLS-Zustellversuche, erfolgreiche wie fehlgeschlagene – wichtig, um MTA-STS-/DANE-Probleme zu bemerken, bevor sie Mail kosten.
BewertungWird bewertet, sobald dieser Domain Mail zugestellt wird – und das ist nicht dasselbe wie „hat einen MX-Record“. Bei leerer MX-RRset und vorhandenem Adress-Record behandelt RFC 5321 §5.1 die Domain selbst als Mail-Exchanger, und RFC 8460 knüpft die Reporting-Policy an gar keinen MX; die Zeile wird dort also mitbewertet, und der Haupt-Scan probt denselben Host an anderer Stelle desselben Berichts — es sei denn, jede seiner Adressen liegt in einem CDN-Edge-Netz; dann wird auf Port 25 überhaupt keine Verbindung versucht, und das Finding „Mailserver vorhanden“ sagt das. Ohne Gewicht entfällt sie nur, wenn nichts zugestellt werden kann (kein MX und kein Adress-Record, oder eine MX-RRset, die keinen Mail-Host nennt); eine fehlgeschlagene Abfrage wird als nicht prüfbar gemeldet. Dann: pass, wenn ein v=TLSRPTv1-Record existiert UND sein rua= ein brauchbares Ziel nennt – RFC 8460 §3 unterstützt genau zwei URI-Schemata, mailto: und https:, das rua-Feld ist Pflicht, und ein mailto: braucht eine vollständige Adresse. fail, wenn der Record existiert, aber ein unbrauchbares rua= trägt — er wirkt eingerichtet und meldet nichts, was schlechter ist als gar keiner; warn, wenn der Record ganz ohne rua= existiert (RFC 8460 §3 macht das Feld zur Pflicht, und das Record Studio bewertet diesen Fall mit fail — der Scan ist hier die mildere der beiden Oberflächen), und warn, wenn kein Record existiert. Eine rua=-Liste mit einem brauchbaren und einem kaputten Ziel bleibt pass – Berichte kommen an –, aber der kaputte Eintrag wird benannt: Es ist die Adresse, die der Betreiber eingetragen hat, weil er dort Berichte wollte. warn, wenn das Versions-Tag nicht exakt v=TLSRPTv1 lautet (§3 verlangt den Wert exakt als TLSRPTv1 und definiert ihn in der ABNF als Groß-/Kleinschreibung-genaues Literal (%s"v=TLSRPTv1", RFC 7405); der Record ist damit keine gültige TLS-RPT-Policy, und ein Absender, der §3 folgt, findet für die Domain keine Reporting-Policy — dasselbe Ergebnis wie ohne Record, daher dieselbe Note, aber die Zeile nennt die Ursache statt „nicht vorhanden“ zu sagen). fail bei mehr als einem v=TLSRPTv1-Record: §3 hält Absender an, dann anzunehmen, „the recipient domain does not implement TLSRPT“ – es werden also gar keine Reports zugestellt. Gewicht 1.
BehebungEinen TXT-Record _smtp._tls mit v=TLSRPTv1; rua=mailto:… veröffentlichen (ein https://-Endpunkt geht ebenfalls, RFC 8460 §3). Für den mailto-Weg gilt: §3 verlangt, dass per SMTP versandte Reports eine gültige DKIM-Signatur der berichtenden Domain tragen – Reports ohne eine solche müssen Empfänger ignorieren.