SPF, DKIM und DMARC einrichten: Anleitung mit echten Tests (2026)

SPF, DKIM und DMARC einrichten ist heute keine Kür mehr, sondern Pflicht, wenn deine Mails ankommen sollen. Die drei Einträge im DNS sagen allen Mailservern der Welt: welche Server in deinem Namen senden dürfen (SPF), dass eine Mail unterwegs nicht verändert wurde (DKIM) und was mit Mails passieren soll, die beides nicht bestehen (DMARC). Fehlt einer davon, landen deine Nachrichten bei Gmail, Outlook und GMX schnell im Spam oder werden gar nicht erst angenommen. Und jeder kann Mails mit deiner Absenderadresse fälschen.

Die gute Nachricht: Alle drei sind nur TXT-Einträge im DNS. Du brauchst keinen eigenen Mailserver, keine teure Software und meistens keine halbe Stunde. Die schlechte: Die Syntax ist streng, und viele Fehler fallen nicht auf, weil die Mail trotzdem irgendwie zugestellt wird.

Wir haben für diesen Artikel am 11. November 2026 nachgemessen, statt abzuschreiben. Von unserem Produktionsserver (Hetzner, Ubuntu 24.04) haben wir die Einträge von 13 Domains abgefragt, darunter unsere eigenen und die großer Anbieter, SPF-Prüfungen mit einer Testbibliothek durchgespielt und eine echte Testmail über unseren Mailanbieter verschickt, deren DKIM-Signatur wir dann gezielt manipuliert haben. Drei Befunde vorweg:

1. Ein einziges Leerzeichen mehr im Text einer Mail zerbricht die DKIM-Signatur. Ein geändertes Datum dagegen nicht, weil unser Anbieter das Date-Feld gar nicht mitsigniert.

2. Der SPF-Eintrag von github.com braucht beim Prüfen genau 10 DNS-Abfragen, das erlaubte Maximum. Ein einziges weiteres include: und die Prüfung endet mit einem Fehler statt mit „pass”.

3. Zwei unserer eigenen Domains haben weder SPF noch DMARC. Eine Fälschung mit ihrer Adresse bekommt beim SPF-Check nicht „fail”, sondern „none”. Für einen Spamfilter ist das kein Grund zum Ablehnen.

Wenn du den Unterschied zwischen DNS-Eintragstypen noch nicht kennst, lies vorher Was ist DNS?. Und wie Mails überhaupt zu dir finden, steht in Was ist ein MX Record?. Hier geht es um die andere Richtung: deine ausgehenden Mails.

SPF, DKIM und DMARC: Was macht welcher Eintrag?

Bevor wir einrichten, das Bild im Kopf. E-Mail ist ein Protokoll aus den 1980ern, und damals hat niemand an Fälschungen gedacht. Wer einen Mailserver betreibt, kann in das Absenderfeld schreiben, was er will: chef@deinefirma.de, service@paypal.com, egal. SMTP prüft das nicht. Genau dieses Loch stopfen die drei Verfahren, jedes an einer anderen Stelle.

Ein Vergleich, der uns geholfen hat: SPF ist die Gästeliste am Eingang. Steht der einliefernde Server drauf, kommt er rein. DKIM ist das Siegel auf dem Brief. Wer es aufbricht, verändert es sichtbar. DMARC ist die Hausordnung, die sagt, was der Türsteher mit Gästen ohne Liste und ohne Siegel macht, und die dem Hausherrn jeden Morgen einen Bericht schreibt.

Wichtig ist, dass keines allein reicht. SPF prüft nur die technische Absenderadresse aus dem Umschlag (den sogenannten Envelope From oder Return-Path), nicht die Adresse, die dein Empfänger im Mailprogramm sieht. DKIM beweist nur, dass irgendeine Domain signiert hat, nicht welche im From: steht. Erst DMARC verknüpft beides mit der sichtbaren Absenderadresse. Das nennt man Alignment, und dazu kommen wir gleich.

Warum das seit 2024 nicht mehr optional ist

Seit Februar 2024 verlangen Google und Yahoo von allen, die mehr als 5.000 Mails pro Tag an ihre Nutzer schicken, SPF und DKIM und mindestens einen DMARC-Eintrag mit p=none. Microsoft hat für Outlook.com, Hotmail und Live im Mai 2025 nachgezogen. Für kleinere Absender gilt formal weniger, praktisch aber fast dasselbe: Mails ohne SPF oder DKIM gehen deutlich öfter in den Spam. Wer einen Newsletter, einen Shop oder ein Kontaktformular betreibt, kommt also nicht drumherum.

Was wir gemessen haben: 13 Domains im Vergleich

Bevor du deinen eigenen Eintrag schreibst, lohnt der Blick, wie andere es machen. Wir haben am 11. November 2026 per dig die SPF- und DMARC-Einträge abgefragt und mit der Python-Bibliothek pyspf gezählt, wie viele DNS-Abfragen eine vollständige SPF-Prüfung auslöst:

Drei Dinge fallen auf. Erstens: Auch die ganz Großen stehen nicht alle auf p=reject. Gmail und Outlook schützen ihre Hauptdomain nur mit p=none (also „nur beobachten”), Subdomains dagegen mit quarantine. Bei Freemail-Adressen ist das verständlich: Millionen Menschen schicken über Mailinglisten und fremde Dienste mit @gmail.com als Absender, eine harte Policy würde massenhaft echte Mails kaputtmachen.

Zweitens: Paypal und mailbox.org, also genau die, deren Adressen am häufigsten gefälscht werden oder die Sicherheit als Produkt verkaufen, stehen auf p=reject. Dort wird eine Fälschung abgewiesen, bevor sie ein Postfach erreicht.

Drittens: Die Zahl der DNS-Abfragen schwankt zwischen 0 und 10. Und 10 ist keine zufällige Zahl, sondern das Limit aus dem SPF-Standard (RFC 7208). Dazu gleich mehr.

SPF einrichten: Schritt für Schritt

SPF steht für Sender Policy Framework. Du legst auf deiner Domain einen TXT-Eintrag an, der mit v=spf1 beginnt und die erlaubten Absender aufzählt. Ein Empfänger, der eine Mail von irgendwer@deinedomain.de bekommt, schaut nach, ob die IP des einliefernden Servers auf der Liste steht.

Schritt 1: Herausfinden, wer in deinem Namen sendet

Das ist der wichtigste und meistunterschätzte Schritt. Typische Absender einer ganz normalen Firmendomain:

• dein Mailanbieter (Google Workspace, Microsoft 365, IONOS, Strato, all-inkl, Posteo, eigener Server)
• dein Shop oder CMS, wenn es Bestellbestätigungen oder Passwort-Mails verschickt
• dein Newsletter-Dienst (Brevo, Mailchimp, CleverReach, Rapidmail)
• Ticket-Systeme, CRM, Rechnungssoftware (Zendesk, HubSpot, sevDesk, lexoffice)
• Kontaktformulare auf deinem Webserver

Vergisst du einen davon, fallen genau dessen Mails durch. Schreib die Liste vollständig auf, bevor du irgendetwas veröffentlichst. Bei uns ist sie kurz: Alle Mails von getmind.io laufen über unseren Mailanbieter, auch die, die unser eigener Server erzeugt. Der meldet sich dort per Benutzername und Passwort an (authentifizierter Versand über Port 587) und lässt den Anbieter zustellen.

Schritt 2: Den Eintrag zusammenbauen

Die Bausteine:

Für typische Anbieter sieht das so aus:

# Nur Google Workspace
beispiel.de.  TXT  "v=spf1 include:_spf.google.com ~all"

# Nur Microsoft 365
beispiel.de.  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Google Workspace + Newsletter-Dienst + eigener Webserver
beispiel.de.  TXT  "v=spf1 include:_spf.google.com include:spf.brevo.com ip4:203.0.113.10 ~all"

Unser eigener Eintrag ist v=spf1 a:ff-web.de mx ~all. Übersetzt: Erlaubt ist der Server hinter ff-web.de und alles, was im MX-Eintrag steht. Alles andere ist verdächtig.

Schritt 3: Genau einen Eintrag veröffentlichen

Eine Domain darf nur einen SPF-Eintrag haben. Wer für jeden neuen Dienst einen zweiten TXT-Eintrag mit v=spf1 anlegt, erzeugt einen permerror, und dann gilt SPF als kaputt, für alle Absender. Neue Dienste kommen also immer in den bestehenden Eintrag, als weiteres include:.

Den Eintrag legst du bei deinem DNS-Anbieter als TXT auf der Domain selbst an (Name @ oder leer). Prüfen kannst du ihn sofort:

$ dig +short TXT getmind.io | grep spf
"v=spf1 a:ff-web.de mx ~all"

Was passiert bei Tippfehlern? Wir haben es ausprobiert

Mit pyspf haben wir verschiedene Einträge gegen eine fremde IP-Adresse geprüft (eine aus dem Dokumentationsbereich, die garantiert auf keiner Liste steht):

Der Tippfehler ~al statt ~all macht den ganzen Eintrag ungültig. Ein include: auf eine Domain, die es nicht (mehr) gibt, ebenso. Das passiert häufiger, als man denkt: Man kündigt einen Newsletter-Dienst, der löscht irgendwann seinen SPF-Eintrag, und bei dir steht noch das alte include:. Und +all ist der gefährlichste Eintrag überhaupt, weil er jedem Server der Welt ausdrücklich erlaubt, in deinem Namen zu senden. Er taucht gern als vermeintlicher „Fix” auf, wenn irgendwas nicht ankam. Das ist kein Fix, das ist ein offenes Scheunentor.

Das 10-Lookup-Limit

Jedes include:, a, mx, exists: und redirect= kostet beim Empfänger eine DNS-Abfrage, und Includes können selbst wieder Includes enthalten. Der Standard erlaubt höchstens 10 solcher Abfragen. Danach ist das Ergebnis permerror.

Wie knapp das in der Praxis wird, zeigt github.com: Deren Eintrag bindet Microsoft, Google (zweimal), Zendesk, Salesforce, Mailchimp, Marketo und Sendgrid ein und landet bei genau 10 Abfragen. Wir haben testweise einen Eintrag gebaut, der GitHubs Liste plus Google Workspace einbindet. Ergebnis:

('permerror', 550, 'SPF Permanent Error: Too many DNS lookups')  # 11 Abfragen

Was hilft, wenn du an die Grenze kommst:

1. Aufräumen. Dienste, die du nicht mehr nutzt, raus. Das bringt fast immer am meisten.
2. mx und a weglassen, wenn die Server ohnehin über ein Include abgedeckt sind.
3. Subdomains nutzen. Newsletter von news.beispiel.de, Rechnungen von rechnung.beispiel.de. Jede Subdomain hat ihr eigenes Limit.
4. Feste IPs statt Includes, aber nur, wenn der Anbieter sie garantiert nicht ändert. Sonst fällt das irgendwann still auseinander.

~all oder -all?

Die ehrliche Antwort: In Verbindung mit DMARC ist der Unterschied kleiner, als die Foren-Diskussionen vermuten lassen, weil DMARC am Ende entscheidet, was passiert. Wir empfehlen trotzdem: Starte mit ~all, solange du nicht sicher bist, dass deine Absenderliste vollständig ist. Wenn die DMARC-Berichte ein paar Wochen lang keine unbekannten, legitimen Absender mehr zeigen, stell auf -all um. Unsere jüngeren Domains (tacilytics.com und eine weitere) haben das von Anfang an, weil dort sicher nur ein einziger Server sendet. getmind.io steht noch auf ~all, das Umstellen ist auf unserer Liste.

Eine Falle sollte man kennen: SPF bricht bei Weiterleitungen. Leitet ein Empfänger seine Mails von alt@firma.de an Gmail weiter, liefert jetzt der Server von firma.de die Mail bei Gmail ein, und der steht nicht in deinem SPF. Genau deshalb braucht es DKIM: Die Signatur reist mit der Mail und übersteht die Weiterleitung, solange niemand den Inhalt verändert.

DKIM einrichten: die Signatur für jede Mail

DKIM steht für DomainKeys Identified Mail. Dein Mailserver signiert jede ausgehende Mail mit einem privaten Schlüssel. Den passenden öffentlichen Schlüssel legst du im DNS ab. Der Empfänger holt ihn, prüft die Signatur und weiß danach zweierlei: Diese Mail wurde von jemandem signiert, der den Schlüssel der Domain hat, und sie wurde seitdem nicht verändert.

Schritt 1: Schlüssel erzeugen lassen

Bei Google Workspace, Microsoft 365 und fast allen deutschen Hostern erzeugst du den Schlüssel im Admin-Bereich mit einem Klick. Der Anbieter zeigt dir danach den DNS-Eintrag an, den du anlegen musst. Bei Microsoft 365 sind das zwei CNAME-Einträge (selector1._domainkey und selector2._domainkey), die auf Microsofts eigene Schlüssel zeigen. Das hat den Vorteil, dass Microsoft die Schlüssel tauschen kann, ohne dass du dein DNS anfassen musst. Bei outlook.com selbst sieht man genau dieses Muster: Der Selektor ist ein CNAME auf outbound.protection.outlook.com.

Wenn du einen eigenen Mailserver mit Postfix betreibst, erledigt das meist OpenDKIM:

# Schlüssel erzeugen (2048 Bit, Selektor "mail")
opendkim-genkey -b 2048 -d beispiel.de -s mail -D /etc/opendkim/keys/beispiel.de/

# Die Datei mail.txt enthält den fertigen DNS-Eintrag
cat /etc/opendkim/keys/beispiel.de/mail.txt

Damit OpenDKIM die Domain auch signiert, muss sie in der KeyTable und SigningTable stehen. Das klingt banal, aber genau hier sind wir selbst schon gestolpert: Unser Mailanbieter nutzt ein Admin-Panel, das neue Domains nicht automatisch in diese beiden Dateien schreibt. Der DNS-Eintrag war da, die Mails gingen raus, signiert wurde trotzdem nichts. Bemerkt haben wir es erst, weil wir uns den Header einer Testmail angesehen haben. Seitdem gilt bei uns: Nach dem Einrichten immer eine Testmail schicken und den DKIM-Signature-Header suchen.

Schritt 2: Den öffentlichen Schlüssel im DNS veröffentlichen

Der Eintrag liegt nicht auf der Domain selbst, sondern auf selektor._domainkey.deinedomain. Der Selektor ist ein frei wählbarer Name, mit dem du mehrere Schlüssel parallel betreiben kannst. Unserer heißt schlicht default:

$ dig +short TXT default._domainkey.getmind.io
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...IDAQAB"

Zwei Details aus unserer Messung, die in vielen Anleitungen fehlen:

• Schlüssellänge. Der Schlüssel von getmind.io hat 2048 Bit, die von zwei neueren Domains nur 1024 Bit, obwohl alle drei beim selben Anbieter liegen. Das Panel hat für neuere Domains offenbar einen kürzeren Standard gewählt. 1024 Bit wird von allen großen Empfängern noch akzeptiert, gilt aber als Auslaufmodell. Wer neu einrichtet, nimmt 2048.
• Länge des Eintrags. Ein 2048-Bit-Eintrag ist bei uns 410 Zeichen lang. Ein einzelner String in einem TXT-Eintrag darf aber höchstens 255 Zeichen haben. Deshalb steht der Schlüssel im DNS als zwei Strings, die der Empfänger aneinanderhängt. Viele DNS-Oberflächen teilen das automatisch, manche nicht. Wenn deine Oberfläche einen Fehler wirft oder den Schlüssel abschneidet, ist das der Grund.

Schritt 3: Testen, und zwar richtig

Wir haben über unseren Anbieter eine Testmail an uns selbst geschickt und den Header angesehen:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=getmind.io;
    s=default; t=1794384428; bh=jyFIZOmU9cBrJGS/...; h=From:To:Subject;
    b=LZUiMBgDRom6Rn4FrZwX5npto7MIRei7...

Die wichtigen Felder: d=getmind.io ist die signierende Domain, s=default der Selektor, bh= ein Hash über den Text der Mail, h= die Liste der mitsignierten Header-Felder und c=relaxed/simple die Art, wie Header und Text vor dem Hashen „normalisiert” werden.

Dann haben wir die empfangene Mail mit der Python-Bibliothek dkimpy geprüft und gezielt verändert:

Das Leerzeichen-Ergebnis erklärt sich aus c=relaxed/simple: Der zweite Teil, simple, gilt für den Text und verzeiht dort fast nichts, nur Leerzeilen ganz am Ende. Mit relaxed/relaxed hätte das doppelte Leerzeichen die Signatur nicht gebrochen. Das ist der Grund, warum manche Mailinglisten und Virenscanner, die Fußzeilen anhängen oder Zeilen umbrechen, DKIM-Signaturen zerstören.

Das zweite Ergebnis hat uns ehrlich überrascht: Unser Anbieter signiert nur From, To und Subject. Datum, Message-ID und alle anderen Felder sind nicht geschützt. Das ist zulässig (nur From ist Pflicht), aber schwach: Wer eine signierte Mail abfängt, kann sie mit neuem Datum erneut verschicken, und die Signatur bleibt gültig. Bei eigenen Servern lohnt es sich, in OpenDKIM die Liste der signierten Felder zu erweitern (SignHeaders bzw. OversignHeaders).

Ein weiterer Fallstrick aus demselben Test: Weil Absender und Empfänger auf demselben Server lagen, hat der Server keinen Authentication-Results-Header eingefügt. Wer sich nur auf diesen Header verlässt, sieht bei Tests an sich selbst also gar nichts. Für einen aussagekräftigen Test schickst du die Mail an ein Postfach bei einem großen Anbieter (zum Beispiel Gmail) und schaust dort unter „Original anzeigen” nach dkim=pass, spf=pass und dmarc=pass.

Schlüssel tauschen

DKIM-Schlüssel sollten nicht ewig leben. Ein vernünftiger Rhythmus ist einmal im Jahr. Der Trick ist der Selektor: Du legst einen neuen Schlüssel mit neuem Selektor an (zum Beispiel 2026a), veröffentlichst ihn im DNS, stellst den Server um und lässt den alten Eintrag noch ein paar Tage stehen, damit Mails, die noch unterwegs sind, prüfbar bleiben. Danach löschst du ihn.

DMARC einrichten: die Regel und die Berichte

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist der Teil, der SPF und DKIM überhaupt erst wirksam macht. Er tut drei Dinge:

1. Er verlangt, dass SPF oder DKIM bestanden ist und dass die geprüfte Domain zur sichtbaren From:-Adresse passt (Alignment).
2. Er sagt dem Empfänger, was er mit Mails tun soll, die das nicht schaffen: nichts (none), in den Spam (quarantine) oder ablehnen (reject).
3. Er lässt sich Berichte schicken, wer alles in deinem Namen Mails verschickt.

Alignment verstehen

Das ist der Punkt, an dem die meisten Einrichtungen scheitern. Ein Beispiel: Dein Newsletter-Dienst verschickt deine Mails mit From: news@beispiel.de, aber mit der technischen Absenderadresse bounce@mail.newsletterdienst.com und signiert mit d=newsletterdienst.com. SPF besteht (für newsletterdienst.com), DKIM besteht (für newsletterdienst.com). DMARC trotzdem nicht, weil keine der beiden Domains zu beispiel.de passt.

Die Lösung ist fast immer dieselbe: Im Dienst eine eigene Absenderdomain einrichten (heißt meist „Domain authentifizieren”), damit er mit d=beispiel.de signiert. Dafür legst du die CNAME- oder TXT-Einträge an, die der Dienst dir anzeigt.

Bei unserer Testmail war alles im Lot: From: thenyx@getmind.io, technischer Absender (Return-Path) ebenfalls getmind.io, DKIM mit d=getmind.io. Beide Prüfungen hätten also unabhängig voneinander für DMARC gereicht.

Es gibt zwei Strengegrade: adkim=r / aspf=r (relaxed, Standard) akzeptiert auch Subdomains, also passt mail.beispiel.de zu beispiel.de. adkim=s / aspf=s (strict) verlangt exakt dieselbe Domain. Posteo und Proton fahren strict, für die meisten Firmen reicht relaxed.

Schritt 1: Mit p=none anfangen

Lege einen TXT-Eintrag auf _dmarc.deinedomain an:

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

p=none ändert an der Zustellung nichts. Du bekommst aber ab jetzt von Gmail, Microsoft, Yahoo, GMX und vielen anderen täglich einen Aggregatbericht an die Adresse aus rua=: eine XML-Datei, meist gezippt, mit allen IP-Adressen, die in den letzten 24 Stunden Mails mit deiner Domain verschickt haben, und ob SPF und DKIM gepasst haben. So steht es auch bei getmind.io: p=none mit Berichten an ein eigenes Postfach.

Ein praktischer Hinweis: Nimm für rua= ein eigenes Postfach oder einen Alias. Bei einer aktiven Domain kommen jeden Tag mehrere Berichte, und dein normales Postfach soll davon nicht zuwachsen. Soll die Adresse auf einer anderen Domain liegen, muss diese das ausdrücklich erlauben (mit einem Eintrag beispiel.de._report._dmarc.andere-domain.de), sonst verwerfen viele Empfänger die Berichte still.

Schritt 2: Berichte auswerten

Die XML-Berichte sind für Menschen schwer lesbar. Es gibt kostenlose Auswerter (zum Beispiel parsedmarc als Open-Source-Werkzeug zum Selbsthosten) und kommerzielle Dienste mit kostenlosen Einstiegstarifen. Was du darin suchst:

• Unbekannte, aber legitime Absender: das CRM, das niemand erwähnt hat, das alte Kontaktformular. Die nimmst du in SPF auf oder richtest DKIM für sie ein.
• Absender mit DKIM-Fail: oft Weiterleitungen oder Mailinglisten, die den Text verändern. Die kannst du meist ignorieren.
• Fremde IPs, die deine Domain fälschen: Genau gegen die richtet sich der nächste Schritt.

Plane für diese Phase zwei bis vier Wochen ein. Bei kleinen Domains mit einem einzigen Mailanbieter reicht oft eine Woche.

Schritt 3: Schrittweise verschärfen

# Phase 2: Fälschungen in den Spam, erst mal nur für ein Viertel
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de"

# Phase 3: alle in den Spam
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de"

# Ziel: ablehnen
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de"

pct= ist ein Hilfsmittel für die Übergangszeit, wird aber von einigen Empfängern nur grob beachtet und ist in der Überarbeitung des Standards umstritten. Verlass dich nicht darauf, sondern schau in die Berichte.

Mit sp= legst du eine eigene Policy für Subdomains fest. Das ist wichtig, weil Angreifer gern auf Subdomains ausweichen, die es gar nicht gibt (rechnung.beispiel.de). Gmail, Outlook und GitHub machen das bewusst so: Die Hauptdomain ist nachsichtiger als die Subdomains.

Die Tags im Überblick

Zu ruf= ein deutlicher Hinweis: Einzelberichte können Teile echter Mails enthalten, inklusive Empfängeradressen. In der EU ist das datenschutzrechtlich heikel, und die meisten großen Anbieter schicken sie deshalb gar nicht. Wir empfehlen, ruf= wegzulassen.

Domains, die gar keine Mails verschicken

Diesen Teil vergessen fast alle, und wir haben ihn bei unseren eigenen Domains auch vergessen. heynyx.dev und nyx.fish verschicken keine Mails. Trotzdem kann jeder eine Mail mit absender@heynyx.dev erzeugen. Unser SPF-Test für eine beliebige fremde IP:

203.0.113.9  heynyx.dev   ('none', '')
203.0.113.9  tacilytics.com  ('fail', 'SPF fail - not authorized')

„none” heißt: Die Domain hat keine Meinung. Kein Spamfilter lehnt eine Mail deswegen ab. „fail” bei tacilytics.com heißt dagegen: Diese IP darf ausdrücklich nicht. Für Domains, die keine Mails senden, reichen drei Einträge, um Fälschungen praktisch unmöglich zu machen:

beispiel.de.         TXT  "v=spf1 -all"
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=reject;"
*._domainkey.beispiel.de.  TXT  "v=DKIM1; p="

Der erste sagt „niemand darf senden”, der zweite „lehnt alles ab”, der dritte (optional) erklärt alle DKIM-Schlüssel für widerrufen. Dazu passt ein Null-MX, wenn die Domain auch nichts empfangen soll. Den haben wir im MX-Artikel ausführlich getestet. Für unsere beiden Domains steht genau das auf unserer Liste.

Die häufigsten Fehler beim SPF, DKIM und DMARC einrichten

Aus unseren Messungen und unseren eigenen Stolpersteinen:

1. Zwei SPF-Einträge auf derselben Domain. Ergebnis: permerror, SPF wirkungslos. Immer zu einem zusammenfassen.
2. Tippfehler am Ende (~al, -al, all ohne Zeichen). Wir haben gemessen: ~al macht den ganzen Eintrag ungültig.
3. Mehr als 10 DNS-Abfragen. Kein Fehler beim Anlegen, aber permerror beim Empfänger. Regelmäßig nachzählen, vor allem nach neuen Diensten.
4. +all als vermeintlicher Fix. Erlaubt jedem Server der Welt, in deinem Namen zu senden.
5. DKIM im DNS, aber nicht am Server aktiv. Ist uns selbst passiert. Testmail schicken, Header lesen.
6. DKIM-Schlüssel abgeschnitten, weil die DNS-Oberfläche keine Strings über 255 Zeichen kann.
7. Newsletter-Dienst ohne eigene Domain-Authentifizierung. SPF und DKIM bestehen, DMARC trotzdem nicht.
8. Direkt mit p=reject starten. Dann fallen legitime Mails durch, die du nie gesehen hast. Immer mit p=none und Berichten beginnen.
9. Bei p=none stehen bleiben. Das ist der häufigste Fehler überhaupt. none schützt niemanden, es beobachtet nur.
10. Domains ohne Mailverkehr ungeschützt lassen. Die sind für Fälscher besonders attraktiv, weil sich dort niemand über Berichte wundert.
11. Eigener Server sendet direkt statt über den Anbieter. Unser VPS steht nicht in unserem SPF-Eintrag. Würde er direkt zustellen, bekäme er bei jedem Empfänger softfail. Wir haben das geprüft: Die IP des Anbieters ergibt pass, die IP unseres eigenen Servers softfail. Deshalb verschickt bei uns jedes Skript über den Anbieter, mit Anmeldung auf Port 587.

Checkliste: SPF, DKIM und DMARC einrichten in 30 Minuten

1. Liste aller Dienste machen, die mit deiner Domain Mails senden.
2. SPF: einen TXT-Eintrag v=spf1 … ~all auf der Domain anlegen, alle Dienste als include: oder ip4:. Nur ein Eintrag!
3. DNS-Abfragen zählen (mit einem SPF-Checker), unter 10 bleiben.
4. DKIM: beim Mailanbieter und bei jedem Dienst aktivieren, Einträge auf selektor._domainkey anlegen, 2048 Bit wählen.
5. Testmail an ein Gmail-Postfach schicken, „Original anzeigen”, spf=pass und dkim=pass mit deiner Domain prüfen.
6. DMARC: v=DMARC1; p=none; rua=mailto:… auf _dmarc anlegen.
7. Zwei bis vier Wochen Berichte lesen, fehlende Absender ergänzen.
8. Auf p=quarantine, dann auf p=reject umstellen. SPF auf -all.
9. Domains ohne Mailverkehr mit v=spf1 -all und p=reject sperren.
10. Einmal im Jahr: DKIM-Schlüssel tauschen, SPF-Liste aufräumen.

Wenn du deinen eigenen Mailserver auf einem VPS betreibst, gehört das zur Grundeinrichtung, genau wie Firewall und Updates. Mehr dazu in Linux-Server einrichten. Und wenn du HTTPS und Zertifikate für den Mailserver brauchst: SSL-Zertifikat erstellen.

FAQ: Häufige Fragen zu SPF, DKIM und DMARC

Brauche ich alle drei, oder reicht SPF?

Du brauchst alle drei. SPF allein bricht bei Weiterleitungen und prüft nicht die sichtbare Absenderadresse. DKIM allein sagt nicht, was bei einem Fehler passieren soll. Erst DMARC verbindet beides mit dem From:, das dein Empfänger sieht. Google, Yahoo und Microsoft verlangen von größeren Absendern ausdrücklich alle drei.

Wie lange dauert es, bis SPF, DKIM und DMARC wirken?

So lange, wie die TTL des Eintrags ist und die Empfänger ihre Caches leeren. Bei einem neuen Eintrag, der vorher nicht existierte, meist wenige Minuten. Bei einer Änderung eines bestehenden Eintrags bis zur alten TTL, typisch 5 Minuten bis 1 Stunde, selten länger.

Kann ich SPF, DKIM und DMARC auch ohne eigenen Mailserver einrichten?

Ja, das ist sogar der Normalfall. Du brauchst nur Zugriff auf das DNS deiner Domain. Die Schlüssel für DKIM erzeugt dein Mailanbieter, du kopierst nur den Eintrag.

Was bedeutet „SPF softfail” im Header?

Der einliefernde Server steht nicht auf deiner Liste, und dein Eintrag endet auf ~all. Die Mail wird meist trotzdem zugestellt, aber als verdächtig markiert. Wenn das bei deinen eigenen, echten Mails steht, fehlt ein Absender in deinem SPF-Eintrag.

Was ist ein DKIM-Selektor?

Ein frei wählbarer Name vor ._domainkey, unter dem der öffentliche Schlüssel liegt. Er steht in jeder Signatur als s=. Mit mehreren Selektoren kannst du mehrere Dienste oder einen alten und einen neuen Schlüssel gleichzeitig betreiben.

Welche DMARC-Policy soll ich nehmen?

Zum Start p=none mit rua=, um Berichte zu sammeln. Nach zwei bis vier Wochen p=quarantine, dann p=reject. Wer bei none stehen bleibt, hat zwar einen Eintrag, aber keinen Schutz.

Warum landen meine Mails trotz SPF, DKIM und DMARC im Spam?

Weil Authentifizierung nur die Eintrittskarte ist, keine Garantie. Spamfilter bewerten auch den Ruf deiner IP und Domain, die Beschwerderate, den Inhalt, Links, fehlende Abmeldelinks bei Newslettern und ob die IP einen passenden Rückwärtseintrag (PTR) hat. Erst wenn alle drei Prüfungen „pass” zeigen, lohnt es sich, dort weiterzusuchen.

Funktioniert DKIM nach einer Weiterleitung noch?

Meistens ja, solange der weiterleitende Server den Inhalt nicht verändert. SPF bricht bei Weiterleitungen dagegen fast immer. Mailinglisten, die Fußzeilen anhängen oder den Betreff ändern, zerstören auch DKIM. Wir haben gemessen: Ein geänderter Buchstabe im Betreff reicht.

Wie prüfe ich, ob meine Einträge stimmen?

Mit dig +short TXT deinedomain.de, dig +short TXT _dmarc.deinedomain.de und dig +short TXT selektor._domainkey.deinedomain.de. Zusätzlich eine Testmail an ein Gmail-Postfach schicken und unter „Original anzeigen” nachsehen. Online-Checker zählen außerdem die SPF-Abfragen.

Ist 1024 Bit für DKIM noch sicher?

Für die nächsten Jahre noch akzeptiert, aber nicht mehr empfohlen. Neue Schlüssel sollten 2048 Bit haben. Bei uns hat der Anbieter für ältere Domains 2048, für neuere 1024 Bit gewählt. Es lohnt sich also, nachzusehen, statt es anzunehmen.

Was ist BIMI?

BIMI zeigt dein Logo neben der Mail im Postfach an, aber nur, wenn DMARC auf quarantine oder reject steht. Für die meisten kleinen Firmen ist das ein späterer Schritt. Erst SPF, DKIM und DMARC sauber, dann über BIMI nachdenken.

Fazit: Einrichten ist leicht, Durchziehen ist der Teil, der zählt

SPF, DKIM und DMARC einzurichten kostet eine halbe Stunde und drei TXT-Einträge. Schwierig ist etwas anderes: die vollständige Liste der Absender, das 10-Lookup-Limit im Blick behalten, und vor allem nicht bei p=none stehen bleiben. Unsere eigenen Messungen haben uns an genau diesen Stellen ehrlich gemacht. getmind.io steht noch auf ~all und p=none, zwei unserer Domains haben gar keinen Schutz, und unser Anbieter signiert weniger Header, als wir dachten. Nichts davon hätte eine Fehlermeldung erzeugt. Es fällt nur auf, wenn man nachsieht.

Unsere Empfehlung: Heute SPF und DKIM prüfen, eine Testmail an Gmail schicken, DMARC mit p=none und Berichten anlegen. Und dir einen Termin in drei Wochen setzen, an dem du auf quarantine umstellst.