SPF, DKIM, and DMARC with CURIAWEB Hosting

SPF, DKIM, and DMARC are among the most important methods for email authentication. They help receiving mail servers assess whether a message was actually sent via authorized systems and whether the sender domain used matches the message.

With normal CURIAWEB hosting, the required DNS records for SPF, DKIM, and DMARC are generally set up automatically. If you send your emails exclusively via the regular CURIAWEB mail infrastructure and the DNS zone is managed by CURIAWEB, you normally do not need to create these records yourself.

Important: Do not change SPF, DKIM, or DMARC records on suspicion. A misconfiguration can cause legitimate emails to fail authentication, resulting in poorer deliverability or classification as spam.

What do SPF, DKIM, and DMARC do? #

The three methods fulfill different tasks and complement each other.

Procedure	Task
SPF	Defines which servers or IP addresses are allowed to send emails for a domain.
DKIM	Signs outgoing messages with a cryptographic signature that can be verified via a public key in the DNS.
DMARC	Link SPF and DKIM to the visible sender domain and publish a policy for DMARC checking.

Put simply, the interaction can be represented as follows:

Outbound email
       ↓
SPF
Is the transmission path authorized?
       +
DKIM
Is the cryptographic signature valid?
       ↓
DMARC
Does at least one successful
authentication match the visible sender domain?
       ↓
Apply DMARC policy

SPF with standard CURIAWEB hosting #

SPF stands for Sender Policy Framework. The SPF record is published as a TXT entry in a domain's DNS.

With standard CURIAWEB hosting, the SPF record is automatically created in the DNS zone.

For example, a typical standard CURIAWEB configuration looks like this:

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

The individual components have different functions:

Component	Meaning
v=spf1	Mark the TXT record as SPF version 1.
+a	Authorize the systems determined via the A-mechanism.
+mx	Authorize the systems resolved via the domain's MX records.
+ip4:144.76.63.89	Authorize this IPv4 address for sending.
~all	Other previously unrecorded shipping sources will receive an SPF softfail.

Important: The SPF record shown here is an example of the standard CURIAWEB hosting configuration. Do not copy it to another domain or hosting environment without first checking the actual transmission path.

What does mean ~all? #

The ~ before all referred to in SPF as a Softfail.

Thus, the domain declares that systems not covered by the preceding mechanisms are not intended as regular dispatch sources. However, the ultimate handling of such a message rests with the receiving system and its further checks.

This differs, for example, from:

-all

The minus sign designates an SPF Fail.

Therefore, you should not simply change an existing SPF record from ~all on -all modify. A stricter policy only makes sense if the entire shipping environment is known and correctly taken into account.

DKIM with CURIAWEB Hosting #

DKIM stands for DomainKeys Identified Mail.

While SPF authorizes the sending path, DKIM works with a cryptographic signature.

Simply put, DKIM consists of two parts:

Private DKIM key
→ is located on the sending system
→ signs the outgoing email

Public DKIM key
→ is published in the DNS
→ enables the recipient to verify it

The private key must not be publicly accessible. Only the public part is located in the DNS.

What does a DKIM record look like? #

DKIM uses a so-called Selector. This allows a domain to use different DKIM keys and rotate keys later.

A DKIM DNS name generally follows this pattern:

selector._domainkey.example.ch

The corresponding TXT record contains, among other things, the public key.

Schematically, a DKIM record looks like this, for example:

v=DKIM1; k=rsa; p=PUBLIC_KEY

The actual public key is significantly longer and is automatically generated for the domain in question.

Attention: Never use a DKIM key from another domain and do not copy DKIM records between domains. The respective key pair belongs to the specific DKIM configuration of the domain.

You usually don't have to create DKIM yourself #

In a standard CURIAWEB hosting configuration, DKIM is set up automatically.

If your domain uses the CURIAWEB DNS zone and emails are sent via the designated mail infrastructure, you should therefore not create an additional DKIM record of your own.

Multiple DKIM selectors are technically quite possible. However, they should only be present if the respective sending systems actually sign with these selector keys.

What does DKIM check? #

During sending, the message is signed with the private DKIM key. The receiving mail server reads, among other things, the domain and selector used from the DKIM signature.

Using this selector, he can retrieve the corresponding public key in the DNS and verify the signature.

For example, a successful DKIM result can be:

dkim=pass

appear in the authentication results of a received message.

What does a DKIM error mean? #

A DKIM error can have various causes. For example, the public key may be missing, an incorrect selector may be used, or the message or relevant signed components may have been modified after signing in such a way that the signature can no longer be successfully validated.

A DKIM error should therefore be investigated based on the specific message and its routing.

DMARC at CURIAWEB Hosting #

DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

DMARC builds upon SPF and DKIM, but adds a crucial point: the relationship to the domain that the recipient sees as the sender in the visible From:-field of the email sees.

With normal CURIAWEB hosting, a DMARC record is also created automatically.

The default CURIAWEB configuration is:

v=DMARC1; p=none;

What does mean v=DMARC1; p=none;? #

In this basic configuration, the record consists of two essential pieces of information.

Component	Meaning
v=DMARC1	Marks the entry as DMARC version 1.
p=none	Do not publish a DMARC policy to quarantine or reject failed messages based solely on the DMARC policy.

p=none does not mean that SPF or DKIM are disabled. Likewise, it does not mean that a receiving spam filter has to accept a suspicious message.

Other security and spam checks of the receiving system remain unaffected by this.

Where is the DMARC record located? #

DMARC is published as a TXT record under the special hostname _dmarc published.

For a domain like:

example.ch

will the DMARC record accordingly under:

_dmarc.example.ch

retrieved.

What are p=none, p=quarantine and p=reject? #

DMARC knows various domain policies.

Policy	Fundamental importance
p=none	No DMARC-based quarantine or reject policy.
p=quarantine	Messages that fail DMARC should be treated accordingly as suspicious by the receiving system, typically through quarantine or spam processing.
p=reject	Messages that fail DMARC should be rejected.

Important: Do not simply switch a domain from p=none on p=quarantine or 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.

What does DMARC alignment mean? #

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 referred to as.

Simplified:

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 and 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.

Briefly explained: 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.

Typical examples are:

• Newsletter- und Marketingplattformen
• CRM systems
• 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.

Attention: 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 Properly setting up and checking SPF for SpamExperts.

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

Important: 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.

We explain more about this under SpamExperts Filter Settings: Why the Default Configuration is Usually the Best Choice.

SPF, DKIM und DMARC in cPanel prüfen #

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

To do this, open:

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 Zone editor use.

You can find a detailed guide on this at Using the DNS Zone Editor in cPanel.

SPF im DNS erkennen #

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

v=spf1

begins.

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

displayed.

Die genaue Darstellung unterscheidet sich je nach empfangendem Mailserver.

Practical Tip: 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.

Common mistakes with SPF, DKIM, and DMARC #

Error	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?

Summary #

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.