SPF Record Check - Seh ich das richtig?

Zensai

Boba Fett Pro
Administrator
Registriert
Aug. 2008
Beiträge
13.726
Hi zusammen,

ich hab hier grade irgendwie Matsch im Kopf und komm nicht auf den Fehler.

Ich versende für eine Domain "verein.com" sowohl von IONOS aus, als auch von Exchange Online aus.

Der zugehörige SPF Record lautet:
Code:
v=spf1 include:spf.protection.outlook.com include:_spf.kundenserver.de -all

Also diese Beiden Server dürfen für diese Domain schicken, ansonsten Hardfail.

Es existiert für die Domain eine Subdomain "abteilung.verein.com", für diese Subdomain schickt ausschließlich Exchange Online Emails, daher ist der zugehörige SPF:
Code:
v=spf1 include:spf.protection.outlook.com -all

Ich habe nun aus einem Postfach "x.y@verein.com" eine Email an diverse Empfänger geschickt und daraufhin von Strato (ja, Strato) einen NDR zurückbekommen dass der Versand an diverse Gmail Adressen fehlschlug.
Code:
Mail delivery to the following recipients has finally failed:
abc123@gmail.com
Explanation: host gmail-smtp-in.l.google.com [64.233.166.27] said: 5.7.26 The MAIL
                FROM domain [Verein.com] has an SPF record with a
                hard 5.7.26 fail policy (-all) but it fails to pass SPF
                checks with the ip: 5.7.26 [81.169.146.147]. To best
                protect our users from spam and phishing, 5.7.26 the
                message has been blocked. Please visit 5.7.26
                https://support.google.com/mail/answer/81126#authenticat
                ion for more 5.7.26 information.
                d7-20020adfef87000000b00314140980c7si4328368wro.702 -
                gsmtp

Meine Frage nun: Ich sehe das doch richtig, dass mein SPF korrekt ist, oder? Die Zielpostfächer haben vermutlich eine Weiterleitung an irgendwelche Gmailadressen drin, leiten dann die Mail entsprechend an Gmail weiter, und weil hier dann eben der Absender nicht mehr ExO oder IONOS ist, läuft Google in den Hardfail und schickt den NDR den ganzen weg zurück. Korrekt? Habt ihr Vorschläge, ob es eine Lösung für diesen Fall gibt? Ich vermute, ein Teil der weiterleitenden Postfächer (die die Email ja dann haben) wird nämlich nicht überwacht.

Danke!
 
Lösung
Das liegt definitiv an Weiterleitungen, was ja auch ein bekanntes Problem von SPF ist. Ich verwende aus diesem Grund nur Softfail, dafür zusätzlich DKIM und DMARC. Weiterleitungen bleiben ja DKIM-signiert und werden dann nicht abgewiesen.
Sehe ich wie du mit den Weiterleitungen.
Im Zeitalter von dmarc/dkim/spf sind automatisierte Weiterleitungen ein NoGo, was ich vielen Kunden schon mehrfach predigen musste...

Das einzige was noch geht ist "als Anhang weiterleiten".
 
Was ist denn mit 81.169.146.147? Matcht das auf irgendeinen der Server in deinem SPF-Eintrag? Gehört wohl zu strato/IONOS.

Edit: Ich sollte mal richtig lesen. Die Gmail-Adressen wurden nicht direkt angeschrieben? Dann kanns ja nur wegen einer Weiterleitung sein. :)
 
Das liegt definitiv an Weiterleitungen, was ja auch ein bekanntes Problem von SPF ist. Ich verwende aus diesem Grund nur Softfail, dafür zusätzlich DKIM und DMARC. Weiterleitungen bleiben ja DKIM-signiert und werden dann nicht abgewiesen.
 
Diese wurden nicht direkt angeschrieben nein, direkt an Gmail komm ich durch.

Ja Weiterleitungen sind ein Krampf, aber halt echt noch überal zu finden, daher wäre ich für Vorschläge offen, wie ich die Weitergeleiteten Mails zugestellt bekomme. Klar, ich könnte einen Softfail einbauen, aber das ist irgendwie auch nicht Sinn der Sache.

Edit: Timing :D

Wollte eigentlich DKIM erst später angehen wenn ich Zeit finde, weil da noch mehr Leute dann beteiligt sind, aber naja.. wird wohl doch früher als Gedacht kommen und ich werd uns mal richtung Softfail und DKIM treibe. Danke auf jeden Fall euch allen!
 
Zensai schrieb:
Wollte eigentlich DKIM erst später angehen wenn ich Zeit finde, weil da noch mehr Leute dann beteiligt sind, aber naja..
Der Schritt DKIM sollte einfach und unkompliziert sein und es besteht ohne DMARC-Policy keine Gefahr, dass Mails abgewiesen werden. Bei Exchange Online habe ich das schon gemacht, IONOS kenne ich persönlich nicht.
 
Ich kriege für die Versender-E-Mail-Adresse (81.169.146.147, gehört eigentlich auch Strato) keinen passenden SPF-Eintrag aus _spf.kundenserver.de – bist du sicher, dass die Angaben richtig sind?

1693821755507.png


Oder hast du den Hostname auch unkenntlich gemacht?
 
Zuletzt bearbeitet:
Zensai schrieb:
Verein.com ist NICHT die richtige Domain :)

Anhang anzeigen 1393472

Ich meine nicht verein.com, sondern die anderen beiden Angaben. Bei SPF wird die Versender-IP (in deinem Text oben 81.169.146.147) gegen die im SPF-Record enthaltenen Listen gecheckt, und du hast ja _spf.kundenserver.de als Quelle angegeben. Und der SPF-Record deckt diese IP halt nicht ab, deswegen die Frage, ob auch _spf.kundenserver.de ausgedacht ist. Weil wenn nicht, liegt das Problem da.

Mein Screenshot oben sind die aktuellen zugelassenen IP-Bereiche im SPF-Record von _spf.kundenserver.de. Und darin ist 81.169.146.147 nicht abgedeckt.
 
Ja genau, dann sind wir uns ja einig. :) Das liegt eben an der Weiterleitung, Kundenserver.de ist IONOS und Outlook.com ist ExO. Die genannte IP ist eben Strato. die natürlich nicht im SPF stehen, eben weil ich ja nicht via Strato versende, sondern es eine Weiterleitung im Zielpostfach ist.
 
Strato und IONOS teilen sich viel Mail-Infrastruktur.

Lösung deines konkreten Problems, wenn es sich bei deiner zitierten Mail um eine von tatsächlich von dir (oder einem anderen vertrauenswürdigen Absender) versendete E-Mail handelt, wäre die Ergänzung von include:_spf.strato.com in deinem SPF-Record, denn darin ist unter anderem die abgelehnte IP aus deinem Beispiel enthalten (über ip4:81.169.146.128/25).

Wenn der Empfänger der E-Mail wirklich die in der Rückmeldung angegebene Gmail-Adresse war (ich weiß, du hast sie hier fürs Forum verfälscht), dann ist es extrem unwahrscheinlich, dass vorher noch eine Weiterleitung auf der anderen Seite via Strato stattfand. Die Rückmeldung kam ja auch direkt vom Google-Server und der lehnt die Sender-IP (die zu Strato gehört) ab, weil sie in deinem Domain-SPF-Eintrag nicht abgedeckt ist. Ich sehe da also keinen Anlass, von irgendeiner Weiterleitungsproblematik auszugehen.

Ich habe mit dem Thema schon einige Erfahrung, ich greife zum Beispiel extra auf SRS via easydns zurück für meine Catch-All-Adressen bei Google Workspace, denn selbst bei diesem Google-"internen" Routing schlägt SPF fehl, allerdings geht das dann auch aus der Fehlermeldung hervor, genau wie in deinem Beispiel, in dem es offenkundig nicht an einer Weiterleitung liegt. Aber wenn du eh auf Softfail und DMARC umsteigen wolltest, why not?
Ergänzung ()

Zensai schrieb:
sondern es eine Weiterleitung im Zielpostfach ist.

Aber ich wäre trotzdem gespannt, wie du diese Konstellation erklären möchtest, also dass du von IONOS eine E-Mail an ein @gmail.com-Postfach schickst und dann eine Rückmeldung von ebendiesem Gmail-Server erhältst, in der dann steht, dass eine STRATO-Absenderadresse (die du für die "verfälschende" Zwischenstelle hältst) nicht autorisiert ist, deine Domain zu verwenden. Wie soll die angebliche Zwischenstelle STRATO da irgendwas manipulieren, wenn die erste Stelle, die etwas verfälschen/weiterleiten könnte, Gmail ist?
 
Zuletzt bearbeitet:
Ich glaube, du verstehst mich immernoch falsch.

Außerdem glaub ich dass wir das schon richtig erfasst haben, aber ich will trotzdem für Klarheit sorgen.

Ich sende nicht direkt an eine Gmail Adresse, das funktioniert wunderbar.

Machen wir ein Fallbeispiel:
Einfacher Newsletter, ich bin Verein.com bei IONOS und will unternehmen.com erreichen.
(Email send rates/greylisting/Spamschutz etc außen vor).
Der Verein.com SPF:
Code:
v=spf1 include:spf.protection.outlook.com include:_spf.kundenserver.de -all

Ich sende also über den IONOS Webmailer von x.y@verein.com meinen Newsletter an info@unternehmen.com.
Auf diese Email kommt ein NDR von Strato zurück, der besagt "Google Mailserver meldet: Email an Eigentümer@gmail.com konnte nicht zugestellt werden, weil die IP des Quellservers 81.169.146.147 (ein Strato Server) nicht mit dem SPF von Verein.com zusammenpasst."

Das legt Nahe, dass der Adminstrator von Unternehmen.com eine permanente Weiterleitung des info@unternehmen.com-Postfachs zu Eigentümer@gmail.com eingerichtet hat.
Die Mail geht also mit unverändertem Absender von Ionos zu Strato, dann über die Weiterleitung zu Gmail. Und genau bei dieser Weiterleitung bleibt der absender ja verein.com, aber der Quellserver der Mail ist für Google eben eine Strato IP, und da greift mein Hard fail.

Google weist folglich die Mail ab, Strato generiert einen NDR "Konnte nicht zustellen" und sendet den widerum wieder zu mir.

P.S.: In meinen SPF kommen nur die Server, die auch mit meiner DOmain senden sollen, ich kann ja nicht jeden Hoster da eintragen, nur weil irgendein Unternehmen was ich erreichen will, Hoster x oder Y oder Z nutzt und dann weiterleitungen einrichtet, weil sie nicht das Unternehmenspostfach direkt prüfen wollen.
 
Zensai schrieb:
Ich sende also über den IONOS Webmailer von x.y@verein.com meinen Newsletter an info@unternehmen.com.
Auf diese Email kommt ein NDR von Strato zurück, der besagt "Google Mailserver meldet: Email an Eigentümer@gmail.com konnte nicht zugestellt werden, weil die IP des Quellservers 81.169.146.147 (ein Strato Server) nicht mit dem SPF von Verein.com zusammenpasst."

Das legt Nahe, dass der Adminstrator von Unternehmen.com eine permanente Weiterleitung des info@unternehmen.com-Postfachs zu Eigentümer@gmail.com eingerichtet hat.
Die Mail geht also mit unverändertem Absender von Ionos zu Strato, dann über die Weiterleitung zu Gmail. Und genau bei dieser Weiterleitung bleibt der absender ja verein.com, aber der Quellserver der Mail ist für Google eben eine Strato IP, und da greift mein Hard fail.

Google weist folglich die Mail ab, Strato generiert einen NDR "Konnte nicht zustellen" und sendet den widerum wieder zu mir.

P.S.: In meinen SPF kommen nur die Server, die auch mit meiner DOmain senden sollen, ich kann ja nicht jeden Hoster da eintragen, nur weil irgendein Unternehmen was ich erreichen will, Hoster x oder Y oder Z nutzt und dann weiterleitungen einrichtet, weil sie nicht das Unternehmenspostfach direkt prüfen wollen.

Ah ok, dass die Mail gar nicht an diese gmail-Adresse als Adressat geschickt wurde, hatte ich ursprünglich nicht so verstanden (jetzt beim Nachlesen schon). Ja, dann hast du natürlich Recht, dass du nicht irgendwelche Hosts ergänzt, die nicht dazugehören :-). Und da lässt sich dann wohl mit SPF auch nix mehr machen. Ist ein Empfängerproblem. Klassiker. :-(
 
Zurück
Oben