SPF, DKIM und DMARC beim CURIAWEB Hosting

SPF, DKIM und DMARC gehören zu den wichtigsten Verfahren zur Authentifizierung von E-Mails. Sie helfen empfangenden Mailservern dabei zu beurteilen, ob eine Nachricht tatsächlich über autorisierte Systeme versendet wurde und ob die verwendete Absenderdomain zur Nachricht passt.

Bei einem normalen CURIAWEB Hosting werden die erforderlichen DNS-Einträge für SPF, DKIM und DMARC grundsätzlich automatisch eingerichtet. Wenn du deine E-Mails ausschließlich über die reguläre CURIAWEB-Mailinfrastruktur versendest und die DNS-Zone bei CURIAWEB verwaltet wird, musst du diese Einträge normalerweise nicht selbst erstellen.

Wichtig: Ändere SPF-, DKIM- oder DMARC-Einträge nicht auf Verdacht. Eine falsche Konfiguration kann dazu führen, dass legitime E-Mails ihre Authentifizierung nicht mehr bestehen und dadurch schlechter zugestellt oder als Spam eingestuft werden.

Was machen SPF, DKIM und DMARC? #

Die drei Verfahren erfüllen unterschiedliche Aufgaben und ergänzen sich gegenseitig.

Verfahren	Aufgabe
SPF	Legt fest, welche Server beziehungsweise IP-Adressen für eine Domain E-Mails versenden dürfen.
DKIM	Versieht ausgehende Nachrichten mit einer kryptografischen Signatur, die über einen öffentlichen Schlüssel im DNS überprüft werden kann.
DMARC	Verknüpft SPF und DKIM mit der sichtbaren Absenderdomain und veröffentlicht eine Richtlinie für die DMARC-Prüfung.

Vereinfacht lässt sich das Zusammenspiel so darstellen:

Ausgehende E-Mail
       ↓
SPF
Ist der Versandweg autorisiert?
       +
DKIM
Ist die kryptografische Signatur gültig?
       ↓
DMARC
Passt mindestens eine erfolgreiche
Authentifizierung zur sichtbaren Absenderdomain?
       ↓
DMARC-Richtlinie berücksichtigen

SPF beim normalen CURIAWEB Hosting #

SPF steht für Sender Policy Framework. Der SPF-Record wird als TXT-Eintrag im DNS einer Domain veröffentlicht.

Bei einem normalen CURIAWEB Hosting wird der SPF-Record automatisch in der DNS-Zone angelegt.

Eine typische CURIAWEB-Standardkonfiguration sieht beispielsweise so aus:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

Die einzelnen Bestandteile haben unterschiedliche Funktionen:

Bestandteil	Bedeutung
v=spf1	Kennzeichnet den TXT-Eintrag als SPF-Version 1.
+a	Autorisiert die über den A-Mechanismus ermittelten Systeme.
+mx	Autorisiert die über die MX-Einträge der Domain ermittelten Systeme.
+ip4:144.76.63.89	Autorisiert diese IPv4-Adresse für den Versand.
~all	Andere, nicht zuvor erfasste Versandquellen erhalten ein SPF-Softfail.

Wichtig: Der hier gezeigte SPF-Record ist ein Beispiel für die normale CURIAWEB-Hostingkonfiguration. Kopiere ihn nicht auf eine andere Domain oder in eine andere Hostingumgebung, ohne vorher den tatsächlichen Versandweg zu prüfen.

Was bedeutet ~all? #

Das ~ vor all bezeichnet bei SPF einen Softfail.

Damit erklärt die Domain, dass Systeme, die von den vorherigen Mechanismen nicht erfasst werden, nicht als reguläre Versandquellen vorgesehen sind. Die endgültige Behandlung einer solchen Nachricht liegt jedoch beim empfangenden System und dessen weiteren Prüfungen.

Das unterscheidet sich beispielsweise von:

-all

Das Minuszeichen bezeichnet einen SPF Fail.

Du solltest einen bestehenden SPF-Record deshalb nicht einfach von ~all auf -all ändern. Eine strengere Policy ist nur sinnvoll, wenn die gesamte Versandumgebung bekannt und korrekt berücksichtigt ist.

DKIM beim CURIAWEB Hosting #

DKIM steht für DomainKeys Identified Mail.

Während SPF den Versandweg autorisiert, arbeitet DKIM mit einer kryptografischen Signatur.

Vereinfacht besteht DKIM aus zwei Teilen:

Privater DKIM-Schlüssel
→ befindet sich auf dem sendenden System
→ signiert die ausgehende E-Mail

Öffentlicher DKIM-Schlüssel
→ wird im DNS veröffentlicht
→ ermöglicht dem Empfänger die Prüfung

Der private Schlüssel darf nicht öffentlich zugänglich sein. Im DNS befindet sich ausschließlich der öffentliche Teil.

Wie sieht ein DKIM-Eintrag aus? #

DKIM verwendet einen sogenannten Selector. Dadurch kann eine Domain unterschiedliche DKIM-Schlüssel verwenden und Schlüssel später austauschen.

Ein DKIM-DNS-Name folgt grundsätzlich diesem Schema:

selector._domainkey.example.ch

Der zugehörige TXT-Record enthält unter anderem den öffentlichen Schlüssel.

Schematisch sieht ein DKIM-Record beispielsweise so aus:

v=DKIM1; k=rsa; p=PUBLIC_KEY

Der tatsächliche öffentliche Schlüssel ist wesentlich länger und wird automatisch für die betreffende Domain erzeugt.

Achtung: Verwende niemals einen DKIM-Schlüssel einer anderen Domain und kopiere keine DKIM-Einträge zwischen Domains. Das jeweilige Schlüsselpaar gehört zur konkreten DKIM-Konfiguration der Domain.

DKIM musst du normalerweise nicht selbst erstellen #

Bei einer regulären CURIAWEB-Hostingkonfiguration wird DKIM automatisch eingerichtet.

Wenn deine Domain die CURIAWEB-DNS-Zone verwendet und E-Mails über die vorgesehene Mailinfrastruktur versendet werden, solltest du deshalb nicht zusätzlich einen eigenen DKIM-Record erstellen.

Mehrere DKIM-Selectoren sind technisch durchaus möglich. Sie sollten aber nur vorhanden sein, wenn die entsprechenden Versandsysteme tatsächlich mit diesen Selector-Schlüsseln signieren.

Was prüft DKIM? #

Beim Versand wird die Nachricht mit dem privaten DKIM-Schlüssel signiert. Der empfangende Mailserver liest aus der DKIM-Signatur unter anderem die verwendete Domain und den Selector.

Über diesen Selector kann er den zugehörigen öffentlichen Schlüssel im DNS abrufen und die Signatur überprüfen.

Ein erfolgreiches DKIM-Ergebnis kann beispielsweise als:

dkim=pass

in den Authentifizierungsergebnissen einer empfangenen Nachricht erscheinen.

Was bedeutet ein DKIM-Fehler? #

Ein DKIM-Fehler kann unterschiedliche Ursachen haben. Beispielsweise kann der öffentliche Schlüssel fehlen, ein falscher Selector verwendet werden oder die Nachricht beziehungsweise relevante signierte Bestandteile können nach der Signierung so verändert worden sein, dass die Signatur nicht mehr erfolgreich validiert werden kann.

Ein DKIM-Fehler sollte deshalb anhand der konkreten Nachricht und ihres Versandweges untersucht werden.

DMARC beim CURIAWEB Hosting #

DMARC steht für Domain-based Message Authentication, Reporting and Conformance.

DMARC baut auf SPF und DKIM auf, fügt aber einen entscheidenden Punkt hinzu: die Beziehung zur Domain, die der Empfänger als Absender im sichtbaren From:-Feld der E-Mail sieht.

Bei einem normalen CURIAWEB Hosting wird auch ein DMARC-Record automatisch angelegt.

Die CURIAWEB-Standardkonfiguration lautet:

v=DMARC1; p=none;

Was bedeutet v=DMARC1; p=none;? #

Der Record besteht in dieser Grundkonfiguration aus zwei wesentlichen Angaben.

Bestandteil	Bedeutung
v=DMARC1	Kennzeichnet den Eintrag als DMARC-Version 1.
p=none	Veröffentlicht keine DMARC-Anweisung, fehlgeschlagene Nachrichten allein aufgrund der DMARC-Policy zu quarantänisieren oder zurückzuweisen.

p=none bedeutet dabei nicht, dass SPF oder DKIM deaktiviert sind. Ebenso bedeutet es nicht, dass ein empfangender Spamfilter eine verdächtige Nachricht akzeptieren muss.

Andere Sicherheits- und Spamprüfungen des empfangenden Systems bleiben davon unberührt.

Wo befindet sich der DMARC-Record? #

DMARC wird als TXT-Record unter dem speziellen Hostnamen _dmarc veröffentlicht.

Für eine Domain wie:

example.ch

wird der DMARC-Record entsprechend unter:

_dmarc.example.ch

abgerufen.

Was sind p=none, p=quarantine und p=reject? #

DMARC kennt verschiedene Domain-Policies.

Policy	Grundsätzliche Bedeutung
p=none	Keine DMARC-basierte Quarantäne- oder Reject-Anweisung.
p=quarantine	Nachrichten, die DMARC nicht bestehen, sollen vom empfangenden System entsprechend als verdächtig behandelt werden, typischerweise etwa durch Quarantäne beziehungsweise Spam-Behandlung.
p=reject	Nachrichten, die DMARC nicht bestehen, sollen zurückgewiesen werden.

Wichtig: Stelle eine Domain nicht einfach von p=none auf p=quarantine oder p=reject um. Zuerst muss sichergestellt sein, dass alle legitimen Versandsysteme korrekt über SPF und/oder DKIM authentifiziert werden und das notwendige DMARC-Alignment erreichen.

Was bedeutet DMARC Alignment? #

DMARC prüft nicht lediglich, ob irgendwo in einer Nachricht SPF oder DKIM erfolgreich ist. Entscheidend ist auch die Beziehung zur sichtbaren Absenderdomain.

Diese Beziehung wird als Alignment bezeichnet.

Vereinfacht:

Sichtbarer Absender:
info@example.ch

SPF:
Prüfung des relevanten Envelope-Sender-Versandwegs

DKIM:
Prüfung der DKIM-Signatur und Signaturdomain

DMARC:
Passt eine erfolgreiche Authentifizierung
zur sichtbaren Absenderdomain?

Damit erschwert DMARC unter anderem, dass ein Angreifer zwar irgendeine eigene Domain korrekt authentifiziert, im sichtbaren Absender aber eine fremde Domain verwendet und diese Authentifizierung als Nachweis für die fremde Domain ausgibt.

Müssen SPF und DKIM beide erfolgreich sein? #

Für einen erfolgreichen DMARC-Test müssen nicht zwingend SPF und DKIM gleichzeitig erfolgreich und aligned sein.

DMARC kann grundsätzlich bestehen, wenn mindestens einer der beiden Authentifizierungswege erfolgreich ist und die erforderliche Übereinstimmung mit der sichtbaren Absenderdomain gegeben ist.

Kurz erklärt: SPF und DKIM sind zwei unterschiedliche Authentifizierungswege. DMARC verbindet deren Ergebnisse mit der sichtbaren Absenderdomain.

Warum verwendet CURIAWEB standardmäßig p=none? #

Eine Domain kann neben dem normalen Hosting-Mailserver weitere Systeme zum Versand verwenden. Dazu können beispielsweise Newsletterdienste, Shops, CRM-Systeme, Buchhaltungssoftware, Ticketsysteme oder externe Cloud-Dienste gehören.

Eine pauschal verschärfte DMARC-Policy kann problematisch werden, wenn solche legitimen Versandquellen nicht korrekt in die Authentifizierungsstruktur eingebunden sind.

Die standardmäßige Konfiguration mit:

v=DMARC1; p=none;

vermeidet deshalb eine pauschale Anweisung, DMARC-fehlgeschlagene Nachrichten allein aufgrund dieser Policy zu quarantänisieren oder zurückzuweisen.

Wenn für eine Domain eine strengere DMARC-Strategie gewünscht ist, sollte zuerst die gesamte Versandlandschaft analysiert werden.

Wann muss die automatische Konfiguration angepasst werden? #

Solange du ausschließlich die normale CURIAWEB-Mailinfrastruktur verwendest, besteht normalerweise kein Grund, die automatisch eingerichteten Einträge zu verändern.

Eine Prüfung beziehungsweise Anpassung kann jedoch notwendig werden, sobald zusätzliche Systeme E-Mails mit deiner Domain als Absender versenden.

Typische Beispiele sind:

• Newsletter- und Marketingplattformen
• CRM-Systeme
• externe SMTP-Dienste
• Microsoft 365 oder andere externe Mailplattformen
• Support- und Ticketsysteme
• Webshops und Transaktionsmail-Dienste
• SpamExperts Outgoing Filtering

Diese Dienste können eigene Anforderungen an SPF, DKIM oder DMARC haben.

Bestehende DNS-Einträge nicht überschreiben #

Wenn ein externer Anbieter beispielsweise einen zusätzlichen SPF-Mechanismus verlangt, darf der vorhandene SPF-Record nicht einfach gelöscht und durch den Beispielrecord des Anbieters ersetzt werden.

Bei SPF müssen alle tatsächlich autorisierten Versandquellen in einer gültigen SPF-Richtlinie berücksichtigt werden.

Achtung: Mehrere separate TXT-Records, die jeweils mit v=spf1 beginnen, sind nicht die richtige Methode, um mehrere Versanddienste zu autorisieren. Die benötigten Mechanismen müssen in einer gemeinsamen SPF-Richtlinie zusammengeführt werden.

Auch DKIM kann sich bei externen Versandsystemen ändern #

Ein externer Versanddienst kann einen eigenen DKIM-Selector verwenden und verlangen, dass dafür ein zusätzlicher DNS-Eintrag angelegt wird.

Das bedeutet nicht automatisch, dass der bestehende CURIAWEB-DKIM-Eintrag entfernt werden muss.

Mehrere DKIM-Selectoren können parallel existieren, wenn unterschiedliche Systeme jeweils mit ihrem zugehörigen Schlüssel signieren.

SpamExperts benötigt eine gesonderte Betrachtung #

Wenn SpamExperts Outgoing Filtering verwendet wird, entspricht der E-Mail-Versandweg nicht mehr vollständig der normalen CURIAWEB-Standardkonfiguration.

Insbesondere der SPF-Record muss dann zur SpamExperts-Outgoing-Infrastruktur passen.

Die entsprechende Konfiguration erklären wir separat unter SPF für SpamExperts richtig einrichten und prüfen.

Auch DKIM kann bei SpamExperts Outgoing Filtering gesondert konfiguriert werden. Eine bereits vorhandene DKIM-Signierung des sendenden Systems muss dabei berücksichtigt werden.

Wichtig: Verwende deshalb nicht einfach die normale CURIAWEB-SPF- oder DKIM-Konfiguration als Vorlage für SpamExperts Outgoing Filtering. Der tatsächliche Versandweg entscheidet darüber, welche Authentifizierungseinstellungen benötigt werden.

SpamExperts prüft SPF, DKIM und DMARC bei eingehenden E-Mails #

SpamExperts verwendet SPF, DKIM und DMARC außerdem bei der Analyse eingehender Nachrichten.

Diese Prüfungen dienen dazu, Informationen über die Authentizität einer eingehenden Nachricht beziehungsweise ihrer Absenderdomain in die Filterentscheidung einzubeziehen.

Die entsprechenden Sender Checks sollten grundsätzlich aktiviert bleiben.

Mehr dazu erklären wir unter SpamExperts Filter-Einstellungen: Warum die Standardkonfiguration meist die beste Wahl ist.

SPF, DKIM und DMARC in cPanel prüfen #

Bei CURIAWEB kannst du die mailbezogenen DNS-Einstellungen in cPanel kontrollieren.

Öffne dazu:

cPanel → E-Mail → E-Mail-Zustellbarkeit

Dort können für die betreffenden Domains unter anderem SPF- und DKIM-bezogene Informationen beziehungsweise erkannte Konfigurationsprobleme angezeigt werden.

Für eine direkte Kontrolle der DNS-Zone kannst du außerdem den Zoneneditor verwenden.

Eine ausführliche Anleitung dazu findest du unter DNS-Zoneneditor in cPanel verwenden.

SPF im DNS erkennen #

Der SPF-Record ist ein TXT-Eintrag, dessen Inhalt mit:

v=spf1

beginnt.

Bei einer normalen CURIAWEB-Konfiguration kann er beispielsweise so aussehen:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

DKIM im DNS erkennen #

DKIM-Einträge befinden sich unter einem Hostnamen mit:

._domainkey.

Beispielsweise schematisch:

selector._domainkey.example.ch

Der konkrete Selector und der öffentliche Schlüssel hängen von der Konfiguration deiner Domain ab.

DMARC im DNS erkennen #

Der DMARC-TXT-Record befindet sich unter:

_dmarc.example.ch

Bei der CURIAWEB-Standardkonfiguration lautet der Inhalt:

v=DMARC1; p=none;

Authentifizierung mit einer Testmail überprüfen #

Zusätzlich zur DNS-Prüfung kannst du eine echte E-Mail über den normalen Versandweg senden und anschließend deren vollständige Nachrichtenheader beziehungsweise Authentifizierungsergebnisse untersuchen.

Je nach empfangendem Maildienst können dort beispielsweise Ergebnisse wie:

spf=pass
dkim=pass
dmarc=pass

angezeigt werden.

Die genaue Darstellung unterscheidet sich je nach empfangendem Mailserver.

Praxis-Tipp: Verwende für einen aussagekräftigen Test genau den Versandweg, den du auch produktiv nutzt. Eine Testmail über einen anderen SMTP-Dienst sagt nichts darüber aus, ob die normale CURIAWEB-Konfiguration korrekt arbeitet.

Was tun bei spf=fail? #

Wenn eine legitime Nachricht einen SPF-Fehler erhält, sollte zuerst der tatsächliche Versandweg untersucht werden.

Prüfe insbesondere, ob die Nachricht über den vorgesehenen Mailserver versendet wurde und ob zusätzliche externe Versanddienste verwendet werden.

Bei einem normalen CURIAWEB-Hosting sollte außerdem kontrolliert werden, ob der automatisch eingerichtete SPF-Record noch vollständig vorhanden ist.

Was tun bei dkim=fail? #

Bei einem DKIM-Fehler sollte geprüft werden, welches System die Nachricht signiert hat, welcher Selector verwendet wurde und ob der dazugehörige öffentliche Schlüssel korrekt im DNS veröffentlicht ist.

Wurde die Domain oder deren DNS-Konfiguration kürzlich zu einem anderen Anbieter verschoben, sollte insbesondere kontrolliert werden, ob die benötigten DKIM-Einträge vollständig übernommen wurden.

Was tun bei dmarc=fail? #

Ein DMARC-Fehler bedeutet nicht automatisch, dass SPF und DKIM beide vollständig ausgefallen sind.

Entscheidend ist auch das Alignment zur sichtbaren Absenderdomain.

Deshalb sollten bei einem DMARC-Problem SPF, DKIM, die sichtbare From-Domain und der tatsächlich verwendete Versanddienst gemeinsam betrachtet werden.

Nach einem DNS-Umzug besonders aufpassen #

SPF, DKIM und DMARC liegen im DNS. Wenn die Nameserver einer Domain geändert oder die DNS-Zone zu einem anderen Anbieter verschoben wird, müssen deshalb auch die für E-Mail benötigten DNS-Einträge korrekt vorhanden sein.

Eine Website kann nach einem DNS-Umzug problemlos funktionieren, während die E-Mail-Authentifizierung trotzdem fehlerhaft ist.

Kontrolliere deshalb nach einem DNS-Umzug nicht nur A-, AAAA- oder MX-Einträge, sondern auch die relevanten TXT-Einträge.

Typische Fehler bei SPF, DKIM und DMARC #

Fehler	Mögliche Folge
Automatischen SPF-Record überschrieben	CURIAWEB-Mailserver oder andere legitime Systeme sind möglicherweise nicht mehr korrekt autorisiert.
Mehrere separate SPF-Records erstellt	SPF kann nicht korrekt ausgewertet werden.
DKIM-Record bei DNS-Umzug vergessen	DKIM-Signaturen können nicht mehr erfolgreich überprüft werden.
Falscher DKIM-Selector	Der Empfänger findet nicht den zur Signatur passenden öffentlichen Schlüssel.
DMARC voreilig auf p=reject gestellt	Legitime, nicht korrekt authentifizierte beziehungsweise nicht aligned versendete Nachrichten können zurückgewiesen werden.
Externen Maildienst hinzugefügt, DNS aber nicht angepasst	SPF, DKIM oder DMARC können für dessen Nachrichten fehlschlagen.
SpamExperts-Konfiguration mit Standardhosting verwechselt	Die Authentifizierung passt möglicherweise nicht zum tatsächlichen Versandweg.

Wann solltest du SPF, DKIM oder DMARC selbst ändern? #

Bei einer normalen CURIAWEB-Hostingkonfiguration lautet die Antwort meistens: gar nicht.

Eine manuelle Anpassung ist vor allem dann erforderlich, wenn sich der Versandweg ändert oder zusätzliche Systeme im Namen deiner Domain E-Mails versenden sollen.

Bevor du Änderungen vornimmst, sollte deshalb immer zuerst geklärt werden:

1. Welche Systeme versenden tatsächlich E-Mails für die Domain?
2. Welcher Mailserver beziehungsweise SMTP-Dienst wird verwendet?
3. Welche SPF-Anforderungen haben diese Systeme?
4. Welches System signiert mit DKIM?
5. Welche DKIM-Selectoren werden verwendet?
6. Ist das für DMARC erforderliche Alignment gegeben?
7. Welche DMARC-Policy ist aktuell veröffentlicht?

Zusammenfassung #

SPF, DKIM und DMARC bilden gemeinsam eine wichtige Grundlage für die Authentifizierung von E-Mails.

Bei einem normalen CURIAWEB Hosting werden die entsprechenden DNS-Einträge grundsätzlich automatisch eingerichtet.

Der SPF-Record kann in der CURIAWEB-Standardkonfiguration beispielsweise so aussehen:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

DKIM wird automatisch für die Domain eingerichtet und ermöglicht die kryptografische Signierung und Überprüfung ausgehender Nachrichten.

Der standardmäßig angelegte DMARC-Record lautet:

v=DMARC1; p=none;

Solange du ausschließlich die normale CURIAWEB-Mailinfrastruktur verwendest, solltest du diese Einstellungen normalerweise nicht verändern.

Eine individuelle Anpassung wird insbesondere dann notwendig, wenn externe Systeme wie Newsletterdienste, CRM-Plattformen, Microsoft 365, externe SMTP-Dienste oder SpamExperts Outgoing Filtering E-Mails im Namen deiner Domain versenden.

Entscheidend ist immer der tatsächliche Versandweg. SPF, DKIM und DMARC sollten deshalb nicht anhand allgemeiner Beispielwerte, sondern passend zur real verwendeten E-Mail-Infrastruktur konfiguriert werden.