IONOS: SPF, DKIM und DMARC für Mail und die DNS-Zone

Von Thomas · virtueller CISO · 11. September 2026

IONOS — das frühere 1&1 — ist ein bedeutender Host und Registrar in Deutschland und Frankreich, mit seinen Rechenzentren in Europa. Viele Organisationen haben sowohl ihre DNS-Zone als auch ihre Mail dort, was die Einrichtung der Authentifizierung vereinfacht: Liegen beide bei IONOS, läuft das Setzen von SPF, DKIM und DMARC auf wenige, miteinander stimmige Einstellungen hinaus. Man muss dennoch die plattformeigenen Konventionen kennen — und ein technisches Erbe aus der 1&1-Zeit, das noch heute Domains in die Falle lockt.

Standardmäßig versendet eine Domain, deren Mail bei IONOS liegt, zwar unter ihrem eigenen Namen, doch ist nicht garantiert, dass DMARC besteht, solange der korrekte SPF-Include nicht veröffentlicht und DKIM im Mail-Bereich nicht aktiviert ist. Ein Empfänger, der p=reject durchsetzt, weist dann legitime Post ab — oft wegen eines geerbten SPF-Includes, der nicht mehr zu den realen Servern passt.

Dieser Leitfaden behandelt den aktuellen SPF-Include und die 1&1-Erbe-Falle, die DKIM-Aktivierung im Mail-Bereich, das Veröffentlichen des DMARC-Eintrags, die daraus folgende Ausrichtung, die Prüfung, ob die Zone wirklich von IONOS verwaltet wird, sowie die häufigen Fehler und den abschließenden Gegenbeweis über die RUA-Berichte.

SPF: der aktuelle Include und das 1&1-Erbe

Der SPF-Eintrag autorisiert die Sendeserver von IONOS, für die Domain zu senden. Die aktuelle empfohlene Form ist:

beispiel.de.  TXT  "v=spf1 include:_spf-eu.ionos.com ~all"

Hier liegt die für IONOS spezifischste Falle. In der 1&1-Zeit lief die SPF-Autorisierung über zwei getrennte Includes — include:_spf.perfora.net und include:_spf.kundenserver.de —, die den alten Mail-Plattformen entsprachen. Viele Domains tragen diese geerbten Werte noch in ihrem SPF-Eintrag. Sie sind nicht immer falsch, blähen aber den Eintrag auf, stapeln DNS-Abfragen und vertragen sich manchmal schlecht mit dem vereinheitlichten Include _spf-eu.ionos.com. Ein Eintrag, der alle drei plus weitere Dienste anhäuft, nähert sich rasch dem Limit von zehn DNS-Abfragen bei SPF, jenseits dessen SPF in einen permerror kippt und für die gesamte Domain ungültig wird.

Die Bereinigung besteht darin zu prüfen, welcher IONOS-Mail-Dienst wirklich genutzt wird, den passenden Include zu behalten und die nutzlosen Erblasten zu entfernen. Ein einziger v=spf1-Eintrag mit dem richtigen Include: das ist das Ziel.

DKIM: die Aktivierung im Mail-Bereich

Bei IONOS wird DKIM nicht zuerst in der DNS-Zone eingegeben: Es wird im Mail-Verwaltungsbereich aktiviert. Sobald die Option für die Domain eingeschaltet ist, erzeugt IONOS das Schlüsselpaar und — wenn die DNS-Zone ebenfalls bei IONOS liegt — veröffentlicht automatisch den passenden DKIM-Eintrag. Wird die Zone anderswo verwaltet, liefert IONOS den Wert zum manuellen Veröffentlichen in der anderen Oberfläche.

Die erzeugte Signatur trägt d=beispiel.de, die Domain selbst: Die DKIM-Ausrichtung ist somit ab der Aktivierung gesichert, auch im strikten Modus. Diese Kopplung — im Mail-Bereich aktivieren, automatische DNS-Veröffentlichung, wenn die Zone bei IONOS liegt — ist die betriebliche Besonderheit von IONOS. Sie macht das Setup einfach, wenn alles beim selben Host liegt, und erzwingt einen zusätzlichen manuellen Schritt, wenn das DNS anderswo delegiert ist.

DMARC: der `_dmarc`-TXT

Der DMARC-Eintrag ist ein TXT, veröffentlicht unter der Subdomain _dmarc:

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

Man beginnt stets mit p=none: Die Richtlinie erzwingt nichts, aber die rua=-Adresse löst die aggregierten Berichte aus, die dazu dienen, vor dem Verschärfen alles zu prüfen. In der IONOS-DNS-Oberfläche erwartet das Namensfeld die relative Subdomain _dmarc — die Plattform ergänzt die Domain. Die Zeile für Zeile aufgeschlüsselten Einträge schlüsseln die zu behaltenden Tags auf. Unter DMARCbis wird die Subdomain-Zugehörigkeit über den DNS Tree Walk bestimmt, ohne die Art zu ändern, wie der Eintrag bei IONOS veröffentlicht wird.

Die DMARC-Ausrichtung: der günstige Fall

DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich an der From-Domain ausrichtet. Die IONOS-Mail liegt im günstigen Fall, wie ein klassisches Mail-Hosting. Auf der DKIM-Seite trägt die Signatur die Domain selbst — die Ausrichtung ist unmittelbar. Auf der SPF-Seite liegt der Nachrichtenumschlag ebenfalls auf der Domain, da IONOS die Post dieser Domain beherbergt: SPF richtet sich also natürlich aus.

Zwei Mechanismen bestehen ausgerichtet, und diese Redundanz schützt: Bricht eine Weiterleitung SPF, überlebt DKIM, und umgekehrt. Es ist die Grundlage, die erlaubt, in Ruhe eine strikte Richtlinie anzustreben — sobald die Abdeckung durch die Berichte bestätigt ist. Die Datenresidenz spielt hier ergänzend hinein: Die gesamte Mail-Verarbeitung und ihre zugehörigen Protokolle bleiben innerhalb der Europäischen Union, ein Punkt, der für Organisationen mit Lokalisierungsanforderungen zählt, auch wenn er an der Ausrichtungsmechanik nichts ändert.

Die europäische Positionierung ist nicht bloß ein Konformitäts-Häkchen. Für Organisationen, deren Empfänger oder Aufsichtsbehörden erwarten, dass Daten innerhalb der EU bleiben, nimmt es eine ganze Kategorie von Fragen während einer Prüfung weg, DNS, Mail und deren Protokolle bei einem europäischen Host zu halten. Die Ausrichtungsmechanik von IONOS ist dieselbe wie bei jedem Host — aber die Antwort auf „Wo liegen unsere Mail-Daten?" ist einfacher, und diese Einfachheit hat einen eigenen Wert, den ein rein technischer Vergleich übersieht.

DNS bei IONOS oder anderswo delegiert

Wie bei jedem Host vermeidet eine vorherige Prüfung den frustrierendsten Fehler: sicherzustellen, dass die DNS-Zone der Domain wirklich von IONOS verwaltet wird. Eine Domain kann bei IONOS registriert sein, aber ihre Nameserver an einen anderen Anbieter delegiert haben; in diesem Fall zeigt die DNS-Oberfläche von IONOS eine Zone, die nicht mehr autoritativ ist, und die dort hinzugefügten Einträge werden nie ausgeliefert.

Diese Prüfung zählt bei IONOS umso mehr, als die automatische DKIM-Veröffentlichung davon abhängt: Sie veröffentlicht den Eintrag nur dann von selbst, wenn die Zone bei IONOS liegt. Zone anderswo delegiert ⇒ DKIM im Mail-Bereich aktiviert, aber ein Eintrag, der in der anderen Oberfläche von Hand zu veröffentlichen ist. Diesen Schritt zu vergessen, lässt ein auf der IONOS-Seite „aktiviertes", im effektiven DNS aber fehlendes DKIM zurück — eine Diskrepanz, die viele fehlende Signaturen in den Berichten erklärt.

IONOS-Postfach oder weiterverkauftes Microsoft 365

IONOS verkauft nicht nur einen Mail-Dienst. Neben seinen hauseigenen Postfächern verkauft es Microsoft 365 weiter — und der SPF-Include ist nicht derselbe. Ein klassisches IONOS-Postfach läuft über _spf-eu.ionos.com; ein über IONOS abonniertes Microsoft 365 versendet über die Infrastruktur von Microsoft, und sein Include ist include:spf.protection.outlook.com. Die beiden zu verwechseln, ist eine Variante der Erbe-Falle: Die Domain trägt einen Include, der nicht zum tatsächlich sendenden Dienst passt, und SPF scheitert.

Der Reflex ist derselbe wie bei jedem Host, der mehrere Produkte weiterverkauft: identifizieren, welches tatsächlich aktiv ist — das hauseigene Postfach oder das weiterverkaufte Microsoft 365 —, bevor der Include festgelegt wird. Eine von einem zum anderen migrierte Domain, die ihr SPF nicht überarbeitet, schleppt einen veralteten Include mit, eine Fehlerquelle ohne ersichtlichen Grund. Dieser Fall ist umso häufiger, als IONOS beide Angebote im selben Kaufweg hervorhebt.

Die Rotation des DKIM-Schlüssels

Liegt die Zone bei IONOS, vereinfacht die automatische DKIM-Aktivierung auch die Rotation: IONOS übernimmt die Schlüsselerneuerung auf seiner Seite, ohne manuellen Eingriff in die Zone. Diese Übernahme ist ein Vorteil — die Rotation, oft vernachlässigt, wenn sie eine manuelle Bearbeitung erfordert, wird zu einem Nicht-Ereignis, und ein alter Schlüssel verweilt nicht.

Ist die Zone anderswo delegiert, wird die Rotation dagegen wieder manuell: Jeder neue von IONOS veröffentlichte Schlüssel muss in die externe DNS-Oberfläche übertragen werden, nach dem Überlappungsprinzip — den neuen veröffentlichen, bevor der alte entfernt wird, um kein Fenster ohne gültige Signatur zu öffnen. Es ist dieselbe Logik wie jede Auswechslung des Signaturmaterials, nur von Hand statt automatisch.

Häufige Konfigurationsfehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Die geerbten 1&1-Includes behalten. _spf.perfora.net / _spf.kundenserver.de, mit dem aktuellen Include gestapelt, blähen den Eintrag auf und nähern ihn dem permerror.

DKIM aktivieren, ohne den Schlüssel zu veröffentlichen (delegierte Zone). DKIM im Mail-Bereich angehakt, aber da die Zone anderswo liegt, wurde der Eintrag nie gesetzt: keine gültige Signatur.

Zwei SPF-Einträge veröffentlichen. Zwei v=spf1 machen SPF vollständig ungültig; die Includes sind in einem zusammenzuführen.

IONOS-Postfach und weiterverkauftes Microsoft 365 verwechseln. _spf-eu.ionos.com für eine Domain zu veröffentlichen, die in Wahrheit über das weiterverkaufte M365 versendet (oder umgekehrt): Der Include deckt die realen Server nicht ab, und SPF scheitert.

Die Richtlinie zu früh verschärfen. Der Wechsel zu p=reject, bevor die Berichte bestätigen, dass sich der gesamte legitime Verkehr ausrichtet, bedeutet, die eigenen Nachrichten abzuweisen — umso schwerwiegender, wenn die IONOS-Mail den täglichen Geschäftsverkehr trägt.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht der IONOS-Bereich, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte bestätigt, ob der IONOS-Verkehr der Domain korrekt zugeordnet wird: DKIM ausgerichtet, SPF ausgerichtet, und keine Quelle, die an beiden scheitert.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Konfiguration, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Man prüft insbesondere, dass der gewählte SPF-Include alle IONOS-Quellen abdeckt und kein 1&1-Erbe das Bild verfälscht. Sobald diese Abdeckung über mehrere Tage bestätigt ist, erfolgt der Wechsel zu p=reject ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.