SPF, DKIM und DMARC prüfen: Bericht statt Ampel

So liest du den Gesamtwert

Der Wert von 0 bis 100 setzt sich aus sieben Bereichen zusammen. SPF bringt 20 Punkte, DKIM und DMARC je 25 – die beiden wiegen am meisten, weil sie über die Ausrichtung entscheiden: Bei Versand über eine Plattform wie ActiveCampaign, Mailchimp oder Brevo steht im Return-Path deren Domain, SPF ist dann nicht ausgerichtet, und DKIM trägt die DMARC-Prüfung allein.

Empfang bringt 10 Punkte, Transportschutz 10, DNSSEC 5, BIMI 5. Die letzten drei sind Kür: Wer sie nicht hat, verliert keine Zustellung, nur Punkte. Wer sie hat, ist weiter als der Durchschnitt – und genau das soll der Wert zeigen.

Ab 90 Punkten heißt es *Vorbildlich*, ab 75 *Solide*, ab 50 *Grundschutz*, darunter *Lückenhaft*. Innerhalb eines Bereichs gilt: Ein Problem setzt den Bereich auf null, jede Warnung kostet ein paar Punkte, Hinweise kosten nichts.

Nicht nachweisbar heißt nicht schlecht. Ein DKIM-Schlüssel, der unter einem eigenen Selektor liegt, taucht in der Liste der 70 geprüften Namen nicht auf. Dann fällt der Bereich aus der Rechnung, der Wert bezieht sich auf die prüfbaren Punkte, und der Bericht sagt das dazu. Mit dem eigenen Selektor im Feld darunter wird das Bild vollständig.

Der Zähler, an dem SPF in der Praxis reißt

Der häufigste Fehler ist nicht der fehlende SPF-Eintrag, sondern der zu lange. RFC 7208 erlaubt höchstens zehn DNS-Abfragen je Auswertung. Gezählt wird jedes `include`, jedes `a`, `mx`, `ptr`, `exists` und jedes `redirect` – auch die, die tief in den Einträgen der eingebundenen Dienste stecken.

Ein Beispiel: `include:_spf.google.com` sieht nach einer Abfrage aus. Wenn daneben noch `include:google.com` steht, kommt dessen eigener Verweis auf `_spf.google.com` hinzu – zwei Abfragen für dieselbe Sache. So sammeln sich über Jahre Newsletter-Dienst, Ticketsystem, Rechnungsversand und Bewerbungsportal an, bis der elfte Verweis alles kippt.

Das Tückische daran: Es passiert lautlos. Der Eintrag sieht vollständig aus, im DNS steht alles, und trotzdem meldet der empfangende Server `permerror` und behandelt die Nachricht, als gäbe es gar kein SPF.

Der Bericht zählt rekursiv durch, zeigt den Baum mit den Kosten jedes Includes und warnt ab acht von zehn Abfragen. Überflüssige Includes erkennt er am Inhalt: Gibt ein Include nichts frei, was ein anderes nicht schon freigibt, steht der aufgeräumte Eintrag zum Kopieren bereit – mit exakt denselben Freigaben und weniger Abfragen.

Warum p=none ohne rua nichts bringt

Der mit Abstand häufigste DMARC-Eintrag im Bestand sieht so aus: `v=DMARC1; p=none;` – und sonst nichts. Er ist formal gültig, erfüllt die Anforderung von Google und Yahoo, und ist trotzdem wirkungslos.

`p=none` bedeutet: nichts tun. Nachrichten, die die Prüfung nicht bestehen, werden ganz normal zugestellt. Das ist als Einstieg auch richtig so – wer sofort auf `reject` geht, blockiert im Zweifel seine eigenen Rechnungsmails.

Der Punkt ist der zweite Teil: Ohne `rua=` werden keine Berichte gesammelt. Genau diese Berichte sind aber der Grund, warum man mit `p=none` anfängt – sie zeigen über einige Wochen, wer alles in deinem Namen sendet und ob alle legitimen Absender sauber authentifiziert sind. Ohne sie bleibt der Eintrag für immer auf `none` stehen, weil die Grundlage für den nächsten Schritt fehlt.

Die Reihenfolge, die funktioniert: `p=none` mit `rua` setzen, vier bis sechs Wochen Berichte sammeln, fehlende Absender nachziehen, dann auf `p=quarantine`, später auf `p=reject`. Der Bericht schlägt jeden dieser Schritte als fertigen Eintrag vor – und prüft, ob ein fremder Berichtsempfänger die Berichte für deine Domain freigegeben hat.

Der PDF-Bericht und der teilbare Link

Jeder Bericht lässt sich als PDF speichern – über den Druckdialog deines Browsers, ohne E-Mail-Adresse und ohne Anmeldung. Gedruckt wird nur der Bericht, alle Bereiche aufgeklappt, mit Datum und Domain im Kopf. Das ist die Fassung, die du deinem IT-Dienstleister oder deinem Chef gibst.

Der Link zum Bericht trägt die Domain als Parameter und startet die Prüfung beim Öffnen neu. Wer ihn bekommt, sieht also den aktuellen Stand, nicht deine Momentaufnahme – nach einer Änderung im DNS genügt ein Klick, um zu sehen, ob sie angekommen ist.

Unter jedem Bericht steht das vollständige Abfrageprotokoll: jeder Name, jeder Typ, welcher Resolver geantwortet hat, wie lange es gedauert hat. Wer einem Befund nicht traut, sieht die Abfrage dahinter.

Was dieses Werkzeug nicht sehen kann

DNS ist öffentlich, deshalb lässt sich alles oben von außen prüfen. Vier Dinge, die für die Zustellung mindestens ebenso wichtig sind, stehen aber nicht im DNS:

Die Beschwerderate. Google verlangt dauerhaft unter 0,3 Prozent. Sichtbar ist sie nur in den Google Postmaster Tools, für die du die Domain einmalig verifizieren musst. Wer regelmäßig an Gmail-Adressen sendet und das nicht eingerichtet hat, fliegt blind.

Der Ruf der geteilten Versandadressen. Bei ActiveCampaign teilst du dir im Regelfall einen Adressbereich mit anderen Kunden. Blocklisten prüft der Bericht seit September 2026 für Domain, Mailserver, Website und Einzeladressen aus dem SPF – die geteilten Versandadressen des Anbieters aber nur, wenn du sie kennst und einzeln im Blacklist-Check eingibst; ihr Ruf ist Sache von ActiveCampaign. Unproblematisch bleibt das alles, solange die eigene Liste sauber ist – und genau deshalb ist Listenhygiene keine Fleißarbeit, sondern Zustellbarkeit.

Die Nachricht selbst. Ob die DKIM-Signatur einer konkreten E-Mail gültig ist, ob der Return-Path zur Absenderdomain passt und ob die Ein-Klick-Abmeldung im Kopf steht, zeigt nur ein Blick in den Nachrichtenkopf einer versendeten Mail. Der Bericht sagt, was das DNS erlaubt – nicht, was eine bestimmte Mail daraus gemacht hat.

Der Inhalt. Ein technisch einwandfrei authentifiziertes Mailing landet trotzdem im Spam, wenn niemand es öffnet. Authentifizierung ist die Eintrittskarte, nicht die Garantie.