Jump to content

SPF Eintrag setzen, keine negativen auswirkungen zu befürchten?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

Hallo, 


Frage: ein SPF Eintrag ist doch immer besser als keiner oder?   
Hauptsache der SPF Eintrag wird z.B. von www.spf-record.de nicht als gänzlich falsch "erkannt"

Meine Sorge ist nur, das ausgehende Mails bestimmte wichtige Empfänger nach Aktivierung des SPF nicht mehr erreichen (weil ein SPF-Detail falsch ist oder die ausgehende Mail beim Empfänger im JUNK landet)

Der aktuelle Mailflow ausgehend ist fehlerfrei. Es gibt keine NDR Claims.   Die Maildomain hat halt noch kein SPF.

 

Details:

  • Ein lokaler-Mailserver versendet über einen externen SMTP Server (des providers)  smtp.provider.de
  • Wenn nun ein SPF hinzugefügt wird,  (und  sicher ist, das kein Outlook/kein Smartphone einen gänzlich fremden/anderen SMTP Server verwendet)
  • SPF Entwurf:   v=spf1 mx a include:smtp-provider.de ip4:öffentliche-ip ~all
  • Einen DMARC Eintrag gleichzeitig im Domain-DNS erstellen kann Sinn machen, weil man durch die "automatische Zusendung von DMARC Reports"   Fakemails u.ä. "erahnen/sehen kann"
  • Ohne SPF kein DMARC 

 

besten dank für eine Einschätzung

Link to post
vor 8 Minuten schrieb Dirk-HH-83:

Frage: ein SPF Eintrag ist doch immer besser als keiner oder? 

Nein. Ein falscher SPF Record ist schlechter als kein Record. :p

 

vor 8 Minuten schrieb Dirk-HH-83:

Hauptsache der SPF Eintrag wird z.B. von www.spf-record.de nicht als gänzlich falsch "erkannt"

 

 

Nein auch ein "falscher" aber syntaktisch richtiger SPF Record kann schlechter als kein SPF Record sein.

vor 8 Minuten schrieb Dirk-HH-83:

Meine Sorge ist nur, das ausgehende Mails bestimmte wichtige Empfänger nach Aktivierung des SPF nicht mehr erreichen (weil ein SPF-Detail falsch ist oder die ausgehende Mail beim Empfänger im JUNK landet)

Der aktuelle Mailflow ausgehend ist fehlerfrei. Es gibt keine NDR Claims.   Die Maildomain hat halt noch kein SPF.

 

Du kannst doch jetzt auch nicht sagen, ob die Mail beim Empfänger im Junk landet. Und wenn klar ist wie der Mailflow aussieht, dann gibts genau keinen Grund nicht schon seit Jahren einen korrekten SPF Record zu nutzen.

 

Wasn, sind das die Stichpunkte deines Dienstleisters, die du nochmal abhaken willst?

vor 8 Minuten schrieb Dirk-HH-83:
  • Ein lokaler-Mailserver versendet über einen externen SMTP Server (des providers)  smtp.provider.de
  • Wenn nun ein SPF hinzugefügt wird,  (und  sicher ist, das kein Outlook/kein Smartphone einen gänzlich fremden/anderen SMTP Server verwendet)
  • SPF Entwurf:   v=spf1 mx a include:smtp-provider.de ip4:öffentliche-ip ~all
  • Einen DMARC Eintrag gleichzeitig im Domain-DNS erstellen kann Sinn machen, weil man durch die "automatische Zusendung von DMARC Reports"   Fakemails u.ä. "erahnen/sehen kann"
  • Ohne SPF kein DMARC 

 

DMARC nur mit SPF kann man machen, führt aber zwangsweise bei einigen Mails zu Spamverdacht (Abwesenheitsnachrichten bspw.).

Wenn die Mails alle über den Provider laufen, dann mußt du erstmal schauen, dass der Provider einen entsprechenden SPF Record hat, den du per include setzen kannst. WEnn nicht, wirst du die IPs die der Provider nutzt, einzeln eintragen müssen.

mx wozu?

a wozu?

~all warum nicht -all? Wer weiß was er tut, setzt den SPF Record auch entsprechend. Und wenn Outlook und Smartphone irgendwelche fremden SMTP Server verwenden, haben die auch ohne SPF Record was falsche gemacht.

 

Bye

Norbert

 

PS: Dann frag provider.de doch auch gleich nach DKIM, wenn du eh dabei bist.

Edited by NorbertFe
Link to post

Zum Testen kannst Du Softfail benutzen. Wenn alles läut, dann "Fail" setzen. Einen SPF Record kannst Dir über dieses Tool erstellen lassen.

Über mxtoolbox und Toolbox kannst Du Deine Mailkonfiguration testen. Ich nutze darüberhinaus ein gmail Konto. Wenn Du eine EMail an gmail sendest kannst Du über "Details" den vollständigen Header ansehen. gmail trägt dort ausführliche Hinweise bzgl. der Prüfung des SPF Records ein.

Link to post
Posted (edited)

Hallo,   besten dank für die klarstellung.

 

 

  • o365 schreibt meines Wissen nach die gleichen SPF-Details in den Header wie GMAIL
  • Stein des Anstoßes war ein Mißverständnis: meine etwas komische SPF-Frage kam deshalb, weil eine Phishingmail eingetroffen ist (von extern), war jedoch als "intern getarnt"   und der Ansprechpartner dachte irrtümlich das man diese Gefahr "lediglich mit SPF-DNS-Eintrag erstellen verringern/verhindern kann"  (was dank eurer klarstellung ja falsch ist)

 

a)

Das Mailgateway hat noch keine Sperre für eingehende Mails von der eigenen Domain und das hätte in dem Fall vermutlich geholfen

 

Auszug Header:

From: "Max Mustermann" <vorname.nachname@firma.de

X-Sender: absender-phishingmail@fremde-gekapperte-domäne.com

Reply-To: "Max Mustermann" <absender-phishingmail@fremde-gekapperte-domäne.com>

X-WatchGuard-Mail-From: absender-phishingmail@fremde-gekapperte-domäne.com

 

Log: 

Envelope Sender: absender-phishingmail@fremde-gekapperte-domäne.com  

 

 

 

b)

eingehende Emails haben leider "noch" kein automatischen Betreffzusatz [EXTERNAL] oder [INTERNAL] - wie man hier sieht führt es zu Folgeproblemen/Bedarf:

 

 

c) 

 

Habe bisher nicht mitbekommen, das dies häufiger praktiziert wird, bzw. "wirklich was bringt"  

Frage:   Welche SPF Überprüfung / Aktion am Email-Eingangsgateway wäre eurer Meinung nach empfehlenswert?
Ziel:  Dem Endverbraucher ggf. über "Betreffmarker signalisieren das es SCAM sein könnte"
Das Mailgateway kann dies prüfen und dann z.B. ein SCL oder Betreff-Marker setzen.


SPF-Ergebnis gleich/ungleich:

PASS

FAIL
SOFT FAIL

NEUTRAL

 

alternatives mailgateway:

SPF-Ergebnis gleich/ungleich:

NONE
PASS
NEUTRAL

SOFTFAIL

FAIL

TEMP-ERROR

PERM-ERROR

 

 

Edited by Dirk-HH-83
Link to post
vor 4 Minuten schrieb Dirk-HH-83:

Das Mailgateway hat noch keine Sperre für eingehende Mails von der eigenen Domain und das hätte in dem Fall vermutlich geholfen

 

Kommt drauf an. Dann hätte aber (d)ein SPF Record auch geholfen. Da muss man nix explizit blocken.

Und dein Header verrät, dass SPF nicht geholfen hätte, sondern evtl. DKIM und DMARC.

 

Zu b: Naja, da tritt dann am Ende auch nur "Gewöhnung" ein und die Leut klicken trotzdem drauf.

 

Zu c: Hab nicht verstanden, was du eigentlich aussagen willst. :)

 

Link to post
Am 25.5.2021 um 13:21 schrieb Dirk-HH-83:

 

b)

eingehende Emails haben leider "noch" kein automatischen Betreffzusatz [EXTERNAL] oder [INTERNAL] - wie man hier sieht führt es zu Folgeproblemen/Bedarf:

 

 

 

Das lässt sich aber wiederum umgehen, wenn Du eine Transportregel aufbaust, die einfach eine Kategorie für INTERN und/oder EXTERN nutzt. Die Kategorie wird bei ausgehenden Mails nicht mit übertragen und Deine Leute müssten nur lernen die Kategorie in Outlook zu lesen oder ggfls. die Spalte einzublenden. Je nachdem welches Mailprogramm/Version Du einsetzt.

Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...