{"id":28769,"date":"2020-12-04T06:07:15","date_gmt":"2020-12-04T06:07:15","guid":{"rendered":"https:\/\/easydmarc.com\/blog\/?p=28769"},"modified":"2025-05-07T18:09:28","modified_gmt":"2025-05-07T18:09:28","slug":"spf-authentifizierung-spf-all-vs-all","status":"publish","type":"post","link":"https:\/\/easydmarc.com\/blog\/spf-authentifizierung-spf-all-vs-all\/","title":{"rendered":"SPF-Authentifizierung: SPF-all vs ~all"},"content":{"rendered":"

Was ist SPF? Mit dem Sender Policy Framework (SPF) kann der Administrator festlegen, welche IP-Adressen E-Mails im Namen einer Domain versenden d\u00fcrfen. Diese Genehmigung wird als TXT-Eintrag im DNS-Provider (Cloudflare, GoDaddy usw.) ver\u00f6ffentlicht. Beachten Sie, dass SPF die 5321.MailFrom-Adresse (auch bekannt als Return-Path-, Envelope From- oder Bounce-Adresse) \u00fcberpr\u00fcft, um sendende IP-Adressen zu autorisieren. Der Mailserver des Empf\u00e4ngers sollte, wenn er sich an die SPF-Richtlinie der Domain des Absenders h\u00e4lt, in \u00dcbereinstimmung mit der ver\u00f6ffentlichten SPF-Richtlinie handeln.<\/span><\/p>\n

Seit der Einf\u00fchrung des Sender Policy Framework im Jahr 2004 gibt es einen historischen Streit \u00fcber die Verwendung von SPF hard fail oder soft fail.<\/span><\/p>\n

In diesem Artikel werden wir er\u00f6rtern, warum Sie SPF softfail vs. hardfail (-all vs. ~all) verwenden sollten.<\/span><\/p>\n

\"\"<\/a><\/p>\n

SPF-Eintrag: Wie sieht er aus?<\/strong><\/h2>\n

Der SPF-TXT-Eintrag beginnt mit dem SPF-Versionsindikator, gefolgt von allen IP-Adressen auf der Whitelist, die berechtigt sind, E-Mails im Namen der Domain zu versenden, und endet mit einem all-Tag. Hier sind die m\u00f6glichen Tags:<\/span><\/p>\n

    \n
  1. -all (Fail): E-Mails von Servern \/ IP-Adressen, die nicht im SPF-Eintrag aufgef\u00fchrt sind, sollten abgelehnt werden.<\/span><\/li>\n
  2. ~all (SoftFail): E-Mails von Servern \/ IP-Adressen, die nicht im SPF-Eintrag aufgef\u00fchrt sind, sollten akzeptiert, aber markiert werden.\u00a0<\/span><\/li>\n
  3. +all (Pass): Alle Server k\u00f6nnen E-Mails im Namen Ihrer Domain senden. Wir empfehlen dringend, diese Option nicht zu verwenden.\u00a0<\/span><\/li>\n
  4. ?all (Neutral): Wird als None \/ Keine Richtlinie interpretiert. Wir empfehlen dringend, diese Option nicht zu verwenden.<\/span><\/li>\n<\/ol>\n

    Die obigen Tags geben an, welche Richtlinie auf E-Mails angewendet werden soll, wenn MBPs (Mailbox-Provider wie Google, Microsoft, Yahoo! usw.) feststellen, dass E-Mails von Servern\/ IP-Adressen gesendet wurden, die nicht im SPF-Eintrag aufgef\u00fchrt sind. Die Verwendung von SPF HardFail oder SoftFail sind die beiden akzeptierteren Methoden. Dennoch liegt die Pr\u00e4ferenz bei ~all.<\/span><\/p>\n

    Da Sie nun wissen, dass Sie +all und ?all nicht verwenden sollten, lassen Sie uns ein Beispiel betrachten, bevor wir uns mit dem Thema SPF SoftFail vs. HardFail befassen.<\/span><\/p>\n

    Beispiel eines SPF-Eintrags:<\/span><\/p>\n

    v=spf1 ip4:172.16.254.1 ip4:213.22.138.0\/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all<\/span><\/p>\n

      \n
    1. v=spf1: Der SPF-Eintrag sollte immer mit der Versionsnummer v=spf1 beginnen.<\/span><\/li>\n
    2. ip4- und ip6-Mechanismen: Listet die einzelnen IP-Adressen (z. B. 172.16.254.1 und 2001:db8:0:1234:0:567:8:1) oder IP-Subnetze (z. B. ip4:213.22.138.0\/24) auf, die berechtigt sind, E-Mails im Namen einer Domain zu versenden. Beachten Sie, dass IPv4-Adressen mit dem Pr\u00e4fix \u201eip4\u201c und IPv6-Adressen mit dem Pr\u00e4fix \u201eip6\u201c versehen werden sollten.<\/span><\/li>\n
    3. Mechanismus \u201einclude\u201c: Wird verwendet, um Dienste von Drittanbietern zu autorisieren, die E-Mails im Namen Ihrer Domain versenden. In diesem Beispiel autorisiert \u201e_spf.google.com\u201c Google Workspace (fr\u00fcher G Suite), E-Mails im Namen Ihrer Domain zu versenden.<\/span><\/li>\n
    4. \u201eall\u201c-Mechanismus: In diesem Beispiel wird das Tag \u201e-all\u201c (Fail) verwendet.<\/span><\/li>\n<\/ol>\n

      Das Beispiel verwendet den SPF-Eintrag hardfail vs. softfail, der alle E-Mails verwirft, die den Test nicht bestehen, einschlie\u00dflich der legitimen.<\/span><\/p>\n

      \"SPF-Record-Generator\"<\/p>\n

      SPF -all vs ~all: Was sollte ich verwenden?\u00a0<\/strong><\/h2>\n

      Vor der Einf\u00fchrung von DMARC (2012) spielte SPF allein eine wichtige Rolle bei der Bek\u00e4mpfung von Return-Path- oder MailFrom-E-Mail-Spoofing-Versuchen, auch wenn es seine Grenzen hat. MBPs wendeten Regeln an, die auf den ausdr\u00fccklichen Richtlinien der Administratoren f\u00fcr SPF-Eintr\u00e4ge (~all oder -all) basierten. Dies f\u00fchrte zu gro\u00dfen Problemen bei der Blockierung legitimer E-Mails aufgrund von SPF-Konfigurationsfehlern, was die meisten und bekannten MBPs dazu veranlasste, sowohl SoftFail (~all) als auch Fail (-all) als Methode zum <\/span>Akzeptieren aber Markieren<\/span><\/i> zu verwenden.<\/span><\/p>\n

      \n