SPF, DKIM und DMARC einrichten: Anleitung für den eigenen Mailversand

Drei Kürzel, drei DNS-Einträge, und ohne sie landen deine Mails zunehmend im Spam-Ordner oder gar nicht erst beim Empfänger. Dieser Text erklärt, was jedes der drei Verfahren tatsächlich prüft, wie die Einträge aussehen und in welcher Reihenfolge du sie einführst, ohne dass zwischendurch etwas ausfällt.

Die drei Verfahren in je drei Sätzen

SPF beantwortet die Frage, welche Server für deine Domain senden dürfen. Du hinterlegst eine Liste im DNS, der Empfänger vergleicht sie mit der IP-Adresse, von der die Mail kam. Passt sie nicht, ist das ein Verdachtsmoment.

DKIM versieht jede einzelne Mail mit einer kryptografischen Signatur. Der öffentliche Schlüssel steht im DNS, der Empfänger rechnet nach. Stimmt die Signatur, wurde die Mail unterwegs nicht verändert und stammt von jemandem, der den privaten Schlüssel besitzt.

DMARC ist die Regel für den Fall, dass SPF und DKIM nicht passen. Du legst fest, ob der Empfänger die Mail trotzdem zustellen, in den Spam-Ordner legen oder abweisen soll. Zusätzlich bekommst du Berichte darüber, wer in deinem Namen sendet.

Die Reihenfolge ist kein Zufall: DMARC funktioniert nur, wenn SPF und DKIM vorher stehen.

SPF: wer darf für deine Domain senden

Ein SPF-Eintrag ist ein TXT-Eintrag auf der Domain selbst. Er sieht typischerweise so aus:

v=spf1 include:spf.spamgo.de include:spf.protection.outlook.com -all

Der Eintrag, Feld für Feld

• v=spf1 ist die Versionsangabe und muss am Anfang stehen.
• include: holt die Serverliste eines anderen Anbieters dazu. Das ist der übliche Weg: Du nennst nicht einzelne IP-Adressen, sondern verweist auf den Anbieter, der seine Liste selbst pflegt. Ein Serverwechsel bei ihm bricht deinen Eintrag dann nicht.
• ip4: und ip6: nennen einzelne Adressen oder Netze. Nötig, wenn ein Gerät oder Server mit fester IP direkt versendet.
• -all am Ende bedeutet: alles andere ist nicht erlaubt. Die weichere Variante ~all heißt nur „verdächtig". Beginne mit ~all und stelle später um.

Wichtig ist die Einzahl: pro Domain darf es genau einen SPF-Eintrag geben. Zwei Einträge sind ein Fehler, den viele Prüfwerkzeuge nicht deutlich genug melden, und das Ergebnis ist ein SPF, der bei manchen Empfängern schlicht als ungültig gilt. Wenn du einen weiteren Anbieter aufnimmst, ergänzt du einen include: im vorhandenen Eintrag.

Das Zehn-Lookup-Limit

Jeder include: löst beim Empfänger eine DNS-Abfrage aus, und die Liste dahinter kann weitere enthalten. Der Standard erlaubt insgesamt zehn solcher Abfragen. Wer darüber kommt, bekommt kein „fast bestanden", sondern einen dauerhaften Fehler, und die Prüfung schlägt fehl, als gäbe es gar keinen SPF-Eintrag.

Das trifft in der Praxis Unternehmen, die über die Jahre Mailanbieter, Newsletter-Werkzeug, CRM, Ticketsystem und Buchhaltungssoftware aufgenommen haben. Gegenmittel: Einträge herauswerfen, die niemand mehr braucht, und Dienste, die nur von einer festen IP senden, direkt als ip4: aufnehmen statt über include:.

DKIM: die Signatur, die unterwegs nicht kaputtgeht

SPF hat eine Schwäche: Es prüft die sendende IP-Adresse. Wird eine Mail weitergeleitet, ändert sich diese Adresse, und SPF schlägt fehl, obwohl die Mail echt ist. DKIM hat dieses Problem nicht, weil die Signatur in der Mail selbst steckt und die Weiterleitung sie nicht berührt.

Beim Versand signiert der Mailserver bestimmte Kopfzeilen und den Inhalt mit einem privaten Schlüssel. Der passende öffentliche Schlüssel steht als TXT-Eintrag im DNS, unter einem Namen wie mb1._domainkey.deinefirma.de.

Selector, Schlüssellänge, Rotation

Der Teil vor ._domainkey heißt Selector. Er existiert, damit mehrere Absender nebeneinander signieren können: Dein Mailanbieter nutzt einen Selector, dein Newsletter-Werkzeug einen anderen, und beide stören sich nicht. Versendest du über mehrere Server, brauchst du entsprechend mehrere DKIM-Einträge. Lege alle an, sonst signieren nur manche Mails gültig.

Zur Schlüssellänge: 2048 Bit sind heute der Normalfall, 1024 Bit gelten als überholt. Manche DNS-Anbieter erlauben keine so langen TXT-Werte am Stück; dann muss der Wert in mehrere Zeichenketten aufgeteilt werden, was die meisten Oberflächen automatisch tun.

Schlüssel gelegentlich zu wechseln ist sinnvoll, aber kein Grund für Nachtschichten. Der übliche Ablauf: neuen Selector anlegen, im DNS veröffentlichen, den Versand darauf umstellen, den alten Eintrag noch einige Tage stehen lassen, dann löschen.

DMARC: die Regel, wenn etwas nicht passt

DMARC ist ein TXT-Eintrag unter _dmarc.deinefirma.de:

v=DMARC1; p=none; rua=mailto:dmarc@deinefirma.de; pct=100

Entscheidend ist p=, die Richtlinie. Und ein Detail, das oft untergeht: DMARC prüft nicht nur, ob SPF oder DKIM bestehen, sondern ob die dabei geprüfte Domain zur sichtbaren Absenderadresse passt. Das nennt sich Alignment. Eine Mail kann SPF bestehen und trotzdem an DMARC scheitern, wenn der technische Absender zu einer anderen Domain gehört als der, die im Postfach angezeigt wird.

none, quarantine, reject in der richtigen Reihenfolge

• p=none: nichts passiert, du bekommst nur Berichte. Der richtige Anfang, aber kein Zustand für die Ewigkeit.
• p=quarantine: nicht bestandene Mails gehen in den Spam-Ordner.
• p=reject: sie werden abgewiesen.

Der Weg führt immer von none über quarantine zu reject, mit mehreren Wochen dazwischen. Wer sofort auf reject geht, entdeckt vergessene Absender daran, dass Kunden anrufen. Mit pct= lässt sich die Richtlinie zunächst auf einen Teil der Mails anwenden, etwa pct=25.

Berichte lesen, ohne davon Vollzeit zu leben

Die Adresse hinter rua= bekommt täglich XML-Berichte von den großen Empfängern. Von Hand sind die kaum lesbar. Lege dafür ein eigenes Postfach an und nutze einen Auswertungsdienst, oder sieh sie nur in den ersten Wochen durch, wenn es darum geht, unbekannte Absender aufzuspüren. Genau dafür ist die Phase mit p=none da.

Reihenfolge der Umstellung ohne Zustellausfall

1. Alle Absender sammeln: Mailanbieter, Newsletter, CRM, Shop, Ticketsystem, Drucker, Buchhaltung. Diese Liste ist meistens länger als gedacht.
2. SPF ergänzen, zunächst mit ~all. Auf die Zehn-Lookup-Grenze achten.
3. DKIM für jeden Absender einrichten, der es anbietet. Alle Selectoren im DNS anlegen.
4. DMARC mit p=none veröffentlichen und zwei bis vier Wochen Berichte sammeln.
5. Auffällige Absender klären: entweder in SPF und DKIM aufnehmen oder abschalten.
6. Auf p=quarantine gehen, weitere Wochen beobachten, dann auf p=reject und SPF auf -all.

DNS-Änderungen brauchen je nach Anbieter bis zu 24 Stunden, bis sie überall sichtbar sind. Plane deshalb nicht mehrere Schritte auf einen Tag.

Häufige Fehler

• Zwei SPF-Einträge. Der häufigste Fehler überhaupt, meist entstanden, weil jemand einen zweiten Anbieter aufgenommen hat, ohne den bestehenden Eintrag zu ergänzen.
• DMARC ohne DKIM. Funktioniert formal, hält aber Weiterleitungen nicht aus. Eine an eine Verteilerliste geschickte Mail scheitert dann regelmäßig.
• Der Eintrag am falschen Ort. DKIM und DMARC gehören auf Unterdomains (selector._domainkey und _dmarc), SPF auf die Domain selbst. Manche Oberflächen hängen den Domainnamen automatisch an, andere nicht, und dann steht der Eintrag doppelt gemoppelt im Nichts.
• Nach dem Anlegen nie wieder hingesehen. Einträge verschwinden bei Anbieterwechseln oder werden von Kollegen überschrieben. Eine regelmäßige Prüfung gehört dazu.

Wie MailBridge das abnimmt

Im Portal legst du deine Absenderdomain an und siehst für SPF, DKIM und DMARC jeweils den gefundenen und den erwarteten Eintrag nebeneinander, mit Kopierknopf für Host, Typ und Wert. Der SPF-Vorschlag ergänzt deinen bestehenden Eintrag, statt ihn zu ersetzen. Steht deine DMARC-Richtlinie noch auf p=none, schlägt das Portal die Umstellung vor. Alle Domains werden täglich geprüft; bricht später ein Eintrag, erscheint das als Handlungsbedarf im Dashboard.

Die Bedienung dazu steht in der Anleitung zu Domains und DNS. Wenn dein Versand über Microsoft 365 lief und dort nicht mehr angenommen wird, hilft der Beitrag zu SMTP-Relay für Microsoft 365 weiter.