Das Sender Policy Framework (SPF) ist ein Verfahren, dass das Fälschen der Absenderadresse einer E-Mail verhindern soll. Der Administrator einer Domain hinterlegt in der DNS-Zone einen Resource Record vom Typ TXT. In diesen Resource Records sind die IP-Adressen oder der Hostname der Server hinterlegt, die E-Mails versenden dürfen. Der Empfänger der E-Mail prüft dann den Resource Record gegen die Informationen, die im E-Mail Header vorhanden sind und lehnt die E-Mail ab, sollten die Informationen nicht übereinstimmen.


Die benötigten Informationen zum Setzen des SPF-Records können Sie unserer Onboarding-Webseite entnehmen. Wir empfehlen grundsätzlich die Verwendung eines SPF-Filters.


1. Variante


Der SPF-Filter kann in zwei verschiedenen Varianten verwendet werden:

  • Variante 1: Hier wird die Prüfung nur verwendet, wenn eine E-Mail von einer internen Domain empfangen wird. Hier wird dann der TXT-Record der eigenen Domain geprüft.
  • Variante 2: Hier wird die Prüfung bei allen eingehenden E-Mails angewandt. Hier wird der TXT-Record der sendenden Domain abgerufen und die Informationen im Header gegengeprüft. 


Welche Variante Sie einsetzen, ist Ihnen überlassen. Bei der Variante 2 kann es ggf. zu erhöhten False Positives (korrekte E-Mails werden ungerechtfertigterweise aussortiert) kommen, falls der TXT-Record Fehler aufweist (z.B. eine IP-Adresse inkorrekt ist oder fehlt). Wir empfehlen, mit Variante 1 zu starten und bei Bedarf auf Variante 2 zu wechseln.


2. Entscheidungsmatrix


Die Einstufung der E-Mail anhand des TXT Records des versenden Servers wirkt sich auf unserer SPF Prüfung aus:


    „v=spf1 include:example.com -all”  -> Hardfail

    „v=spf1 include:example.com ~all” -> Softfail


Dazu haben Sie die Möglichkeit eine bestimmte Handlungsart zu wählen:

  • Hardfail:
    1 = Abweisung
    2 = Quarantänisierung als Spam
    3 = zulassen (nichts tun)

  • Softfail:
    1 = Abweisung
    2 = Quarantänisierung als Spam
    3 = zulassen (nichts tun)


Wobei immer das höherwertige verwendet wird (hardfail > softfail > pass). Im folgenden zwei Beispiele:

A.)

Envelope-From
softfail
Header-From
hardfail
Ergebnis
hardfail

 

B.)

Envelope-From
softfail
Header-From
pass
Ergebnis
softfail

 


Zusätzlich benötigen wir die Angabe, wie die Analyse für Header-From und Envelope-From erfolgen soll. Hierbei bieten sich drei Optionen an:


  • 0 = Analysieren von Header-From und Envelope-From
  • 1 = Explizites Analysieren auf Envelope-From (Standardeinstellung)
  • 2 = Explizites Analysieren auf Header-From


3. DMARC


Hornetsecurity bietet DMARC Validierung an, daher benötigen wir zusätzlich die Information, ob wir DMARC in die Entscheidungsmatrix aufnehmen sollen. Die folgenden Optionen stehen hier zur Verfügung.


  • 0 = DMARC deaktiviert
  • 1 = DMARC aktiviert


Beachten Sie bitte, dass die Aktivierung von DMARC ausdrücklich beim Support angefordert werden muss, das reine setzten einer 1 aktiviert die DMARC Validierung nicht.



4. Syntax

Wenn Sie sich entscheiden SPF auch über Hornetsecurity zu nutzen, wenden Sie sich bitte an den Support und teilen uns mit in welcher Form Sie SPF verwenden möchten. Anschließend finden Sie die Syntax:

 

;Empfänger-Domäne;SPF-Variante;DMARC-Typ;Hardfail-Behandlung;Softfail-Behandlung;Analyse-Option

 

Beispiel:

;example.com;1;0;1;2;0


Quarantänisierte E-Mails können durch das Control Panel ausgelöst werden. Ausnahmen sind durch das Eintragen der versendenden IP-Adresse in die Kunden Whitelist im Control Panel möglich. Speziellere Ausnahmen können über den Compliance Filter erstellt werden.