SPF-Fehler - Mail abgelehnt

Da es ja immer angedeutet wird, mein System wäre irgendwie falsch oder SPF bzw. DKIM sei so wichtig, nun mal eine Frage dazu.

Wie ist denn damit umzugehen?

Mail delivery failed: returning message to sender

  websxxxx@gmail.com
    (ultimately generated from skiclub@xxxxration.ch)
    host gmail-smtp-in.l.google.com [74.125.133.xx]
    SMTP error from remote mail server after pipelined end of data:
    550-5.7.26 The MAIL FROM domain [belegungskalenderxxxx] has an SPF
    550-5.7.26 record with a hard fail policy (-all) but it fails to pass SPF
    550-5.7.26 checks with the ip: [80.67.18.xx]. To best protect our users from
    550-5.7.26 spam and phishing, the message has been blocked. Please visit
    550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more
    550 5.7.26 information. g6-20020a05600c4ec600b114fbc7e32811si8292183wmq.42 - gsmtp

Mein System (Belegungskalender) verschickt also eine Mail. Diese geht an eine Adresse der Schweiz (Skiclub). Diese leiten dann irgendwie weiter an eine Adresse von Gmail. So, nun prüft da wohl Gmail den SPF (ist doch Gmail, der prüft, oder?) Die IP, für die geprüft wird, ist die 80.67.18.xx. Diese gehört zu "Host Europe", ist deren Mailserver. Diese hat mit mir und meinem SPF nichts zu tun, folglich ist das falsch und "hard fail".

Der Bounce kommt zurück von "ispgateway", also Host Europe. Wer prüft da denn nun genau was und wie und warum wird da gegen meine SPF eine IP geprüft, die ich gar nicht habe und mir nicht gehört?

Müsste nicht eigentlich die "ch-Adresse", also der Mailserver von Host Europe den SPF von mir prüfen und dann, nach der Weiterleitung, Gmail den SPF von der "ch" bzw. Host Europe als Weiterleiter??? Hier wird aber, wie erwähnt, die IP des Mailsservers von der ch-Domain gegen meinen Domainnamen geprüft. Das kann natürlich nicht funktionieren, denn HE ist in meinen SPF nicht als Sender freigegeben. Warum auch, ist ja nicht mein Mailserver.

So. vielleicht kann das ja einer erklären. Alex? Wäre ja alles so wichtig etc. Das Problem da habe ich ständig, auch mit T-Online und Web.de, wenn da Mails weitergeleitet werden.

So, und wenn man ein wenig sucht, dann landet man unter anderem auch im Forum von DomainFactory. Dort gibt es einen Thread mit 7 Seiten und genau dem gleichen Problem, allerdings schon über einem Jahr alt:

Huch, nicht wahr? Das ist die gleiche IP, wie bei mir in der Meldung.

Und die Lösung, die die Mods dort empfehlen ist entweder, bei seiner eigenen Domain den SPF auch für MX von domainfactory zu erweitern oder den "hard fail" zu entfernen oder "keine Weiterleitung" zu nutzen. Die beiden ersten Sachen kommen für mich nicht in Frage und die dritte Möglicheit obliegt nicht mir. Ich habe nur das Problem, dass meine Mails nicht ankommen, genau wegen dem SPF und weil da eben Original-Sender-Domain mit einer fremden Mailserver-IP verglichen wird.

Es wird ganz normal per SMPT über meinen Mailserver gesendet. Der Mailserver bzw. die entsprechende Domain hat einen SPF, der explizit meinen Mail-Server per Name, allgemein meine MX als auch meine A-Records freigibt. Also alles richtig.

HE leitet die Mail dann weiter und Google prüft dann den SPF, aber eben den SPF meiner Absender-Domain GEGEN die IP von HE. Und klar, in meinem SPF steht die IP von HE nicht als berechtigt drinnen, warum auch?

Und nein, kein Fake. Die Mail wurde um 9:57 verschickt, an die ch-Adresse und um 9:57 Uhr kam ebenfalls der Fehler direkt zurück, von:

Received: from [80.67.18.34] (helo=mx17.ispgateway.de). Der Bounce selbst ist aber von Google (host gmail-smtp-in.l.google.com [74.125.133.xx]). HE reicht den dann wohl durch.

Ich glaube kaum, dass das alles Spammer sind, die Bounce-Mails faken und dann ein Support-Ticket öffnen oder anrufen, weil sie auf eine Mail warten.

Aber wie gesagt. Es wird nicht meine IP mit meinem SPF verglichen, sondern die IP von HE mit meinem SPF.

Schicke ich direkt an die Adresse von Google geht das. Nur mit der Weiterleitung nicht und das haben eben sehr viele Nutzer und ich kann als Sender nicht wissen, ob das Ziel weiterleitet oder nicht.

Habe ich doch schon in einem anderen Fred mal geschrieben. Mit 1und1 ebenso, wenn eine Weiterleitung da ist. Da kommt dann der DKIM-Bereicht zurück, dass eine Mail abgelehnt wurde, weil die IP nicht zugelassen ist. Auch dort immer, das ist nicht meine IP, sondern eine von einem 1und1-Mail-Server, der (wohl) weiterleitet. Sieht man dort im Bericht ja nicht, nur eben, dass das nicht meine IP ist und daher eben "fail".

Die scheinen also alle in "meinem Namen" weiterzuleiten, was dann das Ziel veranlasst, meine Sender-Domain mit der IP des Mailservers zu vergleichen. Aber der Mail-Server ist dann halt nicht meiner, somit eben falsch.

So, wie schon gesagt, das Spiel geht die ganze Zeit so. Diesmal kam drei per DMARC zurück, Grund auch dort SPF falsch.

Das war ein Kennwort-Reset von einer Kundin. Auch hier, Sender-Domain und SPF ist mein System, also richtig. Geprüft wird aber gegen die IP des weiterleitenden Mailservers und das ist in dem Fall Alfahosting. Hier ging die Mail per Weiterleitung von einer Domain-Adresse des Kunden an T-Online. Hier kam nur kein Bounce von T-Online oder Alfahosting, sondern einfach der DMARC-Bericht.

Hier dann noch mal. Gleiche Kunde, zweiter Versuch des Resets. Ging natürlich auch nicht. Anderes Mail-Relay, aber wieder Alfahosting nach T-Online.

Und hier Nummer drei vom gleichen Tag. Das war eine Weiterleitung über Host Europa nach Gmail. Also exakt das gleiche wie im ersten Post oben, nur andere Adressen und anderer Kunde.

Die gefühlt 50 anderen Mails in dem Report waren alle korrekt und "pass". Alle mit meiner Domain, meinem SPF und meiner IP (v4 oder v6). Nur in diesen Weiterleitungen wird ständig die falsche IP mit dem falschen Sender verglichen.

Ich habe Kunden, die eine Mail von Ihrer Domain haben. So wie eigentlich jeder. Diese Kunden leiten die Mails aber weiter an z.B. T-Online oder gmail. Schrieb ich nun doch schon mehrfach.

Mein System sendet an -> email@domain.de (z.B. von Host Europe - ISPGateway)

Dieser Mailserver leitet dann weiter an name@gmail.com

Gmail prüft nun den SPF, wie oben ersichtlich. Gmail nimmt also MEINE Sender-Domain und prüft, ob die IP des weiterleitenden Mailservers (von Host Europe - ISPGateway) berechtigt ist. Was sie nicht ist. Logisch. Schließlich stehen die Mailserver von ISPGateway NICHT IN MEINEM SPF.

Siehe oben. Es wird die IP von ISPGateway gegen den SPF von meiner Domain verglichen. Nicht meine Domain gegen meine IP und nicht ISP-Domain gegen ISP-IP, sondern deren ISP-IP gegen meine Domain.

"Warum sendest nicht direkt an T-Online?"

Weil ich das nicht weiß! Wenn sich einer anmeldet oder die Adresse ändert in neue-adresse@webseite.de, dann weiß ich doch nicht, ob der die Adresse bei sich nochmal weiterleitet? Woher soll ich das denn wissen? Gibt auch genug, die im Urlaub Adressen umleiten. Das weiß doch der Sender nicht. Erst, wenn die Mail zurückkommt. Ich weiß doch auch nicht, wenn Du Deine Emails weiterleitest, ich schreibe an die gleiche wie vorher auch. Meine "gmx-Adresse" leitet auch weiter. Müsste ich nun also auch fragen, warum Du das nicht weißt. Logisch, weil das ja nicht im Bereich des Senders liegt, was der Empfänger damit macht.

Ich weiß auch nicht, was es da immer zum nachhaken gibt. Also nochmal....

Ich sende eine Mail. Absender sender@sender.de

Diese Mail geht an kunde@kunde.de

Der Kunde leitet die Mail aber weiter an google@gmail.de

Jetzt bekomme ich von Gmail den Bounce, SPF falsch.

Klar, ich weiß ja was passiert, nur nicht warum.

Schicke ich die Mail raus, dann ist das:

Original-Sender: Meine Domain / Email

IP: Meine IP

Schickt der Mailserver dazwischen die weiter, denn steht im Header

Sender: Meine Domain / Email

IP: Die des Mailservers, der weiterleitet

Google hat dann: Sender = meine Domain / Email, IP = weiterleitende Mailserver

Also fragt Google mein SPF ab. Den Record, den Du oben nanntest. Logisch, mein SPF, ist ja auch meine Domain und meine Email. Aber es wird nicht mit meiner Original-IP verglichen, sondern mit der des Mailsystems dazwischen, denn dort steht ja deren IP drinnen, denn die leiteten ja weiter.

Es kann doch nicht so schwer sein.

Mein SPF hat nichts mit dem Mailserver von ISP zu tun. Und die IP von ISP hat nichts mit mir zu tun. Google und die anderen prüfen aber mein SPF mit der IP von ISP.

Alex, nimm nicht mein SPF auseinander, das Ding stimmt und ist 100% korrekt.

Diese "+" bei a oder mx braucht man nicht, denn wenn kein "-" angegeben ist, ist alles automatisch +, das ist der Defaultwert.

Dein "a mx" ist nichts anderes als meins. Ich habe Freigabe für "mx", eben alle, die im DNS hinterlegt sind, so wie Du und extra eine Freigabe für gb80. Ja, der Host stimmt, ist 1000% korrekt. Der steht da drinnen, weil es eben bei den ganzen Domainumzügen auch einen gb70 und gb90 gab, die andere IPs auf einem anderen Mailserver waren. Spielt aber keine Rolle. Wenn man das SPF auflöst, dann hat man den doppelt. Einmal über den reinen "mx" und einmal über den "mx:gb80". Die lösen beide zur gleichen Stelle auf, sind identisch.

Auch die Angaben von "ipvX" sind richtig. Man kann das als "a" angeben, also alle A-Records, die im DNS hinterlegt sind oder eben steuern, welche IPs man will. In meinem Fall eine v4 und eine v6. Und nicht alle "a-Records", denn nicht alle IPs werden vom Mailserver genutzt. Oder eben, auch wegen Umzügen, dass die Systeme dann ja teilweise physisch getrennt sind und so eben explizit gesagt wird, die und die IP ist erlaubt. Umgeht das Problem, dass DNS 24 Stunden braucht, bis es durch ist.

Das da bingt so gesehen auch keine Lösung, bzw. nur indirekt:

"v=spf1 +a +mx +a:gb80.ferien-netzwerk.de ~all"

Wenn Google da nun wieder die IP "80.67.18.xx" gegen abfragt, ist das wieder falsch, denn die 80.67.18.xx gehört ja nicht mir. Das ist weder ein A noch ein MX, noch ein sonstwas Record von mir. Die gehört Host Europe!

550-5.7.26 checks with the ip: [80.67.18.xx]

Aber ja, das Problem kann umgangen werden, nicht gelöst, mit "~all". Schrieb ich ja schon ganz oben, das ist einer der drei Lösungsvorschläge von Host Europe:

"oder den "hard fail" zu entfernen"

Das kommt nicht in Frage, denn das löst "Spam-Probleme" bei anderen aus. Für die ist das "~all" nämlich schlicht also ob da gar kein SPF-Eintrag wäre.

Bleibt also immer noch die eigentliche Frage:

Es sind ja drei Systeme beteiligt

1. Ich als Sender

2. Der Mailserver der weiterleitet

3. Google als Zielserver

Warum prüft Google die IP von 2 gegen den SPF von 1? Oder andersrum. Warum leitet Host Europe die Mail in meinem Namen 1, aber mit seiner IP 2 weiter?

Es gibt ja die Original-Sender-Domain. Die bin ich. Die bleibt auch gleich, auch nach der Weiterleitung. Was da aber irgendwie fehlt ist eine "Original-Sender-IP". Das wäre auch ich und somit alles gut. Vergleich wäre dann 1 mit 1. Aber nach der Weiterleitung steht da dann eben die IP von Host Europe drinnen und somit ist es ein Vergleich 1 mit 2.

Das hat also nichts mit MEINEM SPF zu tun. Das wäre bei Dir genau das gleiche.

Wenn Du von der mail@seo-nw. eine Mail an die Adresse schickst, die ich auch verwendete, dann prüft Google die IP von HE gegen Dein SPF per

550-5.7.26 checks with the ip: [80.67.18.xx]

und auch da. Diese IP steht nicht in Deinem SPF, warum auch. Also "fail". Das ist das gleiche wie bei mir. Die IP steht weder bei Dir noch bei mir drinnen. In beiden Fällen ist das ein fremdes System. Und genau dazu ist SPF ja gedacht, dass ein fremder Sender abgelehnt wird. Nur warum ist das nur bei einzelnen Anbietern so? Also vor allem bei Host Europe und T-Online oder eben neu, Alfahosting. Bei anderen, wo auch Weiterleitungen sind, Yahoo, MSN, Gmx etc, geht das problemlos. Da kommt nix zurück.