Zoho Mail: SPF, DKIM und DMARC-Ausrichtung

Von Thomas · virtueller CISO · 05. September 2026

Zoho Mail nimmt unter den Mail-Suiten eine eigene Stellung ein: Hosting für geschäftliche E-Mail, Kalender, kollaborative Werkzeuge, all das zu einem Preis, der kleine Strukturen ebenso anspricht wie Organisationen, denen die Datensouveränität wichtig ist. Gerade dieser letzte Punkt hat eine oft unterschätzte, unmittelbare Folge für die Authentifizierung: Zoho verteilt seine Kunden auf mehrere regionale Rechenzentren, und die SPF-Konfiguration ist nicht dieselbe, je nachdem, welches davon das Konto beherbergt.

Standardmäßig versendet eine zu Zoho Mail hinzugefügte Domain zwar unter ihrem eigenen Namen — Umschlag und From-Header tragen die Domain der Organisation —, doch ist damit noch nicht garantiert, dass DMARC besteht. Solange der SPF-Eintrag die Server von Zoho nicht autorisiert und die DKIM-Signatur in der Verwaltungskonsole nicht aktiviert ist, verlassen die Nachrichten das System ohne ausgerichtete Authentifizierung. Ein Empfänger, der p=reject durchsetzt, weist sie dann ab, obwohl sie aus einem völlig legitimen Postfach stammen.

Dieser Leitfaden behandelt die drei Bausteine, die Zoho Mail DMARC-tauglich machen: den SPF-Eintrag mit seinem regionalen Include, den in der Konsole erzeugten und dann verifizierten DKIM-Selektor und die daraus folgende Ausrichtung. Anschließend die Frage des Rechenzentrums — der für Zoho spezifischste Fehler —, die häufigen Konfigurationsfallen und den abschließenden Gegenbeweis über die RUA-Berichte.

SPF: der Include, der vom Rechenzentrum abhängt

Der SPF-Eintrag autorisiert die Server von Zoho, für die Domain zu senden. Seine Form hängt von der Hosting-Region des Kontos ab:

beispiel.de.  TXT  "v=spf1 include:zoho.eu ~all"

Der Include zoho.eu gilt für Konten im europäischen Rechenzentrum; ein Konto im US-Zentrum nutzt zohomail.com, ein indisches Konto zoho.in, und so fort. Das ist der plattformspezifischste Punkt: Einen Include aus einer generischen Dokumentation zu kopieren, ohne die tatsächliche Region des Kontos zu prüfen, erzeugt ein SPF, das falsch authentifiziert — die real sendenden Server sind nicht die, die der Include autorisiert, und SPF scheitert je nach ausgehendem Server, den Zoho wählt, sporadisch.

Eine Domain darf nur einen SPF-Eintrag tragen. Versendet die Domain auch über einen anderen Dienst — einen ESP für Kampagnen, eine transaktionale Anwendung —, werden die Includes im selben Eintrag kombiniert, niemals in zwei getrennten Einträgen (was einen permerror auslöste). Das Limit von zehn DNS-Abfragen bei SPF bleibt zu beachten: Jeder Include verbraucht Abfragen, und ein Eintrag, der zu viele Dienste stapelt, überschreitet irgendwann die Obergrenze.

DKIM: der in der Konsole erzeugte Selektor

Anders als SPF wird DKIM nicht allein in der DNS-Zone konfiguriert: Es wird aus der Zoho-Verwaltungskonsole gesteuert. Der Ablauf erfolgt in zwei Schritten. Zuerst erzeugt die Konsole ein Schlüsselpaar für die Domain und zeigt einen zu veröffentlichenden TXT-Eintrag an, unter einem gewählten Selektor — zmail als Standard, anpassbar:

zmail._domainkey.beispiel.de.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"

Dann — und das ist der am häufigsten vergessene Schritt — ist nach der Propagierung des TXT in die Konsole zurückzukehren und die Signatur zu aktivieren. Das Veröffentlichen des Schlüssels genügt nicht: Solange das Kästchen auf Zohos Seite nicht gesetzt ist, verlassen die Nachrichten das System ohne DKIM-Signatur, und der TXT liegt reglos in der Zone. Diese doppelte Handlung — veröffentlichen und dann aktivieren — ist Zohos betriebliche Besonderheit bei DKIM.

Die erzeugte Signatur trägt d=beispiel.de, die Organisationsdomain selbst. Die DKIM-Ausrichtung ist somit ab der Aktivierung gesichert, auch im strikten Modus.

Zwei betriebliche Details verdienen Beachtung. Zunächst die Schlüssellänge: Zoho bietet Schlüssel mit 1024 oder 2048 Bit; 2048 ist der empfohlene Standard, da mehrere Mail-Betreiber 1024 inzwischen als schwach einstufen. Dann die Rotation: Die Erneuerung eines DKIM-Schlüssels bei Zoho bedeutet, einen neuen Selektor zu erzeugen, den entsprechenden TXT zu veröffentlichen, ihn zu aktivieren und den alten nach bestätigter Propagierung zu entfernen. Es ist ein unterbrechungsfreier Wechsel — sofern der alte Selektor nicht gelöscht wird, bevor der neue wirksam ist, sonst verlässt ein Fenster von Nachrichten das System ohne gültige Signatur. Die Erneuerung der Signaturschlüssel folgt überall diesem Überlappungsprinzip.

Die DMARC-Ausrichtung: der günstige Fall

DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich an der From-Domain ausrichtet. Zoho Mail liegt hier 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 auch der Umschlag der ausgehenden Nachrichten auf der Domain der Organisation, da Zoho die Post dieser Domain beherbergt: SPF richtet sich also natürlich aus, ohne eine Umschlag-Subdomain deklarieren zu müssen wie bei manchen ESPs. Zwei Mechanismen bestehen ausgerichtet, und diese Redundanz schützt: Bricht eine Weiterleitung unterwegs SPF, überlebt DKIM; schreibt ein Gateway den Nachrichtentext um und macht die DKIM-Signatur ungültig, hält SPF. Ein Softfail-Qualifier (~all) bleibt umsichtig, solange die Konfiguration bestätigt wird, vor jedem Wechsel zu einem strikteren -all. Die kommentierten Beispiele, Tag für Tag zeigen, wie die _dmarc-Anweisung gesetzt wird, sobald SPF und DKIM stehen — zuerst auf p=none zur Beobachtung, dann verschärfend.

Die Falle des Rechenzentrums

Nahezu alle scheiternden Zoho-Konfigurationen laufen auf eine Regionsdiskrepanz hinaus. Das Konto liegt auf einem bestimmten Rechenzentrum — bei der Anmeldung gewählt, mitunter ohne große Aufmerksamkeit —, aber der SPF-Include, die DKIM-Konsole und die MX-Einträge müssen alle derselben Region entsprechen. Eine Domain, deren Konto im europäischen Zentrum lebt, deren SPF aber auf include:zohomail.com zeigt, sieht ihre Nachrichten auf verwirrende Weise an SPF scheitern: Die Dokumentation scheint befolgt, und dennoch besteht die Authentifizierung nicht.

Der diagnostische Reflex besteht darin, in der Konsole die tatsächliche Hosting-Region zu prüfen und dann jeden Eintrag darauf auszurichten. Die MX-Einträge von Zoho folgen derselben regionalen Logik wie der SPF-Include; ein korrekter MX bei einem Include aus einer anderen Region ist ein klassischer Fall, gerade weil beide zu unterschiedlichen Zeitpunkten konfiguriert werden. Die Migration eines Kontos von einem Rechenzentrum zu einem anderen — ein von Zoho angebotener Vorgang — erfordert überdies, den SPF-Include dabei zu überarbeiten, worauf der Wechsel nicht immer hinweist. Es ist eine Prüfung von wenigen Minuten, die Stunden des Herumprobierens erspart.

Domain-Aliase und Subdomains

Zoho Mail erlaubt, mehrere Domains und Aliase an eine Organisation zu binden. Jede Domain, die Post versendet, bildet einen eigenen Authentifizierungsbereich: Sie braucht ihren eigenen SPF-Eintrag und ihren eigenen DKIM-Schlüssel, veröffentlicht in IHRER Zone. Ein Alias, der die Infrastruktur einer Hauptdomain wiederverwendet, ohne eigene Einträge zu veröffentlichen, versendet unter einer nicht authentifizierten Identität — und DMARC scheitert für genau diesen Alias, selbst wenn die Hauptdomain tadellos ist.

Die Regel gilt auch für Subdomains. Eine versendende Subdomain — Rechnungsstellung, Support, Benachrichtigungen — erbt zwar über den DMARCbis-Tree-Walk die DMARC-Richtlinie der übergeordneten Domain, nicht aber deren SPF-Eintrag oder DKIM-Schlüssel: Diese sind dort zu veröffentlichen, wo die Post tatsächlich ausgeht. Das Vererben der Richtlinie mit dem Vererben der Konfiguration zu verwechseln, ist ein häufiger Fehler, der eine aktive Subdomain ohne ausgerichtete Authentifizierung zurücklässt — unter einer geerbten Richtlinie, die sie abweisen lässt. Die Prüfung Domain für Domain und Subdomain für Subdomain ist daher unerlässlich, sobald mehrere sendende Bereiche im Spiel sind.

Häufige Konfigurationsfehler

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

Den DKIM-Schlüssel veröffentlichen, ohne ihn zu aktivieren. Der TXT ist da, aber die Signatur wird nie angebracht, weil die Aktivierung in der Konsole nicht gesetzt wurde. Symptom: SPF besteht, DKIM fehlt in den Berichten.

Zwei SPF-Einträge stapeln. Einen zweiten v=spf1-Eintrag hinzuzufügen, statt die Includes in einem einzigen zusammenzuführen, löst einen permerror aus, der SPF vollständig ungültig macht — nicht nur die Ergänzung.

Einen Include der falschen Region kopieren. Der Zoho-Fall schlechthin, oben beschrieben: Der Include muss dem Rechenzentrum entsprechen, das das Konto beherbergt, nicht dem, das eine allgemeine Anleitung zufällig nennt. Im Zweifel gibt die Verwaltungskonsole die tatsächliche Region an.

Die Richtlinie zu früh verschärfen. Der Wechsel zu p=reject, bevor anhand der Berichte bestätigt ist, dass sich der gesamte legitime Verkehr ausrichtet — menschliche Post wie Anwendungsbenachrichtigungen —, bedeutet, die Abweisung der eigenen Nachrichten zu riskieren.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die Zoho-Konsole, 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 Zoho-Verkehr der Domain korrekt zugeordnet wird: DKIM ausgerichtet, SPF ausgerichtet, und keine Zoho-Quelle, die an beiden Mechanismen scheitert.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Veröffentlichung des _dmarc-Eintrags, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Der Zoho-Verkehr erscheint unter einem stabilen, der Kontoregion eigenen Satz von Adressen: Eine ausgerichtete Grundlinie ist schnell zu erkennen, und jede neue oder nicht ausgerichtete Zoho-Quelle fällt sofort auf — meist das Zeichen eines aus einer anderen Region sendenden Dienstes oder eines nie aktivierten DKIM-Selektors.

Diese über mehrere Tage gehaltene Prüfung ist es, die die risikolose Verschärfung der Richtlinie erlaubt. Solange die Berichte legitimen, nicht ausgerichteten Verkehr zeigen — einen vergessenen Dienst, eine fehlkonfigurierte Region —, bleibt der Wechsel zu p=reject verfrüht. Sobald die Ausrichtung über alle Ströme bestätigt ist, erfolgt der Übergang zu einer strikten Richtlinie in aller Ruhe. 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.