Wenn du als IT-Admin oder Office-Verantwortlicher vor der Frage stehst, ob ein Dokumentenscanner seine Scans direkt an einen Exchange-Server schicken kann, bist du hier richtig. In vielen Büros sollen Multifunktionsgeräte Scans per E-Mail verschicken. Das klingt einfach, bringt in der Praxis aber Herausforderungen. Geräte müssen sich im Netzwerk anmelden. Sie brauchen passende Authentifizierung. TLS muss korrekt funktionieren. Und es gibt Unterschiede zwischen Exchange Online (Office 365) und einer On-Premises-Installation.
Typische Probleme sind schnell genannt. Scanner unterstützen oft nur einfache SMTP-Authentifizierung. Exchange Online hat aber in vielen Tenants die klassische Authentifizierung eingeschränkt oder deaktiviert. Zertifikate werden nicht akzeptiert, wenn das Gerät keine aktuellen TLS-Versionen spricht. Firewalls oder Relay-Regeln blockieren ausgehende Verbindungen. Mailbox-Größen oder Attachment-Limits bremsen große Scans aus.
Dieser Artikel zeigt dir, welche Optionen es gibt. Du erfährst, wann ein direkter Versand an Exchange möglich ist. Du lernst die Vor- und Nachteile von SMTP AUTH, SMTP-Relay und alternativen Wegen wie lokaler Relay-Server oder Netzwerkspeicher kennen. Außerdem erkläre ich kurz die Rolle von TLS und moderner Authentifizierung wie OAuth2 bei Exchange Online. Detaillierte Konfigurationsanleitungen folgen später. Zuerst klären wir die Voraussetzungen, dann die praktikablen Lösungen für typische Geräte und Netzwerke.
Technische Optionen für den Mailversand vom Scanner
Scanner und Multifunktionsgeräte können auf unterschiedliche Weise Scans in Exchange-Postfächer bringen. Manche Geräte senden E-Mails direkt per SMTP. Andere legen Dateien in einen gemeinsamen Ordner. Moderne Integrationen nutzen Web-APIs. Jede Methode hat eigene Anforderungen an Ports, Authentifizierung und TLS. Außerdem unterscheiden sich Komfort und Sicherheit stark. Exchange Online verlangt oft moderne Authentifizierung und sichere TLS-Verbindungen. On-Premises-Server können flexibler sein, benötigen aber oft angepasste Relay-Regeln oder Firewall-Ports.
Im Folgenden findest du einen kompakten Vergleich gängiger Methoden. Die Tabelle zeigt Voraussetzungen, typische Sicherheitsrisiken, wie aufwändig die Einrichtung ist und wann sich die Methode anbietet. Nutze die Übersicht, um die passende Lösung für dein Gerät und dein Netzwerk zu wählen. Detaillierte Konfigurationen folgen später im Artikel.
| Methode | Voraussetzungen (Ports, Authentifizierung, Zertifikate) | Sicherheitsrisiken | Komplexität der Einrichtung | Empfohlene Einsatzszenarien |
|---|---|---|---|---|
| SMTP-Client-Submission (SMTP AUTH) | Port 587, Benutzername/Passwort, STARTTLS/TLS. Bei Exchange Online muss SMTP AUTH aktiviert sein oder ein spezielles App-Passwort verwendet werden. | Gestohlene Zugangsdaten können E-Mail-Versand ermöglichen. Schwache TLS-Versionen bieten Angriffsfläche. | Niedrig bis mittel. Gerät muss SMTP AUTH unterstützen. | Kleine Installationen mit Geräten, die SMTP AUTH bieten und wo sichere Anmeldedaten verwaltet werden können. |
| SMTP-Relay (IP- oder Connector-basiert) | Port 25 typ. für Relay. Bei Exchange Online: connector für IP-Relay oder Exchange Server als Relay. Vertrauenswürdige IPs oder Relay-Connector erforderlich. | Offenes Relay riskant. Fehlkonfigurierte Allow-Lists können Spam ermöglichen. | Mittel. Erfordert Firewall- und Exchange-Connector-Konfiguration. | Netzwerke mit vielen Geräten oder Geräten ohne SMTP AUTH. Geeignet für On-Premises oder kontrollierte IP-Ranges. |
| Scan-to-Folder über SMB/NFS | SMB-Share erreichbar. Optional Benutzerkonto für Zugriff. Kein Exchange-Zugang erforderlich. SMBv3 empfohlen mit Kerberos/NTLMv2. | Unverschlüsselte SMB-Verbindungen gefährlich. Falsche Rechtevergabe öffnet Dateien. | Niedrig. Share erstellen, Rechte setzen, Scanner konfigurieren. | Szenarien mit Dokumentenmanagement-Systemen oder wenn zentrale Ablage vor E-Mail-Versand gewünscht ist. |
| Exchange Web Services (EWS) | HTTPS (Port 443). Konto mit Mailboxzugriff. Bei On-Premises verfügbar. EWS wird von Microsoft als ältere API angesehen. | Konto mit breiten Rechten kann missbraucht werden. API-Endpunkte müssen abgesichert sein. | Höher. Gerät oder Middleware muss EWS sprechen. | Wenn direkter Posteingang in Mailboxen gewünscht ist und Geräte EWS unterstützen oder ein Connector die API nutzt. |
| Microsoft Graph API | HTTPS (443). OAuth2 mit App-Registrierung in Azure AD. Tokenverwaltung nötig. Nur für Exchange Online sinnvoll. | Fehlende Token-Sicherheit gefährlich. Falsch konfigurierte Berechtigungen geben zu viel Rechte. | Hoch. Entwicklerkenntnisse erforderlich oder ein Vendor-Connector, der Graph nutzt. | Cloud-first-Umgebungen mit hohem Sicherheitsbedarf. Zukunftssichere Integration für Exchange Online. |
| Vendor-Connector / Middleware | Je nach Produkt: lokal laufender Relay oder API-Connector. Häufig TLS und Servicekonto oder App-Registrierung. | Zusätzliche Komponente bedeutet mehr Angriffsfläche. Pflege und Updates nötig. | Mittel bis hoch. Installation und Betrieb der Middleware erforderlich. | Wenn Geräte keine modernen Protokolle unterstützen oder wenn zentrale Logik, Konversion oder Monitoring gewünscht ist. |
Zusammenfassend lässt sich sagen: Ein direkter Versand an Exchange ist möglich. Die beste Methode hängt vom Gerät, der Sicherheitsanforderung und davon ab, ob du Exchange Online oder eine On-Premises-Installation betreibst. Für einfache Setups reicht oft SMTP-Submission. Für hohe Sicherheit und Cloud-Umgebungen sind Graph API oder ein kontrollierter Relay-Connector die bessere Wahl.
Entscheidungshilfe: Sollte dein Scanner direkt an Exchange senden?
Unterstützt das Gerät moderne Authentifizierung und TLS?
Prüfe zuerst, welche Protokolle dein Scanner kann. Kann er SMTP mit STARTTLS oder TLS auf Port 587? Unterstützt er OAuth2 oder nur klassische Benutzeranmeldung? Viele ältere Geräte sprechen nur SMTP AUTH. Exchange Online kann SMTP AUTH in manchen Tenants einschränken. Wenn dein Gerät kein aktuelles TLS oder moderne Authentifizierung bietet, ist ein direkter Versand in Cloud-Umgebungen riskant oder gar nicht möglich.
Willst du Cloud- oder On-Premises-Postfächer erreichen?
Bei Exchange Online sind App-Registrierung und Microsoft Graph die sicherste Option. Alternativ kannst du einen Connector für IP-Relay nutzen. On-Premises erlaubt oft flexiblere Relay-Regeln und EWS-Zugriff. Entscheide nach Standort der Mailboxen. Für hybride Umgebungen kann ein lokaler Relay-Server die Brücke bilden.
Brauchst du zentrale Kontrolle, Logging und Skalierbarkeit?
Wenn du viele Geräte hast oder Auditing und Konvertierung brauchst, ist eine Middleware oder ein zentraler Relay sinnvoll. Ein lokaler SMTP-Relay oder ein Vendor-Connector erlaubt bessere Überwachung und einfachere Zertifikatsverwaltung. Direktes Senden von jedem Gerät erschwert Reporting und Geheimnisverwaltung.
Fazit
Bei Unsicherheit setze auf einen kontrollierten Relay-Ansatz. Für Exchange Online ist die bevorzugte langfristige Lösung Microsoft Graph oder ein sicherer Connector mit eingeschränkten Rechten. Für On-Premises ist ein IP-basiertes Relay oder SMTP-Submission mit starken TLS-Einstellungen oft ausreichend. Verwende dedizierte Servicekonten oder App-Registrierungen. Beschränke IPs, aktivere TLSv1.2/1.3 und überwache Logs. So balancierst du Sicherheit, Wartbarkeit und Kompatibilität.
Häufige Fragen zum direkten Versand von Scans an Exchange
Funktioniert Scan-to-Email mit Exchange Online?
Ja, Scan-to-Email kann mit Exchange Online funktionieren. Viele Tenants haben aber klassische SMTP AUTH deaktiviert. In solchen Fällen brauchst du eine App-Registrierung mit Microsoft Graph oder einen konfigurierten Connector für IP-Relay. Prüfe die Tenant-Policies, bevor du das Gerät einrichtest.
Braucht man SMTP AUTH oder einen Relay?
Das hängt vom Gerät und der Anzahl der Scanner ab. SMTP AUTH ist sinnvoll für einzelne Geräte, die Benutzername und Passwort unterstützen. Für viele Geräte oder Geräte ohne Authentifizierung ist ein IP-basiertes SMTP-Relay oder ein lokaler Relay-Server praktischer. Achte darauf, Relay-Quellen strikt einzuschränken.
Wie verhält es sich mit TLS und Zertifikaten?
Exchange Online verlangt verschlüsselte Verbindungen mit aktuellen TLS-Versionen. Dein Gerät muss Zertifikaten vertrauen und TLSv1.2 oder TLSv1.3 unterstützen. Self-signed Zertifikate auf Gateways führen oft zu Verbindungsproblemen. Halte Firmware und Zertifikatstores auf dem neuesten Stand.
Welche Authentifizierungsarten werden unterstützt: Basic vs. OAuth/Modern Auth?
Viele Scanner unterstützen nur Basic Auth mit Benutzername und Passwort. Microsoft empfiehlt moderne Authentifizierung wie OAuth2 für Graph-API oder Exchange Online. Wenn dein Gerät kein OAuth kann, brauchst du einen Relay oder eine Middleware, die Tokens verwaltet. Vermeide Basic Auth, wenn Security-Policies das verbieten.
Was tun bei älteren Scannern ohne moderne Protokolle?
Nutze einen lokalen SMTP-Relay oder einen Vendor-Connector als Brücke zur Cloud. Alternativ kannst du Scan-to-Folder per SMB einrichten und einen Server die E-Mails erzeugen lassen. Prüfe Firmware-Updates oder den Austausch des Geräts, wenn Sicherheit und Langfristigkeit wichtig sind. Isoliere ältere Geräte im Netz und beschränke deren Zugriffe.
Technische Grundlagen, die du kennen solltest
Bevor du Scanner direkt an einen Exchange-Server anschließt, hilft ein Überblick über die zugrunde liegenden Protokolle und Anforderungen. Die Informationen unten erklären die wichtigsten Begriffe. So kannst du besser einschätzen, welche Lösung in deinem Netzwerk funktioniert.
SMTP-Grundlagen
SMTP ist das Standardprotokoll zum Versenden von E-Mails. Ein Gerät baut eine Verbindung zu einem SMTP-Server auf und übermittelt die Nachricht. Wichtige Ports sind 25 für Server-zu-Server-Verkehr und 587 für Client-Submission. E-Mails bestehen aus Envelope-Daten und Headern. Attachment-Größen, Mime-Typen und Server-Limits beeinflussen, ob große Scans zugestellt werden.
SMTP-Relay vs. SMTP-Client-Submission
SMTP-Client-Submission bedeutet: Gerät meldet sich mit Benutzername und Passwort am Server an und sendet über Port 587. Das ist typisch für einzelne Geräte. SMTP-Relay erlaubt Geräten das Senden ohne individuelles Login. Das Relay akzeptiert Verbindungen meist auf Port 25 und prüft die Quell-IP oder einen Connector. Relay ist praktisch bei vielen Geräten, birgt aber Risiken, wenn es nicht eingeschränkt ist.
Rolle von TLS und Zertifikaten
TLS sichert die Verbindung. Exchange Online verlangt aktuelle TLS-Versionen. Scanner müssen Zertifikaten vertrauen. Viele Geräte unterstützen nur ältere TLS-Versionen. Self-signed Zertifikate auf Gateways führen zu Verbindungsfehlern. Achte auf TLSv1.2 oder TLSv1.3 und aktuelle Firmware.
Authentifizierungsoptionen
Basic Auth nutzt Benutzername und Passwort. Das ist weit verbreitet, aber weniger sicher. SMTP AUTH ist die klassische Methode für SMTP-Submission. OAuth2/Modern Auth arbeitet mit Tokens und ist die empfohlenen Methode für Exchange Online. Viele ältere Scanner unterstützen kein OAuth. Dann brauchst du ein Relay oder Middleware, die Tokens verwaltet.
EWS und Microsoft Graph API als Alternativen
EWS ist eine ältere API für den direkten Zugriff auf Mailboxen. Sie arbeitet über HTTPS. Microsoft Graph ist die moderne Schnittstelle für Exchange Online. Graph verwendet OAuth2 und bietet granulare Berechtigungen. Für neue Integrationen ist Graph die zukunftssichere Wahl.
Netzwerk- und Firewall-Anforderungen
Erlaube ausgehenden Traffic auf die benötigten Ports. Beschränke eingehende Verbindungen. Nutze IP-Allowlists für Relay-Quellen. Berücksichtige NAT, Proxies und Rate-Limits. Überwache Logs und setze Alerting auf, damit ungewöhnliche Versandmuster schnell auffallen.
Praktische Schritt-für-Schritt-Anleitung zur Konfiguration
-
Bestandsaufnahme: Exchange-Version und Topologie klären
Finde zuerst heraus, ob du Exchange Online oder eine On-Premises-Installation nutzt. Prüfe Hybrid-Szenarien. Notiere Exchange-Version, Tenant-Richtlinien und vorhandene Receive-Connectoren. Prüfe Firmware und Protokollunterstützung des Scanners. Dokumentiere, welche Ports und Authentifizierungsarten das Gerät kann.
Hinweis: Manche Tenants haben SMTP AUTH standardmäßig deaktiviert. Kläre das vorab.
-
Auswahl der Methode
Entscheide zwischen SMTP-Client-Submission (SMTP AUTH), SMTP-Relay (IP- oder Connector-basiert) und API-basierten Lösungen wie Microsoft Graph. Wähle SMTP AUTH für einzelne, moderne Geräte mit Benutzeranmeldung. Wähle Relay bei vielen Geräten oder Geräten ohne Authentifizierung. Wähle Graph API für sichere Cloud-native Integrationen.
Warnung: Offenes Relay ist ein Risiko. Beschränke Zugriffsquellen immer strikt.
-
Einrichtung eines dedizierten Postfachs oder Receive Connector
Lege ein Service-Postfach an, wenn Geräte per SMTP AUTH senden sollen. Vergib ein starkes Passwort und begrenze Rechte. Wenn du Relay nutzt, erstelle einen dedizierten Receive Connector auf dem Exchange-Server oder konfiguriere einen Azure-Connector für Exchange Online. Beschränke den Connector auf die Scanner-IP-Adressen.
Tipp: Nutze aussagekräftige Namen für Connectors. So erkennst du den Zweck später schneller.
-
TLS-, Port- und Zertifikatkonfiguration
Stelle sicher, dass Scanner TLSv1.2 oder TLSv1.3 unterstützen. Konfiguriere den korrekten Port. Für SMTP AUTH ist das meist Port 587. Für Relay ist Port 25 üblich. Auf dem Exchange-Server muss ein gültiges Zertifikat installiert sein. Zertifikat muss von einer vertrauenswürdigen CA stammen oder im Gerät als vertrauenswürdig eingetragen sein.
Warnung: Self-signed Zertifikate führen oft zu Verbindungsproblemen. Vermeide sie, wenn möglich.
-
IP-Whitelisting und Testsendungen
Füge die IP-Adressen der Scanner in Firewalls und auf dem Exchange-Connector zur Allow-List hinzu. Restriktiere den Zugriff auf diese IPs. Führe Testsendungen durch. Nutze telnet oder openssl, um Verbindung und TLS zu prüfen. Beispielbefehle: telnet mail.example.com 25 und openssl s_client -connect mail.example.com:587 -starttls smtp.
Prüfe mit dem Scanner eine Testmail. Überwache, ob die Mail im Empfänger-Postfach ankommt und ob Header korrekt sind.
-
Fehlerprüfung und Monitoring
Wenn Mails nicht ankommen, prüfe zuerst Logs auf dem Scanner. Kontrolliere Exchange-Transport-Logs oder Message Trace in Exchange Online. Suche nach TLS-Fehlern, Auth-Fehlern oder Rate-Limits. Verwende Tools wie nslookup, ping und tracert für Netzwerktests.
Richte Monitoring ein. Überwache Verbindungsfehler und ungewöhnliches Versandverhalten. Setze Alerts für wiederkehrende Fehler oder hohe Fehlerraten.
Praxis-Tipps und typische Testbefehle
Nutze diese Checks:
- telnet mail.domain.tld 25 oder 587 um Basisverbindung zu testen.
- openssl s_client -connect mail.domain.tld:587 -starttls smtp um TLS-Handschlag und Zertifikat zu prüfen.
- Überprüfe Exchange-Logs oder Message Trace für Zustellpfade und Fehlermeldungen.
- Teste mit einem dedizierten Servicekonto, bevor du produktive Postfächer nutzt.
Fazit: Arbeite Schritt für Schritt. Dokumentiere jede Änderung. Beginne mit einer Testumgebung, wenn möglich. Setze auf TLSv1.2/1.3, IP-Whitelists und dedizierte Servicekonten. Bei Cloud-Umgebungen ist ein Relay-Connector oder Microsoft Graph oft die nachhaltigste Lösung.
Häufige Fehler und wie du sie vermeidest
Basic Auth ist deaktiviert oder blockiert
Viele Scanner nutzen noch Basic Auth mit Benutzername und Passwort. Exchange Online und Sicherheitsrichtlinien können Basic Auth jedoch deaktivieren. Folge: Anmeldungen schlagen fehl oder werden abgelehnt. Vermeide das, indem du prüfst, welche Authentifizierung dein Tenant erlaubt. Wenn Basic Auth nicht verfügbar ist, nutze einen Relay oder eine Middleware, die OAuth für dich übernimmt. Prüfe Firmware-Updates des Geräts, vielleicht gibt es ein Update für moderne Authentifizierung.
Fehlende oder ungültige TLS-Zertifikate, falsche Ports
Scanner versuchen oft unverschlüsselt zu senden oder nutzen veraltete TLS-Versionen. Exchange Online verlangt aktuelle TLS-Versionen auf den richtigen Ports, zum Beispiel Port 587 für Submission. Ergebnis sind Verbindungsfehler oder abgelehnte Verbindungen. Sorge dafür, dass der Scanner TLSv1.2 oder TLSv1.3 unterstützt, und dass Serverzertifikate von einer vertrauenswürdigen CA stammen. Teste Verbindungen mit openssl s_client, um das Zertifikat und die TLS-Version zu prüfen.
Falsche Connector- oder Relay-Konfiguration
Ein zu offener Relay oder falsch gesetzte Receive Connector erlauben keinen Versand oder erzeugen Sicherheitslücken. Häufig fehlen IP-Beschränkungen oder die Connector-Berechtigungen sind zu weit gefasst. Konfiguriere Connectoren nur für bestimmte Quell-IP-Adressen und begrenze die erlaubten Aktionen. Dokumentiere die Regeln und teste mit einem einzelnen Scanner, bevor du alle Geräte umstellst.
Attachment- oder Mailgrößen-Limits
Große Scans werden durch Attachment-Limits oder Transportlimits blockiert. Exchange-Server und Gateways haben oft Standardgrenzen. Prüfe die maximal erlaubte Nachrichtengröße auf Server und im Tenant. Komprimiere Scans, reduziere Auflösung oder stelle ein, dass große Dateien per Link in einem Netzlaufwerk abgelegt werden. Teste mit unterschiedlich großen Dateien, um die Grenze zu finden.
Fehlende Berechtigungen oder falsche Postfachkonfiguration
Servicekonten ohne Mailboxrechte oder fehlende Mailbox-Zuweisung verhindern Zustellung. Manchmal hat ein Konto nicht die nötigen Send-As oder SendOnBehalf-Rechte. Lege ein dediziertes Servicepostfach an und gib nur die notwendigen Rechte. Nutze klare Namenskonventionen für Servicekonten und überprüfe Zugriffsrechte mit einem Testversand. So vermeidest du unnötige Admin-Rechte und erhöhst die Nachvollziehbarkeit.
Wer schreibt hier?
