SPF-Datensatz-Analyzer

SPF (Sender Policy Framework, RFC 7208) ist ein DNS-basiertes E-Mail-Authentifizierungssystem. Sie veröffentlichen einen TXT-Eintrag an Ihrer Domain, der auflistet, welche IP-Adressen oder Hostnamen autorisiert sind, E-Mails für Ihre Domain zu senden. Wenn ein empfangender Mail-Server eine E-Mail von Ihrer Domain erhaelt, prüft er Ihren SPF-Eintrag, um zu verifizieren, dass der Absender autorisiert ist. Wenn die IP nicht gelistet ist und Ihr SPF mit -all endet (hardfail), wird die E-Mail abgelehnt. SPF arbeitet mit DKIM und DMARC zusammen, um einen vollständigen E-Mail-Authentifizierungs-Stack zu bilden.

RFC 7208 gibt an, dass die SPF-Auswertung nicht mehr als 10 DNS-Abfragen überschreiten darf. Jeder include-, a-, mx-, ptr- und exists-Mechanismus zaehlt als eine Abfrage. Die Includes, die Sie einziehen, können selbst weitere Includes enthalten, was die Anzahl erhöht. Wenn eine Abfrage mehr als 10 DNS-Anfragen auslöst, ist das Ergebnis PermError (permanenter Fehler), was dazu fuehren kann, dass E-Mails abgelehnt oder nicht authentifiziert werden. Häufige Ursachen für das Überschreiten des Limits: Verwendung mehrerer ESPs (Mailchimp + Salesforce + SendGrid), jeder fuegt seinen eigenen Include hinzu. Verwenden Sie SPF-Flattening-Tools, um Include-Ketten in direkte IP4-Listen umzuwandeln.

-all (hardfail): E-Mails von nicht autorisierten Absendern sollten abgelehnt werden. Dies ist die strengste Einstellung. ~all (softfail): nicht autorisierte Absender werden markiert (normalerweise als Spam verschoben), aber nicht abgelehnt. Dies ist permissiver und der sichere Standard beim Ersteinsetzen von SPF. ?all (neutral): keine Richtlinie angegeben - nicht autorisierte Absender werden normal behandelt. +all: erlaubt explizit alle Absender - deaktiviert SPF-Schutz faktisch. Empfehlung: beginnen Sie mit ~all, überwachen Sie DMARC-Berichte einige Wochen, dann wechseln Sie zu -all.

Lösungen: (1) SPF-Flattening: Ersetzen Sie include:-Mechanismen durch die tatsächlichen IP4-Bereiche, auf die sie aufloesen. Dienste wie MXToolbox oder AutoSPF können dies automatisieren. (2) Konsolidieren Sie ESPs: wenn Sie von mehreren Diensten senden, prüfen Sie, ob alle eigene SPF-Includes benötigen. (3) Entfernen Sie ungenutzte Includes: wenn Sie einen ESP gestoppt haben, entfernen Sie seinen Include. (4) Verwenden Sie ein SPF-Makro statt Include für Dienste, die dies unterstützen. Hinweis: Abgeflachte SPF-Einträge brechen, wenn der ESP seine IP-Bereiche ändert - verwenden Sie einen verwalteten SPF-Dienst für kritische Domains.

SPF allein hat eine kritische Einschränkung: Es prüft nur den Envelope-Sender (MAIL FROM), nicht den From:-Header, den Nutzer sehen. Angreifer können E-Mails mit einem legitimen Envelope-Sender, aber einem gefälschten From:-Header senden. SPF + DKIM + DMARC zusammen schliessen diese Luecke: DMARC erfordert 'Ausrichtung' zwischen der SPF/DKIM-Domain und dem sichtbaren From:-Header, wodurch sichergestellt wird, dass das, was der Nutzer sieht, mit dem authentifizierten Inhalt übereinstimmt. Ohne DMARC verhindert das Bestehen von SPF allein keine Display-Name-Spoofing-Angriffe.