Nutzer können E-Mails über Microsoft 365 (Relay) an externe Empfänger versenden, wenn Sie einen Microsoft 365-Tenant haben. Dies erspart es, einen (kostenpflichtigen) SMTP-Relay-Dienst eines Drittanbieters verwenden. Jemand hat in einem Artikel beschrieben, wie sich ein SMTP-Relay in Microsoft 365 einrichten lässt.
Ich bin die Tage auf nachfolgenden Tweet gestoßen, der sich mit der betreffenden Frage befasst. Das Ganze wird im Beitrag How to Set up SMTP relay in Microsoft 365 auf o365info.com beschrieben.
Dieser Beitrag wurde unter
Cloud,
Mail abgelegt und mit
Cloud,
Mail,
Microsoft 365 verschlagwortet. Setze ein Lesezeichen auf den
Permalink.
Passender wäre der Titel:
HowTo: Ein SPAM-Relay in Microsoft 365 aufsetzen
Bei mir wird aufn Mailserver ganze Google und Microsoft Relay Kram hart abgestraft und direkt als Spam geflaggt, da kommt soviel Müll für S*x und Cryto Kram.
Professionelle Versender haben auch 1€ über für anständigen Anbieter. ;-)
Diese Aussage ist so formuliert übelste Polemik.
In größeren Organisationen gibt es viele Gründe, Mails an mehr als nur einem Punkt zu generieren. Ob das nun Niederlassungen sind, spezielle Monitoring-Systeme außerhalb der Kern-IT, Leute im Homeoffice oder etwa – ganz aktuell – Gateways für die ab 1.1.2025 verpflichtende elektronische Rechnung (ZUGFeRD).
Technisch macht es sehr viel Sinn, alle diese Mails eines Unternehmens zu bündeln und über ein (oder nur eine kleine Anzahl von) Relais zu senden.
Das fängt bei Anti-Spam-Maßnahmen wie SPF (wo man diese "permitteten" Sender auflisten muß") an und hört bei Filtern, die etwa prüfen ob die gesetzlichen Pflichtangaben in der Fußzeile enthalten und und diese gegebenenfalls ergänzen noch lange nicht auf. DANE mit DNSSEC hatten wir gerade im Blog.
Inzwischen bieten auch alle Massenmailer wie etwa T-Online oder GMX ein SMTP-Relay an, ein direktes Versenden von Deinem Rechner direkt an Port 25 des Empfängers dürfte allein schon daran scheitern, daß praktisch niemand mehr Mail von IPs aus dem sogenannten "Dialup-Bereich" von DSL-Nutzern annimmt. Bei vielen Anbietern (gerade erst bei T-Online gehabt) ist man inzwischen von Black- zu expliziten Whitelists für SMTP-Server übergegangen.
Bei Microsoft habe ich sogar eine Nachrichtenablaufverfolgung, mit der ich bei Bedarf gerichtsfest nachweisen kann, daß eine bestimmte Mail zu einem bestimmten Zeitpunkt 'rausgegangen ist und der Empfänger sie auf einem Server in seiner Verantwortung (mit einer dann auch noch mitgeloggten Begründung) abgelehnt hat.
Kann man machen, aber wenn Dich etwa Dein Flugticket oder Deine Konzernkarte nicht pünktlich erreicht, hast Du erst mal die Arschkarte.
Gibt genug andere Anbieter wo man versenden kann, der Internetanbieter stellt oft Postfächer bereit, Domain/Webhosting Anbieter ebenfalls, und sonst gibts auch Anbieter wie Mailbox_org oder Posteo ab 1€ ohne Werbung, ohne US Cloud, aufgedrängten Abos usw.. Oder man betreibt als Unternehmen selbst einen Mailserver, bisschen postfix und dovecot ist kein Voodoo. Und wenn es zu kompliziert ist, gibt da auch noch Lösungen wie Mailcow, MailPlus, usw., ne VM oder Root Server bekommt man oft auch hinterhergeworfen.
Wenn man schaut wie oft MS hier im Blog erwähnt wird mit Ausfällen, Sicherheitsproblemen usw…. wäre als Unternehmen auch MS meine erste Wahl…
Bestätigung für zustellen der Nachricht kann man auch im Client einrichten seit Jahrzehnten, dafür muss man nicht zwingend auf MS setzen. Und wenn man eigenen Server betreibt hätte man Alternativ auch noch Logs wo man sich sein "250 ok" rausziehen kann.
Bin nur kleiner privater Betreiber, und da kommt meiste Spam eben von den beiden genannten, da diese leider nicht konsequent auf Blacklisten lange geführt werden.
Und wenn doch, jammern manche Firmen dass beim Kunden Mails nicht ankommen.
Da wird auch nicht Unterschieden, dass man z.B. neue Accounts auf bestimmte Server beschränkt welche problematisch sein können auf Blacklisten, und nach ner Zeit ohne Auffälligkeiten auf andere Server mit besserer Reputation.
Muss jeder für sich selbst wissen, Optionen gibt es genug. Spätestens für Massenmails wie Newsletter usw. sollte man eh andere Anbieter oder zumindest mit anderer Subdomain/Domain versenden.
Deine Meinung in allen Ehren – ich habe selbst viele Jahre Mailserver mit Postfix, Cyrus und OpenXchange betrieben. Und ja, am Anfang spielte da auch eine bei Strato gehostete Domain nebst deren SMTP-Relayserver eine Rolle.
Nur ist alleine das Thema Spamabwehr in letzter Zeit sehr komplex geworden, zu einem gewissen Teil ist es inzwischen schon Voodoo, weil sich keiner in die Karten schauen läßt (Geschäftsgeheimnis), nach welchen Kriterien (Filterausdrücke, Black-/Whitelists oder so weiche Kriterien wie "Anzahl der Links im Mail-Body") er nun gerade filtert.
Unser Wechsel zu Microsoft kam weniger über die Mail-Schiene, sondern weil wir plötzlich mit Corona konfrontiert waren und hunderte Mitarbeiter im Homeoffice saßen. Da mußte eine Kollaborationslösung her und Teams stieß genau in diese Lücke. Sicherlich gab es zu dieser Zeit einen ganzen Strauß ähnlich gestrickter Lösungen, in der Rückschau haben aber die wenigsten davon überlebt. Teams ist stärker geworden, was mich im Nachhinein in dieser Entscheidung bestätigt.
Dazu kommt, daß die meisten unserer Kunden und Lieferanten ebenfalls in diese Richtung gewechselt sind (als Maschinenbauer spielen Endkunden für uns kaum eine Rolle, das meiste ist B2B), was viele Formen der Kollaboration (beispielsweise einen Externen mal schnell als Gast in ein Team aufnehmen oder vertrauliche Dokumente per Sharepoint statt Mail teilen) deutlich leichter macht.
Auch privat kommt man da inzwischen kaum noch vorbei. Ich habe letztes Jahr für den Urlaub Tickets bei einer großen arabischen Fluggesellschaft gebucht – deren Kommunikation (Tickets, Rechnung, Sitzplatzreservierung usw) kommt praktisch alles über die MS-Cloud.
Was soll ich jetzt tun – die ignorieren und für einen deutlichen Aufpreis bei Lufthansa buchen? Auch bei Arzt kann ich es mir nicht aussuchen, ob er M365 verwendet oder vielleicht eine FritzBox an der Wand hängen hat – ich gehe wegen der Behandlung dort hin.
Im Großen und ganzen läuft es recht stabil, mit "ner VM oder Root Server" (been there, done that) habe ich deutlich weniger Redundanz und im Endeffekt sogar weit mehr Arbeit und Verantwortung für die sichere Konfiguration.
Früher hätte ich bei einem Ausfall das ganze Wochenende rotiert, heute werde ich dagegen mal das schöne Wetter nutzen und ins Schwimmbad gehen – etwas gegen die Störung tun kann ich eh nicht.
Gibt da auch andere Lösungen, ich für mich bevorzuge da z.B. Synology NAS, alles lokal unter Kontrolle an Daten, kein Abo, keine US Dienste/Server. Kostenlose Backupoption sämtlicher PC´s/Mac´s usw.
Cloudoption, einfaches "Office" Paket zum zusammenarbeiten, LDAP/AD Server, interner Chat, usw. alles mögliche da.
Aber hey jeder wie er mag, wenn man lieber Lizenzen bezahlt für US Server Dienste nur zu, und sich von denen Abhängig machen möchte. Hat jeder andere Präferenzen.
Fehlt nur noch ne high end IP Kamera von Temu für 5-20€ und per FTP alles dann in OneDrive… ^^ ;-)
Inhaltlich bin ich da näher bei Dir, als Du vielleicht glaubst.
Nur muß man halt immer aufpassen, daß Idealismus nicht irgendwann in Ideologie umschlägt, die einem den Blick auf die Realitäten nimmt.
Als ich hier in den 90er und Nuller Jahren die IT aufgebaut habe (als Entwicklungsingenieur, Admin war man da allenfalls stundenweise nach Feierabend) habe ich tatsächlich sehr viel auf Open Source gesetzt. Office war ein OpenOffice (bis sich das Projekt dann selbst zerlegt hat und Libreoffice geforkt ist), mein bevorzugter Browser ist nach wie vor der Firefox (früher Netscape) und als Mailprogramm behalte ich den Thunderbird solange ich ihn noch irgendwie gegen die Cloud authentifiziert kriege.
Die erste Domain dieser Firma lief unter Samba 2, das erste AD unter Samba 3.
Nur ist es halt immer schwerer, Kollegen dafür zu begeistern. Wer in den Boomjahren frisch von der Hochschule zu uns gekommen ist kannte eben nur Outlook. Office sowie CAD-Programme und IDEs in der Windows-Version.
Inzwischen verantworte ich die IT eines mittelständischen Unternehmens mit hunderten Beschäftigten auf drei Kontinenten, da kann man sich nur sehr begrenzt Egotrips erlauben.
Wie wir zu Teams gekommen sind habe ich oben beschrieben, die anderen großen Alternativen (Zoom und Webex) fallen auch nicht gerade durch besonders hohe Sicherheitsstandards auf.
Den Postfix für die Mitarbeiter habe ich 2020 abgeschaltet (zum internen Gebrauch läuft er freilich noch), rechnet man den Qmail-Vorgänger dazu gab es ihn seit 2001.
Nur macht es halt für eine Kollaboration unwahrscheinlich viel Sinn, Mail, Kalender und die Office-Anwendungen in einem System zu haben.
Letztendlich muß ich dahin gehen, wo unsere Kunden mehrheitlich sind, Mails verlassen größtenteils diese Cloud nicht mehr und werden nur von Tenant zu Tenant ausgetauscht – ohne daß man sich über Microsofts Interpretation von RFCs streiten muß.
Selbstverständlich habe ich ein Backup aller Daten im Haus (wir verwenden Veeam für M365) und für Daten, die im Haus bleiben sollen betreibe ich eine eigene Nextcloud-Instanz (früher Owncloud).
Alles was für die Produktionsprozesse relevant ist liegt auf eigenen VMware-Servern (zukünftig vermutlich Proxmox) und nicht in einer Cloud.
Nur für Mail (gerade wegen der Spam-Problematik), Kollaboration mit anderen Kunden und natürlich Videokonferenzen müssen die Daten sowieso das Haus verlassen, da können sie auch gleich in der Cloud bei Microsoft liegen.
Als Speicherort haben wir übrigens "EU" gewählt und uns das (mit ein paar Einstellungen, die nicht Default sind) auch vom Datenschutzbeauftragten absegnen lassen.
Von dem "großen" Ausfall heute Vormittag haben wir nichts gemerkt – vermutlich war "unser" Speicherort nicht betroffen.
@Fritz: Deine geschilderte Infrastruktur basiert auf einer ausgewogenen und rationalen Entscheidung. Mehr kann man IMHO in einem deutschen mittelständischen Unternehmen nicht tun – es sei denn, man fühlt sich berufen, die Welt zu retten – und hat auch persönlich die Kraft und die Fähigkeit dazu.
Warte, Winzigweich ist kein anständiger Anbieter? Ich wusste das ja schon immer.
Hmm, deine armen Kunden.
Ich sehe das etwas differenzierter: der Mail-Provider des Absenders ist nur eine von vielen Eigenschaften, welche den SPAM-Level eines Mails beeinflussen. Wir blockieren nicht aufgrund irgendwelcher Vorlieben (oder Abneigungen) gesamte Provider. Damit fahren wir (und unsere Kunden) sehr gut.
Übrigens: die Anleitung besteht schon länger von seitens Microsoft: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365 > "Option 3"
Und bezüglich SPAM-Schleuder: wenn das korrekt eingerichtet wird, wird der Mailfluss per IP und/oder Zertifikat eingeschränkt. Da kann niemand Mails versenden, der nicht zugelassen ist.
Ich kann Dich verstehen. Privat habe ich sogar die ganzen MS Office ASN's via Firewall gesperrt. Die sehen meine Mailserver gar nicht erst.
Aber hey, es gibt tatsächlich Alternativen zu Microsoft, wie man an meinen Posteingängen sehen kann. :-D
@ExchangeOnline-Administratoren: Bitte beachten, dass MS angekündigt hat, ein Limit von 2000 Emails pro 24 h und pro cloud-hosted Mailbox für externe Empfänger einzuführen: https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-introduce-external-recipient-rate-limit/ba-p/4114733
Wenn also die Versandadresse wie rechnungsversand@ oder lieferschein@ oder kennwort-reset@ oder no-reply@ als Mailbox im Tenant angelegt ist, zählt MS die Emails.
Da man die Mailboxen wegen NDRs oder Antworten häufig in der Cloud anlegt, könnte das Limit schnell erreicht sein.
Nicht 2000 Mails sondern 2000 Empfänger, das ist ein wesentlicher Unterschied.
Generell ist festzuhalten dass Microsoft die letzen Monate dazu übergegangen ist, das Produkte welche User Lizenzen haben nur für User zu zulassen, und automatisches versenden usw. nur bei Produkten zu zulassen welche even dafür zugelassen sind.
Z.b. wurde schon angekündigt dass O365 SMTP ab kommenden Jahr nur noch via OAUTH funktioniert.
@squat0001: Deine Korrektur stimmt: Es sind 2000 Empfänger. 4 Emails mit je 500 Empfängern pro Email schöpfen das Limit aus. Oder nochmal anders gerechnet: 2000 Rechnungs-Emails mit je einem Empfänger erreichen auch das Limit.
Das bedeutet für mich aber, dass das Limit in der Praxis noch schneller erreicht ist als ich zuerst dachte.
Beispiel:
2000 Emails mit z.B. je 10 Empfänger = 20.000 Empfänger überschreitet das Empfängerlimit 2.000 deutlich.
Wie gesagt, der Dienst soll von Menschen genutzt werden. Für automatisch erzeugte Mails bietet Microsoft besser geeignete Dienste an.
Ich fürchte das geht ein bischen an der Realität deutscher Internet-Anschlüsse vorbei.
Hier wird wie selbstverständlich davon ausgegangen das man eine feste IP(v4)-Adresse hat…
Bei uns ist es in den meisten Fällen wohl einfacher dafür ein Relay-Postfach bei dem Provider einzurichten bei dem die Domain registriert ist.
Unsere Geschäftsanschlüsse haben alle eine feste IPv4-Adresse mit vernünftig eingerichtetem rDNS Eintrag. So der Mailserver nicht grundsätzlich im RZ steht, sondern on premises im Serverraum, kann der also direkt und ohne jedes Relay arbeiten. Und das ist, aus meiner Sicht, auch die notwendige Mindestvoraussetzung für den Betrieb eines Server on premises am DSL-Anschluss. Sind die nicht gegeben (aus welchem Grund auch immer), sollte man sich mal Gedanken machen, ob das alles so richtig ist, was man administriert und an Verträgen abgeschlossen hat.
Leider gibt es noch ein anderes Problem mit den SMTP Relays von O365. Microsoft macht einen Unterschied ob man eine Mail über ein Benutzerpostfach oder einem Drittsystem wie ein ERP, Monitoring oder ähnliches generiert. Die Drittsystem Mails werden dann ja von einer Trusted IP der eigenen Location an den MX von ExO gesendet und dort an den Empfänger ausgeliefert. Und hier ist der Unterschied, während diese Drittsystem Mails von einer MS IP gesendet werden, sind genau diese IPs nicht im SPF inkludiert für vertrauenswürdige Umgebungen. Damit kommen diese Mails gerne mal nicht an. Das Betrifft z.b. auch eine Weiterleitung von Mails über O365. Die Mails von Benutzerpostfächern, gehen wiederum von anderen MS IPs raus, die eine höhere Trust haben und von den SPF Records abgedeckt sind.
Die Einrichtung von Konnektoren ist sicherlich eine Wissenschaft für sich, aber von Microsoft auch gut dokumentiert:
https://learn.microsoft.com/de-de/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail
Solange man seine Domain nicht auch über Microsoft gebucht hat (geht das überhaupt?) ist man selbst für seinen SPF-Record verantwortlich und muß alle in Frage kommende Sender auflisten.
Bei uns sind das einfach zwei /28 (von der Telekom und einem weiteren Anbieter), einzelne feste IPs (Business DSL der Außenstellen) und ein "include:spf.protection.outlook.com", welches zu einer aktuellen Auflistung der von Microsoft verwendeten IPs führt.
Im Moment sind das: spf.protection.outlook.com. 200 IN TXT "v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"
Das ist mir wohl bewusst, wie man eine SPF Record für Microsoft einrichtet. Aber Microsoff packt bewusst nicht alle ihre Sender IPs in diesen SPF Record rein.
Mehr Details gibt es hier zu finden:
https://learn.microsoft.com/de-de/defender-office-365/outbound-spam-high-risk-delivery-pool-about?view=o365-worldwide#relay-pool
Microsoft isoliert diese Mails von Drittsystemen bewusst. Wir hatten dazu mal einen Fall mit einem Kunden von uns, der das MS System wie eine Mailinglist verwendet hatte und diese Mails dann von unserem MS 365 abgewiesen wurden. Trotz des Umstand, daß die Mail von einem ExO System kam, hat unser Tenant die Mail wegen eines SPF Fail abgelehnt. Damals kam die Mail aus dem Range 40.95.0.0/16 und war nicht in dem SPF Incl. spf.protection.outlook.com enthalten gewesen.
Prüfen wir mal, ob ein internes Relay zu ExO die Bedingungen von MS erfüllen kann:
The forwarded or relayed message should meet one of the following criteria to avoid using the relay pool:
1/ The outbound sender is in an accepted domain.
>> Das muss erfüllt sein, sonst nimmt ExO das zu relayende Email gar nicht an.
2/ SPF passes when the message comes to Microsoft 365.
>> Schon schwieriger zu erfüllen: Das interne Relay hat zwar eine public IP, aber es muss sichergestellt werden, dass der SPF-Record diese IP aufführt.
3/ DKIM on the sender domain passes when the message comes to Microsoft 365.
>> Für die meisten Relayserver wie Exchange on-prem, Windows SMTP daemon, hMailServer ist das NICHT zu erfüllen.
Liege ich da richtig?
Kannst Du mal genauer beschreiben, was Du meinst?
Das verlinkte Dokument listet genau zwei Fälle auf.
Möglichkeit 1:
Eine Mail von irgendwo anders her wird einfach 1:1 weitergeleitet. Insbesondere steht im From: keine Domain, die dem Tenant bei M365 entspricht. So interpretiere ich das "Der Kunde verwendet das System wie eine Mailingliste" und so kenne ich es auch von anderen Mailinglisten.
In diesem Fall hat der zum Tenant hinterlegte SPF freilich keine Auswirkung, es zählt der SPF der Domain des ursprünglichen Verfassers und die Mail sollte über den alternativen Relaypool gehen, was sie ja offensichtlich auch tut.
Möglichkeit 2:
Es kommt das Sender Rewriting Scheme SRS zum Einsatz: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
In diesem Fall wird der ursprüngliche Absender derart umgeschrieben, daß der Teil hinter dem "@" im "From:" doch wieder der Domain des Tenants entspricht, also z.B. "SRS0=HHH=TT=example.org=alice@example.com"
In diesem Fall wird die Mail ja im Namen des Tenants "example.com" verschickt, es greifen die Regeln z.B. bezüglich SPF und die Mail geht über den primären Relaypool.
@Fritz: Deine Erklärung ist verständlich und richtig für den Fall, dass eine von extern eingegangene Email weitergeleitet wird. In diesem Fall hat die ursprüngliche EMail im HeaderFrom=MFrom=P2 KEINE accepted domain.
Kannst Du mir erklären, mit welchem Pool das Email nach extern versendet wird, wenn es im HeaderFrom eine Accepted domain hat und über einen Inbound organization Connector von einem ERP-System in den Tenant gekommen ist?
(siehe meine Frage weiter oben: "Liege ich da richtig?")
Vorab: Ich habe keine tieferen Einblicke in die Microsoft Cloud und verfolge auch nicht regelmäßig, ob sich die Dokumente, nach denen ich es damals eingerichtet habe, inzwischen vielleicht geändert haben.
Bei uns läuft es so, daß wir eine Sophos UTM mit passender Lizenz (Mail Protection) einsetzen und alle ausgehende Mails von "accepted domains" über diese relayen.
Offizielle Mail geht immer mit einer Addresse der primären Firmendomain, keine Subdomain und auch kein Alias heraus und die sendende Adresse ist auch im M365-Tenant eingetragen, entweder als Benutzerpostfach (kostet halt was) oder als Alias bzw. Verteilerliste ohne Postfach (dann kostet es keine Lizenz).
Dazu gibt es bei uns einen Sendekonnektor auf Basis der IP-Adresse (wir haben bei zwei Anbietern, einer lokal und einer Telekom jeweils eine /28-Allokation, die dort eingetragen ist, mit einzelnen IPs müßte es aber genauso gehen) und ohne Zertifikatsbasierte Authentifizierung.
Zu Deinen Fragen:
1/ Ja – freilich. Notfalls (wenn die Mail mit irgendwas @intern kommt) schreibt die Sophos das um.
2/ Ja – klar. Einen SPF-Record zu schreiben ist kein Hexenwerk und es gibt Online-Tools, die die Syntax prüfen können. Es gibt einige Limits (z.B. Zahl der resultierenden DNS-Lookups), die man beachten muß.
3/ Auch das geht. Es ist nicht verboten, mehrere sogenannte Selektoren mit öffentlichen Schlüsseln im DNS zu hinterlegen. Einen gibt Microsoft bei der Einrichtung des Tenants bzw. Connectors vor, einen anderen die Sophos. Welcher ausgewählt wird entscheiden die Kopfzeilen der Mail, die Microsoft z.T. ersetzt.
Das Mailrelay erfüllt bei uns noch ein paar Sonderaufgaben – zum Beispiel eine Kopie aller Mails an ein internes DMS zu schicken oder die Fußzeile auf gesetzliche Pflichtangaben (Handelsregisternummer UST-ID…) zu prüfen und im Bedarfsfall einen definierten Footer zu ergänzen, das braucht hier aber keine Rolle zu spielen.
Nach meiner Beobachtung werden die Mails ausgehend über im obigen SPF-Record aufgelistete Microsoft-IPs, also wohl den primären Relaypool versendet.
Ich weiß, daß das überarbeitungsbedürftig ist (Microsoft wird bald zertifikatsbasierte Authentizierung erzwingen und die UTM ist bald EOL), aber das ist der heutige Stand.