SPF, DKIM und DMARC - Spam-Reputation verbessern und Bounces vermeiden

Was wird in diesem Artikel beschrieben?

Neben allgemeinen Informationen zu den Protokollen, Parametern und DMARC-Berichten finden Sie hier folgende Anleitungen mit Beispielkonfigurationen:

• Setzen des SPF-Eintrags und der Parameter als TXT-Record in den DNS-Einstellungen Ihres Providers
• Setzen der DKIM-Einträge als CNAME-Records in den DNS-Einstellungen Ihres Providers
• Setzen des DMARC-Eintrags und der Parameter als TXT-Record in den DNS-Einstellungen Ihres Providers

Voraussetzung

Stellen Sie vorerst sicher, dass die Mails Ihrer Domain (beispielsweise mein.name@example.com) über mailbox versendet und empfangen werden können. Folgen Sie dazu der Anleitung: E-Mail-Adresse der eigenen Domain nutzen.

Dieser Artikel soll Ihnen dabei helfen, die Zuverlässigkeit der Zustellung von Mails in Verbindung mit eigener Domain zu erhöhen, fehlerhafte Zustellungen und Bounces zu vermeiden (z. B. Undelivered Mail Returned to Sender) und sicherzustellen, dass Ihre Mails den Spam-Filter von Google und anderen Mail-Providern erfolgreich passieren können. Des Weiteren hilft die korrekte Implementierung von SPF und DKIM dabei, die Spam-Reputation Ihrer Domain dauerhaft zu verbessern. Privatkunden, die Mail-Adressen mit @mailbox.org ohne eigene Domain verwenden, müssen sich hier keine Gedanken machen – wir haben alle Einstellungen bereits für Sie gesetzt.

Diese Anleitung beschreibt drei wichtige Protokolle und deren Einstellungen im Domain Name System (DNS): SPF, DKIM und das darauf aufbauende Protokoll DMARC. Da die meisten Mail-Anbieter diese Standards nutzen, um Spam zu erkennen, senken Sie mit einer entsprechenden Konfiguration das Risiko, dass Server die von Ihnen versandten Mails als Spam klassifizieren und aussortieren. Grundsätzlich sind dafür drei Einträge nötig, die in den DNS-Einstellungen Ihres Hosting-Providers hinterlegt werden müssen.

Mit den Einstellungen aus dieser Anleitung erreichen Sie Ihre Adressaten zuverlässiger und ganz nebenbei erfüllt Ihre Domain – und somit auch jede Ihrer Mails – die entsprechenden Internetstandards, was nicht zuletzt der allgemeinen Sicherheit dient. mailbox empfiehlt grundsätzlich, diese Einstellungen zu setzen, wenn Sie eigene Domains für Mail nutzen. Besonders Geschäftskunden und Unternehmen, die regelmäßig große Mengen an Mails versenden, sollten diesem Rat folgen: Es gibt deutliche Hinweise darauf, dass Provider zunehmend strenger aussortieren.

Es lohnt sich deshalb, die Begriffe SPF, DKIM und DMARC näher zu betrachten. Diese drei Protokolle sind Kernelemente der Mail-Authentifizierung und spielen eine entscheidende Rolle bei der Erkennung und Prävention von Spam und Phishing-Versuchen. Infolgedessen sind sie auch stark mit der Spam-Reputation Ihrer Domain verknüpft und haben einen direkten Einfluss darauf, wie wahrscheinlich es ist, dass Ihre Mails als Spam eingestuft oder abgelehnt werden.

Eine Reihe von Mail-Dienstanbietern, darunter auch Google, verwenden diese Protokolle, um die Authentizität von Mails zu überprüfen. Wenn eine Mail, die von Ihrer Domain gesendet wird, die SPF- oder DKIM-Prüfungen nicht besteht, kann Google die Mail ablehnen und einen Bounce generieren. Ein Bounce ist im Grunde eine automatische Antwort, die signalisiert, dass die Mail nicht zugestellt werden konnte. In diesem Fall wäre die wahrscheinlichste Ursache für den Bounce, dass die Mail als potenzieller Spam oder Phishing-Versuch eingestuft wurde.

Bounce – Beispiel einer abgelehnten Mail

Von: MAILER-DAEMON@xxxxxx.mailbox.org An: mustermann@example.comD atum: 22.07.2023 22:29 CEST Betreff: Undelivered Mail Returned to Sender This is the mail system at host xxxxxx.mailbox.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message.The mail system "xxxxx@gmail.com": host gmail-smtp-in.l.google.com \[108.xxx.xx.xx\] said: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the 550-5.7.26 sender and Gmail users, and has been blocked. The sender must 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message, 550-5.7.26 DKIM checks did not pass and SPF check for \[example.com\] did not 550-5.7.26 pass with ip: \[80.xxx.xx.xxx\].`

Die Protokolle und Parameter im Überblick

SPF (Sender Policy Framework)

SPF ist ein Verfahren, das dazu dient, festzulegen, welche Mailserver berechtigt sind, Mails im Namen Ihrer Domain zu versenden. Durch die Verwendung von SPF können Sie verhindern, dass Spammer Ihre Domain für unerwünschte und irreführende Mails missbrauchen. In der Praxis prüft der Empfänger-Mailserver die SPF-Einträge in den DNS-Einstellungen Ihrer Domain und vergleicht diese mit der IP-Adresse des sendenden Mailservers. Wenn der sendende Mailserver in den SPF-Einträgen aufgeführt ist, wird die Mail als legitim eingestuft.

DKIM (DomainKeys Identified Mail)

DKIM ist ein weiteres Verfahren zur Mail-Authentifizierung, das dazu dient, die Integrität und Authentizität einer Mail zu überprüfen. Mit DKIM signiert der sendende Mailserver jede ausgehende Mail mit einem digitalen Schlüssel. Dieser Schlüssel ist im DNS-Eintrag Ihrer Domain hinterlegt. Der Empfänger-Mailserver kann diese Signatur überprüfen, indem er den DKIM-Schlüssel in den DNS-Einstellungen Ihrer Domain abruft. Ist die Signatur gültig, kann der Empfänger sicher sein, dass die Mail tatsächlich von Ihrer Domain stammt und während der Übertragung nicht manipuliert wurde.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ist ein Mail-Validierungsprotokoll, das auf den Technologien SPF und DKIM aufbaut und dazu dient, den Missbrauch von Domains in der Mail-Kommunikation zu verhindern. Durch DMARC kann der Besitzer einer Domain bestimmen, wie der Empfänger-Server mit Mails umgehen soll, die die SPF- und DKIM-Checks nicht bestehen. Dabei kann entschieden werden, ob die fraglichen Mails abgewiesen, in den Spam-Ordner verschoben oder normal zugestellt werden sollen. Zusätzlich ermöglicht DMARC den Austausch von Berichten zwischen dem sendenden und dem empfangenden Server, um das Verständnis möglicher Sicherheitsprobleme zu verbessern. Kurz gesagt: Es ist ein hilfreiches Werkzeug zur Verbesserung der Mail-Sicherheit und zur Erhöhung der Zustellbarkeit legitimer Mails.

Beispiele für DNS-Einträge

Die folgende Tabelle enthält Beispiele für die DNS-Einträge, die Sie bei Ihrem Provider benötigen, um SPF, DKIM und DMARC zu konfigurieren. Ersetzen Sie dabei example.com durch Ihre eigene Domain und postmaster@example.com durch Ihre Mail-Adresse.

Hostname	Record Type	Ziel	Protokoll
@	TXT	v=spf1 include:mailbox.org ~all	SPF
MBO0001._domainkey.example.com	CNAME	MBO0001._domainkey.mailbox.org.	DKIM
MBO0002._domainkey.example.com	CNAME	MBO0002._domainkey.mailbox.org.	DKIM
MBO0003._domainkey.example.com	CNAME	MBO0003._domainkey.mailbox.org.	DKIM
MBO0004._domainkey.example.com	CNAME	MBO0004._domainkey.mailbox.org.	DKIM
_dmarc.example.com	TXT	v=DMARC1;p=none;rua=mailto:postmaster@example.com	DMARC

Die Protokolle und Parameter im Detail

Sender Policy Framework (SPF)

Das SPF (Wikipedia) nutzen Administratoren, um im Internet bekanntzugeben, welche Server ausgehende Mails Ihrer Domain versenden dürfen.

Die für Mails zuständigen MX-Einträge im Domain Name System definieren nur, welche Mailserver für den Empfang von Mails einer Domain zuständig sind. Eine Liste von Mailservern, die berechtigt sind, im Namen einer Domain Mails zu versenden, gab es hingegen nicht. Spam in dem Ausmaß, wie wir ihn heute kennen, ist unter anderem nur möglich, weil Absender von beliebigen Rechnern (z. B. kompromittierte Systeme) Mails in fremden Namen verschicken können und es lange keine Methode gab, dies zu verhindern.

Abhilfe sollten Konzepte wie SPF schaffen, das im Internet-Standard unter RFC 4408 spezifiziert wurde. Es ermöglicht Administratoren einer Domain, bestimmte Mailserver zuzuordnen und diese so als legitime Absender für Mails dieser Domain zu definieren.

Ein typischer SPF-Eintrag in einem Standard-Setup ist im DNS als TXT-Eintrag hinterlegt und kann folgenden Inhalt haben:

v=spf1 include:mailbox.org ~all

Bedeutung dieses Eintrags

• v=spf1 – bezeichnet die verwendete SPF-Version
• include:mailbox.org – übernimmt automatisch alle SPF-Einstellungen von mailbox für diese Domain
  Das bedeutet: Alle Mailserver von mailbox (sowohl die Domain mailbox.org als auch die verwendeten IP-Adressen) sind legitimiert, Mails mit Absendern Ihrer Domain zu verschicken

Natürlich können Sie neben mailbox auch weiterhin andere Mailserver für den Versand von Mails für Ihre Domain nutzen. Sie sollten diese aber ebenfalls durch Einträge im DNS legitimieren.

Wichtig: Mehrere SPF-Einträge sind nicht erlaubt! Stellen Sie sicher, dass in den DNS-Einstellungen Ihres Providers nur ein SPF-Record existiert. Widersprüchliche Angaben können zu Problemen führen.

Erlaubte Parameter im TXT-Record zu SPF

Einstellung	Erklärung
v=spf1	Es handelt sich um SPF in der Version 1.
ip4:213.203.238.0/24	Jeder Server aus dem IPv4-Bereich 213.203.238.0/24 darf für diese Domain Mails versenden.
ip6:fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64	Jeder Server aus dem IPv6-Bereich fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64 darf für diese Domain Mails versenden.
mx	Erlaubt es allen in den MX-Records dieser Domain eingetragenen Mailservern, Mails zu versenden.
include:example.com	Erlaubt zusätzlich alle Server, die in den SPF-Einstellungen von example.com hinterlegt sind. Der Server muss hier also eine weitere Abfrage nach dem TXT-Record von example.com machen.
?all	Alle nicht genannten Mailserver dürfen ebenfalls unter diesem Namen Mails verschicken, ohne eine negative oder positive Bewertung zu erhalten.
-all	Mailserver, die nicht in diesem Eintrag aufgeführt sind, dürfen keine Mails für diese Domain versenden.
~all	Annehmende Server sollen diese Nachricht nicht sofort ablehnen, aber weitere Tests durchführen, um zu prüfen, ob die Nachricht Spam ist.

Liste aller SPF-Einträge

Eine vollständige Liste aller zugelassenen Einträge im SPF-Record finden Sie bei OpenSPF.

SPF - Beispielkonfiguration bei Hetzner, Netcup und INWX

Die DNS-Eingabemasken bei Providern sind nicht einheitlich. Die folgenden Abbildungen zeigen exemplarisch und anhand von Beispielen der Provider Hetzner, Netcup und INWX, wie die SPF-TXT-Einträge dort aussehen sollten.

Abbildung 1: Hetzner setzt die Anführungszeichen in Ziel automatisch und verwendet anstelle des Namens der Domain nur ein @.

Abbildung 2: Auch Netcup nimmt das @ als Platzhalter für die Domain, verlangt keine Anführungszeichen.

Abbildung 3: Auch INWX nimmt das @ als Platzhalter für die Domain, verlangt keine Anführungszeichen.

DomainKeys Identified Mail (DKIM)

DKIM (Wikipedia) ist ein technisches Protokoll, mit dessen Hilfe sich die Authentizität von Absendern sicherstellen lässt. Dieses Protokoll geht noch einen Schritt weiter als SPF, indem es die Angaben in Mails mit einer digitalen Signatur absichert, für die zuvor ein spezieller Schlüssel im DNS hinterlegt wurde.

Nur mit diesem Schlüssel kann ein fremder Mailserver verifizieren, ob die empfangene Nachricht mit einer solchen Signatur im Header wirklich von der genannten Domain versandt wurde. Der dafür benutzte Mail-Header lautet DomainKey-Signature-Header.

Damit das funktioniert, muss der Mailserver-Administrator (also wir von mailbox) eine Signatur erzeugen, diese mit einem kryptographischen Verfahren signieren und für die Mail-Kommunikation verfügbar machen (also im Domain Name System eintragen). Wenn dieser Prozess scheitert, dann kann der Mailserver des Absenders nicht eindeutig verifiziert werden und die betreffende Mail wird eher als Spam klassifiziert und somit aussortiert.

Wenn Sie DKIM mit der folgenden Anleitung aktivieren, dann verringern Sie die Wahrscheinlichkeit, dass empfangende Server Ihre Mails fälschlicherweise als Spam markieren.

DKIM Parameter & Einstellungen

Zu erfolgreichen DKIM-Einträgen gibt es verschiedene Wege. mailbox empfiehlt den Eintrag als CNAME-Record. Wir stellen aktuell vier Schlüssel für DKIM bereit, die Sie als DNS-Einträge bei Ihrem Domain-Registrar hinterlegen müssen. Hinterlegen Sie alle vier Keys in vier separaten CNAME-Einträgen:

Abbildung 4

Individueller Key (ersetzen Sie dabei example.com durch Ihre Domain)	Record Type	Ziel
MBO0001._domainkey.example.com	CNAME	MBO0001._domainkey.mailbox.org.
MBO0002._domainkey.example.com	CNAME	MBO0002._domainkey.mailbox.org.
MBO0003._domainkey.example.com	CNAME	MBO0003._domainkey.mailbox.org.
MBO0004._domainkey.example.com	CNAME	MBO0004._domainkey.mailbox.org.

Abbildung 4 (Tabelle) zeigt einen typischen Eintrag beim Provider Hetzner. Im Auswahlmenü Recordtyp wählen Sie CNAME, unter Hostname tragen Sie den gewählten Key als Subdomain Ihrer Domain ein (hier MBO0001._domainkey.example.com) sowie im Feld Ziel (bei Hetzner) gefolgt von einem Punkt.

Die Schreibweise im letzten Feld kann – genauso wie die Benennung der Felder der DNS-Eingabemaske – von Provider zu Provider variieren: Manche Provider (beispielsweise Hetzner) verlangen den abschließenden Punkt, andere ergänzen ihn. Sie sollten hier unbedingt die Dokumentation Ihres Providers konsultieren.

DKIM - Beispielkonfigurationen bei Hetzner, Netcup und INWX

Hetzner

Abbildung 5: Der CNAME-DNS-Eintrag bei Hetzner für den Key MBO0001 mit Punkt am Ende.

Abbildung 6: Der CNAME-DNS-Eintrag bei Netcup verlangt im Feld Destination keinen abschließenden Punkt.

Und auch der Provider INWX verzichtet im CNAME-DNS-Eintrag darauf.

Alte Methode

2021 änderten wir bei mailbox unsere Empfehlung für den DKIM-Eintrag. Bisher rieten wir dazu, DKIM-Einträge als TXT-Records anzulegen. Diese Methode wird auch weiterhin funktionieren, sie hat allerdings einen gravierenden Nachteil: Falls wir etwas an unseren Schlüsseln ändern müssen, werden alle TXT-Einträge, die auf die alten Keys verweisen, ungültig. Kunden und Admins mit TXT-Einträgen für DKIM müssten selbst aktiv werden, um zu verhindern, dass ihre Mails höhere Spam-Bewertungen bekommen.

Kunden, die unsere DKIM-Schlüssel per CNAME-Eintrag festlegen, brauchen auch dann nicht aktiv werden.

Gleichwohl können Sie das jederzeit umstellen – wichtig ist dabei nur die Reihenfolge der Umstellung: Löschen Sie erst den TXT-Eintrag aus dem DNS und fügen Sie dann den CNAME-Eintrag hinzu. Wenn Sie beides kurz nacheinander erledigen, sollte DKIM für Ihre Domain auch während der sich anschließenden, automatischen Synchronisation des Domain Name Systems verfügbar sein.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

DMARC-Einträge (Wikipedia) legen fest, ob und wie Mailserver beim Empfang von Mails DKIM-Signaturen und SPF-Einträge verifizieren. Wenn Sie Mails über mailbox versenden, können Sie mit Hilfe des DMARC-Eintrags eine Art „Empfehlung“ aussprechen, wie mit Mails umgegangen werden soll, die Ihren Absender tragen, aber beispielsweise nicht DKIM-signiert sind.

Für DMARC-Einstellungen ist neben einem DKIM-Eintrag im DNS auch ein existierender SPF-Eintrag eine Voraussetzung. Die Abbildungen 7 bis 9 zeigen exemplarisch die DNS-Eingabemasken verschiedener Provider – auch hier sollten Sie die Dokumentation Ihres Providers konsultieren, um Fehler zu vermeiden.

Schritt-für-Schritt-Anleitung

1. Legen Sie im DNS einen (weiteren) TXT-Eintrag an.
2. Fügen Sie unter Host, Name oder Hostname den Parameter _dmarc. gefolgt von Ihrer Mail-Domain ein, also beispielsweise:

_dmarc.example.com

Beachten Sie dabei die unterschiedlichen Schreibweisen der Provider.

3. Fügen Sie unter Wert, Ziel oder Destination diesen Parameter ein:

v=DMARC1;p=none;rua=mailto:postmaster@example.com

Die Mail-Adresse, die Sie hier spezifizieren, erhält ab sofort die Fehlermeldungen der DMARC-Prüfungen – Sie sollten also eine eigene Adresse spezifizieren.

4. Als TTL (Time-To-Live) empfehlen wir 400.

DMARC - Beispielkonfigurationen bei Hetzner, Netcup und INWX

Beim Provider Hetzner beispielsweise sieht ein korrekter DNS-Eintrag für DMARC folgendermaßen aus:

Abbildung 7: Hetzner - Anlegen des DMARC-TXT-Eintrag im DNS.

Abbildung 8: Netcup - Anlegen des DMARC-TXT-Eintrag im DNS.

Abbildung 9: Anlegen des DMARC-TXT-Eintrag bei INWX.

DMARC – Optionen und Parameter

Parameter	Beschreibung
v=DMARC1	DMARC in Protokollversion 1 wird verwendet.
ruf=mailto:E-Mail-Adresse	Der Inhaber der genannten Mail-Adresse erhält Fehlerberichte (forensischer Report). In Deutschland ist die Nutzung dieser Option nicht zulässig, da Sie Mails erhalten könnten, die nicht für Sie bestimmt waren. Wir raten von der Nutzung dieses Parameters ab.
rua=mailto:E-Mail-Adresse	Der Inhaber der genannten Mail-Adresse (diese Mail-Adresse muss zur Domain gehören, über die der Versand läuft) erhält die bisweilen umfangreichen Detailberichte über alle DMARC-Aktivitäten. Da dies zu einer großen Menge an eingehenden Berichten führen kann, sollten Sie hierfür eine separate Mail-Adresse verwenden. Die Berichte enthalten Datum, Uhrzeit, Empfänger- und Absenderdomain, IP-Adressen, SPF- und DKIM-Informationen, die angewendete DKIM-Policy sowie die mit SPF und DKIM verknüpfte Domain.
p=none	Dieser Parameter ist immer erforderlich. Hier legen Sie fest, wie der empfangende Server verfahren soll, wenn Mails nicht korrekt authentifiziert werden konnten. Gültige Optionen sind: p=none: Es wird nichts unternommen und die Nachricht wird dem Zielpostfach zugestellt, so wie es vom Absender vorgesehen wurde. Die Mails werden im täglichen Bericht geloggt, der an die im rua-Parameter hinterlegte Adresse geschickt wird. p=quarantine: Eingehende Nachrichten ohne korrekte Authentifizierung werden als Spam markiert und in den Spamordner des Empfängers gelegt. p=reject: Nicht korrekt authentifizierte Mails werden abgelehnt. Der empfangende Server schickt eine Unzustellbarkeitsnachricht (Bounce) an den Absender.

DMARC – Beobachten, auswerten & anpassen

Bitte beachten Sie, dass Sie die Einstellungen beim p-Parameter zu Beginn nicht auf die restriktiven Werte quarantine oder reject setzen sollten. Wir empfehlen zunächst die Option p=none zu verwenden, die Lage zu beobachten, die Reports auszuwerten und als Anhaltspunkte für benötigte Einstellungen zu nutzen.

Typische Probleme, die aus zu restriktiven Einstellungen resultieren, sind beispielsweise vom Empfangsserver abgelehnte Mails (Bounces) oder nicht mehr validierbare elektronische Signaturen bei Mail-Weiterleitungen. Gelegentlich nutzen andere Abteilungen Ihrer Firma den Mailserver für Anwendungen, von denen der Mail-Admin nichts weiß, die aber gleichzeitig für die Firma von hoher Bedeutung sein könnten (z. B. Monitoring, Marketing-Newsletter, etc.).

Aus den Reports können Sie nützliche Informationen gewinnen und entsprechende Maßnahmen ergreifen. Ist alles geklärt, sollten Sie hier eine strengere Regel eintragen.

Achten Sie bei der Auswertung der DMARC-Reports auf folgende Faktoren:

• Welche Server oder externen Anbieter versenden Mails im Namen Ihrer Domain?
• Welcher Anteil der Mails aus Ihrer Domain erfüllt die DMARC-Anforderungen?
• Welche Server oder Services versenden Mails, die nicht den DMARC-Richtlinien entsprechen?

DMARC-Berichte auswerten & verstehen

DMARC-Aggregatberichte

DMARC-Aggregatberichte geben Einblick in die DMARC-Aktivitäten einer bestimmten Domain über einen festgelegten Zeitraum. Diese zusammengefassten Berichte liefern Informationen wie die Anzahl der Nachrichten, die die DMARC-Authentifizierung erfolgreich oder nicht erfolgreich durchlaufen haben, die IP-Adressen der sendenden Server und die angewendeten Authentifizierungsverfahren.

DMARC-Forensikberichte

DMARC-Forensikberichte bieten tiefe Einblicke in spezifische Mail-Nachrichten, die die DMARC-Prüfung nicht bestanden haben. Diese forensischen Auswertungen beinhalten sowohl die komplette Mail-Nachricht als auch Daten zum Authentifizierungsstatus und den Ursachen des Fehlschlags. Mithilfe dieser Berichte lassen sich bestimmte Fälle von Mail-Täuschung oder Missbrauch nachvollziehen.

Es gibt unterschiedliche Formate, in denen DMARC-Berichte erstellt werden können, darunter XML, CSV und JSON. Das gewählte Format hängt von den Vorlieben des Domain-Inhabers oder seines DMARC-Serviceanbieters ab. Manche Mail-Empfänger bieten dem Domain-Inhaber zudem DMARC-Fehlerberichte an, die Informationen über Nachrichten bereitstellen, die an der DMARC-Prüfung gescheitert und daher abgelehnt oder in Quarantäne versetzt wurden.

Mehr Details zu DMARC-Auswertung

Für mehr Details zur Auswertung von DMARC-Berichten bietet diese Seite (verfügbar auf Deutsch & Englisch) nützliche Informationen: Was sind DMARC-Berichte und kann man sie lesen?

Troubleshooting

SPF-Troubleshooting

Linux & macOS

Linux- und macOS-Benutzer können im Terminal den Befehl dig nutzen, gefolgt von ihrer Domain und den gewünschten, abzufragenden Einträgen:

DNS-TXT-Abfrage im Linux Terminal

dig example.com txt

; DiG 9.11.3-1ubuntu1.13-Ubuntu example.com txt
;; global options: +cmd
;; Got answer:
;; HEADER- opcode: QUERY, status: NOERROR, id: 64449
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.            IN    TXT

;; ANSWER SECTION:
example.com.        1800    IN    TXT    "v=spf1 include:mailbox.org ~all"

;; Query time: 120 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 28 12:33:50 CEST 2020
;; MSG SIZE  rcvd: 174

Kontrollieren Sie bitte, ob die Zeile nach der ANSWER SECTION einen Eintrag beinhaltet, der mit v=spf1 beginnt und include:mailbox.org enthält.

Windows

Windows-Benutzer können in der Kommandozeile (cmd.exe) den folgenden Befehl absetzen, bitte ersetzen Sie auch hier example.com mit dem Namen Ihrer Domain:

DNS-TXT-Abfrage an der Windows-Befehlszeile

nslookup -type=txt example.com
Server: UnKnown
Address: 192.168.179.1

Nicht autorisierende Antwort:
example.com text

"_globalsign-domain-verificationZKyu_ATrp-l27Q11kIjqiPNjI6Tt_g7vnp3qYsViBk"
"v=spf1 include:mailbox.org ~all"

Kontrollieren Sie bitte, ob die Antwort eine Zeile beinhaltet, die mit v=spf1 beginnt und include:mailbox.org enthält.

DKIM-Troubleshooting

Linux & macOS Betriebssystem

Linux- und macOS-Benutzer können im Terminal diesen Befehl absetzen – wichtig ist hier, dass in der ANSWER SECTION diese Zeichenfolge angezeigt wird:
"v=DKIM1; krsa;" "p...." gefolgt vom korrekten Key.

dig MBO0001._domainkey.example.com TXT

;; ANSWER SECTION:
MBO0001._domainkey.example.com. 3403 IN TXT "v=DKIM1; krsa;" "pMIIBIkANBgkqh..."

Windows Betriebssystem

Windows-Benutzer können an der Kommandozeile (cmd.exe) den folgenden Befehl absetzen:

nslookup -type=txt MBO0001._domainkey.example.com`

Server: UnKnown
Address: 192.168.179.1

Nicht autorisierende Antwort:
MBO0001._domainkey.example.com text

"v=DKIM1; krsa;"
"pMIIBIkANBgkqhyiG9w0DETJUIICAQ8AMIIBCgKCAQEA..."

Prüfen Sie bitte, dass in der Antwort die Zeichenfolge "v=DKIM1; krsa;" "p...." enthalten ist, gefolgt von einer mehrzeiligen Darstellung des DKIM-Schlüssels.

DMARC-Troubleshooting (Linux & macOS)

Dieser Abschnitt beschreibt, wie Sie DMARC-Einträge korrekt prüfen und wie Sie einen häufig auftretenden Fehler vermeiden, bei dem Mails abgelehnt werden, obwohl eine gültige DMARC-Policy gesetzt ist.

Hintergrund: DMARC-Validierung und optionale Parameter

DMARC-Records bestehen laut RFC ausschließlich aus zwei verpflichtenden Parametern:

• v (Version)
• p (Policy/Handlung)

In der Praxis zeigt sich jedoch, dass einige empfangende Mailserver Nachrichten ablehnen, wenn der optionale Parameter rua fehlt – obwohl dies nicht dem RFC-Standard entspricht. Dieses Verhalten ist fehlerhaft, kommt aber regelmäßig vor.

Um unnötige Ablehnungen zu vermeiden, wird empfohlen, immer einen gültigen rua-Parameter bereitzustellen**, selbst wenn der DMARC-Record ohne ihn gültig wäre.

DMARC-Einträge unter Linux & macOS prüfen

Auf Linux- und macOS-Systemen können Sie DMARC-Einträge direkt im Terminal prüfen. Entscheidend ist, dass in der ANSWER SECTION ein Eintrag der Form

v=DMARC1; p=...

ausgegeben wird. Was danach folgt, hängt von der individuellen Konfiguration ab.

Beispielbefehl

Hinweis: Einige empfangende Mailserver lehnen Mails ab, wenn der optionale rua-Parameter fehlt. Obwohl dies laut RFC nicht erforderlich ist, empfiehlt es sich, rua immer anzugeben.

dig _dmarc.example.com TXT

;; ANSWER SECTION:
_dmarc.example.com. 1800 IN TXT "v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ..."

Hinweis: Einige empfangende Mailserver lehnen Mails ab, wenn der optionale rua-Parameter fehlt. Auch wenn dies laut RFC nicht zwingend erforderlich ist, empfiehlt es sich, rua anzugeben, um unnötige Ablehnungen zu vermeiden.

Erwartete Ausgabe

;; ANSWER SECTION:
_dmarc.example.com. 1800 IN TXT "v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ..."

Achten Sie darauf, dass der Parameter rua gesetzt ist, da dies bei bestimmten empfangenden Systemen notwendig ist, um DMARC-Validierungsfehler und unnötige Ablehnungen zu verhindern.

Windows-Benutzer

Windows-Benutzer können an der Kommandozeile (cmd.exe) diesen Befehl absetzen:

nslookup -type=txt _dmarc.example.com

Server: UnKnown
Address: 192.168.179.1

Nicht autorisierende Antwort:
_dmarc.example.com text
v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ...

Weiterführende Links und Tools

• Weitere Informationen zu diesem Thema finden Sie in diesem Vortrag unseres CEO Peer Heinlein: SPF / DKIM-Vortrag und in einem Video von der Minidebconf 2021 in Regensburg.
• Prüfen Sie SPF, DKIM und DMARC mit diesem Tool: MECSA-Tool der Europäischen Kommission. Hierzu müssen Sie eine Testnachricht senden, sodass auch die vom Mail-Anbieter verwendeten Postausgangsserver sicher bestimmt werden können.
• Bis 2021 empfahl mailbox, DKIM-Informationen in TXT-Einträgen zu hinterlegen – hier finden Sie die (inzwischen veraltete) Anleitung: DKIM-Einträge über TXT-Felder im DNS setzen.
• Sie können Ihr Setup mit Google- oder Yahoo-Test-Accounts prüfen: AppMailDev DKIM-Test.
• Zusätzliche Informationen zu den Anforderungen für die Mail-Authentifizierung beim Versand an Gmail-Konten finden Sie in der Google-Dokumentation.