SPF, DKIM und DMARC für eine netcup-Domain eintragen

Dies ist Teil 33 unserer netcup-Serie. Davor: Teil 32: IPv6. Danach: Teil 34: DNS-API.

Viele Mails landen im Spam, weil die Domain nicht sauber ausweist, wer für sie senden darf. Die Einträge dafür gehören in die DNS-Zone Ihrer Domain. Diese Anleitung erklärt die Reihenfolge und zeigt, wo die Einträge bei netcup liegen. Die Werte selbst kommen von dem Dienst, der Ihre Mails verschickt.

Diese Anleitung ist mit der netcup-Dokumentation und der Oberfläche des CCP abgeglichen (Stand 30.10.2026). Die Befehle wurden nicht auf einem netcup-Server getestet.

Voraussetzungen

• Domain mit netcup-Nameservern. Bei eigenen Nameservern gehören die Einträge dorthin, siehe Teil 25
• Liste aller Dienste, die mit dieser Domain senden, also Postfach, Shop, Newsletter oder Server
• Die Angaben Ihres Mailanbieters für SPF und DKIM
• Grundlagen zu DNS aus Teil 7

Schritt 1: Absender auflisten

Schreiben Sie alle Systeme auf, die Mails mit Ihrer Domain als Absender schicken. Das ist wichtiger als jeder Eintrag: Fehlt ein Dienst im SPF, können seine Mails abgelehnt werden.

Verifizieren: Sie haben die vollständige Liste und die Angaben aller Anbieter.

Schritt 2: DNS-Ansicht öffnen

Im CCP gehen Sie auf Domains und klicken auf die Lupe neben der Domain. Bestand-Domains haben den Tab DNS, neue Domains den Tab CloudDNS. Der Tab zeigt, welche Art Sie haben.

Neue Einträge kommen in die leeren Zeilen.

Verifizieren: Sie sehen die vorhandenen Einträge. Prüfen Sie, ob schon ein TXT-Eintrag mit v=spf1 existiert.

Schritt 3: SPF eintragen

Pro Domain darf es nur einen SPF-Eintrag geben (RFC 7208). Gibt es schon einen, ergänzen Sie ihn. Beispiel für einen Mailserver der Domain und einen Anbieter:

Host: @
Type: TXT
Destination: v=spf1 mx include:spf.example.net ~all

include:spf.example.net ist ein Beispiel, den echten Wert nennt Ihr Anbieter. Mit ~all gelten andere Server als verdächtig, -all ist strenger. Nutzen Sie -all erst, wenn alle Absender erfasst sind. SPF erlaubt höchstens zehn Mechanismen mit DNS-Abfrage, darunter include, a und mx, auch verschachtelte include zählen mit. Darüber schlägt die Prüfung mit permerror fehl (RFC 7208, Abschnitt 4.6.4).

Bei Bestand-Domains speichern Sie mit DNS Records speichern, bei CloudDNS mit Änderungen anwenden.

Ein grüner Kasten bestätigt die Eingabe, ein roter zeigt einen Fehler. Laut netcup werden Änderungen im Regelfall in etwa 10 Minuten aktualisiert, weltweit kann es wegen TTL bis zu 48 Stunden dauern.

Verifizieren: Nach einigen Minuten zeigt dig TXT example.com +short genau einen Eintrag mit v=spf1.

Schritt 4: DKIM eintragen

DKIM aktivieren Sie beim Mailanbieter. Er erzeugt den Schlüssel und nennt Host, Typ und Wert. Je nach Anbieter ist das ein TXT- oder ein CNAME-Eintrag. Beim netcup-Webhosting läuft DKIM über CNAME-Einträge, das zeigt Teil 7. Für einen eigenen Mailserver zeigt die OpenDKIM-Anleitung das Erzeugen.

Ein CNAME ist nur möglich, wenn für diesen Host kein anderer Eintrag existiert.

DKIM-Schlüssel sind oft länger als 255 Zeichen, so lang darf eine einzelne Zeichenkette in einem TXT-Eintrag sein. Solche Werte werden im DNS auf mehrere Zeichenketten verteilt, die Empfänger setzen sie wieder zusammen. Ob das CCP lange Werte selbst teilt, nennt die Dokumentation nicht. Prüfen Sie deshalb nach dem Speichern mit dig, ob der Wert vollständig ankommt.

Verifizieren: dig TXT selector._domainkey.example.com +short oder die CNAME-Abfrage liefert den Wert. Senden Sie dann eine Testmail und prüfen Sie im Header, dass dkim=pass steht.

Schritt 5: DMARC eintragen

Tragen Sie DMARC erst ein, wenn SPF und DKIM funktionieren. Beginnen Sie nur mit Beobachten:

Host: _dmarc
Type: TXT
Destination: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Mit p=none bitten Sie Empfänger um keine besondere Behandlung, Sie erhalten aber Berichte. Liegt die Berichtsadresse unter einer anderen Domain, muss diese laut RFC 7489 (Abschnitt 7.1) den Empfang per DNS-Eintrag bestätigen. Lesen Sie sie einige Wochen und verschärfen Sie dann auf p=quarantine und p=reject. Das Vorgehen zeigt die Anleitung zu DMARC-Reports. Für Einträge ohne Handarbeit hilft unser SPF- und DMARC-Generator.

Verifizieren: dig TXT _dmarc.example.com +short zeigt den Eintrag.

Schritt 6: Ausrichtung verstehen

Das ist der häufigste Grund, warum Mails trotz korrektem SPF bei DMARC durchfallen. DMARC prüft nicht nur, ob SPF oder DKIM bestanden sind, sondern ob eines davon zu der Domain in der Absenderzeile From passt (RFC 7489, Abschnitt 3.1):

• SPF prüft die Domain des technischen Absenders, also die Adresse im Umschlag der Mail. Newsletter-Dienste nutzen dort oft ihre eigene Domain. SPF besteht dann, passt aber nicht zu Ihrer Domain.
• DKIM nennt die signierende Domain im Feld d=. Signiert der Dienst mit seiner eigenen Domain, passt auch das nicht.

Für DMARC reicht es, wenn einer der beiden Wege passt. Richten Sie bei jedem Dienst deshalb die DKIM-Signatur mit Ihrer eigenen Domain ein. Ein include im SPF allein genügt bei solchen Diensten nicht.

Verifizieren: Senden Sie von jedem Dienst eine Testmail an ein Postfach, dessen Quelltext Sie lesen können, und suchen Sie den Header Authentication-Results. Dort sollten spf=pass oder dkim=pass sowie dmarc=pass stehen. Der genaue Aufbau hängt vom Empfänger ab.

Troubleshooting

Häufige Fragen

Brauche ich das auch ohne Mailversand?

Für eine Domain ohne Mailversand schützt v=spf1 -all vor Missbrauch der Adresse. Das ist eine Empfehlung, keine Pflicht von netcup.

Gilt das auch für Mails vom Server?

Ja. Senden Sie über einen Anbieter wie in Teil 20, gelten dessen SPF-Angaben.

Fazit

Erst die Absender klären, dann SPF, DKIM und zuletzt DMARC mit p=none. Prüfen Sie bei jedem Dienst die Ausrichtung, denn ein bestandenes SPF reicht allein nicht. Verschärfen Sie erst, wenn die Berichte das erlauben.

Weiterführende Anleitungen und Quellen

• Teil 7: DNS-Records
• Teil 20: Mailversand
• netcup Helpcenter: DNS anpassen (Bestand-Domains)
• netcup Helpcenter: DNS anpassen (CloudDNS)
• RFC 7208: SPF
• RFC 6376: DKIM
• RFC 7489: DMARC