How to Configure DKIM, SPF, and DMARC Records for a Zimbra Server

DKIM, SPF, and DMARC solve three different parts of outbound email authentication, and a reliable Zimbra deployment needs them to work together. SPF tells receivers which systems are allowed to send with your envelope domain. DKIM adds a cryptographic signature tied to a domain. DMARC checks whether a passing SPF or DKIM identity aligns with the domain visible in the message's From header, then publishes a handling and reporting policy.

One current standards detail matters here: as of October 2026, the active DMARC protocol specification is RFC 9989, published in May 2026. It obsoletes the older RFC 7489 and changes some deployment details, including making the old pct tag historic and introducing the t testing tag. That is important if you are copying an older DMARC example from a previous Zimbra guide or DNS tutorial.

What you need before changing DNS

You need administrative shell access to a Zimbra MTA, access to the authoritative public DNS zone for your sending domain, and a complete list of every system that legitimately sends mail using that domain. That list may include your Zimbra server, a relay or smart host, marketing platforms, ticketing systems, cloud applications, and any disaster-recovery mail service.

A common misunderstanding is that publishing records for the Zimbra host alone is always enough. It is only enough when Zimbra is truly the only authorized sender. SPF is evaluated against the SMTP identity, and DMARC can expose forgotten third-party senders once enforcement is enabled. Action: inventory all outbound sources before you publish a restrictive SPF or DMARC policy.

Step 1: Generate the DKIM key in Zimbra

Zimbra includes the zmdkimkeyutil utility for domain-level DKIM signing. Zimbra's official documentation says to run it on an MTA server. To add DKIM data for a domain that does not already have it, switch to the Zimbra account and run:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

The command stores the DKIM data in Zimbra's LDAP domain entry and prints the selector and public TXT record you need to publish. Zimbra's DKIM signing documentation also documents -q to query existing DKIM data, -u to update it, and -r to remove it.

For modern Zimbra installations, the output may differ in exact selector value from examples you see online. The selector is not supposed to be a fixed word such as default or zimbra; use exactly the selector that your own server prints. Action: copy the entire public-key record from your command output rather than reconstructing it manually.

Schritt 2: DKIM-TXT-Eintrag veröffentlichen

DKIM-Prüfer suchen den öffentlichen Schlüssel im DNS unter einem Namen, der aus dem Selektor und dem Schlüsselnamen zusammengesetzt ist ._domainkey. Der Mechanismus ist in RFC 6376 definiert . In der Praxis sieht der Eintrag für DNS-Anbieter üblicherweise folgendermaßen aus:

Ob Sie nur YOUR_SELECTOR._domainkeyden vollständigen oder den vollständigen Zonennamen eingeben YOUR_SELECTOR._domainkey.example.com, hängt von Ihrem DNS-Verwaltungspanel ab. Einige Anbieter fügen den Zonennamen automatisch an. Tipp: Überprüfen Sie den vollständigen Zonennamen in der Anzeige Ihres Anbieters, bevor Sie ihn speichern, um versehentliche Fehler zu vermeiden ...example.com.example.com.

Schritt 3: Erstellen Sie einen SPF-TXT-Eintrag für die sendende Domain.

SPF wird als DNS-TXT-Eintrag in der Domain veröffentlicht, deren Absenderberechtigung Sie beschreiben möchten. RFC 7208 schreibt TXT-Einträge für SPF vor und besagt, dass mehrere SPF-Einträge für denselben Inhabernamen einen permanenten Fehler verursachen. Erstellen Sie also nicht einfach einen zweiten v=spf1TXT-Eintrag, nur weil Sie einen weiteren E-Mail-Dienst hinzufügen.

Wenn Ihr Zimbra-Server direkt von einer stabilen öffentlichen IPv4-Adresse sendet, sieht ein Minimalbeispiel so aus:

v=spf1 ip4:203.0.113.10 -all

Wenn alle in den MX-Einträgen Ihrer Domain aufgeführten Hosts legitime Absender sind, können Sie dies verwenden mx. Wenn ein Drittanbieterdienst eine SPF-Include-Domain veröffentlicht, benötigen Sie möglicherweise einen include:Mechanismus. Der genaue Eintrag ist umgebungsspezifisch, daher gibt es keine allgemein gültige Zimbra-SPF-Zeichenfolge.

Ein weiterer häufiger Fehler ist die Annahme, dass eine strikte Absenderprüfung ~allimmer sicherer ist als eine vollständige -all. Die entscheidende Frage ist, ob Ihre Liste autorisierter Absender vollständig ist. Eine strikte Prüfung -allist dann sinnvoll. Vorgehensweise: Autorisieren Sie jeden legitimen Absender in einem SPF-Eintrag, verifizieren Sie diesen im Produktivbetrieb und wählen Sie dann den endgültigen allQualifizierer auf Basis dieser Nachweise aus.

SPF sollte möglichst einfach gehalten werden. RFC 7208 beschränkt die Anzahl der Mechanismen und Modifikatoren, die DNS-Abfragen auslösen, während der Auswertung auf 10. Eine Überschreitung dieses Limits kann zu Problemen führen permerror. Maßnahmen: Zählen Sie die Includes und andere DNS-erweiternde Mechanismen, bevor Sie einen weiteren Anbieter hinzufügen.

Schritt 4: DMARC zuerst im Überwachungsmodus veröffentlichen

Die DMARC-Richtlinie ist unter [Link einfügen] veröffentlicht _dmarc.example.com. Ein erster, vorsichtiger Eintrag lautet:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneDiese Adresse fordert Empfänger auf, die Verarbeitung gemäß der DMARC-Richtlinie während der Datenerfassung nicht zu ändern. Sie ruaverlangt aggregierte Berichte; das aktuelle Format für aggregierte Berichte ist in RFC 9990 spezifiziert . Verwenden Sie ein Postfach oder einen Berichtsdienst, der DMARC-Berichte verarbeiten kann, anstatt eines unbeaufsichtigten persönlichen Posteingangs.

Kopieren Sie nicht blindlings pct=10Beispiele pct=25für Rollouts aus älteren Artikeln. RFC 9989 gilt als pcthistorisch, da die praktische Anwendung uneinheitlich war. Der aktuelle Standard verwendet t=ybei Bedarf Testverfahren. Empfehlung: Beginnen Sie mit p=noneder Analyse von Berichten; verlassen Sie sich nicht allein auf prozentuale Stichproben als Sicherheitsmechanismus.

Schritt 5: Überprüfen Sie alle drei Einträge im öffentlichen DNS.

Nachdem der DNS-Anbieter die Einträge veröffentlicht hat, können Sie diese von außerhalb des autoritativen Servers oder von einem Resolver abfragen, der öffentliche DNS-Einträge sieht. Zum Beispiel:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Prüfen Sie bei SPF, ob unter dem angegebenen Besitzernamen nur eine TXT-Antwort mit v=spf1dem entsprechenden Präfix existiert. Prüfen Sie bei DKIM, ob der Selektor exakt mit dem von Zimbra gespeicherten Wert übereinstimmt. Prüfen Sie bei DMARC, ob unter dem erwarteten Namen ein gültiger DMARC-Richtlinieneintrag vorhanden ist.

Die DNS-Propagation hängt von Ihrem Provider, der Gültigkeitsdauer (TTL) und dem Resolver-Cache ab. Eine Änderung, die sofort auf einem autoritativen Nameserver sichtbar ist, kann dennoch an anderer Stelle im Cache gespeichert sein. Empfehlung: Testen Sie die DNS-Propagation mit mindestens einem unabhängigen öffentlichen Resolver, bevor Sie Zimbra für eine veraltete Antwort verantwortlich machen.

Schritt 6: Senden Sie eine echte Nachricht und überprüfen Sie die Authentifizierungskonformität.

Senden Sie eine Nachricht von der Zimbra-Domäne an ein Postfach eines anderen Anbieters und prüfen Sie die vollständigen Nachrichtenkopfzeilen. Ein erfolgreiches Ergebnis sollte normalerweise eine gültige DKIM-Signatur und/oder ein gültiges SPF-Ergebnis sowie eine gültige DMARC-Prüfung anzeigen, da mindestens eine authentifizierte Identität mit der sichtbaren Absenderdomäne übereinstimmt.

Hier zeigt sich ein weiteres Missverständnis: DMARC benötigt nicht zwingend sowohl SPF als auch DKIM. Es genügt eine gültige, ausgerichtete SPF-Identität oder eine gültige, ausgerichtete DKIM-Identität. RFC 9989 definiert eine lockere Ausrichtung als Standard für beide Mechanismen aspf, adkimobwohl Sie mit `--strikte-alignment` eine strikte Ausrichtung anfordern können s. Handlungsempfehlung: Prüfen Sie Authentication-Resultsgenau, welcher Mechanismus die gültige DMARC-Überprüfung ermöglicht.

Schritt 7: Gehen Sie erst dann von der Überwachung zur Durchsetzung über, wenn die Berichte fehlerfrei sind.

Sobald Ihre DMARC-Daten zeigen, dass legitime Absender sich korrekt authentifizieren und ausrichten, können Sie die Richtlinie ändern p=quarantine. p=rejectIm aktuellen Standard drücken diese Richtlinien nonedie Bewertung des Domaininhabers hinsichtlich nicht authentifizierter Nutzung aus, Empfänger behalten jedoch weiterhin die Entscheidungsgewalt über die lokale Handhabung.quarantinereject

DMARC sollte nicht p=rejectals Zustellbarkeitsoptimierung betrachtet werden. DMARC dient primär der Authentifizierung und dem Schutz vor Domainmissbrauch; es macht erwünschte E-Mails nicht automatisch vertrauenswürdig und garantiert auch keine Zustellung im Posteingang. Handlungsempfehlung: Die Durchsetzung von DMARC sollte eine Sicherheitsentscheidung sein, die auf einer abgestimmten Authentifizierungsabdeckung basiert und nicht auf dem Versprechen höherer Zustellungsraten.

Schritt 8: DKIM-Schlüssel rotieren, ohne den alten DNS-Eintrag sofort zu löschen.

Um DKIM-Daten für eine Domain zu aktualisieren, dokumentiert Zimbra Folgendes:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

Der Befehl aktualisiert die DKIM-Daten und erstellt einen neuen DNS-Eintrag. Zimbra empfiehlt ausdrücklich, den vorherigen TXT-Eintrag für eine gewisse Zeit im DNS zu belassen, damit Nachrichten, die mit dem vorherigen Schlüssel signiert wurden, weiterhin während der Übertragung oder in der Warteschlange verifiziert werden können. Vorgehensweise: Veröffentlichen Sie zuerst den neuen Selektor, verifizieren Sie ihn und behalten Sie den vorherigen Selektor vorübergehend bei, bevor Sie ihn entfernen.

Kurzübersicht: Was jeder Datensatz beweist

Zimbra-spezifische Überprüfungen, die sich lohnen

Die E-Mail-Schutzrichtlinien von Zimbra weisen darauf hin, dass DKIM pro Domain generiert und im öffentlichen DNS jeder Domain veröffentlicht werden muss. Sie dokumentieren außerdem Ausrichtungsprobleme, die bei bestimmten Personas oder im Verhalten von Autorespondern in älteren Konfigurationen auftreten können. Diese Details sind situationsabhängig und nicht universell gültig: Wenn Ihre Implementierung Aliase, Personas, Relays oder ungewöhnliche Methoden zum Umschreiben von Envelope-Froms verwendet, testen Sie diese Nachrichtenpfade separat.

Bei einer Zimbra-Installation mit mehreren Domains müssen Sie die DKIM-Konfiguration und die DNS-Veröffentlichung für jede sendende Domain wiederholen. SPF und DMARC sind ebenfalls Domain-Richtlinien; gehen Sie nicht davon aus, dass ein Eintrag auf einer gehosteten Domain automatisch auch eine andere, nicht verwandte Domain abdeckt. Empfehlung: Erstellen Sie eine kleine Testmatrix für jede Domain und jede ausgehende Route, bevor Sie die strikte DMARC-Durchsetzung aktivieren.

Checkliste für die abschließende Validierung

• Es gibt genau einen SPF-Eintrag, der mit „@“ beginnt, v=spf1für jede sendende Domain.
• Der SPF-Eintrag enthält alle autorisierten ausgehenden Routen und bleibt innerhalb der SPF-DNS-Verarbeitungsgrenzen.
• Zimbra signiert ausgehende E-Mails mit dem für diese Domain gespeicherten Selektor.
• Der passende öffentliche DKIM-Schlüssel ist im öffentlichen DNS unter . sichtbar selector._domainkey.
• Der DMARC-TXT-Eintrag wird unter der angegebenen Adresse veröffentlicht _dmarc.domainund verwendet die aktuelle Syntax.
• Externe Testnachrichten zeigen einen erfolgreichen SPF- oder DKIM-Test und somit auch einen erfolgreichen DMARC-Test an.
• Die zusammengefassten Berichte werden geprüft, bevor sie von der Überwachung in die Quarantäne oder zur Ablehnung verschoben werden.
• Alte DKIM-Selektoren bleiben während der Rotation vorübergehend erhalten und werden erst nach dem Übergangsfenster entfernt.

Wenn diese Prüfungen erfolgreich sind, veröffentlicht Ihr Zimbra-Server nicht nur drei DNS-Einträge, sondern stellt eine zusammenhängende Authentifizierungskette bereit, die von externen Empfängern überprüft werden kann. Dieser Unterschied ist wichtiger als das Kopieren einer Beispielzeichenfolge aus einer Anleitung, da die korrekten SPF-Quellen, der DKIM-Selektor und die DMARC-Durchsetzungszeitpunkte davon abhängen, wie Ihre E-Mails das Unternehmen tatsächlich verlassen.