SPF und DKIM bei Gandi einrichten

Von Thomas · virtueller CISO · 2026-07-24

Eine bei Gandi registrierte Domain startet mit einem stillen Vorsprung: Die DNS-Zone kommt nicht leer an. Die MX-Einträge zeigen vom ersten Tag an auf den hauseigenen Maildienst, und ein SPF-Eintrag mit Verweis auf _mailcust.gandi.net steht schon im Zonen-Template, bevor die erste Webmail-Anmeldung stattfindet. Das ist besser als die leere Seite, die viele Hoster liefern — aber dieser Vorsprung nährt eine Illusion: die einer „bereits authentifizierten" Domain. Ein standardmäßig gesetztes SPF mit neutralem Qualifikator, ohne aktiviertes DKIM und ohne veröffentlichtes DMARC schützt so gut wie nichts: Es dokumentiert, es verbietet nichts.

Dieser Leitfaden geht den kompletten Weg auf der Gandi-Seite durch: was GandiMail und LiveDNS genau abdecken, was das standardmäßig vorgeschlagene SPF wert ist und ab wann es nicht mehr reicht, wie DKIM aktiviert wird und was sich hinter den Selektoren gm1 bis gm3 verbirgt, wie sich die Zone bearbeiten lässt — Weboberfläche, Textmodus oder API — und wie der sehr verbreitete Fall zu behandeln ist, in dem die Domain bei Gandi registriert ist, die Postfächer aber bei Microsoft 365 oder Google Workspace leben.

Die Logik wäre bei jedem Registrar dieselbe: ein einziges SPF, das zusammengeführt wird, DKIM-Schlüssel, die veröffentlicht werden, eine Zone, die sauber zu bearbeiten ist, eine Prüfung am Ende. Der entsprechende Leitfaden für OVHcloud folgt demselben Aufbau; hier geht es um die Besonderheiten von Gandi.

GandiMail und LiveDNS: zwei Bausteine, die zu trennen sind

Gandi vereint drei Rollen, die gedanklich besser auseinandergehalten werden. Die erste ist die des Registrars: die Miete des Domainnamens selbst. Die zweite ist LiveDNS, die hauseigene DNS-Plattform — Nameserver unter ns-…-a/b/c.gandi.net, standardmäßig bei jeder neuen Domain —, die die Zone und ihre Einträge beherbergt. Die dritte ist GandiMail, der Maildienst: Postfächer, Webmail, IMAP und SMTP über mail.gandi.net. Diese drei Bausteine lassen sich frei kombinieren: Eine bei Gandi registrierte Domain kann ihre Zone an einen anderen DNS-Hoster delegieren, und eine LiveDNS-Zone kann problemlos einen fremden Maildienst bedienen. Der Kardinalpunkt des ganzen Themas passt in einen Satz: SPF und DKIM werden dort veröffentlicht, wo die DNS-Zone lebt, nicht dort, wo die Postfächer leben.

Eine zeitliche Einordnung gehört dazu. Die zwei historisch mit jeder Domain gebündelten Postfächer sind aus dem Angebot verschwunden: Seit Ende 2023 ist GandiMail eine kostenpflichtige Option. Viele Gandi-Domains haben also gar kein aktives Gandi-Postfach mehr — doch die Zone trägt weiterhin die Einträge des ursprünglichen Templates: MX auf spool.mail.gandi.net und fb.mail.gandi.net, das hauseigene SPF. Das Ergebnis sind Zonen, die einen Maildienst ankündigen, den es nicht mehr gibt. Das Aufräumen dieser Überbleibsel ist fester Bestandteil der Authentifizierungsarbeit: Jeder Eintrag, der keiner realen Nutzung mehr entspricht, ist eine verschwendete DNS-Auflösung und eine zusätzliche Zeile Verwirrung im Inventar.

Das von Gandi vorgeschlagene SPF: wann es reicht, wann es erweitert werden muss

Das Gandi-Zonen-Template setzt an der Wurzel der Domain einen Eintrag dieser Art:

@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"

Entschlüsselt: Das include delegiert an Gandi die Liste der sendeberechtigten IP-Adressen — die ausgehenden Relays von GandiMail, die Gandi weiterentwickelt, ohne dass die Zone des Kunden sich je bewegen muss. Das abschließende ?all ist ein neutraler Qualifikator: Es sagt nichts über Server außerhalb der Liste aus. Für einen automatisch gesetzten Eintrag ist das eine vorsichtige Wahl, aber ein neutrales SPF erlaubt auf Empfängerseite keinerlei Ablehnung — es beobachtet, ohne sich festzulegen.

Wann reicht dieses SPF? Solange die gesamte Post der Domain über GandiMail hinausgeht — Webmail, IMAP/SMTP-Client über mail.gandi.net —, deckt das include sämtliche Sendungen ab. Die einzige verbleibende Arbeit ist die Härtung des Qualifikators: ~all (Softfail) während der Beobachtungsphase, dann -all, sobald die DMARC-Berichte das Inventar bestätigt haben.

Wann reicht es nicht mehr? In dem Moment, in dem ein externer Versender ins Spiel kommt: Newsletter über Mailjet oder Brevo, Transaktionsmails über SendGrid oder Amazon SES, ein CRM, das „im Namen der" Domain sendet. Die goldene Regel lautet dann zusammenführen, niemals hinzufügen: ein einziger v=spf1-Eintrag, dessen Mechanismenliste wächst.

v=spf1 include:_mailcust.gandi.net include:spf.mailjet.com ~all

Ein zweites v=spf1-TXT neben dem ersten erzeugt einen permerror — SPF-Fehlschlag für alle, legitime Flüsse eingeschlossen. Und die Grenze von zehn DNS-Auflösungen lauert: Jedes include zählt, und die der ESPs verschachteln oft mehrere weitere.

DKIM bei GandiMail: eine Aktivierung, drei Selektoren

SPF authentifiziert den sendenden Server; DKIM signiert die Nachricht selbst, und die Signatur überlebt Weiterleitungen. Bei GandiMail beginnt die Aktivierung im E-Mail-Bereich der Domain-Verwaltung — ein eigener Button stößt alles an; der genaue Pfad durch die Oberfläche verschiebt sich mit jedem Redesign, und die Gandi-Dokumentation bleibt in diesem Punkt die einzige aktuelle Referenz. Was die Aktivierung erzeugt, ist dagegen stabil: drei CNAME-Einträge.

gm1._domainkey 10800 IN CNAME gm1.gandimail.net.
gm2._domainkey 10800 IN CNAME gm2.gandimail.net.
gm3._domainkey 10800 IN CNAME gm3.gandimail.net.

Liegt die Zone auf LiveDNS, werden diese drei Zeilen automatisch hinzugefügt. Ist das DNS anderswo delegiert, müssen sie beim Zonen-Hoster von Hand angelegt werden — gleiche Namen, gleiche Ziele. Die Eleganz der Konstruktion liegt im CNAME: Der öffentliche Schlüssel bleibt bei Gandi gehostet, das ihn erneuern kann, ohne dass die Zone der Domain sich je ändert. Die drei Selektoren gm1, gm2 und gm3 existieren genau für diese Rotation: Während ein Schlüssel signiert, bereitet sich der nächste vor. Das ist ein echter operativer Vorteil gegenüber dem eingefrorenen TXT, das einmal eingefügt und dann jahrelang vergessen wird — die Rotation der DKIM-Schlüssel ist eine Hygiene, die kaum ein Team durchhält, solange sie manuell bleibt.

Die LiveDNS-Zone bearbeiten: Oberfläche, Textmodus, API

LiveDNS bietet drei Zugänge, und jeder hat seine Falle. Die Weboberfläche zeigt die Zone Eintrag für Eintrag: Typ, Name, TTL, Wert. Ein TXT ist in wenigen Klicks hinzugefügt, die Anführungszeichen werden verwaltet, und Zeichenketten über 255 Zeichen — typischerweise ein 2048-Bit-DKIM-Schlüssel — werden automatisch aufgeteilt. Der Textmodus zeigt die gesamte Zone wie eine Zonendatei: praktisch, um mehrere Einträge auf einmal einzufügen, aber es gelten die Syntaxregeln von Zonendateien, Punkt am Ende inklusive (die Pannenliste unten kommt darauf zurück). Die LiveDNS-REST-API (v5) schließlich öffnet die Automatisierung: Authentifizierung per persönlichem Zugriffstoken, ein HTTP-Request pro geschriebenem Eintrag — der natürliche Weg, um SPF und DKIM als Infrastructure-as-Code zu verwalten, mit den Terraform- und Ansible-Konnektoren, die darauf aufbauen.

Eine übergreifende Einstellung verdient Aufmerksamkeit: die TTL, standardmäßig 10800 Sekunden (drei Stunden). Vor einem Eingriff an SPF oder DKIM verkürzt ein Absenken auf 300 Sekunden das Korrekturfenster, falls sich ein Fehler einschleicht; danach geht es wieder hinauf. Für Domains, die bei Gandi registriert sind, deren Zone aber an Cloudflare delegiert ist, wird dieselbe Übung auf Cloudflare-Seite — mit eigenen Fallen, allen voran dem orangefarbenen Proxy — in dem eigenen Cloudflare-Leitfaden behandelt.

Domain bei Gandi, Postfächer anderswo: nur die Werte ändern sich

Das ist vermutlich der häufigste Fall: Domain und Zone leben bei Gandi, die Postfächer bei Microsoft 365 oder Google Workspace. An der Methode ändert sich nichts — nur die Einträge ändern sich.

Auf der Microsoft-365-Seite wird das SPF zu v=spf1 include:spf.protection.outlook.com -all, und DKIM nimmt die Form zweier CNAMEs an, selector1._domainkey und selector2._domainkey, die auf den Tenant unter onmicrosoft.com zeigen; die Signatur wird im Defender-Portal eingeschaltet. Auf der Google-Workspace-Seite: SPF v=spf1 include:_spf.google.com ~all, und DKIM als TXT google._domainkey, dessen Schlüssel — 2048 Bit empfohlen — in der Admin-Konsole erzeugt und dann in LiveDNS eingefügt wird, das die Aufteilung der langen Zeichenkette übernimmt.

Zwei Reflexe runden das Bild ab. Erstens: include:_mailcust.gandi.net entfernen, sobald keine Nachricht mehr über GandiMail hinausgeht — ein totes Include verbraucht eine der zehn erlaubten DNS-Auflösungen und weitet die autorisierte Fläche ohne Gegenleistung aus. Zweitens: die Gandi-MX des Templates durch die des tatsächlichen Anbieters ersetzen — MX-Einträge, die auf spool.mail.gandi.net zeigen, während die Postfächer bei Microsoft liegen, leiten eingehende Post fehl und trüben die Diagnose.

Die häufigen Fehler, vom SPF-Duplikat bis zum Punkt am Ende

DMARC-Berichte und Community-Foren erzählen immer dieselben Geschichten. Eine kleine Pannenliste:

Das SPF-Duplikat. Die vorbefüllte Zone enthält bereits ein v=spf1; der Einrichtungsassistent eines ESP empfiehlt, ein eigenes hinzuzufügen; beide koexistieren, und heraus kommt ein permerror. Die Zusammenführung in einen einzigen Eintrag ist der einzige Ausweg.
Der alte SPF-Typ. Zonen, die aus Gandis „klassischer" DNS-Infrastruktur geerbt wurden, können noch einen Eintrag vom Typ SPF (Typ 99) tragen, längst durch RFC 7208 abgekündigt: Nur das TXT zählt, das Typ-Duplikat stiftet Verwirrung und gehört gelöscht.
Der Punkt am Ende. Im Textmodus wird aus gm1.gandimail.net ohne abschließenden Punkt gm1.gandimail.net.beispiel.de. — ein CNAME, der nichts auflöst. Das Webformular vervollständigt den Namen implizit, der Textmodus nicht: Die Regel hängt vom benutzten Editor ab, daher die Überraschungen beim Kopieren einer Zeile von einem Kontext in den anderen.
Die Ungeduld. Bei einer Standard-TTL von drei Stunden liefern die Resolver den alten Wert weiter aus, bis der Cache abläuft. Dreißig Sekunden nach der Änderung zu testen und auf Fehlschlag zu schließen ist ein Klassiker der DNS-Propagation.
Die vergessene Subdomain. SPF wird nicht vererbt: Eine sendende Subdomain (newsletter.beispiel.de) braucht einen eigenen Eintrag.

Der nächste Schritt hat seine eigene Pannenliste: die DMARC-Syntax mit ihren Semikolons und Stolper-Tags, katalogisiert in den Syntaxfehlern eines DMARC-Eintrags.

Prüfen, dann DMARC anschließen

Die Prüfung wird nicht geraten, sie wird gemessen. Auf der Kommandozeile decken zwei Abfragen das Wesentliche ab:

dig TXT beispiel.de +short
dig CNAME gm1._domainkey.beispiel.de +short

Die erste muss ein einziges v=spf1… zurückgeben, die zweite das Ziel gm1.gandimail.net.. Der Realitätstest vervollständigt die Kontrolle: eine Nachricht an ein Gmail-Postfach, dann die Lektüre des Headers Authentication-Results — spf=pass und dkim=pass mit einem der Selektoren gm1 bis gm3 sind die Unterschrift einer gesunden Konfiguration.

Sind SPF und DKIM gesetzt, bleibt der Anschluss der Ebene, die beide auswertet: DMARC, als TXT auf _dmarc.beispiel.de, beginnend mit v=DMARC1; p=none; rua=mailto:…, um zu beobachten, ohne etwas zu blockieren. Statt die Syntax zu improvisieren, ist der sicherere Start eine Sammlung kommentierter DMARC-Eintrag-Beispiele zum Anpassen. Die aggregierten Berichte enthüllen dann, was das Inventar übersehen hat — den alten Server, der noch sendet, das von einer Tochter angeschlossene Tool — und leiten den Aufstieg zu p=quarantine und dann p=reject, dem Punkt, an dem sich die Fälschung der Domain nicht mehr lohnt.

Fazit

Gandi liefert eine vorbefüllte Zone, die zehn Minuten Vorsprung verschafft, keine vollständige Authentifizierung. Das hauseigene SPF include:_mailcust.gandi.net deckt GandiMail ab und sonst nichts: Es wird gehärtet (~all, dann -all) und zusammengeführt — niemals verdoppelt —, wenn ein ESP dazukommt. DKIM schaltet sich mit einem Button ein und ruht auf drei CNAMEs gm1 bis gm3, die die Schlüsselrotation in Gandis Händen lassen. Die Zone lässt sich per Formular, Textmodus oder API bearbeiten, mit dem Punkt am Ende und der Drei-Stunden-TTL als wiederkehrenden Fallen. Und wenn die Postfächer bei Microsoft 365 oder Google Workspace leben, bleibt die Methode bestehen: Nur die Werte ändern sich, sofern die GandiMail-Überbleibsel entsorgt werden. Für die genauen Oberflächenpfade, die sich mit jedem Redesign verschieben können, ist die Gandi-Dokumentation maßgeblich.

Die Schlusskontrolle kostet nichts: Ein Durchlauf der Domain durch die kostenlose DMARC-Analyse zeigt auf einen Blick den realen Zustand von SPF, DKIM und DMARC, so wie empfangende Server sie sehen. Und um den Versuch zu verwandeln — die Berichte verfolgen, die vergessene Quelle aufspüren, die Policy bis p=reject führen —, öffnet die Erstellung eines Kontos die kontinuierliche Überwachung, genau dort, wo die Zonenbearbeitung endet.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos