Aktuell erreichen mich viele Anfragen zu Exchange Server und den Versand von Mails via IONOS. Zum 15.01.2024 stellt IONOS die Smarthost Funktion für IONOS Postfächer ein, dies heißt im Umkehrschluss: Exchange Server können IONOS nicht mehr als Smarthost verwenden. Weitere Informationen von IONOS gibt es hier:
Scheinbar gibt es recht viele Leute, die von dieser Abschaltung betroffen sind, daher hier mal ein kleiner Artikel zu dem Thema.
Welche Konfiguration ist betroffen?
Alle Exchange Server welche einen Sendeconnctor mit IONOS als Smarthost verwenden, sind von der Abschaltung der Smarthost Funktion betroffen. Hier mal ein Beispiel einer betroffenen Konfiguration mit smtp.ionos.de als Smarthost:
Konkret bedeutet dies, dass Exchange keine Mails mehr an Empfänger im Internet schicken kann. Eigentlich ist diese Konfiguration auch schon recht veraltet. Früher hat man diese Art der Konfiguration häufiger angetroffen. Meistens wurden damals die E-Mails via POP3 und POP Connector (bspw. POPcon) aus einem Postfach beim Provider abgeholt und an einen on-Prem Exchange Server zugestellt. Der Versand von Mails via Exchange erfolgte dann über den Smarthost, bzw. den SMTP Server des Anbieters. Damals hat man dies gemacht, da nicht jeder eine feste IP hatte, der Himmel noch Wolkenlos (ohne Cloud) und Microsoft Small Business Server ziemlich angesagt war. Die Betonung liegt hier auf „war“.
Welche Möglichkeiten gibt es?
Ein vorweg: Exchange Server unterstützen schon lange kein Sender Based Routing mehr. Eine Anpassung der Exchange Konfiguration um mehrere Postfächer für den Versand der Mails zu nutzen ist also nicht möglich. Es gibt zwar Drittanbieter Tools (wie beispielsweise ExSBR) mit denen Sender Based Routing möglich wird, dies macht aber die Konfiguration nicht besser. Da gibt es bessere Möglichkeiten:
Option 1: Cloud AntiSpam Anbieter
Es gibt eine Vielzahl an Cloud AntiSpam Lösungen und die meisten eignen sich gerade für kleinere Unternehmen. Die meisten dieser Lösungen beinhalten auch genau die Smarthost Funktion, welche IONOS nun einstellt. Im Prinzip funktionieren fast alle Cloud AntiSpam Lösungen nach dem gleichen Prinzip: Der MX Eintrag einer Domain zeigt auf den Cloud AntiSpam Anbieter. Der Anbieter filtert böse Mails mit seiner Lösung raus und schickt die guten Mails an ein beliebigen Mailserver. In der Regel muss der on-Prem Exchange Server nur irgendwie erreichbar sein, beispielsweise per DynDNS. Wie gesagt, es gibt eine Vielzahl von Anbietern für jede Unternehmensgröße und die Implementierung ist einfach: MX Eintrag und Sende Connector ändern, oft reicht dies schon aus. Als Bonus bekommt man oft noch State-of-the-Art Spam Filter.
Ich wollte erst keine Namen nennen, aber ExSBR hab ich ja auch namentlich erwähnt:
Ich möchte aber nichts empfehlen, daher teilt keine weitere Anbieter in den Kommentaren.
Option 2: Selber machen…
Ich stelle On-Prem Exchange Server nicht in Frage, ein Unternehmen wird seine Gründe haben, warum es einen on-Prem Exchange Server gibt und dieser beispielsweise nicht zu Office 365 migriert wurde. Es ist schließlich recht aufwändig einen on-Prem Exchange Server zu betreiben, daher könnte man es sich auch etwas einfacher machen und die Maildienste von IONOS nicht mehr benutzen. In diesem Fall braucht man natürlich mal mindestens eine feste IP. Um das AntiSpam Thema muss man sich dann selbst kümmern, hier könnte man entweder die recht rudimentären AntiSpam Features des Exchange Servers einsetzen oder eine spezielle Appliance / E-Mail Gateway oder Software einsetzen. Hier gibt es also auch wieder viele Möglichkeiten, natürlich muss man sich dann selbst um all die Themen rund um das Thema E-Mail kümmern. Wer das nicht möchte, könnte ja Option 1 wählen.
Wer also eine spezielle Appliance oder Software sucht um den E-Mail Empfang und Versand direkt selbst zu machen (MX auf eigene IP), der wird unter anderem hier fündig:
Exchange selbst bringt schon alles mit um E-Mails direkt zu Empfangen und auch zu Versenden. IONOS als Smarthost und POP3 Postfächer, sowie einen POP Connector braucht es dazu nicht. Voraussetzung ist hier allerdings eine feste IP, aber auch hier gibt es ja zig Möglichkeiten, wenn man etwas kreativ wird.
Option 3: Exchange Hybrid
Wer sich gefragt hat, ob die Konfiguration POP Mailbox und Smarthost in Verbindung mit einem on-Prem Exchange Server auch im Jahr 2023 noch sinnvoll ist und Office 365 schon mal in Betracht gezogen hat, könnte diese Option in Betracht ziehen.
Exchange Server ermöglichen den Hybrid Betrieb mit Office 365. Im Hybrid Mode kann Office 365 benutzt werden um Mails zu empfangen und zu versenden (MX Eintrag zeigt auf O365). Dazu müssen die Exchange Postfächer nicht zwingend zu Office 365 migriert werden. Office 365 kann sich im Hybrid Mode um den Empfang/Versand sowie die AntiSpam Funktionen kümmern und die Mails an die on-Prem Mailboxen zustellen.
Bei mir persönlich ist es jetzt schon wieder ein paar Tage her, dass ich einen frischen Office 365 Tenant für Exchange Hybrid eingerichtet hab, aber ich meine mich zu erinnern, dass noch keine Office 365 Lizenzen erforderlich sind, wenn die Postfächer noch on-Prem gespeichert werden und keine Office 365 Dienste benutzt werden. Es sollte also reichen die Konten via AAD Connect zu EntraID zu synchronisieren und keine Lizenz zuzuweisen. Im Hybrid Mode sollte dann schon Versand / Empfang und Routing zu on-Prem funktionieren.
Glaub ich…. Kann das jemand bestätigen oder wiederlegen?
Option 4: Es gibt andere Smarthost Anbieter
Es gibt andere Anbieter welche euch einen Smarthost für das Versenden von Mails anbieten. Die meisten Anbieter kommen da eher aus dem E-Mail Marketing Umfeld, bieten aber oft Standard E-Mail Relay bzw. Smarthost Funktionalität. Für diese Option würde es also ausreichen, sich einen anderen Anbieter zu suchen und diesen als Smarthost im Exchange Sendeconnector zu konfigurieren. In diesem Fall rechnen die meisten Anbieter allerdings nach der Anzahl der gesendeten Mails ab.
Auch hier wieder ein Beispiel:
Fazit
Falls ihr von der IONOS Smarthost Abschaltung betroffen seit und einen on-Prem Exchange Server einsetzt, dann ist meine persönliche Meinung: Nutzt Option 1: Sucht euch einen Cloud AntiSpam Anbieter und nutzt diesen auch für den Versand der Mails. In der Regel ist die Konfiguration einfach und die Anbieter unterstützen dabei. Ziel sollte sein: Keine POP Konten mehr, die braucht man einfach nicht mehr!
Lasst uns gerne darüber diskutieren.
Hier einen Nachtrag:
Hatte die Tage Kontakt mit IONOS, weil es eben nicht funktioniert hat mit dem Thema „Alle Domains im selben Vertrag“. Das wurde dann in die Technik weitergeleitet und von dort kam dann die Info das dies jetzt freigeschaltet sei. Tatsächlich funktioniert der Smarthost jetzt tatsächlich mit allen Domains im Vertrag.
Daraus schlussfolgere ich zweierlei:
1) eigentlich sollte das prinzipiell so sein und es klappt aber nicht bei allen aus welchen Gründen auch immer. Dafür spricht, dass es mit einem anderen Vertrag von Beginn an tatsächlich funktioniert hat
2) oder aber IONOS schaltet das nur bei den Nutzern frei, die sich aktiv an den Support wenden. Das hätte für IONOS den Vorteil das IONOS „zählen“ kann wie viele Kunden das überhaupt so nutzen?
Wie auch immer ich kann bestätigen das die Smarthost-Funktion mit unterschiedlichen Domains im selben Vertrag weiterhin verfügbar ist bei IONOS. Wer damit Probleme hat, sollte sich also an den IONOS Support wenden.
Moin,
seit Umstellung funktioniert oof (Out-Of-Office) nicht mehr und wird abgewiesen da Mail From fehlt und somit abgewiesen wird von Ionos. Support lässt noch auf sich warten.
Hallo Christian,
ja, hier genauso. Hast du dazu eine Rückmeldung vom Support bekommen? Selbst mein IT-Dienstleister ist ratlos und rät dazu auf eigenen Versand ohne Smarhost umzustellen.
Hallo, ich hänge mich mal an. Wir sind von dem gleichen Problem betroffen. Normale Mails werden verschickt, bei den „Out-Of-Office“ Nachrichten gibt es Fehlermeldungen. Gibt es hier bereits Lösungen?
Hallo,
wir haben das gleiche Problem. Seitens Support bekommen wir die Antwort, dass es nicht mehr geht. OOF-Nachrichten werden nicht mehr weitergereicht. Ich habe den Account-Manager angeschrieben und mitgeteilt, dass OOF* standardisiert ist und das wir eine Lösung benötigen. Falls nicht zeitnah ein Lösung gefunden wird, planen wir auch einen eigenen Smarthost zu betreiben. Das ist nun 3 Wochen her. ‚Still ruht der See‘ seit dem…..
*
Die RFC8098 unter Punkt 3 teilt mit, dass die Absenderadresse leer sein muss. („The envelope sender address (i.e., SMTP „MAIL FROM“) of the MDN MUST be null (), specifying that no Delivery Status Notification messages nor other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.”). An diesen Standard halten sich alle Microsoft Exchange Server.
Wird es nicht mehr geben bei Ionos, hier die Antwort unseres Betreuers:
Guten Tag,
danke für die Information. Inzwischen gab es einen weiteren Fall diesbezüglich und wir haben Rückmeldungen aus dem Backoffice.
Dass die Out-of-Office-Nachrichten keinen ReturnPath erlauben gem RFC kollidiert tatsächlich mit den Einstellungen unserer Postfächer.
Unsere Postfächer sind eben nicht als Relays ausgelegt, sondern für die standardmäßige Nutzung als Postfächer.
Wir können also für ein Problem, welches durch die Nutzung als Relay für Exchange-Server entsteht keine Sonderkonfiguration vornehmen.
Ich hätte gern eine elegante Lösung gefunden, tut mir leid.
Freundliche Grüße
Matthias Reichert
IONOS Kundenservice
Hallo zusammen,
Und zwar sende ich mit einer Journalregel alle aus- und eingehenden Mails weiter an die Mailarchiv-Lösung von Securepoint.
So wie es aussieht mag das IONOS aber jetzt nicht mehr, da es dann zwar von Multisendcon „via journal@domain.de“ verschickt wird, aber im FROM-Feld der originale Absender behalten wird. Grundsätzlich ja gut, damit das Mailarchiv das richtig archiviert…
Nun gibt es im Multisendcon die Option „FROM Adresse auswerten anstatt die vom Exchangeserver im SMTP Protokoll angegebene Absenderinformation“, welche das Problem tatsächlich behebt. Allerdings nur für die ausgehenden Mails, bei den eingehenden findet er dann keinen Relay-Account für die externe Absenderadresse.
Hat jemand zufällig auch schon das Problem gehabt?
Durch Zufall bin ich auf folgenden Beitrag gestoßen.
Ich habe es noch nicht umgesetzt, sieht aber robust aus und würde machen was wir brauchen.
Für Lau
Exchange-Sender-Based-Routing
https://www.tuescher.net/Exchange-Sender-Based-Routing/
Hallo,
ich glaube fast, dass MultiSendCon nichts anderes macht… aber da bin ich raus. Ist mir im Wirkbetrieb zu „heiß“.
Gruß Thomas
Hallo zusammen,
heute (29.01.2023) war es nun also soweit, obwohl beide Domain in einem (Business) Vertrag sind, kann nur noch eine Domain, über den einen SMTP Connector des Exchange, senden…
Vielen Dank für den Tip mit MultiSendCon… wirklich Easy zu konfigurieren.
Gruß Thomas
Hallo, trotz der anderslautenden Erklärungen von Ionos klappt es NICHT mit einer anderen Absendedomain zu schicken, auch wenn die im gleichen Vertrag sind. Die Frage ist jetzt nur ist das ein „Feature“ oder ein „Bug“ von Ionos.
Habe zum Glück nur einen Kunden mit dieser Situation, über 100 EUR für ein einziges Postfach zzgl. Einrichtung fände ich da doch etwas happig.
Hallo,
das mit dem Bug wäre mal interessant zu erfahren… MultiSendCon hat ja 30 Tage Testzeitraum… wenn IONOS es bis dahin ändert ;-)
Gruß Thomas
Hallo Ansgar, dem kann ich nur zustimmen. Die bekommen das nicht auf die Reihe. Mehrere Telefonat mit unqualifizierten Mitarbeiter (wobei 80% der Zeit in Warteschleifen verbracht wurde) haben mich nicht weiter gebracht. Obwohl ich da eine lustige Mail von IONOS bekam mit der Meldung: „Wir haben Ihr Problem gelöst“. Ein Mitarbeiter hat mir eine interne Memo vorgelesen, nachdem es mir zugesagt wurde, das es funktioniert. Nun denn, der Supportfall ist wieder eröffnet worden. Warten wir es ab ….
Hallo, was viele noch bedenken sollen: E-Mailweiterleitungen gehen dann nicht mehr vom Exchange aus und auch NDRs (hier sollte ggf. die Postmasteradresse angepasst werden) Grüße
moni meinen Sie hier auch die Stellvertretereinstellungen ?
Hallo zusammen,
zum Einem gut zu lesen, dass die Relay funktion weiterhin unterstützt wir… zum Anderen ist es für uns, und vielleicht auch noch einigen anderen, „dumm gelaufen“.
Wir haben mehr als eine Domain auf dem Exchange gehostet, die sind zwar alle bei IONOS aber da der Teil nach dem @ passen muss wird das so wohl nicht mehr laufen…
Hat jemand schon etwas gelesen, ob man im IONOS oder EX Einstellungen machen kann damit das weiter funktioniert?
Es sind ja alles IONOS Damain… da muss doch was gehen ;-)
Danke, Gruß Thomas
Schau dir mal Multisendcon an. Ist die einfachste Lösung in deinem Fall. Spitzen Software. Nutze ich seit Jahren.
Servus Thomas,
Lösung für dich, wäre eine Domain bei Variomedia zu buchen und dann als SMTP Smarthost zu verwenden.
Kollege hatte das auch schon hier erwähnt, glaube ich.
Grüße
Hallo Thomas,
deine Aussage so ist nicht richtig.
>>> Es sind ja alles IONOS Damain… da muss doch was gehen ;-) <<<
Warum sind die denn nicht alle im gleichen Vertrag? Gleicher Vertrag = geht weiterhin. Steht mittlerweile ja auch im Hilfedokument.
Hallo,
Danke an alle Antworter.
Doch, sind alle im gleichen Vertrag… und dann geht es? Das wäre ja meine Lösung, habe ich im Dokument nicht gesehen!
Na dann halte ich mal noch die Füße still…
Danke und schöne Feiertage, Gruß Thomas
Hallo,
IONOS hat den Hilfeartikel angepasst und klargestellt, dass die Smarthost Funktion erhalten bleibt:
https://www.ionos.de/hilfe/index.php?id=5380&utm_rid=c31efd46-e8d7-44b5-bdd6-f7de6ce61090#c234239
Grüße
Mädels, das schlimme daran, ist das schlimme dadrin, ich rufe bei , seit Mitte Dezember wöchendlich mehrfach an, jedes mal eine neue Aussage das gipfelte darin, das mir die einer eine Lösung für die nahe Zukunft angekündigt hatten, die sich dann als Erklärung des Problem mit anderen Beispieldomänen ( zum toppen der Verwirrung mit nicht .de Endungen ), das hat mal eben zwei Wochen Warten gekostet. Das Beste an der ganzen Nummer ist allerdings das von Anfang Dezember bis mitte Januar zu machen , die Zeit wo es am wenigsten echte Arbeitstage gibt.
Hi,
heute kam eine Erinnerungsmail von 1und1, in der es heisst:
„Bitte vergewissern Sie sich bis spätestens 28.01.2024, dass die Domain der Absenderadresse und die Authentifizierungsadresse in den Einstellungen des Postausgangsservers (SMTP) der von Ihnen verwendeten Software übereinstimmen.“
Das ist bei mir der Fall…die Authentifizierungsadresse ist die Hauptadresse der Domain, die wir als einzige nutzen.
Warum bekommt man trotzdem die Erinnerungsmail? Habt Ihr die auch erhalten?
Grüße.
ich glaube, die ganze Geschichte ist ganz falsch gelaufen bei ionos, die dachten es gibt nicht mehr viele smarthost user, dass hat ein Oberbongo entschieden wegen , wie immer , Sicherheitsproblemen und vorgaben von Google.
Dann fingen die ersten an bei Ionos zu kündigen …. schwub gab es den „smarthost light“ alle Mails von der gleichen Domaine. Die Leute haben trotzdem weiter gekündigt.
Dann oh , jetzt eine politische Entscheidung und die steht nirgendwo schriftlich , nur mündlich die gibt es bei denen nur intern schriftlich. Alle Domaine einer Kundennummer !!!! , da diese aber nirgendwo in der Mail steht ist das „politisch“. Das mit der Mail würde ich eher als Folgefehler sehen.
Wurden auch von der IONOS- Hiobsbotschaft aufgeschreckt und haben sofort sehr lautstark protestiert. Das Zurückrudern jetzt ist ja ganz nett. Hinterläßt aber einen fahlen Beigeschmack. Die knapp gesetzte Frist zur Umstellung und die Art und Weise der Bekanntmachung läßt künftig wohl nichts Gutes erwarten.
In Absprache mit meinen Kunden wurde inzwischen ein VPS-Smarthost mit den Merkmalen spf, dmarc und dkim eingerichtet. Postfixadmin (unterstützt Multidomains) kann ich in diesem Zusammenhang sehr empfehlen. Und weil die gebotene VPS-Leistung kaum ausgeschöpft wird, darf Jitsi-meet,netdata und nagios mit an den Start. Nachdem alle IMAP-Posftächer auf das VPS umgezogen waren, zogen auch die Domains nach.
Altverträge sind und werden gekündigt. Das rechnet sich für den Kunden und für uns.
So wie ich die Lage sehe ist 1&1 da zurückgerudert. Auf der aktuellen Hilfeseite finden sich dazu präzise Angaben.
Ich habe versucht hier eine Antwort zu posten, diese wurde aber leider immer als SPAM rejected.
Das Forum bei borncity mit identischem Inhalt ließ das Posting zu, deshalb hier der Link zu diesem Beitrag:
https://www.borncity.com/blog/2023/12/01/ionos-schafft-smtp-relay-smarthost-zum-15-januar-2024-ab/#comment-166442
Danke für die Info!
Nun ist der Artikel bei Ionos klar und auch das Beispiel Smarthost und Exchange erklärt: https://www.ionos.de/hilfe/e-mail/allgemeine-themen/wichtige-aenderung-fuer-das-versenden-von-e-mails-mit-abweichender-absenderadresse/
Alle Exchange Server mit einer externen Domain können den Ionos Smarthost somit ganz normal weiternutzen.
Alles etwas unklar.
Ionos schriebt selbst auf der Info-Seite:
Hinweis
Beachten Sie: Der Teil Ihrer E-Mail-Adresse vor dem @-Zeichen kann weiterhin frei gewählt werden. Der Teil der E-Mail-Adresse nach dem @-Zeichen muss bei Absenderadresse und verwendetem E-Mail-Postfach der Gleiche sein.
Also müsste ja eine klasische smarthost@xxx.de Adresse für alle Postfächer mit @xxx.de weiterhin funktionieren.
Ja!
Wir hatten das Thema auch vor einigen Jahren, weil DF, All-Inkl. und ein weiterer Provider von uns weggefallen sind für den Zweck, und sind dann mit dem Smarthost zu Variomedia gegangen. Super Provider dafür in meinen Augen. Kümmern sich darum, dass nirgends Blacklisting oder ähnliches greift. Sobald man selber mal unbeabsichtigt zur Schleuder wird, greifen deren Automatismen und blocken einen und man muss auf die Suche gehen. Das sorgt erstens dafür, dass man die Lücken findet und zweitens dass deren Netz sauber bleibt. Uns hat es schon mehrfach geholfen Dinge zu finden, die uns selbst nicht aufgefallen sind. Einfach eine Domain dort registrieren und für wenige Euros im Jahr hat man einen guten Provider für das Thema.
Ich bin da inzwischen auch entspannt und denke nicht, dass die Smarthost-Funktion sterben wird.
Hier die Antwort vom IONOS-Support:
Hallo,
an dieser Stelle bedanke ich mich noch einmal für das freundliche Telefonat.
Sie können auch ab dem 15.01.2024 über uns via Mail Relay / Smarthost senden. Gerne nenne ich Ihnen hierzu die Voraussetzungen:
1.) Bitte stellen Sie sicher, dass Sie bei uns ein Postfach angelegt haben, das sie als Mail Relay nutzen. Beispiel: „versand@ihredomain.tld“
2.) Bitte stellen Sie sicher, dass auf der Domain Ihres Mail Relay Postfachs ein IONOS SPF-Eintrag gesetzt ist:
https://www.ionos.de/hilfe/domains/mailserver-und-verwandte-records-konfigurieren/spam-versand-vermeiden-mit-spf-record/
3.) Ihre Mail Relay Adressen müssen dieselbe Domain nutzen wie auch Ihr Mail Relay Postfach („versand@ihredomain.tld“)
Beispiel:
Sie möchten über die Adressen „info@ihredomain.tld“, „mail@ihredomain.tld“, „rechnung@ihredomain.tld“ senden. Hierzu benötigen Sie mindestens ein Mail Relay Postfach bei IONOS, welches den Domain Part „ihredomain.tld“ nutzt.
Freundliche Grüße
IONOS Kundenservice
Auf weitere Anfrage erhielt ich die Antwort, dass jedes existierende IONOS-Postfach auch als Mail Relay Postfach genutzt werden kann.
Das klingt ja soweit gut. Dann müssten viele denke ich doch nichts anpassen.
so was unprof. als Antwort, wir sind in Deutschland das LAnd der .de `s und die erklären das mit .tld weiß einer welches land das ist ?
.tld = Top Level Domain ;)
#rtfm
eine weitere Möglichkeit ist seinen eigenen Smarthost auf einem Linux vServer zu betreiben. Dies ist sinnvoll wenn man keinen der erwähnten Antispam Anbieter nutzt weil der Postfix Mailserver umfangreiche Prüf, Verschlüsselungs und Routingmöglichkeiten bietet. Lediglich Antivirus ist im Open Source Umfeld nicht so toll. Aber da kann man sich auch eine kommerzielle Engine kaufen und dort installieren. Je nach Anbieter kostet so ein vServer zwischen 5 und 10 Euro monatlich. Es gibt auch die Möglichkeit kostenlose Cloudserver dazu zu verwenden. Gibt es bei Oracle in Frankfurt und bei AWS leider nur in den USA.
Die Hilfeseite ist hier eindeutig. Jedes Postfach muss auch mit seiner Adresse sich per SMTP authentifizieren am IONOS Server.
Für Mail Basic und Mail Business
Um die Sicherheit für unsere Kunden zu erhöhen, können Sie ab dem 15.01.2024 nur noch E-Mails über unsere Server senden, wenn Sie in Ihrem E-Mail-Programm, Ihrem E-Mail-Server, Ihrer Software oder in Ihrer E-Mail-App für den Versand von E-Mails eine Absenderadresse verwenden, die zu Ihrem Postfach gehört. Ab dem 15.01.2024 ist es nicht mehr möglich, E-Mails mit alternativen oder leeren Absendern über unsere Server zu versenden.
Beispiel:
Sie haben ein E-Mail-Postfach mit der E-Mail-Adresse max.mustermann@example.com eingerichtet. In diesem Fall können Sie ab dem 15.01.2024 nur E-Mails mit dem Absender max.mustermann@example.com versenden.
Wenn die E-Mail-Adressen für den Absender und die Authentifizierung am Postausgangsserver (SMTP) in den Einstellungen Ihrer verwendeten Software nicht übereinstimmen, werden betroffene E-Mails ab dem 15.01.2024 von unseren SMTP-Servern mit der folgenden Fehlermeldung abgelehnt und nicht versendet:
Sender address is not allowed.
Multisendcon wäre hier also eine denkbare Lösung.
Habe ich selbst im Einsatz und läuft 1A seit Jahren.
Hallo, auch mich beschäftigt das Thema sehr, habe ich doch einige Exchange Server die betroffen sind.
Ich habe eben mit dem Support von Ionos telefoniert und dieser teilte mir mit “ ruhig bleiben, wir arbeiten an einer Lösung“.
Das hört sich doch schon mal gut an. Warte ich also noch ab. Sind wohl doch einige Kunden die jetzt bei Ionos unruhig geworden sind.
Gruß Tordi
Hallo,
ich war nach der E-Mail bereits irritiert, aber das Telefonat mit dem Kundenservice hat mich vollends verwirrt. Mir wurde jetzt nämlich gesagt, dass wir überall unsere Mailausgangsserver-Credentials korrigieren müssen: von smtp.1und1.de auf smtp.ionos.de. Auf meine Frage hin, was das denn jetzt mit der erhaltenen E-Mail und auch mit den Aussagen von https://www.ionos.de/hilfe/index.php?id=5380&utm_rid=c31efd46-e8d7-44b5-bdd6-f7de6ce61090 zu tun haben soll, erschließt sich mir nicht.
Da mir der Supporter an Inkompetenz kaum zu überbieten schien, bat ich um einen Rückruf unseres persönlichen Beraters. Kam natürlich bisher nicht, auch unsere Mail von vergangenem Donnerstag wurde bisher nicht beantwort.
Wir nutzen keinen Exchange Server, sondern versenden über Web-Scripts z.B. mit PHP Mail(). Dort geben wir je nach Sprache des Kunden als From-Adresse unsere .com-Domain oder die .de-Domain an. Unsere Web-Scripts sollten angeblich nicht betroffen sein, da wir für alle From-Adressen NUR Domains aus demselben Vertrag verwenden (laut https://www.ionos.de/hilfe/index.php?id=5459).
Keine Ahnung, was jetzt stimmt. Der Telefon-Support widerspricht allem, die eine Mail sagt so, die andere sagt anders. Und wir stehen im Regen mit mehreren Hundert Scripts, von denen wir nicht wissen, ob sie bis 14.1. angepasst werden müssen oder eben doch nicht.
Gruß
Andreas
Die Funktion mail() sollte man nicht verwenden, da man sich selber an alle RFCs halten muss.
Besser wäre es eine Mailerklasse zu verwenden wie zB den PHPMailer.
Und dann sollte man die Config für den Versand einfach überall inkludieren, dann muss man auch nicht mehrere hundert Scripts warten. Also einfach mal die Gelegenheit nutzen es ordentlich zu machen….
Hallo,
das ist immer leicht gesagt, wenn man nur selbst an seiner Website arbeitet und nur ein oder ein paar wenige Scripts laufen hat. Wenn man aber über die Jahre ein Entwicklerteam mit mehr als 10 Entwicklern daran arbeiten hatte und viele verschiedene Mailkonfigurationen nutzt (da viele unterschiedliche Anwendungsgebiete) und immer wieder unterschiedliche Anforderungen und Profile hat, dann sieht die Sache schon anders aus.
Wie dem auch sei, das tut hier nichts zur Sache. Die Frage bleibt, ob Web-Scripts angepasst werden müssen und wenn ja in welcher Form.
Inzwischen bekamen wir vom IONOS-Support die wenig bis gar nicht hilfreiche Auskunft:
„Diese Änderung ist nötig, damit Ihre E-Mails empfangen werden können.
Wenn Sie diese Einstellung nicht hinterlegen möchten, akzeptieren wir dies jedoch kann es möglich sein, dass Ihre E-Mails nicht korrekt beim Empfänger ankommen.“
Das war wohl die Antwort auf die erste Mail, in der wir nachgefragt haben, ob es eine Möglichkeit gibt, diese Änderungen zu umgehen. Da aber die Ursprungsnachricht nicht mitgeschickt wurde, können wir nur spekulieren. Und die Antwort ansich ist ja auch… sagen wir mal vorsichtig „ungenau“.
Wir müssen die Änderung also nicht durchführen. Aber funktioniert dann halt vielleicht nicht mehr. Wahnsinn, wäre ich nicht drauf gekommen!
Hallo Franky,
wir haben kein Hosting und die Ausformulierung der Mail ist wohl falsch. Absender mit der gleichen Domain dürfen auch eine andere Authentifizierung benutzen, ob Hosting oder nicht. Für Exchange ändert sich damit nichts.
Quelle:
– Übersichtstabelle der Fachabteilung, welche Adressen noch gehen
Die Aussage von Peer ist korrekt und gilt auch für die normale SMTP-Authentifizierung. Damit ist der von Franky dargestellte Weg weiterhin möglich.
Wir hatten aber auch 2 „falsche“ Absender, so dass wir die Mail erhalten haben. Da wir von den 2 „falschen“ Absendern nichts wussten, dachten wir aber auch so wie hier beschrieben.
Grüße
Das ist alles schön und gut, aber solange bei IONOS die rechte Hand nicht weiß was die linke macht, kann man solchen Aussagen einfach nicht vertrauen und man sollte auf jeden Fall einen Plan B in der Hinterhand haben.
Hi Christian, so ganz sicher bin ich mir nicht… nur weil der Mitarbeiter das so sagt…
Wir haben 2 sende-domains (firma1.com & firma2.com) – beim Sendeconnector ist bei „Zustellung“ als username mit passw. smtp@firma1.com eingetragen, geht ja nur einer. Bei „Bereichsdefinition“ ist SMTP und Domäne = *
Ich hätte das nun so verstanden, dass die ausgehenden Mails von @firma2.com dann jetzt von Ionos zurückgewiesen werden, da ja nicht mit @firma1.com übereinstimmen.
Lt. Mitarbeiter nicht, aber … … … Teufel // Eichhörnchen …
Hallo, identisch hier… aber… wenn nur nach dem @ entscheidend ist, und so scheint es sich heraus zu kristallisieren, müssen nur beide Domain bei IONOS gehostet sein… dann klappt es (theoretisch).
Gruß Thomas
Hallo Lord_iMac,
soweit ich gesehen habe, haben sich die Aussagen der Fachabteilung nicht widersprochen, oder?
Fakt ist, dass die erste Mail nicht richtig formuliert war. Und der Telefonsupport (auch bei mir!) keine Ahnung hat. Aber das erwarte ich doch vom Telefonsupport nicht. Schade ist das natürlich
—
Hallo Peer,
ich habe eine Mail von der Fachabteilung mit den konkreten Aussagen und Fallbeispielen erhalten. Ganz konkret aufgelistet:
– geht nach dem 15.01.2024
– geht nicht nach dem 15.01.2024
Das ist für mich dann so verbindlich. Den Fall mit 2 Domains habe ich aber nicht.
Was sagt denn die Fachabteilung per Mail? Hatte den Support angeschrieben mit Bitte um Weiterleitung an die Fachabteilung.
Ich stehe jetzt echt auf dem Schlauch. Drauf ankommen lassen möchte ich es nicht, wenn bei IONOS die rechte Hand nicht weiß was die linke macht. Am Ende fallen wir hinten runter und stehen für einige Stunden ohne ausgehende E-Mails da. Unschön.
Wir betreiben einen Exchange 2016 (aktuellste CU/Sicherheits Patch-Level) onprem über IONOS als SMTP-Smarthost. Per IGetMail werden die Mails eingehend (POP3) abgerufen und intern an den Exchange weitergeleitet. Eigentlich bisher eine saubere und sichere Methode wie sie scheinbar bei vielen anderen auch zum Einsatz kommt.
Aber wie Eingangs erwähnt ist es mir zu unsicher darauf zu vertrauen das IONOS die Domain weiterhin als Smarthost akzeptiert. Darauf kann und möchte ich mich nicht verlassen, wenn sie zum Kunden anderes kommunizieren.
Jetzt stelle ich mir doch die Frage wie man das umstellen kann. Ja, wir könnten unseren Exchange über einen Reverse Proxy ans Netz hängen und die MX Einträge entsprechend anpassen. Doch birgt dies einen großen Nachteil in meinen Augen. Wir könnten nicht wie bisher beides betreiben. Exchange Postfächer für die „Priviligierten“ und POP3/IMAP Postfächer für die „unwichtigeren“ Dinge. Ersteres ist natürlich auch an ein gewisses Lizenzlimit gebunden.
Eigentlich sehe ich bei uns lediglich die Möglichkeit einen eigenen POP3/IMAP Server aufzusetzen welcher dann als Smarthost fungiert. Wie seht ihr das?
Was mir vor allem gerade noch als Idee kam, man könnte ja auch die MX Einträge umstellen auf den omprem Exchange und alles, was er nicht behandeln kann, weiterleiten an den SMTP von IONOS. Über eine Relaydomäne (internal Relay) sollte das doch abbildbar sein.
Wenn man unbedingt zum Backscatterproblem werden will, dann kann man das machen. ;)
Dann hat man aber sowieso ein ganz anderes Problem oder interpretiere ich das jetzt falsch?
Nein, denn Backscatter kannst du in diesem Szenario meist gar nicht vermeiden. Denn dazu müsste der erste Host schon alle Empfänger kennen, die du über ihn nur nach „hinten“ relayen willst. Wenn das gegeben ist, hast du kein Problem, aber meist eben schon.
Ich hatte einen Denkfehler und habe vollkommen unterschlagen das wir noch eine E-Mail Security (Sonicwall) vor unserem Exchange haben, damit sollten eigentlich alle Probleme obsolet sein und der Exchange selbst hängt nicht direkt am Netz außer ausgehend. Das ist doch ein denkbares Szenario.
Dann muss deine Sonicwall alle dahinter liegenden Empfänger kennen, oder du bzw. Dann der endgültige Server ist backscatter-Kandidat.
Um die Verwirrung komplett zu machen, anderslautende Aussage und Mail von einem Ionos Support Mitarbeiter.
Wenn ich das richtig verstehe und wie er mündlich sagte, wird Smarthost nicht abgeschafft. Die Domainendung ist relevant, nicht der user vor dem @.
Wir haben 2 Domains, die über den Smarthost senden und das soll weiterhin funktionieren, sagt er, da beide im selben Vertrag sind.
***
Hallo ,
wie telefonisch besprochen versende ich ihnen weitere infos über die E-Mail was Sie erhalten haben bezühglich Versand von E-Mails mit abweichender Absenderadresse
Für Shared Hosting Linux und Managed Server
E-Mails, die Sie über Ihren IONOS Webspace senden, erfordern ab dem 15.01.2024 eine Absenderadresse, die zu einer Domain Ihres IONOS Vertrages gehört. Der Versand mit alternativen oder leeren E-Mail-Absendern über IONOS Server ist ab diesem Zeitpunkt nicht mehr möglich. Dies betrifft alle Skripte, Apps und Programme die auf Ihrem Webspace eingesetzt werden.
Dieser Artikel erklärt Ihnen, was Sie bei dieser Umstellung beachten müssen.
Hinweis
Diese Änderung wird zu Ihrer Sicherheit eingeführt und kann nicht angepasst werden.
Beispiel
Ihr IONOS Vertrag enthält die Domain example.com. Sie haben auf dem dazugehörigen Webspace ein Skript installiert, dass den Inhalt eines Kontaktformulars als E-Mail an Sie verschickt. Als Absenderadresse verwenden Sie eine E-Mail-Adresse von Gmail (Google Mail) mit der Endung @gmail.com.
Ab dem 15.01.2024 können Sie nur noch Absenderadressen in Ihrem Skript verwenden, die auf @example.com enden. E-Mails mit anderen Absendern werden nicht zugestellt. Der IONOS Postausgangsserver (SMTP) Server übermittelt in diesem Fall den folgenden Fehlercode: Sender address is not allowed
Für Mail Basic und Mail Business
Um unsere Kundschaft zu schützen, werden wir zum Versenden von E-Mails nur noch Adressen unterstützen, die via SMTP authentifiziert sind. Das bedeutet, dass die Versand-Mail-Adresse die gleiche Domain-Endung (Teil nach dem @) haben muss, die auch die Adresse hat, die in unserem Mail-System hinterlegt ist. Auch das Leerlassen der angegebenen Versandadresse (Aliasadresse) ist nicht möglich, wenn diese von einem Programm verlangt wird.
Viele Nutzende verwenden „gefälschte“ oder „leere“ Aliasadressen und hinterlegen für das Absenden eine Adresse, die über eine bei uns gehostete Domain authentifiziert wird. Das wird mit der Deaktivierung unterbunden. Wenn eine Aliasadresse verwendet wird, muss diese die gleiche Domain-Endung haben, wie die authentifizierte Absenderadresse. Damit geben wir unserer Kundschaft weiterhin die Möglichkeit z. B. catch-all-Mail-Adressen zu verwenden.
Vielen Dank für Ihre Mitarbeit.
Ich wünsche Ihnen einen schönen Tag.
Bei allen Fragen zu Ihren Hosting-Produkten stehe ich Ihnen mit Rat und Tat zur Seite. Sie erreichen mich telefonisch, per E-Mail oder Chat. Meine Kontaktdaten finden Sie unter https://mein.ionos.de/contact. Sollte ich einmal nicht direkt erreichbar sein, so wird ein gut informierter Kollege aus meinem Team Ihre Anfrage entgegennehmen.
Freundliche Grüße
Besim Shaqiri
Ihr persönlicher Berater
Kontakt | Facebook | X
E-Mail: support@ionos.de
IONOS SE
Elgendorfer Str. 57
56410 Montabaur
Hauptsitz Montabaur
Amtsgericht Montabaur / HRB 24498
Umsatzsteuer-IdentNummer: DE815563912
Vorstand: Hüseyin Dogan, Claudia Frese, Arthur Mai, Dr. Markus Noga, Dr. Jens-Christian Reich, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Sven Fritz
***
Hallo zusammen,
ich mache das ganze über einen kleinen Provider.
Da hat man persönlichen support und keine Maleste mit Antispam.
Habe keine Ahnung, ob ich den Namen hier nennen darf.
Gruß
Dirk
Hallo zusammen,
auch ich bin verwirrt über die Mail von IONOS und benötige Hilfe durch dieses Forum.
Habe es auch so verstanden, dass es nur um Abweichungen hinter dem @ geht, also Domains die nicht zu IONOS gehören und die man ja per POP3 Connector durchaus in den Exchange einbinden kann.
Wenn jetzt die komplette Mail Adresse als Absender stimmen muss ist das mit 100 Mailboxen echt blöd… habe ich es richtig hier gelesen, dass man im EX nicht die Möglichkeit hat jede Mailbox einzeln als Absender zu deklarieren?
Ich hoffe immer noch darauf, dass es für IONOS Domains keine Auswirkungen hat.
Gruß Thomas
Ich lese es so, dass es um unterschiedliche Domains geht, die natürlich alle bei IONOS sind. Fremde Domains konnte man vorher, soviel ich weiß, auch schon nicht verschicken. Wäre ja noch schöner…
Im genannten Link zum IONOS Hilfe-Center ist aber einmal von @example.com und einmal von @example.org die Rede.
Solange der Kunde keine Mail von IONOS bekommen hat, würde ich auch nicht reagieren. Aber das am 15.01. mal im Hinterkopf behalten
Empfang funktioniert dann ja noch, nur beim Versand gibt es sofort eine Rückmeldung von IONOS.
Der Exchange kann den SMTP nicht nach Benutzer auswählen. Exchange kann ja auch kein POP3 abrufen. Er möchte gerne der Hauptmailserver sein. Das Konstrukt ist bei meinen Kunden noch aus alten SBS Zeiten. Und dann lässt man es meist so…
Auf der Info-Seite
https://www.ionos.de/hilfe/index.php?id=5380
könnte man unter dem Hinweis:
Wenn Sie die bisher verwendete Absenderadresse als Weiterleitungsadresse eingerichtet haben und diese eine abweichende Domain enthält, kann diese Weiterleitungsadresse ab dem 15.01.2024 nicht mehr als Absenderadresse verwendet werden.
verstehen eine Weiterleitung innerhalb der Domain würde das Postfach für den Versand legitimieren?
Eine klare Antwort konnte ich vom Support auch (noch) nicht erhalten…
Habe nun (wenn auch nicht die erhoffte) Antwort vom Support erhalten.
Deutlich, dass die komplette Adresse mit dem Postfach übereinstimmen muss…
vielen Dank, für Ihre Rückmeldung.
Die info@ ist eine Weiterleitung, die am dem 15.01.2023 nicht als angebliche absender E-Mail-Adresse angegeben werden kann, falls Sie dies machen wollen, wie es aktuell noch möglich.
Also kann eine Antwort nur von einem vollwertigem Postfach gegeben werden, dass E-mails senden undempfangen kann, wie „markus@“.
Falls Sie jedoch auch von der „info@“ E-Mails senden wollen, können Sie diese als Weiterleitung löschen und als vollwertige E-Mail-Adresse anlegen.
Bei weiteren Fragen oder Informationen stehen wir Ihnen jederzeit zur Verfügung.
Mit freundlichen Grüßen
Fidan Zeqiri
IONOS SE
Elgendorfer Str. 57
56410 Montabaur
Hallo,
Exchange steht normalerweise hinter der Firewall und sollte es Sophos sein, bittet sich dieses als sende
conector zu verwenden. Mit entsprechenden Revers DNS Einstellungen funktioniert ohne dritte.
Hallo,
ein paar meiner Kunden sind ebenfalls betroffen. Mein Plan sieht bisher so aus, dass ich den Sendeconnector auf „direkte Zustellung an MX Record“ umstelle. Dabei beachten:
feste IP (haben alle)
passender Reverse DNS Eintrag beim Internetprovider (prüfen, ggf. setzen)
SPF-Record bei Ionos anpassen (prüfen, ggf. um Exchange erweitern)
Dann wäre der ausgehende Mailversand mit der selben Funktionalität gewährleistet.
Habe ich etwas vergessen?
Hallo,
das würde ich auf die schnelle auch bevorzugen. Aber wie müsste er rDNS-Eintrag aussehen?
Im SPF würde ich meine feste IP eintragen.
Technisch egal, solange er punktiert ist (dotted). Leider werden gibts aber auch Spam Checks, die sich nicht an rfc halten und die erwarten da quasi rückwärts den Namen. Deswegen ja reverse record. Also a record löst auf ip auf und Reverse löst die ip wieder auf diesen Namen. Im allgemeinen fährt man also mit dem eigenen Hostnamen am besten. Ja im spf einfach die statische ip eintragen.
Achso, für die die jetzt direkt von ihrer statischen ip aus versenden: t-online und einige andere sind relativ strikt wenn sie auf einmal Mails von solchen (statischen) ips bekommen. Also immer schon die outbound queues in den ersten Tagen im Auge behalten. ;)
Meine beliebteste Konfiguration: den Mailserver des verwendete DSL-Providers als Smarthost nutzen, da ist ja meistens ein Postfach dabei beim Vertrag.
Da ich privat einen Exchange einsetze, benutze ich genau dieses Email-Konto von 1&1 als Smarthost. Funktioniert schon jahrelang problemlos.
meinte HMail
Hab was ähnliches Mal bei einem Kunden gebraucht, der keinen Smarthost unterstützte. Einfach einen Gmail dazwischen hängen und jedes Postfach einzeln versenden lassen…geht bis heute einwandfrei, nur eben viel klickerei am Anfang
Das ist so nicht richtig, ich hab den Support von IONOS diesbezüglich angeschrieben, hier die Antwort:
Hallo Michael Schmalz-Hennemann,
vielen Dank für Ihre E-Mail.
Um Sie als unseren Kunden zu schützen, werden wir zum Versenden von E-Mails nur noch Adressen unterstützen, die via SMTP authentifiziert sind. Das bedeutet, dass die Versand-Mail-Adresse die gleiche Domain-Endung (Teil nach dem @) haben muss, die auch die Adresse hat, die in unserem Mail-System hinterlegt ist. Alles, was vor dem @-Zeichen steht ist für uns irrelevant.
Überprüfen Sie Sie dann bitte ob Sie via SMTP authentifiziert sind und ob als Absenderadresse @Ihre Domain steht.
Tut mir leid für die Missverständnisse, für Rückfragen stehen wir Ihnen auch telefonisch zur Verfügung. Sie erreichen meine Kollegen und mich täglich rund um die Uhr – zu Ihren Festnetzkonditionen – unter 0721 170 555.
Freundliche Grüße
Laura Perteshi
IONOS Kundenservice
Kontakt | Facebook | X
E-Mail: support@ionos.de
IONOS SE
Elgendorfer Str. 57
56410 Montabaur
Hauptsitz Montabaur
Amtsgericht Montabaur / HRB 24498
Umsatzsteuer-IdentNummer: DE815563912
Vorstand: Hüseyin Dogan, Claudia Frese, Arthur Mai, Dr. Markus Noga, Dr. Jens-Christian Reich, Britta Schmidt, Achim Weiß
Wenn das wirklich so stimmen würde, wäre das Smarthost-Problem gelöst. Ich werde den Support kontaktieren, um eine Bestätigung zu erhalten.
Puh, diese Support-Aussage widerspricht dann ganz klar der E-Mail, die die Kunden erhalten haben und auch der Aussage auf der Website.
So ist es, dort steht nämlich:
„Beispiel:
Sie haben bei IONOS die E-Mail-Adresse max.mustermann@example.com erstellt und verwenden in einem E-Mail-Programm wie z. B. Thunderbird oder Microsoft Outlook die E-Mail-Adresse kontakt@example.org als Absender. In diesem Fall müssen Sie statt der Absenderadresse kontakt@example.org die E-Mail-Adresse max.mustermann@example.com verwenden.“
Das Beispiel ist von denen auch denkbar ungünstig gewählt. Abweichende Top-Level-Domain und abweichender Alias vor dem @! Ionos schreibt nämlich nicht, ob kontakt@example.com funktionieren würde (über das Postfach max.mustermann@example.com).
Das gleiche wurde auch mir vom IONOS-Support telefonisch mitgeteilt.
Gruß
T
Moin,
bei einem Telefonat mit ionos wurde mir das leider nicht bestätigt.
Es kann natürlich sein, das die Mitarbeiterin nur das offizielle Statement wieder gab.
Grüße
Gregor
Ja, auf der Webseite steht es auch so, dass nur die Sendedomain wichtig ist.
In der E-Mail und am telefonischen Support gibt es die Auskunft dass die komplette E-Mail-Adresse stimmen muss.
Die E-Mail zur Abschaltung haben von meinen Kunden bisher nur diejenigen bekommen, die auch mehrere Domänen bei IONOS haben und dann auch mit unterschiedlichen Domänen raussenden.
Ich habe es jetzt mit Multisendcon gelöst. Erstmal nach Absenderdomain filtern und entsprechendes SMTP-Konto auswählen. Da muss am Exchange nicht viel gemacht werden.
Nächstes Jahr müssen eh alle Kunden anfangen, sich Gedanken um das Supportende von Exchange machen, da kann man dann alles auf links drehen ;-)
???
Exchange 2019 wird bis Oktober 2025 mit Updates versorgt.
Zudem wirds auch danach weiterhin Exchange on Prem geben. Nur halt nicht zum Einmal-Kaufpreis, sondern zum monatlichen Abo. Aber On Prem wird weiter möglich sein.
Option 7?
Multisendcon benutzen und jede EMail als eigenen Smarthost nutzen. :-D
Hast du das im Einsatz läuft gut ? Langt da die Lite Lizenz?
Hätte noch ne andere Frage, wie kann ich dich kontaktieren
Vielen Dank Bernd
Der Unterschied bei Lite ist, dass nur ein Relayserver, also ein Anbieter verwendet werden kann.
Normal hast ja als SmartHost irgendeine Mail, aber da kannst nur eine eintragen.
Da bräuchtest dann die Pro-Version.
Vielen Dank
und die „EMail als eigenen Smarthost“ trägst du wo ein?
Lad Dir doch die 30-Tage Testversion runter. Multisendcon habe ich bei Kunden, die mehrere Provider haben, schon seit Jahren im Einsatz. Gab bisher noch nie Probleme.
Es wird aber die Pro-Version benötigt.
Light ist nur für alte Exchange (2003 z.B.) die noch kein TLS können. Die können mit Multisendcon Light wieder senden.
Antwortet Servolutions auf Eure Anfragen? Ich habe das Gefühl, die machen nichts mehr. Mehrere Anfragen von mir blieben unbeantwortet, wir haben bei einigen Kunden noch popcon im Einsatz, welcher aber ein Paar bugs hat. Ich würde ja in Betracht ziehen, eine Lizenz von Multisendcon zu erwerben, aber so…
Ich hab vor kurzem bei mir meinen privaten Exchange aufgesetzt, mit PopCon und MultiSendcon.
-> Da kam direkt die Lizenz + Rechnung
Bei uns im Geshcäft nutzen wir die Software auch des öfteren, da klappt der Kontakt eigentlich immer ganz gut.
Ja, manchmal dauert es bei Servolutions. Aber nach der Mail notfalls anrufen hat bei mir immer geklappt. Habe immer schnell jemanden erreicht.
Option 5: eigene (zusätzliche) Domäne auf einem vserver einrichten und diesen dann als Smarthost nutzen. Der SPF-Eintrag bei IONOS muss natürlich angepasst (erweitert um diesen Server) werden.
Option 6: sender based routing via hmailserver. Der ist kostenlos und kann das. Nachteil: jede emailadresse bei ionos muss auf dem hmailserver ebenfalls eingerichtet werden.
Bezüglich Option 3:
Mag sein, dass es funktioniert ohne Lizenzen Exchange Online als Smarthost zu verwenden. Aber lizenzrechtlich sauber ist das nicht.
Dafür brauchst du eine EOP-Lizenz pro Postfach, dann ist das kein Problem. Entweder EOP einzeln kaufen oder wenn zum Beispiel ein Office E3 Abo vorhanden ist, bist du auch dabei.
Reicht dann ein Office E3 Abo um Exchange Online als Smarthost für alle Email-Postfächer zu nutzen?
Meiner Meinung nach nicht, ist aber wahrscheinlich wie die Azure Plan Lizenz.
Einmal kaufen -> alle Features für den Tenant aktiviert
Aber dennoch wird laut AGBs für jeden, der diese Features nutzt, eine Lizenz benötigt.
Ja, das reicht. Im Office E3 Plan ist Exchange Plan 2 mit drin und damit auch eine EOP Lizenz. Damit darfst du über EXO relayen.
Wichtig ist halt, dass du alle Postfächer lizensiert und ein funktionierendes Exchange Hybrid hast. Hast du das nicht (zum Beispiel nur 50% lizensiert), dann klappt es trotzdem, ist dann aber zur Hälfte unlizensiert. Siehe hier: https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-protection-service-description/exchange-online-protection-service-description