Also ich habe mal kurz mit meinem Kollegen (KI) gesprochen der sagt:
Der entscheidende Fehler ist hier:
Zitat
550 5.7.509 Access denied, sending domain versender.invalid does not pass DMARC verification and has a DMARC policy of reject.
Das bedeutet:
- Die Empfängerseite (Microsoft 365 / Outlook) hat die Mail wegen fehlgeschlagener DMARC-Prüfung abgelehnt.
- Obwohl die Mail ursprünglich bei Strato offenbar korrekt signiert war, ist die Authentifizierung unterwegs kaputtgegangen.
Die relevanten Zeilen sind:
- ursprünglich bei Strato:
- spf=pass
- dkim=pass
- dmarc=pass
aber später bei Microsoft:
- spf=fail
- dkim=fail (body hash did not verify)
- dmarc=fail
- compauth=fail
Das zeigt ziemlich klar:
Die Mail wurde nach dem DKIM-Signieren verändert oder über einen Server geleitet, der die Authentifizierung beschädigt hat.
Wichtig ist diese Kette:
smtp.strato.de
→ mo4-p00-ob.smtp.rzone.de
→ mail.ispmail.de
→ Microsoft 365
Der problematische Hop ist sehr wahrscheinlich:
mail.ispmail.de (195.185.212.45)
Denn dort schlägt plötzlich SPF fehl und DKIM wird ungültig.
Mögliche Ursachen
1. Mailserver verändert den Body (sehr wahrscheinlich)
DKIM meldet:
dkim=fail (body hash did not verify)
Das passiert typischerweise wenn:
- Disclaimer angehängt werden
- MIME-Struktur verändert wird
- Attachments umcodiert werden
- Zeilenumbrüche geändert werden
- Antivirus/Spamfilter Inhalte modifizieren
Rspamd/Postfix-Gateways sind dafür bekannte Kandidaten.
2. Falscher SMTP-Relay
SPF sagt:
domain of versender.invalid does not designate 195.185.212.45 as permitted sender
Das heißt:
- Der empfangende Server sieht mail.ispmail.de als tatsächlichen Sender.
- Diese IP steht aber offenbar nicht im SPF der Domain.
Wenn mail.ispmail.de ein eigenes Relay/Gateway ist, muss dessen IP entweder:
- im SPF stehen
oder - die Mail unverändert weiterleiten und DKIM intakt lassen.
Momentan passiert beides nicht.
3. ARC-Kette ungültig
Zusätzlich:
ARC sollte eigentlich Authentifizierungsergebnisse „retten“ bei Weiterleitungen. Funktioniert hier aber ebenfalls nicht.
Wahrscheinlich ist die ARC-Implementierung auf dem Zwischenserver fehlerhaft oder unvollständig.
Was du prüfen solltest
Wenn mail.ispmail.de dein eigener Server ist
Dann:
A) Keine Mailmodifikation nach DKIM
Prüfen:
- Disclaimer deaktivieren
- MIME-Rewriting deaktivieren
- Antivirus/Spamfilter testen
- Rspamd-Milter prüfen
Insbesondere:
- mime modification
- add footer
- force reencode
B) SPF erweitern
Die IP:
muss ggf. in den SPF der Domain aufgenommen werden.
Beispiel:
v=spf1 ip4:195.185.212.45 include:_spf.strato.com -all
(abhängig vom tatsächlichen Setup)
C) DKIM nach dem letzten verändernden Hop signieren
Falls mail.ispmail.de Inhalte verändert, muss:
- dort neu DKIM-signiert werden
- mit d=versender.invalid
Wenn das nur ein Weiterleitungsserver ist
Dann solltest du:
- SRS (Sender Rewriting Scheme) aktivieren
- ARC korrekt konfigurieren
- möglichst keine Inhaltsänderungen durchführen
Warum es früher evtl. funktioniert hat
Microsoft 365 ist seit 2024/2025 deutlich strenger geworden bei:
- DMARC reject
- SPF alignment
- ARC validation
- CompAuth
Besonders bei:
- Weiterleitungen
- Mailinglisten
- Relayservern
- selbst betriebenen Gateways
Kurzdiagnose
Die Mail war beim Versand korrekt authentifiziert, wurde aber auf mail.ispmail.de so verändert oder weitergeleitet, dass:
- DKIM ungültig wurde
- SPF nicht mehr passte
- dadurch DMARC scheiterte
- Microsoft die Mail wegen p=reject endgültig abgelehnt hat
Der wahrscheinlichste Fix:
- keine Veränderung der Mail auf mail.ispmail.de
oder - dort korrekt neu DKIM-signieren + SPF sauber konfigurieren.