Sofortige Prüfung und Validierung Ihres SPF-Records. Wir prüfen auf Syntaxfehler, doppelte Records und „zu viele DNS-Lookups“ und zeigen dann genau, wie Sie Probleme beheben. Schnell und kostenlos.
SPF erlaubt maximal 10 DNS-Lookups. Überschreiten Sie diese Zahl, schicken empfangende Server einen PermError zurück, sodass jede gesendete E-Mail fehlschlägt.
Eine Domain, die Google Workspace, Salesforce und Mailchimp HubSpot nutzt, kann dieses Limit unbemerkt erreichen.
Sie können pro Domain nur einen SPF-TXT-Record haben. Wenn Sie zwei haben, geben empfangende Server einen PermError zurück.
Dies passiert typischerweise nach dem Wechsel des E-Mail-Anbieters, wenn der alte Record zurückbleibt. Löschen Sie das Duplikat und führen Sie alles zusammen.
Ein falsch gesetztes Leerzeichen oder Tippfehler kann Ihren gesamten Record unbrauchbar machen.
Typische Beispiele sind inlcude statt include oder ein Record, der nicht mit v=spf1 beginnt. Der SPF Checker markiert solche Fehler rot und zeigt genau, wo das Problem liegt.
?all (neutral) lehnt unautorisierte Absender nicht ab — E-Mails werden trotzdem zugestellt. Vermeiden Sie dessen Verwendung. Für aktive, versendende Domains nutzen Sie ~all zusammen mit DMARC auf p=reject — das lehnt nicht authentifizierte E-Mail ab, ohne legitime Zustellung zu gefährden.
-all ist nur für inaktive Domains reserviert, die keine E-Mails versenden.
„SubdoMailing“ oder subdomainbasierte Mailings sind eine fortschrittliche Angriffsmethode, die Schwachstellen in der DMARC-Umsetzung ausnutzt. Indem Nachrichten von scheinbar legitimen Subdomains verschickt werden, die Authentifizierungschecks bestehen, können Cyberkriminelle vertrauenswürdige Organisationen glaubhaft fälschen und Empfänger täuschen.
Mit diesem Leitfaden erfahren Sie mehr über:
SPF steht für Sender Policy Framework. Es handelt sich um ein E-Mail-Authentifizierungsprotokoll, das als Whitelist fungiert und festlegt, welche Absender berechtigt sind, in Ihrem Namen E-Mails zu senden. Es soll E-Mail-Fälschungen verhindern.
SPF steht für Sender Policy Framework. Es handelt sich um ein E-Mail-Authentifizierungsprotokoll, das als Whitelist fungiert und festlegt, welche Absender berechtigt sind, in Ihrem Namen E-Mails zu senden. Es soll E-Mail-Fälschungen verhindern.
DNS-TXT-Record, der empfangenden Mailservern mitteilt, welche IPs/Hosts zum Versand von E-Mails für eine Domain autorisiert sind.
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.5 -all
Das Record beginnt mit v=spf1, listet die autorisierten Absender auf und endet mit einem all-Qualifier. Es darf nur einen Record pro Domain geben — keine Ausnahmen.
Die von SPF Checker bereitgestellte SPF-Tree-Visualisierung zeigt jeden Schritt der Auflösung eines SPF-Records, wie jede Regel geprüft wird und ob sie als bestanden, nicht bestanden oder neutral bewertet wird. Diese Visualisierung hilft, die Hierarchie der SPF-Regeln zu verstehen und mögliche Probleme oder Fehlkonfigurationen im Record zu erkennen.
Am 27. Februar 2024 entdeckten Forscher von Guardio eine groß angelegte Ad-Fraud-Kampagne, die auf tausenden kompromittierten Domains und Subdomains basiert. Mehr Informationen zur SubdoMailing-Attacke und zum Selbstschutz finden Sie hier.
Das Tool von Red Sift erkennt, ob Ihr SPF-Record kompromittierte Includes enthält, die Ihre Domain für Spoofing-Attacken anfällig machen. Die dynamische SPF-Tree-Visualisierung zeigt genau an, wo vergiftete Includes existieren. Bei Entdeckung kompromittierter Includes sollten Sie diese Einträge umgehend aus Ihrem SPF-Record entfernen.
Wenn Sie eine SPF-Prüfung für Ihre Domain durchführen, stellen Sie sicher, dass die Authentifizierung für von Ihrer Domain gesendete E-Mails richtig konfiguriert ist und reduzieren so das Risiko, dass Ihre E-Mails als Spam markiert oder von den Empfängerservern abgelehnt werden.
Abhängig von der SPF-Konfiguration der angegebenen Domain werden Informationsmeldungen angezeigt, mit der Option "im SPF-Baum hervorheben".
Ja, der SPF Checker kann Fehler in verschachtelten Includes von Drittanbieter-Records erkennen, indem jeder eingebundene SPF-Record in der Hierarchie analysiert wird. So können Sie Fehler in fremden SPF-Konfigurationen erkennen und beheben, die auch die Mail-Authentifizierung Ihrer eigenen Domain beeinträchtigen.
Sie können über Tools wie nslookup oder dig die DNS-Records Ihrer Domain abfragen, um auf den SPF-Record zuzugreifen. Alternativ können Sie Online-SPF-Prüfwerkzeuge oder die DNS-Verwaltungsoberfläche Ihres Registrars oder Hostinganbieters nutzen.
Ein Void Lookup entsteht, wenn eine Regel im SPF-Record zu einer DNS-Anfrage führt, die kein Ergebnis liefert – ein Hinweis auf eine Fehlkonfiguration oder einen ungültigen Eintrag. Void Lookups können zu SPF-Fehlschlägen führen und sollten für eine korrekte SPF-Konfiguration behoben werden.
Syntaxfehler in einem SPF-Record können behoben werden, indem Sie die SPF-Syntaxregeln überprüfen und sicherstellen, dass der Record korrekt aufgebaut ist. Typische Fehler sind fehlende oder falsch gesetzte Regeln, ungültige Zeichen und fehlerhafte Leerzeichen. Nach Identifikation können Syntaxfehler mit der DNS-Verwaltung Ihres Registrars oder Hosters korrigiert werden.
SPF-Mechanismen sind Bestandteile eines SPF-Records, die festlegen, welche Mailserver für den Versand im Namen einer Domain autorisiert sind. Dazu zählen IP-Adressen, Domainnamen und Qualifier, die bestimmen, wie der Mechanismus interpretiert werden soll. Mit passenden Mechanismen im SPF-Record steuern Domaininhaber genau, welche Mailserver ihren Namen nutzen dürfen und stärken so die E-Mail-Authentifizierung und Sicherheit.
Führen Sie eine Prüfung durch und achten Sie auf einen Record, gültige Syntax, ≤10 DNS-Lookups.
Typischerweise wegen mehrfacher Records, Syntaxproblemen oder zu vielen „include“-Lookups.
RFC 7208 begrenzt SPF auf 10 DNS-Mechanismen, um empfangende Server vor Überlastung zu schützen. Jeder include, a, mx, ptr und redirect zählt. Überschreiten Sie dieses Limit, schlägt SPF für jede E-Mail fehl, auch für legitime. Der SPF Checker zeigt Ihre aktuelle Lookup-Anzahl an und woher diese stammt.
-all (Hardfail) lehnt E-Mails von nicht autorisierten Absendern direkt ab. ~all (Softfail) nimmt diese an, leitet sie aber meist in den Spam. ?all (neutral) gibt keine Auskunft und bietet keinen Schutz. Für Produktivdomains ist -all die richtige Einstellung. ~all nur benutzen, solange Sie noch legale Absender identifizieren.
Ja, und das sollten Sie auch. SPF auf yourdomain.com schützt nicht mail.yourdomain.com oder newsletter.yourdomain.com. Jede sendende Subdomain benötigt einen eigenen Record. Subdomains ohne SPF sind anfällig für Spoofing.
