Infomaniak: SPF, DKIM und DMARC für die Mail

Von Thomas · virtueller CISO · 12. September 2026

Infomaniak, ein Genfer Host, hat eine starke Identität rund um Datenschutz und Ökologie aufgebaut: Daten in der Schweiz, eigene Infrastruktur, eine offen souveräne Positionierung. Für eine Organisation, die sowohl ihre DNS-Zone als auch ihre Mail dort betreibt, ist die Einrichtung der Authentifizierung eine der einfachsten am Markt — die Oberfläche bietet einen Assistenten, der SPF, DKIM und oft DMARC nahezu ohne manuelle Eingabe setzt. Man muss dennoch verstehen, was dieser Assistent tut, seine Grenzen kennen, wenn das DNS anderswo verwaltet wird, und das Ergebnis prüfen, statt ihm blind zu vertrauen.

Standardmäßig versendet eine Domain, deren Mail bei Infomaniak liegt, unter ihrem eigenen Namen, doch die Authentifizierung ist nur aktiv, wenn die Einträge tatsächlich veröffentlicht sind. Liegt die Zone bei Infomaniak, übernimmt das der Assistent; liegt sie anderswo, müssen die Werte von Hand in die andere Oberfläche übertragen werden. Ohne das weist ein Empfänger, der p=reject durchsetzt, legitime Post ab.

Dieser Leitfaden behandelt den automatischen Einrichtungsassistenten, den SPF-Include, die DKIM-Aktivierung, das Veröffentlichen von DMARC, die daraus folgende Ausrichtung, die Prüfung der Zone, die Frage der Schweizer Souveränität sowie die häufigen Fehler und den abschließenden Gegenbeweis über die RUA-Berichte.

Der automatische Einrichtungsassistent

Infomaniaks Trumpf ist sein Assistent. Wird die DNS-Zone der Domain bei Infomaniak verwaltet, bietet die Aktivierung der Mail an, die Authentifizierung in einem Schritt zu konfigurieren: Der Assistent erstellt den SPF-Eintrag, erzeugt und veröffentlicht den DKIM-Schlüssel und schlägt oft einen Start-DMARC-Eintrag vor. Was anderswo das Eingeben mehrerer Einträge von Hand verlangt, läuft hier auf eine Bestätigung hinaus.

Diese Einfachheit ist real, nimmt aber nicht die Notwendigkeit, zu verstehen und zu prüfen. Der Assistent setzt ein vorsichtiges Start-DMARC — typischerweise p=none —, das die Berichte auslöst, ohne etwas abzuweisen: Das ist der richtige Ausgangspunkt, aber der Aufstieg in der Richtlinie bleibt eine danach zu treffende Entscheidung, auf der Grundlage der Berichte, kein Wert, den der Assistent anstelle des Betreibers festlegt. Zu verstehen, was jeder Eintrag tut, hilft auch, zu diagnostizieren, falls eines Tages eine unerwartete Quelle auftaucht.

Ein Wort dazu, was der Assistent nicht sieht. Er konfiguriert die Einträge für die Infomaniak-Mail — das ist sein Bereich, und er deckt ihn gut ab. Jeder andere Absender der Domain, davor oder danach hinzugefügt (ein Newsletter-Werkzeug, eine E-Commerce-Plattform, eine hauseigene Anwendung), ist für ihn unsichtbar: Seine SPF-Includes und seine DKIM-Schlüssel werden nicht automatisch integriert. Der Assistent ist daher ein ausgezeichneter Ausgangspunkt für eine Domain, bei der Infomaniak der einzige Absender ist; sobald es mehrere gibt, wird die Konfiguration zu einer Inventaraufgabe, die nur die RUA-Berichte wirklich abschließen.

SPF: der Infomaniak-Include

Der SPF-Eintrag autorisiert die Server von Infomaniak, für die Domain zu senden:

beispiel.de.  TXT  "v=spf1 include:spf.infomaniak.ch ~all"

Verwaltet der Assistent die Zone, wird dieser Eintrag automatisch gesetzt. Der Punkt der Wachsamkeit erscheint, sobald ein anderer Dienst ebenfalls für die Domain sendet — ein ESP für Newsletter, eine transaktionale Anwendung. Die Includes sind dann im selben v=spf1-Eintrag zusammenzuführen, niemals in einem zweiten (zwei SPF-Einträge machen SPF vollständig ungültig). Jeder Include verbraucht DNS-Abfragen: jenseits von zehn kippt SPF in einen permerror. Das Limit von zehn DNS-Abfragen bei SPF bleibt daher zu beachten, sobald mehrere Dienste koexistieren, auch mit einem Assistenten.

DKIM: automatisch oder manuell

DKIM folgt derselben Logik wie der Rest. Liegt die Zone bei Infomaniak, erzeugt der Assistent das Schlüsselpaar und veröffentlicht den DKIM-Eintrag von selbst; die erzeugte Signatur trägt d=beispiel.de, die Domain selbst, und die DKIM-Ausrichtung ist von Anfang an gesichert, auch im strikten Modus. Wird die Zone anderswo verwaltet, liefert Infomaniak den DKIM-Wert zum manuellen Veröffentlichen in der anderen DNS-Oberfläche. Der bereitgestellte Schlüssel hat eine robuste Länge (2048 Bit), von den großen Anbietern erwartet; ein gesunder Standard, den zu schwächen kein Grund besteht.

Die Rotation folgt derselben Aufteilung: automatisch und transparent, wenn die Zone bei Infomaniak liegt, sonst manuell — mit dem üblichen Überlappungsprinzip (den neuen Schlüssel veröffentlichen, bevor der alte entfernt wird). Es ist dieselbe Logik wie jede Erneuerung der Signaturschlüssel, mit der Übernahme obendrein, wenn alles an einem Ort liegt.

DMARC: der Start-Eintrag

Der DMARC-Eintrag ist ein TXT unter der Subdomain _dmarc:

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

Der Assistent schlägt oft einen bei p=none mit einer Berichtsadresse vor. Das ist genau der richtige Start: Die Richtlinie erzwingt nichts, aber die aggregierten Berichte beginnen zu fließen. Die kommentierten Beispiele, Tag für Tag schlüsseln die für das Weitere anzupassenden Tags auf (sp, adkim, aspf). Unter DMARCbis wird die Subdomain-Zugehörigkeit über den DNS Tree Walk bestimmt, ohne die Art zu ändern, wie der Eintrag 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 Infomaniak-Mail liegt im günstigen Fall. Auf der DKIM-Seite trägt die Signatur die Domain selbst — die Ausrichtung ist unmittelbar. Auf der SPF-Seite liegt der Umschlag auf der Domain, da Infomaniak die Post beherbergt: SPF richtet sich natürlich aus. Zwei Mechanismen bestehen ausgerichtet, und diese Redundanz schützt, falls einer der beiden unterwegs wegfällt.

Es ist diese doppelte Abdeckung, die erlaubt, eine strikte Richtlinie anzustreben, sobald die Berichte es bestätigen — ein Ziel, das der Assistent vorbereitet, aber nicht allein überschreitet.

DNS bei Infomaniak oder anderswo verwaltet

Eine vorherige Prüfung bedingt alles Weitere: zu wissen, ob die DNS-Zone wirklich bei Infomaniak liegt. Das bestimmt, ob der Assistent die Einträge selbst veröffentlichen kann oder ob sie von Hand in eine andere Oberfläche zu übertragen sind. Eine bei Infomaniak registrierte Domain, deren Nameserver aber anderswo delegiert sind, sieht den Assistenten Werte vorschlagen, die er nicht veröffentlichen kann — und vergisst man, sie zu übertragen, bleibt die Authentifizierung unvollständig, trotz einer Oberfläche, die „alles erledigt" zu haben scheint.

Die Prüfung ist schnell: Die effektiven Nameserver der Domain lesen sich in einer NS-Abfrage. Zeigen sie auf Infomaniak, ist der Assistent autoritativ; sonst sind SPF, DKIM und DMARC in der Oberfläche zu veröffentlichen, die die Zone wirklich verwaltet, unter Übernahme der von Infomaniak gelieferten Werte.

Die Schweizer Datensouveränität

Das Souveränitätsargument von Infomaniak verdient eine nützliche Nuance. Die Schweiz ist nicht in der Europäischen Union, profitiert aber von einem Angemessenheitsbeschluss, der ihr Datenschutzniveau als gleichwertig anerkennt — Ströme personenbezogener Daten von der EU in die Schweiz sind daher ohne zusätzlichen Mechanismus geregelt. Für eine Organisation, die ihre Post außerhalb außereuropäischer Rechtsordnungen halten möchte, ist ein Schweizer Host eine kohärente Option, unterschieden sowohl von einem Host innerhalb der EU als auch von einem Akteur, der extraterritorialen Zugriffsgesetzen unterliegt.

Das ändert nichts an der Mechanik von SPF, DKIM oder DMARC — die Ausrichtung wird überall gleich betrachtet — aber es wiegt bei der Wahl eines Hosts und ist mit dem Rest von Infomaniaks Positionierung stimmig. Der Speicherort der Mail-Daten und der zugehörigen Protokolle gehört zu den Fragen, die eine regulierte Organisation klar beantworten können muss — und ein Host, der sie geradeheraus beantwortet, vereinfacht die Vorbereitung einer Prüfung entsprechend. Für Organisationen im DACH-Raum, die geografische Nähe und Datenschutz zugleich gewichten, ist dieser Punkt oft ausschlaggebend.

Häufige Konfigurationsfehler

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

Dem Assistenten blind vertrauen, ohne zu prüfen. Der Assistent setzt gute Einträge, aber ein danach hinzugefügter Drittdienst oder eine delegierte Zone entzieht sich seinem Blick: Die Berichte bleiben der Schiedsrichter.

Delegierte Zone: vergessen, die Werte zu übertragen. DKIM auf der Infomaniak-Seite „konfiguriert", aber nie in der effektiven Zone veröffentlicht: keine gültige Signatur.

Zwei SPF-Einträge veröffentlichen. Einen ESP als zweiten v=spf1 hinzuzufügen statt eines zusammengeführten Includes macht SPF vollständig ungültig — nicht nur die Ergänzung, sondern den gesamten Eintrag.

DMARC für „fertig" halten, weil der Assistent lief. Der Assistent setzt den Eintrag auf p=none: Die Domain ist beobachtet, noch nicht geschützt. Der Schutz kommt erst mit der Verschärfung, nach dem Lesen der Berichte entschieden — ein Schritt, den der Assistent vorsichtshalber nicht allein überschreitet.

Die Richtlinie zu früh verschärfen. Umgekehrt bedeutet der Wechsel zu p=reject, bevor die Berichte bestätigen, dass sich der gesamte legitime Verkehr ausrichtet, die eigenen Nachrichten abzuweisen.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die Infomaniak-Oberfläche, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist — was der Assistent oft von Anfang an vorschlägt —, 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 Infomaniak-Verkehr der Domain korrekt zugeordnet wird, und offenbart vor allem jede Quelle außer Infomaniak — ein ESP, eine Anwendung —, die der Assistent nicht abgedeckt hat.

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. Es ist die Bestätigung, dass sich alle legitimen Quellen ausrichten — Infomaniak und die anderen —, die das Verschärfen erlaubt. 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.