{"id":1851,"date":"2026-07-26T10:40:16","date_gmt":"2026-07-26T07:40:16","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1851"},"modified":"2026-08-03T10:32:22","modified_gmt":"2026-08-03T10:32:22","slug":"spf-fuer-den-wordpress-e-mail-versand-einrichten","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/spf-fuer-den-wordpress-e-mail-versand-einrichten\/","title":{"rendered":"SPF f\u00fcr den WordPress-E-Mail-Versand einrichten"},"content":{"rendered":"

Ein Unternehmen nimmt einen Transaktionsmail-Anbieter f\u00fcr WordPress in Betrieb und ver\u00f6ffentlicht daf\u00fcr einen zweiten SPF-Eintrag. Einige Empf\u00e4nger melden nun einen dauerhaften SPF-Fehler. Gleichzeitig pr\u00fcft das Team nur die sichtbare From<\/code>-Adresse und \u00fcbersieht die separate Return-Path-Domain des Providers.<\/p>\n

Eine korrekte Konfiguration beginnt bei der SMTP-Envelope-Identit\u00e4t. Alle legitimen Versanddienste dieser Domain werden erfasst, in einer einzigen Richtlinie zusammengef\u00fchrt und anschlie\u00dfend anhand empfangener Mailheader gepr\u00fcft.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS SMTP Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was das Thema bedeutet<\/h2>\n

    Sender Policy Framework (SPF) ist eine DNS-Richtlinie, die Systeme zum Versand f\u00fcr eine SMTP-MAIL FROM<\/code>-Domain berechtigt. Der empfangende Server vergleicht die verbindende IP mit dem SPF-Eintrag dieser Envelope-Domain; ohne nutzbare MAIL-FROM-Identit\u00e4t kann die HELO-Domain ausgewertet werden.<\/p>\n

    SPF signiert die Nachricht nicht und authentifiziert allein nicht die f\u00fcr Leser sichtbare From<\/code>-Adresse. DMARC kann einen SPF-Erfolg nur verwenden, wenn die authentifizierte Envelope-Domain zur sichtbaren From-Domain ausgerichtet ist.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    F\u00fcr die Hauptdomain existiert bereits ein SPF-Eintrag f\u00fcr Microsoft 365. Beim Anschluss des WordPress-Providers wird dessen include<\/code> als zweiter SPF-TXT-Datensatz ver\u00f6ffentlicht. Empf\u00e4nger, die beide Richtlinien finden, k\u00f6nnen darauf mit permerror<\/code> reagieren.<\/p>\n

    Der DNS-Verantwortliche ermittelt zuerst die Return-Path-Domain des Providers. Wird die Unternehmensdomain ausgewertet, kommt das notwendige Include in die vorhandene Richtlinie. Verwendet der Provider seine eigene Domain, wird der Unternehmenseintrag nicht nur wegen der sichtbaren From-Adresse ver\u00e4ndert. Ma\u00dfgeblich sind die Testheader.<\/p>\n

    Warum es wichtig ist und wann es eingesetzt wird<\/h2>\n

    SPF hilft Empf\u00e4ngern, berechtigte Versandserver von einer unbefugten Nutzung der Envelope-Domain zu unterscheiden. Eine unvollst\u00e4ndige Richtlinie schadet legitimen Mails; eine zu breite Richtlinie berechtigt Systeme, die nicht mehr senden sollen.<\/p>\n

    WordPress teilt die Domain m\u00f6glicherweise mit Mitarbeiterpostf\u00e4chern, Helpdesk, Shopsystem, Marketingplattform oder Relay. Bevor der abschlie\u00dfende Qualifizierer versch\u00e4rft wird, m\u00fcssen s\u00e4mtliche legitimen Quellen derselben Envelope-Domain bekannt sein.<\/p>\n

    SPF l\u00e4sst sich sinnvoll einrichten, wenn die Organisation das zust\u00e4ndige DNS kontrolliert und das Senderinventar pflegen kann. Verwaltet der Mailanbieter die Return-Path-Domain selbst, gilt dessen Dokumentation; zus\u00e4tzliche Eintr\u00e4ge an der sichtbaren From-Domain helfen dann nicht automatisch.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Senden Sie eine kontrollierte WordPress-Mail und lesen Sie Return-Path<\/code>, Received-SPF<\/code> und Authentication-Results<\/code>, um die tats\u00e4chlich ausgewertete Domain zu bestimmen.<\/li>\n
    2. Erfassen Sie alle f\u00fcr diese Domain berechtigten Dienste einschlie\u00dflich IPv4, IPv6, Relays und Provider-include<\/code>-Mechanismen.<\/li>\n
    3. Pr\u00fcfen Sie die aktuellen autoritativen TXT-Datens\u00e4tze. Pflegen Sie genau eine mit v=spf1<\/code> beginnende Richtlinie und f\u00fchren Sie ben\u00f6tigte Mechanismen dort zusammen.<\/li>\n
    4. Entfernen Sie alte Quellen erst nach Best\u00e4tigung durch die zust\u00e4ndige Stelle. W\u00e4hlen Sie den abschlie\u00dfenden all<\/code>-Qualifizierer bewusst.<\/li>\n
    5. Fragen Sie autoritatives DNS und mehrere Resolver ab und senden Sie \u00fcber jede verbleibende Quelle. SPF-Ergebnis und DMARC-Alignment werden getrennt gepr\u00fcft.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      L\u00f6sen Sie verschachtelte include<\/code>– und redirect<\/code>-Ketten auf und z\u00e4hlen Sie alle DNS-ausl\u00f6senden Mechanismen gegen das SPF-Lookup-Limit. Ber\u00fccksichtigen Sie leere Antworten, Providerabh\u00e4ngigkeiten, IPv6, Makros und Subdomains. Auch ein kurzer Eintrag kann \u00fcber Drittanbieter das Limit \u00fcberschreiten.<\/p>\n

      Dokumentieren Sie f\u00fcr jede externe Abh\u00e4ngigkeit Verantwortliche, Zweck, Pr\u00fcfdatum und Entfernungskriterium. Ein negativer Test von einer nicht autorisierten Quelle geh\u00f6rt ebenfalls zur Abnahme, allerdings nur in einer kontrollierten Umgebung ohne gef\u00e4lschte Kundenmail.<\/p>\n

      Pr\u00fcfen Sie die Richtlinie nach Providerwechseln, \u00dcbernahmen, Helpdesk-\u00c4nderungen oder neuen Marketingdiensten erneut. Ein Drittanbieter kann den Inhalt eines Includes \u00e4ndern, ohne dass sich der TXT-Wert der Unternehmensdomain sichtbar \u00e4ndert.<\/p>\n

      Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/h2>\n

      Ver\u00f6ffentlichen Sie nicht mehrere SPF-Richtlinien f\u00fcr denselben Namen, \u00fcbernehmen Sie keine undokumentierten Provider-IP-Bereiche, lassen Sie alte Sender nicht unn\u00f6tig berechtigt und verwenden Sie keinen veralteten ptr<\/code>-Mechanismus. Auch ein sofortiger Wechsel auf einen strikten Fehlerqualifizierer ohne Inventar kann legitime Mail blockieren.<\/p>\n

      Sichern Sie vor der \u00c4nderung den genauen bisherigen DNS-Wert und die Zust\u00e4ndigkeit. Ber\u00fccksichtigen Sie TTL und Verteilung. Scheitern weiterhin ben\u00f6tigte Sender, liefern autoritative Server unterschiedliche Werte, wird das Lookup-Limit \u00fcberschritten oder die falsche Domain ausgewertet, stellen Sie die vorige einzelne Richtlinie wieder her und kl\u00e4ren das Inventar.<\/p>\n

      \n

      Wie AIOWS unterst\u00fctzt:<\/p>\n

      AIOWS SMTP Manager<\/h2>\n

      Der AIOWS SMTP Manager h\u00e4lt SMTP-Server, Absenderidentit\u00e4t und kontrollierten Test auf WordPress-Seite sichtbar, w\u00e4hrend SPF vorbereitet wird. Die Header einer \u00fcber diesen Weg versendeten Testmail zeigen den tats\u00e4chlichen Return Path und die vom Empf\u00e4nger ausgewertete SPF-Domain.<\/p>\n

      Vergleichen Sie diese Header mit der aktuellen Providerdokumentation und dem autoritativen DNS-Eintrag. Wiederholen Sie die Pr\u00fcfung mit einem echten WordPress-Ereignis auf demselben Versandweg; ein allgemeiner Test belegt nicht, dass Formular-, Bestell- und Kontomails identische Einstellungen verwenden.<\/p>\n

      AIOWS kann keine DNS-Eintr\u00e4ge ver\u00f6ffentlichen oder \u00e4ndern, das SPF-Include des Providers nicht steuern und keine unberechtigte Quelle legitimieren. Ein SPF-Pass erzeugt au\u00dferdem kein DMARC-Alignment, wenn die Domains nicht zusammenpassen. DNS-Verantwortung, Senderinventar und Richtlinienpflege bleiben au\u00dferhalb des Moduls.<\/p>\n

      AIOWS SMTP Manager ansehen<\/a>AIOWS-Tarife vergleichen<\/a><\/p>\n<\/section>\n

      Passende AIOWS-Artikel<\/h2>\n