SPF, DKIM und DMARC prüfen – plus Security-Header

Was SPF, DKIM und DMARC sind – und was die Ampel sagt

SPF, DKIM und DMARC sind drei Einträge im DNS deiner Domain. Zusammen legen sie fest, wer E-Mails in deinem Namen verschicken darf und was mit einer Fälschung passieren soll. SPF nennt die Server, die senden dürfen. DKIM hängt an jede Mail eine Signatur, deren öffentlicher Schlüssel im DNS liegt. DMARC verbindet beides mit der Absenderadresse, die im Postfach sichtbar ist, und sagt empfangenden Servern, was sie mit einer Mail tun sollen, die keine der beiden Prüfungen besteht.

Fehlt DMARC oder steht es auf p=none, kann jeder Rechnungen mit deiner Absenderadresse verschicken, ohne dass ein Empfänger die Anweisung bekommt, sie auszusortieren. Wie solches E-Mail-Spoofing funktioniert und woran man eine gefälschte Mail im Header erkennt, steht im eigenen Beitrag.

Grün heißt: vorhanden und wirksam. Gelb: vorhanden, aber mit einer Lücke. Rot: fehlt, oder so fehlerhaft, dass empfangende Server den Eintrag verwerfen. Grau: nicht prüfbar, weil ein Server nicht rechtzeitig geantwortet hat. Die vierte Zeile schaut auf die Website selbst: welche Sicherheits-Header die Startseite mitschickt.

So sieht ein Ergebnis mit vier grünen Ampeln aus, hier für bitinformer.com, eine meiner eigenen Domains. Auch dann steht unter jeder Ampel, was noch zu tun ist:

SPF Check: ein Eintrag, höchstens zehn Abfragen

Der Check liest alle TXT-Einträge der Domain und zählt nur die, die mit v=spf1 beginnen – so schreibt es RFC 7208 vor. Stehen dort zwei, werten empfangende Server keinen davon aus. Steht v=spf1 mitten in einem Eintrag, wird er ignoriert; der Check meldet ihn trotzdem, weil meist jemand etwas erlauben wollte, das jetzt nicht erlaubt ist.

Danach folgt er jedem include und redirect und zählt die DNS-Abfragen, die ein Empfänger machen muss. Mehr als zehn sind nach RFC 7208 ein Fehler, und dann besteht auch eine echte Mail die Prüfung nicht. Zum Schluss zählt, womit der Eintrag endet: -all und ~all sind in Ordnung, ?all sagt nichts aus, +all erlaubt jedem Server der Welt das Senden. Wie man einen Eintrag von Hand liest, steht in SPF-Eintrag erstellen und prüfen.

DKIM Check: gefunden ist ein Beleg, nicht gefunden keiner

Ein DKIM-Schlüssel liegt unter <selector>._domainkey.<domain>, und den Selector wählt der Mailanbieter frei. Es gibt keine DNS-Abfrage, die alle Selektoren einer Domain auflistet. Der Check probiert deshalb 30 gängige Namen durch, darunter google, selector1, selector2, default, k1 und s1.

Findet er nichts, heißt das nicht, dass es kein DKIM gibt. Deshalb ist diese Zeile ohne Fund gelb und nie rot. Den eigenen Selector findest du im Quelltext einer Mail, die du verschickt hast: in der Zeile DKIM-Signature steht er nach s=. Oben unter „DKIM-Selector angeben“ eingetragen, prüft der Check genau diesen.

DMARC Check: p, sp, pct und rua

Gelesen wird der Eintrag unter _dmarc.<domain>. Hat eine Subdomain keinen eigenen, gilt nach RFC 7489 der Eintrag der übergeordneten Domain, und zwar mit sp=, wenn es gesetzt ist. Mehrere DMARC-Einträge nebeneinander zählen wie keiner.

Grün ist p=quarantine oder p=reject für alle Mails. p=none ist gelb: der Eintrag beobachtet nur. Ebenfalls gelb ist ein pct unter 100, weil die Richtlinie dann nur für einen Teil der Mails gilt. Fehlt rua, bekommt niemand die Berichte, aus denen man sieht, wer in deinem Namen sendet – das steht im Befund dabei. Die Schritte von p=none bis reject stehen in DMARC einrichten: SPF, DKIM und der _dmarc-Eintrag.

Security-Header der Website

Für die vierte Zeile ruft der Check einmal die Startseite über https auf, bei Bedarf zusätzlich mit www. davor, und liest die Kopfzeilen der Antwort. Bewertet werden fünf: HSTS, Content-Security-Policy, Schutz vor Einbettung (X-Frame-Options oder frame-ancestors), X-Content-Type-Options und Referrer-Policy. Wie im Security-Scan zählt der Wert, nicht das bloße Vorhandensein: ein HSTS mit max-age=0 schützt nichts. Werte, die wirken, und die Fallen dabei stehen in Security-Header und SEO.

Was der Check nicht tut

Er liest nur, was ohnehin öffentlich ist: DNS-Einträge, die jeder Mailserver beim Empfang abfragt, und die Startseite, wie ein Browser sie lädt. Er baut keine Verbindung zu Mailservern auf, verschickt keine Testmail und testet keine Ports – dafür gibt es den Security-Scan. Ob ein Mailserver der Domain auf einer Spam-Blacklist steht, zeigt der Blacklist-Check.

Die Domain wird nicht gespeichert. Sie steht nur im Arbeitsspeicher der Prüffunktion, bis zu 15 Minuten lang, damit eine wiederholte Abfrage nicht neu rechnet. Gezählt wird nur, dass geprüft wurde, damit niemand den Check im Dauerlauf benutzt: ohne Konto sind es höchstens acht Prüfungen pro Stunde.

Wie die vier Ampeln in Tirol ausfallen würden

Dieselben Prüfungen habe ich im September und Oktober 2026 an 149 Tiroler Domains gemacht: die Hauptdomains aller 34 Tourismusverbände und 115 Betriebe, von der Zahnarztpraxis bis zum Hotel. DNS am 27. und 29.09.2026, die Header der 131 erreichbaren Startseiten am 03.10.2026, alles passiv über öffentliche Einträge. So würden die Ampeln stehen:

135 von 149 Domains, also 91 %, würden bei DMARC rot oder gelb zeigen. Bei SPF ist das Bild besser: Nur 14 haben gar keinen Eintrag. Die Lücke liegt fast immer im letzten Schritt, der Richtlinie. Was die einzelnen Befunde für Tourismusbetriebe bedeuten, steht in E-Mail-Spoofing; genannt werden dort wie hier nur Summen.