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: Juli 2026 · 23 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): Beginnt die Eingabe mit www., wird genau dieses Label entfernt und die übergeordnete Domain bewertet. Andere Subdomains werden NICHT umgeschrieben – sie können legitim eine eigene Mail-Identität betreiben und erhalten stattdessen die hostspezifische Bewertung.
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, wenn genau ein v=spf1-Record existiert; sonst fail (Gewicht 2). Ausnahme: Ein Hostname ohne MX (z. B. www.) erhält nur ein warn (Gewicht 1) – die Sende-Policy liegt bei der Organisationsdomain; v=spf1 -all auf dem Host ist optionale HELO-Härtung.
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-Standardverhalten (all) #
Der abschließende all-Mechanismus bestimmt, wie mit nicht autorisierten Absendern umgegangen wird. +all ist gefährlich; für sendende Domains ist ~all (Softfail) oft robuster als -all (Weiterleitungen), geparkte Domains sollten -all verwenden.
Bewertungpass mit -all oder ~all (kontextabhängig); warn bei ?all/fehlendem all; +all → fail + Cap C (SPF erlaubt jeden Absender). Gewicht 2.
BehebungSendende Domain: ~all oder -all (mit DMARC) verwenden. Geparkte Domain: -all. Niemals +all.
Genau ein SPF-Record #
Mehrere v=spf1-Records führen laut RFC 7208 zu einem PermError – SPF schlägt dann vollständig fehl.
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 ptr verwendet wird. Gewicht 1.
BehebungDen ptr-Mechanismus aus dem SPF-Record entfernen.
SPF-DNS-Lookups (Limit 10) #
SPF erlaubt maximal 10 DNS-Lookups (include, a, mx, exists, redirect). Werden mehr benötigt, tritt ein PermError auf und SPF gilt als nicht bestanden.
Bewertungpass bei ≤ 10 Lookups; fail darüber. Gewicht 1.
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 keinen SPF-Record hat (Gewicht 2). Ziele mit %-Makros können nicht geprüft werden und werden übersprungen.
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. Hat der geprüfte Name selbst keinen Record, fragen Empfänger bis zu acht immer kürzere Namen bis hinunter zur TLD ab (DNS Tree Walk, RFC 9989 §4.10; psd=-Tags steuern, wo die Organisationsdomain liegt) und eine geerbte Policy zählt. Der v-Wert ist case-sensitiv – ein Record wie v=dmarc1 wird komplett 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 beobachtet nur, schützt aber nicht (RFC 9989 nennt das „Monitoring Mode“). Nur p=quarantine (Spam) oder p=reject (Abweisung) erreichen Enforcement und verhindern Spoofing. Ein fehlendes p zählt als p=none (implizites Default); ein Record mit ungültigem 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 (RFC 9989 §4.10.1).
Bewertungpass mit reject; warn mit quarantine; none (explizit, implizit oder als §4.10.1-Rückfall) → fail + Cap C; ein unwirksamer Record (ungültige Werte, kein rua) → fail + Cap C. Gewicht 3.
BehebungStufenweise gemäß RFC 9989 §7.4 anheben: rund einen Monat p=none mit Reports, ähnlich lange p=quarantine, dann p=reject. Domains mit p=reject dürfen sich nicht allein auf SPF verlassen – ausgehende Mails mit DKIM signieren (§7.4/§8); Domains, deren Nutzer über Mailinglisten posten, sollten p=reject sorgfältig abwägen.
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 Legacy-Empfänger die Policy nur auf einen Teil der Mails an. Das Tag wurde in RFC 9989 (DMARCbis) entfernt – aktuelle Empfänger ignorieren es vollständig, es erzeugt also nur inkonsistentes Verhalten zwischen alten und neuen Empfängern.
BewertungWird nur bewertet, wenn das Tag vorhanden ist: pass bei 100 %; sonst warn. Gewicht 1.
Behebungpct auf 100 erhöhen und das Tag anschließend entfernen (seit RFC 9989 obsolet). Ein bewusstes pct=0 stattdessen durch t=y ersetzen – RFC 9989 (App. A.6) benennt es als Nachfolger.
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 bestimmt – Geschwister-Subdomains 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).
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 <your-domain>._report._dmarc.<target> mit v=DMARC1 veröffentlichen.
Subdomain-Policy (sp=/np=) #
Ein schwaches sp (z. B. none) untergräbt ein starkes p: Subdomains lassen sich dann weiterhin spoofen. RFC 9989 definiert zusätzlich np= für nicht existierende Subdomains – wertvoll, weil Spoofer gern Hosts wie invoice.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).
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 entfernen (sie erben dann p) oder auf mindestens quarantine/reject setzen – und im Record der Organisationsdomain veröffentlichen.
DMARC-Record-Syntax #
Über die Policy hinaus hat RFC 9989 das Record-Format verschärft: Doppelte Tags machen das Empfängerverhalten undefiniert (strikte Empfänger verwerfen den ganzen Record, RFC 6376 §3.2), fo= hat harte Regeln (0 und 1 schließen sich aus, d/s höchstens einmal, ohne ruf komplett ignoriert), ungültige Tag-Werte fallen stillschweigend auf ihre Defaults zurück, und die Tags ri=/rf= sowie das !size-URI-Suffix wurden aus dem Standard entfernt (historic).
BewertungErscheint nur, wenn etwas auffällt: warn bei doppelten Tags oder kaputten fo=-Werten, info bei entfernten/ignorierten Legacy-Tags und Werten, die auf Defaults zurückfallen. Gewicht 0–1.
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 über bekannte Selektoren ein Schlüssel gefunden wird; sonst warn (der Selektor kann abweichen). 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 + SPF ohne erlaubte Absender): Eine Domain, die nie sendet, braucht keine Signaturschlüssel.
BehebungDKIM beim Mail-Provider aktivieren und den veröffentlichten Selektor im DNS hinterlegen.
DKIM-Schlüssellänge #
Zu kurze DKIM-Schlüssel (RSA < 1024) sind brechbar. Empfohlen: RSA ≥ 2048 oder Ed25519.
Bewertungpass > 1024 (2048 empfohlen); warn bei 1024; fail < 1024. Gewicht 1.
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. 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 (Empfänger ignorieren Fehler → kein Schutz); h=sha1 ist kryptografisch schwach.
Bewertungwarn bei Test-Flag oder SHA-1. Gewicht 1.
BehebungDas Test-Flag t=y entfernen und SHA-256 verwenden (a=rsa-sha256).
BIMI (Markenlogo) #
BIMI zeigt das Markenlogo (und mit VMC ein verifiziertes Badge) im Posteingang an – ein Vertrauenssignal, das nur mit einer durchgesetzten DMARC-Policy (p=quarantine/reject, pct=100, sp nicht none) funktioniert. Bei p=none wird das Logo nie angezeigt. 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 BIMI-autorisierten CA (DigiCert, GlobalSign, SSL.com) endet – und das ausgelieferte Logo muss dem Bild entsprechen, das die CA im Zertifikat hinterlegt hat (RFC-3709-Logotype). Ü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.
Bewertunggood nur, wenn Logo und Mark-Zertifikat vollständig verifizieren; warn, wenn das Logo kein SVG Tiny PS ist, das VMC fehlt/abgelaufen/nicht von einer autorisierten CA ist oder das ausgelieferte Logo nicht zum Zertifikat passt; warn (Gewicht 1), wenn BIMI gesetzt ist, DMARC aber nicht durchgesetzt wird – der Record ist dann wirkungslos. Sonst informativ (Gewicht 0).
BehebungEinen BIMI-Record default._bimi mit SVG-Tiny-PS-Logo (l=) und einem VMC/CMC einer BIMI-autorisierten CA (a=) veröffentlichen; exakt die zertifizierte Logo-Datei ausliefern und zuvor DMARC auf quarantine/reject mit pct=100 bringen.
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.
Bewertungpass, wenn Null MX korrekt gesetzt ist. Gewicht 1.
BehebungFür nicht empfangende Domains MX 0 . plus v=spf1 -all und DMARC p=reject setzen.
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 und verraten den Absender nicht, werden daher nicht als solcher gewertet.
BewertungRein informativ – wirkt sich nie auf die Note aus. Wird ein gehosteter Anbieter erkannt und fehlt sein dokumentierter include: für ausgehende Mail im veröffentlichten SPF-Record, schlägt ein Hinweis vor, ihn zu ergänzen.
BehebungFalls der erkannte Anbieter Mail für die Domain versendet, sollte sein dokumentierter SPF-include: im v=spf1-Record stehen. Weitere Absender (Newsletter, CRM, Transaktions-/ESP) sind in MX nicht sichtbar und müssen separat ins SPF aufgenommen werden.
MTA-STS #
MTA-STS erzwingt TLS für die Mailzustellung 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 (1 Woche … max. 1 Jahr gemäß §3.2) sowie ob die mx-Einträge zu den tatsächlichen MX passen.
Bewertungpass bei mode: enforce mit passenden MX und ausreichendem max_age; warn bei testing/none, MX-Mismatch, fehlendem id=, max_age außerhalb 604800–31557600 oder einem nur über IPv6 erreichbaren Policy-Host (reine IPv4-Absender können die Policy nicht abrufen). Eine nicht abrufbare Policy-Datei ist warn und nennt die Ursache: einen Policy-Host, der nur auf private/interne Adressen auflöst, fehlende A/AAAA-Records, einen HTTP-Status ungleich 200 oder einen Redirect (RFC 8461 §3.3 erlaubt nur 200 und verbietet Redirects). 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.
TLS-RPT (SMTP TLS Reporting) #
TLS-RPT liefert tägliche Reports über fehlgeschlagene TLS-Zustellungen – wichtig, um MTA-STS-/DANE-Probleme zu bemerken.
Bewertungpass, wenn ein _smtp._tls-TXT-Record mit v=TLSRPTv1 existiert; sonst warn. Gewicht 1.
BehebungEinen TXT-Record _smtp._tls mit v=TLSRPTv1; rua=mailto:… veröffentlichen.