Validieren Sie Ihren Sender-Policy-Framework-Eintrag
DNS & Einträge
DNS-Abfrage Alle DNS-Einträge für jede Domain A-Eintrag-Abfrage IPv4-Adressen für eine Domain AAAA-Eintrag-Abfrage IPv6-Adressen für eine Domain MX-Abfrage Mailserver für eine Domain NS-Abfrage Autoritative Nameserver TXT-Abfrage TXT-Einträge, SPF, Verifizierung CNAME-Abfrage Kanonische Namen (Alias)-Einträge SOA-Abfrage Start-of-Authority-Eintrag SRV-Abfrage Dienst-Standort-Einträge CAA-Abfrage Welche CAs Zertifikate ausstellen dürfen Reverse DNS (PTR) IP-Adresse zu Hostname DNSSEC-Prüfung Ist die Domain signiert und validiert? DNS-Gesundheitscheck Ein vollständiger Bericht zu Delegierung & DNSE-Mail-Zustellbarkeit
SPF-Prüfung Validieren Sie Ihren Sender-Policy-Framework-Eintrag DMARC-Prüfung Untersuchen und bewerten Sie Ihre DMARC-Richtlinie DKIM-Prüfung Finden und validieren Sie Ihren öffentlichen DKIM-Schlüssel Blacklist-Prüfung Prüfen Sie eine IP gegen E-Mail-Sperrlisten (DNSBLs) SMTP-Test Mit einem Mailserver verbinden und STARTTLS prüfen MTA-STS-Prüfung Erzwungene TLS-Richtlinie für eingehende Mails BIMI-Prüfung Markenlogo-Eintrag für E-Mail TLS-RPT-Prüfung SMTP-TLS-BerichtsrichtlinieNetzwerk & Web
SSL-Zertifikat-Prüfung TLS-Zertifikat und Ablauf einer Website untersuchen HTTP-Header-Prüfung Antwort-Header, Weiterleitungen und Sicherheit untersuchen Ping (TCP) Erreichbarkeit und Latenz über TCP Port-Prüfung Welche gängigen Ports offen sindDomain
WHOIS-Abfrage Registrierungsdaten für Domains, IPs und ASNsSPF (Sender Policy Framework) teilt empfangenden Mailservern mit, welche Hosts E-Mails für Ihre Domain versenden dürfen. Ein fehlerhafter SPF-Record – doppelt vorhanden, zu viele DNS-Lookups oder ohne 'all'-Mechanismus – sorgt dafür, dass legitime Nachrichten im Spam landen. IPeek findet Ihren SPF-Record, analysiert jeden Mechanismus und kennzeichnet die Probleme, die Ihrer Zustellbarkeit schaden.
SPF liegt als TXT-Record auf Ihrer Root-Domain und beginnt mit v=spf1. Empfängt ein Server eine Nachricht, die angeblich von Ihnen stammt, schlägt er diesen Record nach und prüft, ob die sendende IP autorisiert ist. Ein Record wie v=spf1 include:_spf.google.com ip4:198.51.100.10 -all bedeutet: „Erlaube die Hosts von Google und diese eine IP, weise alles andere ab.“ Mechanismen werden von links nach rechts ausgewertet; der erste Treffer gewinnt. Der abschließende all-Mechanismus ist der Auffangmechanismus, der das Standardergebnis für jeden nicht ausdrücklich gelisteten Host bestimmt.
Der all-Mechanismus legt Ihre Richtlinie fest: -all ist ein Hardfail (nicht gelistete Absender werden abgewiesen), ~all ist ein Softfail (Annahme, aber als verdächtig markiert) und +all erlaubt jeden – verwenden Sie es niemals. SPF begrenzt DNS-abfragende Mechanismen (include, a, mx, ptr, exists, redirect) zudem auf insgesamt 10 Lookups; wird das überschritten, ist das Ergebnis ein permerror, der als Fehlschlag gewertet wird. Auch verschachtelte includes zählen mit, sodass das Hinzufügen mehrerer Anbieter das Budget unbemerkt aufbraucht. IPeek zählt jeden Lookup und warnt, bevor Sie an die Grenze stoßen.
SPF allein reicht nicht aus. Es authentifiziert den Envelope-Absender (den Return-Path), nicht die sichtbare From-Adresse, die Nutzer sehen – Spoofer können SPF also bestehen und trotzdem Ihre Marke fälschen. DMARC schließt diese Lücke, indem es eine Übereinstimmung (Alignment) zwischen der SPF-Domain und der From-Domain verlangt und SPF mit DKIM kombiniert, sodass eines von beiden eine Nachricht authentifizieren kann. Betrachten Sie SPF als eine von drei Ebenen: SPF autorisiert Hosts, DKIM signiert Inhalte und DMARC verknüpft beides mit Ihrer From-Domain und setzt die Richtlinie durch.
SPF erlaubt maximal 10 DNS-abfragende Mechanismen pro Auswertung. Die Mechanismen include, a, mx, ptr, exists und redirect verbrauchen jeweils Lookups, und verschachtelte includes zählen auf dasselbe Limit ein. Eine Überschreitung von 10 erzeugt einen permerror, den Empfänger als Authentifizierungsfehler behandeln. Fassen Sie includes zusammen oder „flatten“ Sie sie, um unter der Grenze zu bleiben.
Der Unterschied liegt in der Durchsetzung. -all ist ein Hardfail, der Empfänger anweist, Mail von jedem nicht gelisteten Host abzuweisen, während ~all ein Softfail ist, der sie zur Annahme, aber Markierung als verdächtig anweist. Nutzen Sie ~all während der Testphase und wechseln Sie zu -all, sobald Sie bestätigt haben, dass jeder legitime Absender autorisiert ist. Vermeiden Sie +all, das jeden autorisiert.
Ein SPF-Record allein garantiert keine Zustellung in den Posteingang. Häufige Ursachen sind das Überschreiten des 10-Lookup-Limits (permerror), ein fehlender oder zu großzügiger all-Mechanismus, ein sendender Host, der gar nicht autorisiert ist, oder doppelte SPF-Records auf derselben Domain. SPF schützt zudem nicht Ihre sichtbare From-Adresse – für eine starke Zustellbarkeit benötigen Sie zusätzlich DKIM und DMARC.
Nein. Eine Domain muss genau einen SPF-Record (v=spf1) als TXT-Record veröffentlichen. Zwei oder mehr SPF-Records verursachen einen permerror, und Empfänger können Ihre Mail abweisen oder die Authentifizierung scheitern lassen. Wenn Sie mehrere Absender autorisieren müssen, fassen Sie diese mit zusätzlichen include- oder ip4/ip6-Mechanismen in einem einzigen Record zusammen, statt einen zweiten Record anzulegen.
Nein. SPF authentifiziert den Envelope-Absender (den Return-Path bzw. MAIL FROM), nicht den From-Header, den Ihre Empfänger tatsächlich sehen. Deshalb kann SPF allein das Spoofing Ihrer Marke nicht verhindern. DMARC ergänzt das SPF-Alignment und verlangt, dass die SPF-Domain mit der sichtbaren From-Domain übereinstimmt – genau das schließt die Lücke zwischen den Prüfungen auf Protokollebene und dem, was Nutzer lesen.