Wer "was ist SPF DKIM DMARC" sucht, hat meistens ein konkretes Problem: Der Newsletter landet bei Kunden im Spam, Shopware oder WooCommerce warnen im Backend vor fehlender Absender-Authentifizierung, oder ein ESP wie CleverReach, rapidmail oder Mailjet verlangt vor dem Versand eine "verifizierte Domain". Die kurze Antwort: SPF, DKIM und DMARC sind drei DNS-Einträge, die zusammen beweisen, dass eine E-Mail tatsächlich von deiner Domain autorisiert wurde – und nicht von jemandem, der sich nur als du ausgibt. Ohne diese drei Bausteine bewerten GMX, Web.de, T-Online, Gmail und Outlook jede Nachricht von deiner Domain automatisch als riskanter.
Warum es diese drei Einträge überhaupt braucht
Das klassische E-Mail-Protokoll (SMTP) wurde ohne eingebaute Absender-Prüfung entworfen. Jeder Server kann behaupten, im Namen einer beliebigen Domain zu senden – genau das nutzen Phishing- und Spam-Versender aus. SPF, DKIM und DMARC schließen diese Lücke nachträglich, jeder auf seine eigene Art. Zusammen bilden sie das, was Postmaster-Teams "Absender-Authentifizierung" nennen, und sind heute keine Kür mehr, sondern für Massenversender Pflicht – die Anforderungen von Google und Yahoo an Bulk-Sender (SPF und DKIM aktiv, DMARC mindestens auf p=none, funktionierendes One-Click-Unsubscribe, eine Beschwerdequote unter 0,3 %) gelten inzwischen faktisch als Mindeststandard für jeden, der von einer deutschen Domain aus an Gmail- oder Yahoo-Adressen sendet.
SPF: Wer darf in deinem Namen senden
SPF (Sender Policy Framework) ist ein TXT-Eintrag in deiner DNS-Zone, der auflistet, welche Server E-Mails im Namen deiner Domain verschicken dürfen. Empfangende Server vergleichen die tatsächliche Absender-IP mit dieser Liste. Ein typischer Eintrag sieht so aus:
In der Praxis wächst dieser Eintrag schnell, wenn mehrere Systeme senden: der eigene Mailserver, ein ESP wie CleverReach oder Brevo, das Shopware- oder JTL-Shop-Backend für Transaktionsmails, HubSpot für Marketing-Mails. Jeder zusätzliche Dienst braucht einen eigenen include:-Baustein – und SPF erlaubt maximal zehn solcher Lookups. Wer das überschreitet, bekommt einen "permerror" und SPF fällt für die ganze Domain aus.
DKIM: Die digitale Signatur der Nachricht
DKIM (DomainKeys Identified Mail) hängt jeder ausgehenden Mail eine kryptografische Signatur an, die mit einem privaten Schlüssel erzeugt wird. Der öffentliche Gegenpart liegt als TXT-Eintrag in deiner DNS-Zone, meist unter einem Selector wie selector1._domainkey.deinedomain.de. Der empfangende Server holt sich diesen öffentlichen Schlüssel und prüft, ob die Signatur zur Nachricht passt. Stimmt sie nicht überein oder wurde die Mail unterwegs verändert, schlägt die Prüfung fehl. Anders als SPF ist DKIM unabhängig vom versendenden Server – die Signatur bleibt auch gültig, wenn eine Mail über einen Relay weitergeleitet wird, was SPF in solchen Fällen oft bricht.
Bei Shopware, WooCommerce, Shopify oder Shop-Systemen mit externem SMTP-Provider wird der DKIM-Schlüssel meist automatisch vom Anbieter erzeugt – du musst nur den bereitgestellten TXT-Eintrag korrekt in deiner DNS-Zone hinterlegen.
DMARC: Die Regel, die alles zusammenführt
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf und macht zwei Dinge: Erstens legt es fest, was mit Mails passieren soll, die weder SPF noch DKIM sauber bestehen (p=none, p=quarantine oder p=reject). Zweitens verschickt es täglich aggregierte Berichte an eine von dir festgelegte Adresse – damit siehst du erstmals schwarz auf weiß, wer in deinem Namen sendet, auch Systeme, die du vielleicht vergessen hast einzutragen. Ein einfacher Einstiegs-Eintrag:
v=DMARC1; p=none; rua=mailto:dmarc-reports@deinedomain.deWichtig: DMARC greift nur, wenn mindestens SPF oder DKIM zusätzlich im sogenannten "Alignment" mit der sichtbaren Absenderdomain (From:-Header) übereinstimmen. Details zur schrittweisen Umstellung von p=none auf p=reject findest du in der DMARC-Anleitung.
So prüfst du deine eigenen Einträge in der Praxis
- DNS-Einträge per Konsole oder Online-Tool auf Tippfehler und Duplikate prüfen.
- Einen echten Testversand an mehrere Provider gleichzeitig schicken – reine Header-Analyse zeigt nicht, wie GMX, Web.de oder T-Online tatsächlich reagieren.
- Prüfen, ob SPF und DKIM auch im DMARC-Alignment tatsächlich "pass" melden.
- Landet die Mail im Spam-Ordner statt im Posteingang, Header und Zustellwege vergleichen.
Am schnellsten geht das mit einem kostenlosen Inbox-Placement-Test: Du schickst eine Mail an bereitgestellte Seed-Adressen bei über 20 Providern und siehst sofort, ob sie im Posteingang, bei Werbung/Promotions oder im Spam landet, dazu den SPF/DKIM/DMARC-Status im Klartext und Screenshots, wie die Mail im echten Postfach aussieht – ganz ohne Registrierung.
p=none, damit du erst ein paar Tage Berichte sammelst, bevor du auf quarantine oder reject umstellst. Wer direkt mit p=reject startet, riskiert, dass vergessene Systeme (etwa ein altes CRM oder ein zweiter Newsletter-Dienst) plötzlich komplett blockiert werden.Typische Fehler aus der DACH-Praxis
- Zwei SPF-Einträge auf derselben Domain (z. B. ein alter vom Hoster, ein neuer vom ESP) – erlaubt ist immer nur ein einziger
v=spf1-Eintrag pro Domain. - WooCommerce oder ein klassischer WordPress-Shop versendet über
wp_mail()direkt vom Hosting-Server, ohne dass dessen IP im SPF-Eintrag steht oder DKIM konfiguriert ist – die Lösung ist ein SMTP-Plugin mit sauber verbundenem Versanddienst. - Shopware- oder JTL-Shop-Transaktionsmails laufen über den Standard-Hosting-Versand statt über einen konfigurierten externen SMTP-Connector.
- DMARC-Reports werden nie ausgewertet – die tägliche Warnung vor unautorisierten Sendern verpufft im Postfach.
- Nach einem Domain- oder Providerwechsel (z. B. Umzug von GMX/Web.de-Hosting zu einem neuen ESP) werden die alten DNS-Einträge vergessen und stehen weiter aktiv.