Einen SPF-, DMARC- oder DKIM-Eintrag lesen

Der Analysator liest den eingefügten Eintrag als Text und prüft ihn an den Regeln seiner eigenen Spezifikation: SPF-Mechanismen und Modifier (RFC 7208), DMARC-Tags (RFC 7489) und DKIM-Schlüsseleinträge (RFC 6376, aktualisiert durch RFC 8301). Jeder Hinweis nennt die Regel, gegen die die Zeile verstößt.

Nichts wird abgefragt und nichts verifiziert: keine DNS-Abfrage, keine Prüfung einer Signatur und kein Zustelltest. Ein Eintrag, der hier besteht, ist stimmiger Text; ob er zu dem passt, was die Domain veröffentlicht, muss im DNS geprüft werden.

Fügen Sie den Wert des TXT-Eintrags ein oder klicken Sie auf Beispiel laden. Lassen Sie v=-Tag und Anführungszeichen so, wie sie veröffentlicht sind.
Belassen Sie den Typ auf Automatisch erkennen, oder wählen Sie SPF, DMARC oder DKIM, wenn der Eintrag mehrdeutig ist.
Klicken Sie auf Lokal auswerten. Der Bericht zeigt Befunde, eine Tabelle der Begriffe bzw. Tags und Zähler wie das SPF-Abfragebudget in der Form x / 10.
Lesen Sie die Tabelle neben den Befunden: Qualifier und Hinweis wiederholen die beanstandete Stelle, und die JSON-Ansicht überträgt dieselben Daten in ein Ticket.
Korrigieren Sie den Eintrag im Zoneneditor, warten Sie die TTL ab und fügen Sie ihn zur Kontrolle erneut ein.

Was jeder Eintragstyp enthalten muss

Was der SPF-Bericht zählt

Mechanismen werden in ihrer Reihenfolge mit Qualifier gelesen (+ pass, - fail, ~ softfail, ? neutral); der Eintrag muss nicht mit all enden. Ohne all oder mit redirect= hängt das Ergebnis eines nicht passenden Hosts von den Angaben ab, die vorhanden sind.

Das Limit von zehn Begriffen nach RFC 7208 umfasst include, a, mx, ptr, exists und redirect. ip4, ip6, all und exp zählen nicht, doppelte Begriffe zählen erneut. Mechanismen nach all stehen in der Tabelle, laufen aber nie.

DMARC-Tags mit Wirkung

v=DMARC1 muss vorne stehen, und p= (none, quarantine oder reject) ist das, was Empfänger anwenden; sp= setzt die Policy für Subdomains, pct= begrenzt den Anteil der betroffenen Mail.

rua= und ruf= erwarten URIs, üblicherweise mailto:-Adressen. adkim und aspf akzeptieren r oder s, fo wirkt nur zusammen mit ruf=, rf kennt nur afrf, und Tags, die DMARC nicht definiert, werden ignoriert statt den Eintrag zu verwerfen.

DKIM-Schlüssel und ihre Nutzbarkeit

Ein Schlüsseleintrag wird pro Selector veröffentlicht: v=DKIM1 zuerst, k= als rsa oder ed25519, p= mit dem öffentlichen Schlüssel in Base64. Ein leeres p= ist kein Fehler, sondern widerruft den Schlüssel.

RFC 8301 setzt die Untergrenze: Unter 1024 Bit entsteht keine gültige Signatur, 2048 Bit sind die empfohlene Größe, und SHA-1 darf nicht verwendet werden. Das s=-Tag muss email enthalten, t=y kennzeichnet den Testbetrieb.

Was eine Textprüfung nicht sehen kann

SPF-include-Ketten, DMARC-Alignment und DKIM-Selectoreinträge werden erst bei der Zustellung per DNS aufgelöst. Der Analysator beurteilt nur den vorliegenden Text; ein fehlender Hinweis garantiert also nicht, dass eine Domain authentifiziert sendet.

Der DKIM-Schlüsseleintrag hängt am Selector: Fügen Sie den Eintrag des tatsächlich signierenden Selectors ein (zum Beispiel selector1._domainkey), nicht den der Domain-Wurzel.