SPF, DKIM und DMARC prüfen
Der Test liest die DNS-Einträge einer Domain aus und sagt dir, was fehlt, was falsch steht und was du ändern musst. Kostenlos, ohne Anmeldung, ohne Angabe einer E-Mail-Adresse.
Ein SPF-Eintrag legt fest, welche Server für eine Domain senden dürfen. Ein DKIM-Schlüssel erlaubt Empfängern, die Signatur einer Mail nachzurechnen. Ein DMARC-Eintrag bestimmt, was mit Mails geschehen soll, die weder SPF noch DKIM bestehen, und wohin die Berichte darüber gehen. Alle drei sind TXT-Einträge im DNS, und alle drei prüft dieser Test in einem Durchgang, zusammen mit den MX-Einträgen für den Empfang.
Domain prüfen
Der Test fragt drei Stellen im DNS ab: die Domain selbst für SPF und die MX-Einträge, _dmarc.deinefirma.de für die Richtlinie und <selector>._domainkey.deinefirma.de für den Schlüssel. Es werden ausschließlich öffentlich abrufbare Einträge gelesen.
Bericht per Mail, wenn du magst
Das Ergebnis steht oben, vollständig und ohne Gegenleistung. Wenn du es zusätzlich schriftlich brauchst, etwa um es an die Person weiterzugeben, die euer DNS verwaltet, schicken wir es dir per Mail.
Was der Test abfragt
SPF: welche Server für deine Domain senden dürfen
Ein SPF-Record ist ein TXT-Eintrag im DNS, der die Server nennt, die für eine Domain senden dürfen. Der Empfänger vergleicht die IP-Adresse, von der die Mail kam, mit dieser Liste. Passt sie nicht, ist das ein Verdachtsmoment.
Der Test prüft mehr als das Vorhandensein. Er zählt die DNS-Abfragen, die der Eintrag auslöst, denn RFC 7208 erlaubt in Abschnitt 4.6.4 genau zehn. Wer darüber liegt, bekommt bei jedem Empfänger einen PermError, und dann wirkt der Eintrag so, als gäbe es ihn nicht. Weiter prüft der Test, ob genau ein Eintrag existiert, welcher Qualifier am Ende steht und ob veraltete Mechanismen wie ptr darin vorkommen.
DKIM: die Signatur, die Empfänger nachrechnen
Ein DKIM-Schlüssel ist ein öffentlicher Schlüssel im DNS, mit dem Empfänger die Signatur einer Mail prüfen. Die Signatur entsteht beim Versand mit dem passenden privaten Schlüssel. Stimmt sie, wurde die Mail unterwegs nicht verändert.
Hier liegt die Grenze jedes Prüfwerkzeugs: Der Schlüssel steht unter einem frei gewählten Namen, dem Selector, und das DNS erlaubt es nicht, die vorhandenen Namen aufzulisten. Der Test probiert deshalb 24 Selectoren durch, die gängige Anbieter verwenden. Findet er keinen, heißt das nicht, dass die Domain kein DKIM nutzt. Es heißt nur, dass der Name nicht unter den geprüften war. Trag ihn oben ein, dann wird er gefunden. Bei einem gefundenen Schlüssel prüft der Test die Länge, ob er widerrufen ist und ob er im Testmodus steht.
DMARC: die Regel für nicht bestandene Prüfungen
Ein DMARC-Eintrag ist ein TXT-Eintrag unter _dmarc, der festlegt, was mit Mails passiert, die SPF und DKIM nicht bestehen. Zusätzlich nennt er die Adresse, an die Empfänger ihre Berichte schicken.
Der Test liest die Richtlinie, prüft die Reihenfolge und Gültigkeit der Angaben und sagt dir, ob eine Berichtsadresse hinterlegt ist. Fehlt für eine Subdomain der eigene Eintrag, sucht er den Eintrag der übergeordneten Domain und nennt dir, welcher tatsächlich gilt. Das ist der häufigste Grund für die falsche Meldung „kein DMARC" bei anderen Werkzeugen.
Die drei Einträge im Überblick
| Host | Typ | Beispielwert | Zweck |
|---|---|---|---|
deinefirma.de |
TXT | v=spf1 include:spf.spamgo.de ~all |
Nennt die sendeberechtigten Server |
mb1._domainkey.deinefirma.de |
TXT | v=DKIM1; k=rsa; p=MIIBIjAN… |
Öffentlicher Schlüssel für die Signatur |
_dmarc.deinefirma.de |
TXT | v=DMARC1; p=none; rua=mailto:dmarc@deinefirma.de |
Regel und Berichtsadresse |
Viele Anbieter erwarten im Feld für den Host nur den Teil vor der Domain, also @ für die Domain selbst und _dmarc statt _dmarc.deinefirma.de. Steht der Eintrag nach dem Speichern doppelt, etwa als _dmarc.deinefirma.de.deinefirma.de, war das die Ursache.
So sieht ein Ergebnis aus
Geprüft am 18. August 2026, Domain mailbridge.email, also unsere eigene:
| Eintrag | Befund | Was der Test sagt |
|---|---|---|
| SPF | bestanden | Eintrag vorhanden, endet auf -all, löst 5 von 10 erlaubten DNS-Abfragen aus. |
| DKIM | nicht gefunden | Unter den 24 geprüften Selectoren war keiner vorhanden. Das ist kein Beweis für fehlendes DKIM. |
| DMARC | Fehler | Unter _dmarc.mailbridge.email steht ein TXT-Eintrag, aber es ist kein DMARC-Eintrag: dort wurde versehentlich der SPF-Wert hineinkopiert. |
| MX | bestanden | Ein Empfangsserver, erreichbar. |
Note D, ein Fehler und eine Warnung. Wir lassen dieses Beispiel absichtlich stehen, statt ein sauberes zu erfinden: Der Fehler ist echt, und er zeigt genau die Art von Panne, die man ohne Prüfung nicht bemerkt. Ein TXT-Eintrag war an der richtigen Stelle vorhanden, nur mit falschem Inhalt, und jedes Werkzeug, das nur „kein DMARC gefunden" meldet, schickt einen beim Suchen in die falsche Richtung.
Bestanden, Warnung, Fehler: was die drei Zustände bedeuten
- Bestanden heißt: geprüft und in Ordnung.
- Warnung heißt: es funktioniert, aber etwas fehlt oder wirkt nur halb. Ein fehlender DMARC-Eintrag steht hier, weil ihn keine Vorschrift verlangt, die Domain ohne ihn aber keinen Schutz gegen Fälschungen hat.
- Fehler heißt: der Eintrag ist kaputt oder schädlich. Zwei SPF-Einträge auf einer Domain gehören hierher, weil die Prüfung dann bei allen Empfängern ausfällt, ebenso
+all, weil es Fälschungen ausdrücklich erlaubt. - Unbekannt heißt: die Abfrage selbst hat nicht geklappt. Das ist eine Aussage über das DNS in diesem Moment, nicht über die Domain. Der Test behauptet in diesem Fall nie, ein Eintrag fehle.
Fehlermeldungen und was sie bedeuten
| Meldung | Bedeutung | Was du tust |
|---|---|---|
| PermError | Der SPF-Eintrag ist dauerhaft unauswertbar, meist wegen zu vieler DNS-Abfragen oder zweier Einträge. | Abfragen zusammenfassen, überzählige Einträge entfernen. |
| TempError | Die Prüfung war vorübergehend nicht möglich, etwa weil ein Nameserver nicht antwortete. | Später erneut prüfen. Tritt es dauerhaft auf, ist ein Nameserver defekt. |
SoftFail (~all) |
Der Absender ist nicht aufgeführt, der Empfänger soll die Mail trotzdem annehmen und vermerken. | Nichts. Das ist die empfohlene Einstellung im Regelbetrieb. |
Fail (-all) |
Der Absender ist nicht aufgeführt und soll abgewiesen werden. | Nur setzen, wenn wirklich alle sendenden Systeme im Eintrag stehen. |
Neutral (?all) |
Der Eintrag trifft keine Aussage. Er ist damit praktisch wirkungslos. | Auf ~all ändern. |
| None | Für die Domain gibt es überhaupt keinen SPF-Eintrag. | Einen anlegen, siehe Tabelle oben. |
| Kein passender DKIM-Selector | Unter den geprüften Namen lag kein Schlüssel. Der Selector kann trotzdem existieren. | Den eigenen Selector aus einer versandten Mail ablesen und oben eintragen. |
DMARC ohne rua |
Es ist eine Richtlinie hinterlegt, aber keine Adresse für die Berichte. | rua=mailto:… ergänzen. Ohne Berichte siehst du nicht, was durchfällt. |
| Ausrichtung nicht erfüllt | SPF oder DKIM haben bestanden, aber für eine andere Domain als die im sichtbaren Von-Feld. | Absenderdomain und geprüfte Domain in Übereinstimmung bringen. |
Häufige Fehler in den Einträgen
Zwei SPF-Einträge auf einer Domain
Erlaubt ist genau ein Eintrag je Domain. Zwei entstehen fast immer dadurch, dass ein neuer Dienst dazukommt und sein Eintrag daneben gestellt wird statt in den vorhandenen hinein. Das Ergebnis ist ein PermError, und die Domain steht danach schlechter da als ohne jeden SPF-Eintrag. Die Lösung ist, beide zu einem zusammenzufassen und die include:-Angaben aneinanderzureihen.
Mehr als zehn DNS-Abfragen im SPF
Jedes include:, jedes a, mx, ptr und exists kostet eine DNS-Abfrage, und die Abfragen der eingebundenen Einträge zählen mit. Wer Microsoft 365, ein Newsletter-Werkzeug und einen Shop einzeln einträgt, liegt schnell bei zwölf. Bei elf ist Schluss: Empfänger brechen mit PermError ab, und der ganze Eintrag wirkt nicht mehr. Dieser Test zählt die Abfragen für dich und zeigt, welcher Eintrag wie viele verursacht. Wenn du deinen Versand über ein Relay bündelst, ersetzt ein einziges include: alle diese Einträge.
Der DKIM-Eintrag steht am falschen Ort
Der Schlüssel gehört auf <selector>._domainkey.deinefirma.de. Häufig fehlt der Teil ._domainkey, oder der Anbieter hängt die Domain ein zweites Mal an. Ein leerer Wert hinter p= ist übrigens kein Versehen, sondern die vorgesehene Form für einen widerrufenen Schlüssel.
DMARC bleibt auf p=none stehen
Der Einstieg mit p=none ist richtig, aber er ist kein Ziel. Solange die Richtlinie dort steht, kann jeder in deinem Namen senden, ohne dass ein Empfänger etwas dagegen tut. Wenn die Berichte über einige Wochen zeigen, dass alle deine eigenen Absender bestehen, geh auf p=quarantine und später auf p=reject.
Fehlenden Eintrag nachtragen
- Melde dich bei dem Anbieter an, der die DNS-Zone deiner Domain verwaltet. Das ist der Anbieter, bei dem die Domain registriert ist, oder derjenige, auf dessen Nameserver sie zeigt.
- Öffne die Verwaltung der DNS-Einträge und suche den Bereich für TXT-Einträge.
- Trag den fehlenden Eintrag mit Host, Typ und Wert genau so ein, wie der Test ihn nennt. Bei SPF ist der Host die Domain selbst, bei DMARC lautet er
_dmarc. - Speichere und warte, bis die Änderung sichtbar ist. Meist dauert das wenige Minuten, in seltenen Fällen bis zu 24 Stunden.
- Prüfe die Domain hier erneut. Bleibt der Befund gleich, sieh nach, ob der Host doppelt geschrieben wurde, etwa
_dmarc.deinefirma.de.deinefirma.de.
Die ausführliche Reihenfolge für eine Umstellung ohne Zustellausfall, mit allen Feldern erklärt, steht im Ratgeber unter SPF, DKIM und DMARC einrichten.
Was bedeutet p=none bei DMARC?
p=none heißt, dass Empfänger nichts tun sollen, wenn eine Mail die Prüfung nicht besteht. Die Mail wird normal zugestellt. Der Nutzen liegt allein in den Berichten: du erfährst, wer in deinem Namen sendet, bevor du etwas blockierst. Als Dauerzustand schützt p=none nicht, als Einstieg ist es genau richtig.
Warum landen meine Mails trotz SPF im Spam?
SPF ist nur eines von mehreren Signalen. Die häufigsten Gründe trotz gültigem SPF sind: der Eintrag löst mehr als zehn DNS-Abfragen aus und fällt damit komplett aus, es fehlt DKIM, die Absenderadresse im sichtbaren Von-Feld passt nicht zur geprüften Domain, oder die sendende IP-Adresse hat eine schlechte Reputation. Die ersten drei zeigt dieser Test. Zur Reputation hilft der Beitrag zu IP oder Domain auf einer Blacklist.
Wie finde ich den DKIM-Selector meiner Domain?
Der Selector steht im Kopf jeder signierten Mail. Öffne eine Mail, die du selbst versandt hast, lass dir die Kopfzeilen anzeigen und suche die Zeile DKIM-Signature. Der Wert hinter s= ist der Selector. Im DNS lässt sich der Name nicht auflisten, deshalb kann kein Prüfwerkzeug ihn zuverlässig erraten.
Wie lange dauert es, bis eine DNS-Änderung wirkt?
Meist wenige Minuten, in seltenen Fällen bis zu 24 Stunden. Maßgeblich ist die TTL des alten Eintrags: so lange darf ein Resolver den vorherigen Wert noch aus seinem Zwischenspeicher beantworten. Ein neuer Eintrag, für den vorher nichts da war, ist in der Regel sofort sichtbar.
Brauche ich DKIM, wenn SPF eingerichtet ist?
Ja. SPF prüft nur, von welchem Server eine Mail kam, und diese Prüfung bricht bei jeder Weiterleitung. DKIM signiert die Mail selbst und übersteht Weiterleitungen. DMARC gilt als bestanden, wenn eines von beiden passt, deshalb machen die zwei Verfahren zusammen die Zustellung stabil.
Ist der Test kostenlos?
Ja, ohne Anmeldung und ohne Angabe einer E-Mail-Adresse. Abgefragt werden ausschließlich öffentliche DNS-Einträge. Wir legen keine Liste der geprüften Domains an. Was genau übertragen wird, steht in der Datenschutzerklärung.
Wie MailBridge SPF, DKIM und DMARC übernimmt
MailBridge ist ein SMTP-Relay: Geräte und Anwendungen geben ihre Mail an unsere Server ab, und die übernehmen den Versand über deine Absenderdomain. Für die drei Einträge bedeutet das dreierlei. Bei SPF genügt ein einziges include: für alle unsere Server, egal wie viele es sind und ob wir einen austauschen. DKIM signieren wir selbst, du trägst einen Eintrag ein und musst nie einen Schlüssel erzeugen oder wechseln. Deinen DMARC-Eintrag legst du weiterhin selbst an, dabei nimmt dir kein Anbieter etwas ab.
Im Portal stehen für jede Domain der gefundene und der erwartete Eintrag nebeneinander, mit Kopierknopf für Host, Typ und Wert. Alle Domains werden täglich nachgeprüft, und bricht später ein Eintrag, erscheint das als Handlungsbedarf.
Standards und Stand dieser Seite
Herausgeber dieser Seite ist MailBridge, ein Dienst der LOGIN SystemHaus GmbH in Wiesbaden. Alle Server stehen in Deutschland.
Die geprüften Verfahren sind in RFC 7208 (SPF, 2014), RFC 6376 (DKIM, 2011) und RFC 7489 (DMARC, 2015) festgelegt. Die Grenze von zehn DNS-Abfragen und die von zwei leeren Abfragen stehen in RFC 7208, Abschnitt 4.6.4. Die Empfehlung, auf ptr zu verzichten, steht in RFC 7208, Abschnitt 5.5. Ein MX-Eintrag muss nach RFC 2181, Abschnitt 10.3, direkt auf einen Namen mit Adresse zeigen und nicht auf einen Alias. Die ausdrückliche Angabe, dass eine Domain keine Mail annimmt, regelt RFC 7505.
Zuletzt geprüft am 18. August 2026.