SPF, DKIM und DMARC: Diese drei Einträge vor großen Mailings prüfen

SPF-Validierung und systematische DNS-Diagnosen helfen, Authentifizierungsfehler, Zustellprobleme und Ausfälle von Webdiensten aufzuspüren.

•

Fehlkonfigurationen im Domain Name System (DNS) und fehlerhafte Authentifizierungseinträge zählen zu den häufigsten Ursachen für gestörte Mailzustellungen und Sicherheitsrisiken wie E-Mail-Spoofing. Technische Dokumentationen und Leitfäden beschreiben detailliert, wie Administratoren und Domaininhaber mit spezialisierten SPF-Checkern Authentifizierungseinträge validieren und Fehlern bei der Dienstverfügbarkeit auf den Grund gehen können.

Validierung von SPF-Einträgen und typische Konfigurationsfehler

Das Sender Policy Framework (SPF) erlaubt es Domaininhabern festzulegen, welche IP-Adressen oder Hosts autorisiert sind, E-Mails im Namen einer bestimmten Domain zu versenden. Auf diese Weise lassen sich Spam und E-Mail-Betrug wirksam eindämmen.

Der Ablauf der Prüfung folgt einem festen Muster: Der SPF-Record wird als TXT-Record in der DNS-Verwaltung hinterlegt. Trifft eine Nachricht ein, prüft der empfangende Server diesen Record und entscheidet über Annahme, Kennzeichnung oder Zurückweisung der Mail.

Ein typischer SPF-Eintrag wie v=spf1 ip4:192.0.2.0/24 -all autorisiert beispielsweise ausschließlich das angegebene /24-Netzwerk, während alle anderen Absender abgewiesen werden. Vor dem Eintrag müssen alle sendenden Server-IP-Adressen vollständig erfasst werden.

Zu den klassischen syntaktischen Fehlerquellen zählt unter anderem ein fehlendes Leerzeichen zwischen dem Typbezeichner und dem Hostnamen. Zudem ist zu beachten, dass der eigenständige Type-99-SPF-Record mittlerweile als veraltet gilt, nachdem die experimentelle Phase für eigene DNS-RR-Typen im Jahr 2014 endete.

Für die Überprüfung stehen unterschiedliche Werkzeuge bereit:
* Manuelle Abfragen: Administratoren können SPF-Records über Befehlszeilenwerkzeuge wie nslookup oder dig kontrollieren, wobei die relevanten Angaben im Answer-Abschnitt der Ausgabe erscheinen.
* Online-Validatoren: Dienste wie der DMARC Analyzer von Mimecast ermöglichen eine schnelle Prüfung per Domaineingabe, während Werkzeuge wie SPF Surveyor die autorisierten Server grafisch aufbereiten.
* Empfängerseitige Kontrolle: Nach dem Versand an Konten wie Gmail lässt sich in den Kopfzeilen direkt einsehen, ob die SPF-Prüfung erfolgreich durchlaufen wurde.

Regelmäßige Prüfungen stellen sicher, dass autorisierte Server korrekt hinterlegt sind und bestehende DNS-Lookup-Limits nicht überschritten werden, da solche Fehler die Zustellbarkeit unmittelbar beeinträchtigen.

Fehlermeldungen bei der Mailzustellung und Authentifizierung

Fehlkonfigurationen machen sich häufig erst durch Fehlermeldungen des Empfängers bemerkbar. Ein bekanntes Beispiel ist die Meldung Dovecot LMTP 5.7.1 authentication required for sender.

Dieser Fehler weist darauf hin, dass der empfangende Dovecot-LMTP-Server die Nachricht zurückweist, weil die Absenderidentität nicht erfolgreich verifiziert werden konnte – die Ursache liegt somit nicht in der lokalen Konfiguration des Empfängers, sondern beim Absender.

Anzeige

Wer sich mit der Absicherung der digitalen Kommunikation und dem Schutz vor Identitätsdiebstahl beschäftigt, sollte die Taktiken der Angreifer genau kennen. Dieser kostenlose Report enthüllt die aktuellen Methoden der Cyberkriminellen und wie man sie rechtzeitig entlarvt. 7 psychologische Schwachstellen jetzt entdecken

Typische Auslöser für diesen Status sind Absender-IPs, die im SPF-Eintrag fehlen, nicht im DNS veröffentlichte DKIM-Schlüssel oder eine fehlende Übereinstimmung in den DMARC-Richtlinien.

Je nach Konfiguration führt dies zur Quarantäne, zur direkten Abweisung (Bounce) und bei größeren Versandvolumina zu erheblichen Reputationsschäden. Administratoren sollten daher vor umfangreichen Mailings SPF, DKIM und DMARC gemeinsam validieren und Empfängerlisten bereinigen.

Systematische Diagnose bei nicht erreichbaren Web- und Nameservern

Probleme mit DNS-Einträgen betreffen nicht nur den E-Mail-Verkehr, sondern häufig die gesamte Service-Verfügbarkeit. Bei nicht erreichbaren Servern lassen sich die Ursachen in drei grundlegende Klassen unterteilen: Ausfälle auf Netzwerkebene (Ping scheitert), Fehler auf Anwendungsebene (Dienste wie Nginx, Apache oder Tomcat antworten trotz erfolgreichem Ping nicht) sowie fehlerhafte DNS-Auflösungen.

Anzeige

Die technische Absicherung von E-Mails ist nur ein Teil der Unternehmenssicherheit, denn auch gezielte Manipulationen fordern Verantwortliche zunehmend heraus. Experten erklären in diesem kostenlosen Leitfaden, wie Sie Phishing-Angriffe in vier Schritten stoppen, bevor sie entstehen. Kostenlosen Leitfaden für Hacker-Abwehr herunterladen

Für die Überprüfung der DNS-Auflösung stehen fünf etablierte Ansätze zur Verfügung: Kommandozeilenbefehle (dig, nslookup), Website-Diagnosedienste (wie Pingdom oder GTmetrix), Online-Domain-Abfragen (wie whois.com oder domaintools.com), spezialisierte DNS-Tools (wie IntoDNS oder DNSLookup) sowie die Analyse interner Server-Logs wie der access.log von Apache. Dabei muss berücksichtigt werden, dass die weltweite Propagation von DNS-Änderungen je nach Einstellung mehrere Stunden oder länger in Anspruch nehmen kann. Die aktuell genutzte DNS-Server-IP lässt sich unter Windows über ipconfig /all und auf macOS- oder Linux-Systemen mittels ifconfig verifizieren.

Eine strukturierte Ursachenforschung umfasst folgende Kernbereiche:
* Netzwerk und Ports: Überprüfung der A-Records und Firewall-Regeln (beispielsweise Port 80 und 443 in Cloud-Sicherheitsgruppen).

Mittels netstat oder ss -tlnp muss sichergestellt sein, dass Dienste an 0.0.0.0:80 lauschen und nicht fälschlicherweise auf 127.0.0.1:80 beschränkt sind.
* Dienststatus und Logs: Prüfung der Webserver via systemctl status nginx/httpd sowie Kontrolle von Fehlerprotokollen wie /var/log/nginx/error.log.

Fehler wie 502 Bad Gateway deuten oft auf nicht erreichbare Backends hin, während FastCGI connect() failed ein Problem mit PHP-FPM anzeigt.
* Rechte und Ressourcen: Verzeichnisse benötigen typischerweise Rechte wie 755 und Dateien 644; Fehlkonfigurationen mit 777 oder 600 können 403 Forbidden-Meldungen provozieren. Ergänzend sind Datenbankverbindungen, Systemressourcen (CPU, Arbeitsspeicher, Inodes) sowie SSL-Zertifikate auf Gültigkeit zu kontrollieren.