{"id":22680,"date":"2026-08-28T16:02:23","date_gmt":"2026-08-28T14:02:23","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22680"},"modified":"2026-08-28T16:02:24","modified_gmt":"2026-08-28T14:02:24","password":"","slug":"spf-dkim-dmarc-hosting","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/it\/hilfe\/e-mail-spamexperts\/spf-dkim-dmarc-hosting\/","title":{"rendered":"SPF, DKIM e DMARC con l'hosting CURIAWEB"},"content":{"rendered":"

SPF, DKIM e DMARC<\/strong> geh\u00f6ren zu den wichtigsten Verfahren zur Authentifizierung von E-Mails. Sie helfen empfangenden Mailservern dabei zu beurteilen, ob eine Nachricht tats\u00e4chlich \u00fcber autorisierte Systeme versendet wurde und ob die verwendete Absenderdomain zur Nachricht passt.<\/p>\n\n\n\n

Bei einem normalen CURIAWEB Hosting werden die erforderlichen DNS-Eintr\u00e4ge f\u00fcr SPF, DKIM und DMARC grunds\u00e4tzlich automatisch eingerichtet. Wenn du deine E-Mails ausschlie\u00dflich \u00fcber die regul\u00e4re CURIAWEB-Mailinfrastruktur versendest und die DNS-Zone bei CURIAWEB verwaltet wird, musst du diese Eintr\u00e4ge normalerweise nicht selbst erstellen.<\/p>\n\n\n\n

\n

Importante:<\/strong> \u00c4ndere SPF-, DKIM- oder DMARC-Eintr\u00e4ge nicht auf Verdacht. Eine falsche Konfiguration kann dazu f\u00fchren, dass legitime E-Mails ihre Authentifizierung nicht mehr bestehen und dadurch schlechter zugestellt oder als Spam eingestuft werden.<\/p>\n<\/blockquote>\n\n\n\n

Was machen SPF, DKIM und DMARC?<\/h2>\n\n\n\n

Die drei Verfahren erf\u00fcllen unterschiedliche Aufgaben und erg\u00e4nzen sich gegenseitig.<\/p>\n\n\n\n

Procedimento<\/th>Compito<\/th><\/tr><\/thead>
SPF<\/strong><\/td>Legt fest, welche Server beziehungsweise IP-Adressen f\u00fcr eine Domain E-Mails versenden d\u00fcrfen.<\/td><\/tr>
DKIM<\/strong><\/td>Versieht ausgehende Nachrichten mit einer kryptografischen Signatur, die \u00fcber einen \u00f6ffentlichen Schl\u00fcssel im DNS \u00fcberpr\u00fcft werden kann.<\/td><\/tr>
DMARC<\/strong><\/td>Verkn\u00fcpft SPF und DKIM mit der sichtbaren Absenderdomain und ver\u00f6ffentlicht eine Richtlinie f\u00fcr die DMARC-Pr\u00fcfung.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vereinfacht l\u00e4sst sich das Zusammenspiel so darstellen:<\/p>\n\n\n\n

Ausgehende E-Mail\n       \u2193\nSPF\nIst der Versandweg autorisiert?\n       +\nDKIM\nIst die kryptografische Signatur g\u00fcltig?\n       \u2193\nDMARC\nPasst mindestens eine erfolgreiche\nAuthentifizierung zur sichtbaren Absenderdomain?\n       \u2193\nDMARC-Richtlinie ber\u00fccksichtigen<\/code><\/pre>\n\n\n\n
SPF beim normalen CURIAWEB Hosting<\/h2>\n\n\n\n
SPF<\/strong> significa Sender Policy Framework<\/strong>. Der SPF-Record wird als TXT-Eintrag im DNS einer Domain ver\u00f6ffentlicht.<\/p>\n\n\n\n
Bei einem normalen CURIAWEB Hosting wird der SPF-Record automatisch in der DNS-Zone angelegt.<\/p>\n\n\n\n
Eine typische CURIAWEB-Standardkonfiguration sieht beispielsweise so aus:<\/p>\n\n\n\n
v=spf1 +a +mx +ip4:144.76.63.89 ~all<\/code><\/p>\n\n\n\n
Die einzelnen Bestandteile haben unterschiedliche Funktionen:<\/p>\n\n\n\n
Bestandteil<\/th>Significato<\/th><\/tr><\/thead>
v=spf1<\/code><\/td>Kennzeichnet den TXT-Eintrag als SPF-Version 1.<\/td><\/tr>
+a<\/code><\/td>Autorisiert die \u00fcber den A-Mechanismus ermittelten Systeme.<\/td><\/tr>
+mx<\/code><\/td>Autorisiert die \u00fcber die MX-Eintr\u00e4ge der Domain ermittelten Systeme.<\/td><\/tr>
+ip4:144.76.63.89<\/code><\/td>Autorisiert diese IPv4-Adresse f\u00fcr den Versand.<\/td><\/tr>
~all<\/code><\/td>Andere, nicht zuvor erfasste Versandquellen erhalten ein SPF-Softfail.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n
Importante:<\/strong> Der hier gezeigte SPF-Record ist ein Beispiel f\u00fcr die normale CURIAWEB-Hostingkonfiguration. Kopiere ihn nicht auf eine andere Domain oder in eine andere Hostingumgebung, ohne vorher den tats\u00e4chlichen Versandweg zu pr\u00fcfen.<\/p>\n<\/blockquote>\n\n\n\n
Cosa significa ~all<\/code>?<\/h2>\n\n\n\n
Il ~<\/code> ladro all<\/code> bezeichnet bei SPF einen Softfail<\/strong>.<\/p>\n\n\n\n
Damit erkl\u00e4rt die Domain, dass Systeme, die von den vorherigen Mechanismen nicht erfasst werden, nicht als regul\u00e4re Versandquellen vorgesehen sind. Die endg\u00fcltige Behandlung einer solchen Nachricht liegt jedoch beim empfangenden System und dessen weiteren Pr\u00fcfungen.<\/p>\n\n\n\n
Das unterscheidet sich beispielsweise von:<\/p>\n\n\n\n
-all<\/code><\/p>\n\n\n\n
Das Minuszeichen bezeichnet einen SPF Fail<\/strong>.<\/p>\n\n\n\n
Du solltest einen bestehenden SPF-Record deshalb nicht einfach von ~all<\/code> su -all<\/code> \u00e4ndern. Eine strengere Policy ist nur sinnvoll, wenn die gesamte Versandumgebung bekannt und korrekt ber\u00fccksichtigt ist.<\/p>\n\n\n\n
DKIM beim CURIAWEB Hosting<\/h2>\n\n\n\n
DKIM<\/strong> significa DomainKeys Identified Mail<\/strong>.<\/p>\n\n\n\n
W\u00e4hrend SPF den Versandweg autorisiert, arbeitet DKIM mit einer kryptografischen Signatur.<\/p>\n\n\n\n
Vereinfacht besteht DKIM aus zwei Teilen:<\/p>\n\n\n\n
Privater DKIM-Schl\u00fcssel\n\u2192 befindet sich auf dem sendenden System\n\u2192 signiert die ausgehende E-Mail\n\n\u00d6ffentlicher DKIM-Schl\u00fcssel\n\u2192 wird im DNS ver\u00f6ffentlicht\n\u2192 erm\u00f6glicht dem Empf\u00e4nger die Pr\u00fcfung<\/code><\/pre>\n\n\n\n
Der private Schl\u00fcssel darf nicht \u00f6ffentlich zug\u00e4nglich sein. Im DNS befindet sich ausschlie\u00dflich der \u00f6ffentliche Teil.<\/p>\n\n\n\n
Wie sieht ein DKIM-Eintrag aus?<\/h2>\n\n\n\n
DKIM verwendet einen sogenannten Selettore<\/strong>. Dadurch kann eine Domain unterschiedliche DKIM-Schl\u00fcssel verwenden und Schl\u00fcssel sp\u00e4ter austauschen.<\/p>\n\n\n\n
Ein DKIM-DNS-Name folgt grunds\u00e4tzlich diesem Schema:<\/p>\n\n\n\n
selector._domainkey.example.ch<\/code><\/p>\n\n\n\n
Der zugeh\u00f6rige TXT-Record enth\u00e4lt unter anderem den \u00f6ffentlichen Schl\u00fcssel.<\/p>\n\n\n\n
Schematisch sieht ein DKIM-Record beispielsweise so aus:<\/p>\n\n\n\n
v=DKIM1; k=rsa; p=PUBLIC_KEY<\/code><\/p>\n\n\n\n
Der tats\u00e4chliche \u00f6ffentliche Schl\u00fcssel ist wesentlich l\u00e4nger und wird automatisch f\u00fcr die betreffende Domain erzeugt.<\/p>\n\n\n\n
\n
Attenzione:<\/strong> Verwende niemals einen DKIM-Schl\u00fcssel einer anderen Domain und kopiere keine DKIM-Eintr\u00e4ge zwischen Domains. Das jeweilige Schl\u00fcsselpaar geh\u00f6rt zur konkreten DKIM-Konfiguration der Domain.<\/p>\n<\/blockquote>\n\n\n\n
DKIM musst du normalerweise nicht selbst erstellen<\/h2>\n\n\n\n
Bei einer regul\u00e4ren CURIAWEB-Hostingkonfiguration wird DKIM automatisch eingerichtet.<\/p>\n\n\n\n
Wenn deine Domain die CURIAWEB-DNS-Zone verwendet und E-Mails \u00fcber die vorgesehene Mailinfrastruktur versendet werden, solltest du deshalb nicht zus\u00e4tzlich einen eigenen DKIM-Record erstellen.<\/p>\n\n\n\n
Mehrere DKIM-Selectoren sind technisch durchaus m\u00f6glich. Sie sollten aber nur vorhanden sein, wenn die entsprechenden Versandsysteme tats\u00e4chlich mit diesen Selector-Schl\u00fcsseln signieren.<\/p>\n\n\n\n
Was pr\u00fcft DKIM?<\/h2>\n\n\n\n
Beim Versand wird die Nachricht mit dem privaten DKIM-Schl\u00fcssel signiert. Der empfangende Mailserver liest aus der DKIM-Signatur unter anderem die verwendete Domain und den Selector.<\/p>\n\n\n\n
\u00dcber diesen Selector kann er den zugeh\u00f6rigen \u00f6ffentlichen Schl\u00fcssel im DNS abrufen und die Signatur \u00fcberpr\u00fcfen.<\/p>\n\n\n\n
Ein erfolgreiches DKIM-Ergebnis kann beispielsweise als:<\/p>\n\n\n\n
dkim=pass<\/code><\/p>\n\n\n\n
in den Authentifizierungsergebnissen einer empfangenen Nachricht erscheinen.<\/p>\n\n\n\n
Was bedeutet ein DKIM-Fehler?<\/h2>\n\n\n\n
Ein DKIM-Fehler kann unterschiedliche Ursachen haben. Beispielsweise kann der \u00f6ffentliche Schl\u00fcssel fehlen, ein falscher Selector verwendet werden oder die Nachricht beziehungsweise relevante signierte Bestandteile k\u00f6nnen nach der Signierung so ver\u00e4ndert worden sein, dass die Signatur nicht mehr erfolgreich validiert werden kann.<\/p>\n\n\n\n
Ein DKIM-Fehler sollte deshalb anhand der konkreten Nachricht und ihres Versandweges untersucht werden.<\/p>\n\n\n\n
DMARC beim CURIAWEB Hosting<\/h2>\n\n\n\n
DMARC<\/strong> significa Domain-based Message Authentication, Reporting and Conformance<\/strong>.<\/p>\n\n\n\n
DMARC baut auf SPF und DKIM auf, f\u00fcgt aber einen entscheidenden Punkt hinzu: die Beziehung zur Domain, die der Empf\u00e4nger als Absender im sichtbaren From:<\/strong>-Feld der E-Mail sieht.<\/p>\n\n\n\n
Bei einem normalen CURIAWEB Hosting wird auch ein DMARC-Record automatisch angelegt.<\/p>\n\n\n\n
Die CURIAWEB-Standardkonfiguration lautet:<\/p>\n\n\n\n
v=DMARC1; p=none;<\/code><\/p>\n\n\n\n
Cosa significa v=DMARC1; p=none;<\/code>?<\/h2>\n\n\n\n
Der Record besteht in dieser Grundkonfiguration aus zwei wesentlichen Angaben.<\/p>\n\n\n\n
Bestandteil<\/th>Significato<\/th><\/tr><\/thead>
v=DMARC1<\/code><\/td>Kennzeichnet den Eintrag als DMARC-Version 1.<\/td><\/tr>
p=nessuno<\/code><\/td>Ver\u00f6ffentlicht keine DMARC-Anweisung, fehlgeschlagene Nachrichten allein aufgrund der DMARC-Policy zu quarant\u00e4nisieren oder zur\u00fcckzuweisen.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
p=nessuno<\/code> bedeutet dabei nicht, dass SPF oder DKIM deaktiviert sind. Ebenso bedeutet es nicht, dass ein empfangender Spamfilter eine verd\u00e4chtige Nachricht akzeptieren muss.<\/p>\n\n\n\n
Andere Sicherheits- und Spampr\u00fcfungen des empfangenden Systems bleiben davon unber\u00fchrt.<\/p>\n\n\n\n
Wo befindet sich der DMARC-Record?<\/h2>\n\n\n\n
DMARC wird als TXT-Record unter dem speziellen Hostnamen _dmarc<\/code> ver\u00f6ffentlicht.<\/p>\n\n\n\n
F\u00fcr eine Domain wie:<\/p>\n\n\n\n
example.ch<\/code><\/p>\n\n\n\n
wird der DMARC-Record entsprechend unter:<\/p>\n\n\n\n
_dmarc.example.ch<\/code><\/p>\n\n\n\n
abgerufen.<\/p>\n\n\n\n
Was sind p=nessuno<\/code>, p=quarantena<\/code> e p=rifiuta<\/code>?<\/h2>\n\n\n\n
DMARC kennt verschiedene Domain-Policies.<\/p>\n\n\n\n
Policy<\/th>Importanza fondamentale<\/th><\/tr><\/thead>
p=nessuno<\/code><\/td>Keine DMARC-basierte Quarant\u00e4ne- oder Reject-Anweisung.<\/td><\/tr>
p=quarantena<\/code><\/td>Nachrichten, die DMARC nicht bestehen, sollen vom empfangenden System entsprechend als verd\u00e4chtig behandelt werden, typischerweise etwa durch Quarant\u00e4ne beziehungsweise Spam-Behandlung.<\/td><\/tr>
p=rifiuta<\/code><\/td>Nachrichten, die DMARC nicht bestehen, sollen zur\u00fcckgewiesen werden.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n
Importante:<\/strong> Stelle eine Domain nicht einfach von p=nessuno<\/code> su p=quarantena<\/code> o p=rifiuta<\/code> um. Zuerst muss sichergestellt sein, dass alle legitimen Versandsysteme korrekt \u00fcber SPF und\/oder DKIM authentifiziert werden und das notwendige DMARC-Alignment erreichen.<\/p>\n<\/blockquote>\n\n\n\n
Cosa significa allineamento DMARC?<\/h2>\n\n\n\n
DMARC pr\u00fcft nicht lediglich, ob irgendwo in einer Nachricht SPF oder DKIM erfolgreich ist. Entscheidend ist auch die Beziehung zur sichtbaren Absenderdomain.<\/p>\n\n\n\n
Diese Beziehung wird als Allineamento<\/strong> definito.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
Sichtbarer Absender:\ninfo@example.ch\n\nSPF:\nPr\u00fcfung des relevanten Envelope-Sender-Versandwegs\n\nDKIM:\nPr\u00fcfung der DKIM-Signatur und Signaturdomain\n\nDMARC:\nPasst eine erfolgreiche Authentifizierung\nzur sichtbaren Absenderdomain?<\/code><\/pre>\n\n\n\n
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\u00fcr die fremde Domain ausgibt.<\/p>\n\n\n\n
M\u00fcssen SPF und DKIM beide erfolgreich sein?<\/h2>\n\n\n\n
F\u00fcr einen erfolgreichen DMARC-Test m\u00fcssen nicht zwingend SPF e<\/strong> DKIM gleichzeitig erfolgreich und aligned sein.<\/p>\n\n\n\n
DMARC kann grunds\u00e4tzlich bestehen, wenn mindestens einer der beiden Authentifizierungswege erfolgreich ist und die erforderliche \u00dcbereinstimmung mit der sichtbaren Absenderdomain gegeben ist.<\/p>\n\n\n\n
\n
Breve spiegazione:<\/strong> SPF und DKIM sind zwei unterschiedliche Authentifizierungswege. DMARC verbindet deren Ergebnisse mit der sichtbaren Absenderdomain.<\/p>\n<\/blockquote>\n\n\n\n
Warum verwendet CURIAWEB standardm\u00e4\u00dfig p=nessuno<\/code>?<\/h2>\n\n\n\n
Eine Domain kann neben dem normalen Hosting-Mailserver weitere Systeme zum Versand verwenden. Dazu k\u00f6nnen beispielsweise Newsletterdienste, Shops, CRM-Systeme, Buchhaltungssoftware, Ticketsysteme oder externe Cloud-Dienste geh\u00f6ren.<\/p>\n\n\n\n
Eine pauschal versch\u00e4rfte DMARC-Policy kann problematisch werden, wenn solche legitimen Versandquellen nicht korrekt in die Authentifizierungsstruktur eingebunden sind.<\/p>\n\n\n\n
Die standardm\u00e4\u00dfige Konfiguration mit:<\/p>\n\n\n\n
v=DMARC1; p=none;<\/code><\/p>\n\n\n\n
vermeidet deshalb eine pauschale Anweisung, DMARC-fehlgeschlagene Nachrichten allein aufgrund dieser Policy zu quarant\u00e4nisieren oder zur\u00fcckzuweisen.<\/p>\n\n\n\n
Wenn f\u00fcr eine Domain eine strengere DMARC-Strategie gew\u00fcnscht ist, sollte zuerst die gesamte Versandlandschaft analysiert werden.<\/p>\n\n\n\n
Wann muss die automatische Konfiguration angepasst werden?<\/h2>\n\n\n\n
Solange du ausschlie\u00dflich die normale CURIAWEB-Mailinfrastruktur verwendest, besteht normalerweise kein Grund, die automatisch eingerichteten Eintr\u00e4ge zu ver\u00e4ndern.<\/p>\n\n\n\n
Eine Pr\u00fcfung beziehungsweise Anpassung kann jedoch notwendig werden, sobald zus\u00e4tzliche Systeme E-Mails mit deiner Domain als Absender versenden.<\/p>\n\n\n\n
Esempi tipici sono:<\/p>\n\n\n\n