SPF, DKIM und DMARC einfach erklärt: In diesem Artikel lernst du, was hinter den drei Kürzeln steckt, warum sie gemeinsam über die Zustellbarkeit deiner E-Mails entscheiden und wie du sie einrichtest, ohne dich in RFC-Dokumenten zu verlieren. Am Ende weißt du außerdem, woran du merkst, wenn einer der drei Records versehentlich kaputtgeht.
Warum E-Mail-Zustellung plötzlich zum Problem wird
Wir haben das selbst erlebt: Ein Kunde beschwert sich, dass Rechnungsmails im Spam-Ordner landen oder gar nicht erst ankommen – dabei hat sich am Mailserver scheinbar nichts geändert. Der eigentliche Grund liegt fast nie am Mailserver selbst, sondern an den DNS-Einträgen, die E-Mail-Provider wie Google oder Microsoft nutzen, um zu prüfen, ob eine Nachricht wirklich vom angegebenen Absender stammt.
Genau hier kommen SPF, DKIM und DMARC ins Spiel. Alle drei sind reine DNS-TXT-Records, kein Softwareprodukt, keine zusätzliche Installation – aber wenn einer davon fehlt oder fehlerhaft konfiguriert ist, kann das genügen, damit E-Mails als verdächtig eingestuft werden.
Was ist SPF, DKIM und DMARC eigentlich?
Die drei Mechanismen lösen jeweils ein anderes Teilproblem der E-Mail-Authentifizierung, funktionieren aber am besten im Zusammenspiel.
SPF: Wer darf im Namen der Domain versenden
SPF steht für Sender Policy Framework und listet in einem TXT-Record, welche Server berechtigt sind, E-Mails im Namen einer Domain zu versenden. Empfangende Mailserver prüfen bei eingehender Post, ob der absendende Server in dieser Liste steht – steht er nicht drin, wertet das den Absender-Trust ab oder führt direkt zur Ablehnung. Ein typischer SPF-Record sieht etwa so aus: v=spf1 include:_spf.mailanbieter.de -all, wobei das -all am Ende bedeutet, dass alle nicht gelisteten Server strikt abgelehnt werden sollen.
DKIM: Die digitale Signatur jeder E-Mail
DKIM (DomainKeys Identified Mail) fügt jeder ausgehenden E-Mail eine kryptografische Signatur hinzu, die mit einem öffentlichen Schlüssel im DNS abgeglichen wird. Anders als SPF prüft DKIM nicht den Absende-Server, sondern ob der Inhalt der E-Mail auf dem Transportweg verändert wurde – eine Art digitales Siegel, das Manipulation sichtbar macht. Der öffentliche Schlüssel liegt dabei ebenfalls als TXT-Record im DNS, meist unter einer Subdomain wie selector._domainkey.deinedomain.de.
DMARC: Die Regel, was bei einem Fehlschlag passiert
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf und legt fest, was passieren soll, wenn eine E-Mail bei einer der beiden Prüfungen durchfällt: nichts tun (p=none), in Quarantäne/Spam verschieben (p=quarantine) oder komplett ablehnen (p=reject). Zusätzlich lässt sich über DMARC ein Reporting-Postfach hinterlegen, an das E-Mail-Provider automatisiert Berichte über fehlgeschlagene Zustellversuche schicken.
Warum das Zusammenspiel entscheidend ist
Keiner der drei Records funktioniert wirklich gut allein. SPF ohne DMARC lässt sich leicht umgehen, weil Angreifer einfach eine ähnlich aussehende Domain nutzen können, ohne dass der Empfänger gewarnt wird. DKIM ohne SPF sagt nichts darüber, ob der Server überhaupt berechtigt war zu senden. Und DMARC ohne sauber konfiguriertes SPF und DKIM hat schlicht keine verlässliche Grundlage, auf der es Entscheidungen treffen könnte.
Für deutschsprachige Unternehmen, die viel Geschäftskommunikation per E-Mail abwickeln – Rechnungen, Vertragsunterlagen, Terminbestätigungen – ist das kein theoretisches SEO-Thema, sondern hat direkten Einfluss darauf, ob Kunden diese E-Mails überhaupt zu Gesicht bekommen. Große deutsche Mailprovider und internationale Anbieter wie Gmail werten fehlende oder fehlerhafte DMARC-Konfigurationen zunehmend als Vertrauenssignal – seit 2024 verlangt Google bei Massen-Versendern sogar explizit einen gültigen DMARC-Record.
Typische Fehler bei der Einrichtung
Ein häufiger Stolperstein ist, dass Unternehmen mehrere Versanddienste nutzen – etwa den eigenen Mailserver, ein Newsletter-Tool und ein CRM-System – aber nur einen davon im SPF-Record berücksichtigen. Jeder zusätzliche Dienst, der E-Mails im Namen der Domain verschickt, muss im SPF-Record als include-Eintrag ergänzt werden, sonst schlägt die Prüfung für diesen Versandweg fehl. Ein zweiter klassischer Fehler ist ein zu vorsichtig eingestellter DMARC-Record: Viele starten mit p=none, um erstmal nur Reports zu sammeln, vergessen dann aber, später auf p=quarantine oder p=reject umzustellen – wodurch DMARC zwar konfiguriert ist, aber faktisch nichts blockiert.
Wie Pingoclock das löst – konkret und ehrlich
Pingoclock überwacht im Premium-Plan die SPF-, DKIM- und DMARC-Records jeder Domain fortlaufend und meldet automatisch, wenn sich einer dieser Einträge ändert oder verschwindet – etwa weil ein neu eingebundenes Marketing-Tool den bestehenden SPF-Record versehentlich überschrieben hat.
Pingoclock erklärt SPF, DKIM und DMARC nicht nur, sondern überwacht die drei Records im Premium-Plan aktiv und schlägt Alarm, sobald sich einer davon ohne Ankündigung verändert – ein Feature, das viele reine DNS-Lookup-Tools nicht bieten.
Die Änderungshistorie zeigt dabei genau, welcher Teil eines SPF- oder DMARC-Records sich geändert hat, statt nur pauschal zu melden, dass „etwas anders“ ist. Das ist besonders wertvoll, wenn mehrere Personen oder Agenturen gemeinsam an derselben Domain arbeiten und niemand allein den Überblick über alle Änderungen behält.
Ein Beispiel aus dem Alltag
Stell dir vor, ein Unternehmen bindet ein neues Vertriebs-Tool an, das automatisch E-Mails im Namen der eigenen Domain versendet. Der Support des Tools schickt eine kurze Anleitung, einen SPF-Eintrag zu ergänzen – aber statt des bestehenden Records zu erweitern, wird versehentlich der komplette alte SPF-Record ersetzt. Von diesem Moment an lehnen einige Mailserver E-Mails vom eigentlichen Hauptmailserver ab, weil der plötzlich nicht mehr im SPF-Record gelistet ist. Ohne laufende Überwachung fällt das oft erst auf, wenn Kunden sich beschweren, dass Rechnungen nicht ankommen – mit DNS-Monitoring wäre die Änderung am SPF-Record sofort protokolliert und gemeldet worden.
Häufige Fragen zu SPF, DKIM und DMARC
Reicht SPF allein aus, um E-Mail-Spoofing zu verhindern? Nein. SPF prüft nur, ob der sendende Server berechtigt ist, sagt aber nichts über den Inhalt oder eine mögliche Manipulation aus. Erst im Zusammenspiel mit DKIM und einer klaren DMARC-Policy entsteht ein wirksamer Schutz.
Wie finde ich heraus, ob meine DMARC-Konfiguration überhaupt etwas bewirkt? Ein DMARC-Record mit p=none sammelt nur Berichte, blockiert aber nichts. Erst p=quarantine oder p=reject sorgt dafür, dass fehlgeschlagene E-Mails tatsächlich aussortiert werden.
Was passiert, wenn ein SPF- oder DKIM-Record versehentlich gelöscht wird? Mailserver, die bislang über diesen Weg als vertrauenswürdig galten, werden ab diesem Zeitpunkt schlechter bewertet oder abgelehnt – oft ohne sichtbaren Fehler auf der eigenen Seite, bis Kunden auf ausbleibende E-Mails hinweisen.
Muss ich SPF, DKIM und DMARC selbst manuell prüfen? Manuell geht das über DNS-Lookup-Tools, ist aber fehleranfällig, weil Änderungen leicht übersehen werden. Eine laufende Überwachung wie das DNS Monitoring von Pingoclock meldet Abweichungen automatisch, statt dass man sie zufällig entdeckt.
E-Mail-Authentifizierung ist eines der Themen, bei denen die Einrichtung einmalig ist, das Risiko aber dauerhaft bleibt – jede spätere Änderung an der DNS-Zone kann SPF, DKIM oder DMARC beeinflussen, ohne dass jemand es beabsichtigt hat. Wenn du sichergehen willst, dass deine E-Mail-Zustellung stabil bleibt, lohnt sich ein Blick auf unsere DNS-Überwachung oder ein kostenloser Start mit anschließendem Upgrade auf Premium.
Kostenlos starten, später ohne Datenverlust upgraden
Keine Kreditkarte. Server in Deutschland.
