SPF und DKIM bei OVHcloud einrichten

Von Thomas · virtueller CISO · 2026-07-23

Ein beachtlicher Teil der europäischen Domains liegt bei OVHcloud: Der Registrar und Hoster aus Roubaix verwaltet mehrere Millionen DNS-Zonen, und ein guter Teil davon trägt auch die E-Mail der jeweiligen Organisation. DMARC allein urteilt über nichts: Es stützt sich vollständig auf SPF und DKIM, die beiden Mechanismen, die beweisen, dass eine Nachricht wirklich von dort kommt, wo sie herzukommen behauptet. Vor jedem Vorhaben einer p=reject-Policy müssen diese beiden Fundamente sauber gelegt sein — und bei OVHcloud hängt die Art, sie zu legen, zuerst vom gebuchten E-Mail-Angebot ab.

Die Schwierigkeit ist nicht technischer, sondern kartografischer Natur. MX Plan, Email Pro und Hosted Exchange teilen weder dieselbe Versandinfrastruktur noch denselben SPF-Wert noch denselben Weg zur DKIM-Aktivierung; die Anleitung des einen Angebots auf ein anderes anzuwenden ist der häufigste Fehler, der in der Praxis zu sehen ist. Hinzu kommt eine hausgemachte Falle: der SPF-Eintrag, den OVHcloud beim Anlegen einer Zone standardmäßig setzt — oft vergessen, Jahre später manchmal dupliziert.

Dieser Leitfaden geht die vollständige Konfiguration durch — Identifikation des Angebots, DNS-Zone, SPF je nach Fall, DKIM mit seinen CNAME-Selektoren, Fehler aus der Praxis, Verifikation — und hält sich dabei an die stabilen Mechanismen. Die Menüpfade des Kundenbereichs dagegen wandern mit jeder Überarbeitung: Für den exakten Klick ist die OVHcloud-Dokumentation des betroffenen Angebots maßgeblich.

MX Plan, Email Pro, Exchange: drei Angebote, drei Sätze von Einträgen

Alles beginnt mit einer Inventurfrage: Welches Angebot trägt die Postfächer der Domain wirklich? MX Plan ist das historische Shared-Angebot, bei vielen Domainnamen und Webhosting-Paketen inklusive: einfache Postfächer, ein Webmail und eine geteilte Infrastruktur, deren MX-Server unter Namen der Art mx*.mail.ovh.net antworten. Email Pro ist die professionelle Mittelklasse: größere Postfächer, eigene Infrastruktur, Servicezusagen. Hosted Exchange schließlich ist ein echtes, von OVHcloud betriebenes Microsoft Exchange mit eigenen Einträgen (MX, Autodiscover) — nicht zu verwechseln mit Microsoft 365, wo die Infrastruktur die von Microsoft und die Konfiguration eine völlig andere ist.

Jedes dieser Angebote besitzt seine eigene Versandinfrastruktur, also seinen eigenen SPF-Wert und seine eigene DKIM-Prozedur. Der Katalog entwickelt sich zudem weiter — eine auf Zimbra gestützte Produktlinie tritt neben die historischen Angebote — und eine einzelne Domain kann über die Jahre mehrere Dienste ansammeln. Der gesunde Reflex besteht darin, vor jedem Eingriff ins DNS die aktiven E-Mail-Dienste im Kundenbereich aufzulisten: Die Hälfte der schiefen Konfigurationen, die in der Praxis auftauchen, stammt von einer Exchange-Anleitung, die auf einen MX Plan angewendet wurde — oder umgekehrt.

Die DNS-Zone: geführte Oberfläche oder Textmodus

Die gesamte Konfiguration spielt sich in der DNS-Zone der Domain ab, erreichbar über den OVHcloud-Kundenbereich. Die geführte Oberfläche zeigt die Zone als Tabelle und bietet einen Assistenten zum Anlegen von Einträgen, der die nützlichen Typen kennt (TXT, CNAME, MX, SPF als TXT dargestellt). Das ist der bequeme Weg für eine punktuelle Änderung.

Für die Prüfung ist der Textmodus Gold wert: Die Zone erscheint dort als ein Block im BIND-Format, alle TXT-Einträge auf einen Blick. Es ist der schnellste Weg, ein doppeltes v=spf1, einen verwaisten alten DKIM-Selektor oder eine exotische, aus einer Migration geerbte TTL zu entdecken. Die OVHcloud-API (Bereich /domain/zone) automatisiert dieselben Operationen — nützlich, sobald der Bestand über einige Domains hinauswächst.

Zwei Realitäten verdienen es, im Kopf zu bleiben. Erstens folgt die Propagation der TTL der Einträge — meist 3600 Sekunden als Standard: Eine Änderung ist nicht sekundengenau überall sichtbar. Zweitens: Ist die Domain bei OVHcloud registriert, zeigen ihre Nameserver aber woandershin, dann ist die OVHcloud-Zone reine Dekoration — alles entscheidet sich beim tatsächlichen DNS-Hoster. Der Fall einer bei Cloudflare verwalteten Zone wird gesondert behandelt; die Logik der Einträge bleibt identisch, nur die Oberfläche wechselt.

SPF je nach Angebot — und die Falle des Standard-Eintrags

SPF beantwortet eine einfache Frage: Welche IP-Adressen dürfen im Namen der Domain Post versenden? Die Antwort passt in einen einzigen TXT-Eintrag an der Zonenwurzel. Für MX Plan passt der dokumentierte Wert auf eine Zeile:

beispiel.de.  IN TXT  "v=spf1 include:mx.ovh.com ~all"

Der Mechanismus include:mx.ovh.com autorisiert die geteilte Versandinfrastruktur von OVHcloud, über die die Nachrichten der MX-Plan-Postfächer und der Webhosting-Skripte laufen. Bei Email Pro und Exchange ist die Versandinfrastruktur nicht dieselbe, und der einzubindende Wert weicht ab: Er steht in der OVHcloud-Anleitung des jeweiligen Angebots, und genau dort ist er zu entnehmen, statt den Wert von MX Plan abzuschreiben. Das stabile Prinzip dagegen ändert sich nie: ein einziger TXT-Eintrag v=spf1, der alle legitimen Quellen zusammenführt — das OVHcloud-Angebot, aber auch die Marketing-Plattform (Brevo, Mailchimp…), das Rechnungswerkzeug, das CRM. Jedes include verbraucht einen Teil des Budgets von zehn DNS-Auflösungen, das der Standard vorgibt; wer stapelt, ohne zu zählen, landet direkt beim permerror.

Dann kommt die hausgemachte Falle. Beim Anlegen einer Zone mit den Standard-Einträgen hinterlegt OVHcloud bereits einen SPF-TXT, der die eigene Infrastruktur autorisiert. Dieser gut gemeinte Standard hat zwei perverse Effekte. Erstens überlebt er Migrationen: Eine Domain, deren Post inzwischen bei Microsoft 365 oder Google Workspace liegt, behält eine offene Autorisierung für die geteilte OVHcloud-Infrastruktur — und aus Sicht von SPF wird jede Maschine dieser geteilten Infrastruktur zu einem legitimen Absender der Domain. Zweitens nährt er den Reflex, einen neuen SPF-Eintrag „hinzuzufügen", statt den bestehenden zu bearbeiten: Dann koexistieren zwei v=spf1-TXT, und der Standard kennt kein Pardon — das Ergebnis ist ein permanenter Fehler, keine Zusammenführung. Dieselbe Frage des vom Registrar gesetzten Standards stellt sich auch anderswo; die entsprechende Konfiguration bei Gandi zeigt eine andere Mechanik bei identischem Heilmittel: eine einzige Zeile, aktuell gehalten.

Bleibt die Wahl des abschließenden Qualifikators. ~all (Softfail) markiert nicht gelistete Quellen als verdächtig, ohne ihre Abweisung zu verlangen; -all (Fail) fordert die glatte Abweisung. Während der Inventurphase ist ~all die vorsichtige Wahl; sobald DMARC steht, entscheidet ohnehin die DMARC-Policy über das Schicksal nicht ausgerichteter Nachrichten, und die Verschärfung von SPF wird eher zur Feinheit als zur Notwendigkeit.

DKIM: CNAME-Selektoren, aktiviert über Kundenbereich oder API

DKIM versieht die Nachricht mit einer kryptografischen Signatur, die der Empfänger anhand eines öffentlichen Schlüssels prüft, veröffentlicht im DNS unter einem Namen der Form <selektor>._domainkey.beispiel.de. Bei OVHcloud gibt es keinen Schlüssel zum Kopieren und Einfügen: Die Aktivierung erzeugt zwei Selektoren in Form von CNAME-Einträgen, die auf von OVHcloud verwaltete Ziele zeigen (Namen unterhalb von dkim.mail.ovh.net). Der Vorteil dieser Konstruktion ist real: Der öffentliche Schlüssel bleibt bei OVHcloud, das ihn regelmäßig rotieren kann, ohne dass an der Zone irgendetwas geschieht — die beiden Selektoren wechseln sich ab, einer signiert, während der andere auf die nächste Rotation wartet.

Die Aktivierung hängt vom Angebot ab. Bei Exchange und Email Pro wird sie über den Kundenbereich gesteuert, in der Konfiguration der an den Dienst angebundenen Domain, oder über die API. Bei MX Plan hat OVHcloud die Aktivierung auf den neueren Angeboten weitgehend automatisiert, und die API kann sie auf älteren Domains anstoßen oder prüfen. Da die exakten Beschriftungen der Schaltflächen sich regelmäßig ändern, ist die aktuelle Prozedur die der OVHcloud-Dokumentation — die hier beschriebenen Mechanismen (zwei Selektoren, CNAME, verwaltete Rotation) sind der stabile Teil.

Ein Sonderfall verdient Aufmerksamkeit: Liegt die DNS-Zone nicht bei OVHcloud, können die beiden CNAME-Einträge nicht automatisch gesetzt werden. Die anzulegenden Werte werden dann im Kundenbereich angezeigt oder sind über die API abrufbar, und sie müssen beim tatsächlichen DNS-Hoster übernommen werden — Zeichen für Zeichen. Ein falsch geschriebener Selektor erzeugt eine nicht verifizierbare Signatur, also einen stillen DKIM-Fehlschlag.

Fehler aus der Praxis

Drei Fehlerfamilien tauchen in den DMARC-Berichten von bei OVHcloud gehosteten Domains immer wieder auf.

Zwei v=spf1-TXT-Einträge. Der häufigste Fehler, geboren aus dem Standard-SPF. Ein Empfänger, der zwei SPF-Einträge auf demselben Namen findet, liefert einen permanenten Fehler zurück: Die Nachricht kann SPF nicht mehr bestehen, so gut jede der beiden Zeilen für sich auch sein mag. Das Heilmittel ist eine einzige Operation: zusammenführen, dann das Duplikat löschen — der Textmodus der Zone macht die Diagnose unmittelbar.
Der Rest nach der Migration. Post von MX Plan zu Microsoft 365 migriert, oder von Exchange zu einer anderen Plattform: Das SPF behält das alte, nutzlos gewordene include (auf einer geteilten Infrastruktur sogar riskant), während DKIM noch mit den Selektoren des alten Angebots signiert — oder gar nicht mehr, weil die CNAME-Einträge mit dem Dienst gelöscht wurden. DMARC-Berichte entlarven diese Geister binnen Tagen: eine Quelle, die gestern sendete und heute nicht mehr, eine Signatur, die seit einem präzisen Datum fehlschlägt.
Die TTL, die Tests verfälscht. Eine veröffentlichte Korrektur wird erst nach Ablauf der Caches beobachtbar, mit der Standard-TTL bis zu einer Stunde. Dreißig Sekunden nach der Änderung testen, auf Fehlschlag schließen und erneut „korrigieren" führt zu inkohärenten Zonen. Die nützliche Disziplin: die TTL vor einer geplanten Migration absenken, dann einen vollen Zyklus abwarten, bevor ein Urteil fällt.

Verifizieren, bevor verschärft wird

Die Verifikation geschieht auf drei Ebenen. Zuerst das rohe DNS: Eine TXT-Abfrage der Zonenwurzel muss genau ein v=spf1 zurückliefern; eine Abfrage der Namen selector1._domainkey und selector2._domainkey muss den CNAME-Einträgen bis zu den von OVHcloud gehosteten Schlüsseln folgen. Die detaillierte Methode, samt Werkzeugen und Fallstricken, wird in der Prüfung eines SPF-Eintrags durchgespielt.

Dann der Test in Originalgröße: eine Nachricht an ein Gmail- oder Outlook.com-Postfach, gefolgt von der Lektüre des Authentication-Results-Headers der empfangenen Nachricht. Die erwarteten Angaben: spf=pass, dkim=pass mit einem OVHcloud-Selektor und ausgerichtete Domains. Schließlich die Beobachtung über die Zeit: Die Veröffentlichung eines DMARC-Eintrags im Überwachungsmodus zeigt, was Empfänger weltweit tatsächlich sehen, Woche für Woche:

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

Die Beispiele für DMARC-Einträge liefern die zur jeweiligen Lage passende Vorlage — aktive Domain, defensive Markendomain, Subdomains. Diese Beobachtungsphase ist es, die eine Konfiguration, die „gut aussieht", in eine bewiesene verwandelt.

Fazit

Bei OVHcloud sind SPF und DKIM schnell eingerichtet, sobald drei Fixpunkte stehen: das tatsächlich gebuchte E-Mail-Angebot (MX Plan, Email Pro oder Exchange — jedes mit eigener Infrastruktur, eigenem SPF-Wert, eigener DKIM-Prozedur), die DNS-Zone als einziger Ort der Wahrheit (mit dem Textmodus als Prüfwerkzeug) und die Falle des Standard-SPF, verantwortlich für die meisten doppelten v=spf1 in freier Wildbahn. DKIM wird über den Kundenbereich oder die API aktiviert, in Form zweier CNAME-Selektoren, deren Rotation OVHcloud verwaltet; die klassischen Fehler — SPF-Duplikat, Migrationsrest, nicht bedachte TTL — lassen sich alle durch eine aufmerksame Lektüre der Zone und der Berichte fangen.

Der kürzeste Ausgangspunkt bleibt eine kostenlose DMARC-Analyse der Domain: Binnen Sekunden zeigt sie den realen Zustand von SPF, DKIM und DMARC, wie ein Empfänger sie sieht — Duplikate inklusive. Steht die Diagnose, erlaubt es ein angelegtes Konto, die Berichte zu sammeln, die beiden OVHcloud-Selektoren dauerhaft im Blick zu behalten und die Policy auf Grundlage von Belegen statt Vermutungen in Richtung p=reject zu führen.

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