Outlook CLI: E-Mail vom Terminal senden

Wie sendet man Outlook-E-Mails per CLI vom Terminal?

Verbinden Sie Outlook oder Microsoft 365 einmalig, dann senden Sie mit nylas email send --to user@example.com --subject "Hello" --body "Hi" --yes. So erhalten Sie einen Outlook-CLI-Sende-Workflow ohne Azure-AD-App-Registrierung, MSAL-Einbindung oder SMTP-Konfiguration.

Derselbe Befehl deckt exakt den Anwendungsfall „Outlook-E-Mail per Kommandozeile senden" ab, der Entwickler sonst in Graph-API-App-Registrierung oder SMTP-Credential-Setup zwingt.

Das Problem beim programmatischen Senden von Outlook-E-Mails beginnt im Microsoft-Setup-Flow.

Programmatisches Senden von Outlook-E-Mails erfordert 4-5 Setup-Schritte im Microsoft-Ökosystem: Azure-AD-Anwendung registrieren, Mail.Send-API-Berechtigungen konfigurieren, Admin-Einwilligung einholen, die MSAL-Authentifizierungsbibliothek integrieren und Token-Refresh handhaben. Für einen einmaligen Versand vom Terminal oder aus einem Shell-Skript verwandelt dieser Aufwand eine 10-Sekunden-Aufgabe in ein 45-Minuten-Projekt.

Microsofts empfohlener Sendepfad ist der Graph-API-Endpunkt /sendMail. Laut Microsofts OAuth-2.0-Dokumentation laufen Access Tokens nach 60-90 Minuten ab und erfordern Refresh-Token-Rotation.

Für einen schnellen Versand vom Terminal oder aus einem Shell-Skript ist das zu viel Setup. SMTP über smtp.office365.com auf Port 587 funktioniert noch, aber Microsoft hat Basic Auth für Exchange Online im Oktober 2022 eingestellt. Benutzername/Passwort geht nicht mehr.

Nylas CLI umgeht all das. Es kommuniziert mit der Nylas API, die OAuth2-Token-Refresh, Provider-Routing und Verbindungsmanagement übernimmt. Einmal authentifizieren, dann mit einem Befehl senden.

1. Installation

Nylas CLI ist in unter 30 Sekunden auf macOS, Linux oder Windows installiert und erfordert weder Azure-AD-App-Registrierung noch Graph-API-Credentials oder eine MSAL-Bibliothek. Die Binary ist eine einzelne Go-Executable unter 20 MB, die Plattform und Architektur bei der Installation automatisch erkennt.

Auf macOS oder Linux installieren Sie per Homebrew. Unter Windows — wo laut Statcounter über 80 % der Outlook-Desktop-Nutzer arbeiten — verwenden Sie den PowerShell-Einzeiler. Beide Methoden prüfen SHA-256-Prüfsummen automatisch. Weitere Installationsoptionen finden Sie im Erste-Schritte-Guide.

2. Outlook-Konto authentifizieren

Die Authentifizierung verbindet Nylas CLI über einen einzigen OAuth2-Flow mit Ihrem Outlook- oder Microsoft-365-Postfach und ersetzt die mehrstufige Azure-AD-App-Registrierung, die die Graph API erfordert. Der gesamte Vorgang dauert etwa 2 Minuten und speichert Zugangsdaten sicher in Ihrem System-Keyring, sodass Sie sich nicht bei jedem Befehl erneut authentifizieren müssen.

Gehen Sie zu dashboard-v3.nylas.com, erstellen Sie eine Anwendung und verbinden Sie Ihr Outlook- oder M365-Postfach. Konfigurieren Sie dann das CLI mit Ihrem API-Schlüssel. Laut Microsofts OAuth-2.0-Dokumentation laufen Access Tokens nach 60-90 Minuten ab — Nylas übernimmt den Refresh automatisch im Hintergrund.

nylas auth config
# API-Schlüssel bei Aufforderung einfügen

# Verbindung prüfen
nylas auth whoami
# => Authenticated as you@company.com (Microsoft)

Zugangsdaten werden in Ihrem OS-Keyring gespeichert (macOS Keychain, Windows Credential Manager oder Linux libsecret). Sie müssen sich erst erneut authentifizieren, wenn Sie den Grant widerrufen.

3. Von Benutzerpostfach, Alias oder Shared Mailbox senden

Microsoft-365-Organisationen verwalten typischerweise 3-5 Postfach-Identitätstypen pro Abteilung — Benutzerpostfächer, Shared Mailboxes, Verteilergruppen, Ressourcenräume und Send-As-Aliase. Nylas CLI sendet von jeder dieser Identitäten, indem die richtige Grant-ID angegeben wird. Die entscheidende Frage ist nicht nur „Kann ich eine Nachricht senden?" — sondern „Von welcher Postfach-Identität soll diese Nachricht kommen?"

Um von Ihrem persönlichen Outlook-Postfach zu senden, führen Sie den Befehl ohne Grant-ID aus — das CLI verwendet Ihr standardmäßig authentifiziertes Postfach. Um von einer Shared Mailbox oder Abteilungsidentität zu senden, übergeben Sie die Grant-ID der Shared Mailbox als erstes Argument. Jeder Grant entspricht genau einer Postfach-Identität in Exchange Online.

# Von Ihrem eigenen Outlook-Postfach senden
nylas email send \
  --to "colleague@company.com" \
  --subject "Q2 planning doc" \
  --body "Hi — the planning doc is ready for review." \
  --yes

# Von einem Shared-Mailbox-Grant senden
nylas email send <shared-mailbox-grant-id> \
  --to "vendor@partner.com" \
  --subject "PO #4521" \
  --body "Purchase order 4521 is ready for review." \
  --yes

Wenn send-as- oder Shared-Mailbox-Rechte fehlen, gibt Microsoft 365 einen 403-Fehler zurück und lehnt den Versand ab, obwohl die Befehlssyntax korrekt ist. Laut Microsofts Exchange-Online-Berechtigungsdokumentation können Shared-Mailbox-Delegierungsänderungen bis zu 60 Minuten benötigen, um sich zu verbreiten. Dieser Fehler ist ein Exchange-Online-Richtlinienproblem, kein CLI-Problem.

4. Verteilerlisten, Aliase und Team-Queues

Microsoft-365-Verteilerlisten und M365-Gruppen werden serverseitig auf alle Mitgliederpostfächer erweitert, sodass ein einziger nylas email send-Befehl Hunderte von Empfängern erreichen kann, ohne clientseitige Adressauflösung. Unternehmen mit 500+ Mitarbeitern pflegen üblicherweise 20-50 Verteilerlisten für Abteilungen, Projektteams und Compliance-Routing. Nylas CLI sendet an diese Listen genauso wie an einzelne Adressen — indem die Listenadresse im --to-Flag angegeben wird.

Die folgenden Beispiele zeigen zwei gängige Muster: Broadcast an eine Engineering-Verteilerliste und Weiterleitung eines Vertragsupdates an die Rechtsabteilung per CC mit einem Compliance-BCC. Das --bcc-Flag verbirgt Compliance- oder Journaling-Adressen in der sichtbaren Empfängerliste — eine häufige Anforderung in regulierten Branchen wie Finanz- und Gesundheitswesen.

# An eine Verteilerliste senden
nylas email send \
  --to "engineering-all@company.com" \
  --subject "Deployment window tonight" \
  --body "Production deploy starts at 22:00 UTC. Freeze all PRs by 21:00." \
  --yes

# Compliance- oder Archivempfänger einbeziehen
nylas email send \
  --to "contracts@company.com" \
  --cc "legal@company.com" \
  --bcc "compliance@company.com" \
  --subject "Contract update" \
  --body "Updated terms are ready for review in the contract system." \
  --yes

5. HTML-Bodys und geschäftliche Workflow-E-Mails

Geschäftliche Outlook-E-Mails enthalten häufig Rechnungen, Freigaben, Leistungsbeschreibungen und Beschaffungsupdates. Der aktuelle CLI-Sendebefehl akzeptiert HTML über --body, unterstützt gehostete Templates über --template-id und hält die Dateizustellung getrennt: Veröffentlichen Sie die Datei in Ihrem Dokumentensystem und senden Sie den Link, oder verwenden Sie die Nylas API/SDK, wenn ein MIME-Anhang erforderlich ist.

Outlooks Rendering-Engine verarbeitet HTML über Microsofts Word-HTML-Parser, sodass einige CSS-Eigenschaften anders gerendert werden als in Gmail oder Apple Mail. Halten Sie automatisierte HTML-Bodys klein, verwenden Sie Inline-Styles für kritische Eigenschaften und lassen Sie DLP- und Transportregeln auf Mandantenebene die endgültige Nachricht nach dem Versand prüfen.

nylas email send \
  --to "client@example.com" \
  --subject "Invoice #1042" \
  --body "<h1>Invoice #1042</h1><p>Amount due: <strong>$2,400.00</strong></p><p>Payment link: <a href='https://pay.example.com/1042'>pay.example.com/1042</a></p>" \
  --yes

6. Zeitgesteuerten Versand planen und Microsoft-365-Limits beachten

Zeitgesteuerter E-Mail-Versand in Microsoft 365 ermöglicht es, eine Nachricht jetzt zu verfassen und zu einem bestimmten Zeitpunkt senden zu lassen — nützlich, um Empfänger in anderen Zeitzonen zu erreichen oder Follow-ups außerhalb der Geschäftszeiten einzureihen. Microsoft 365 begrenzt die meisten Tarife auf 30 Nachrichten pro Minute und 10.000 Empfänger pro Tag, sodass Massen- oder automatisierte Sendeschleifen bewusst gedrosselt werden müssen, um temporäre Sperren zu vermeiden.

Das --schedule-Flag akzeptiert natürlichsprachige Zeitausdrücke wie "tomorrow 9am" oder "next Monday 2pm EST". Bei Massen-Sendeschleifen hält ein 2-Sekunden-Sleep zwischen den Nachrichten Sie deutlich unter Microsofts 30-Nachrichten-pro-Minute-Grenze und vermeidet die temporäre Sendesperre, die bis zu 24 Stunden dauern kann.

# Follow-up zeitgesteuert senden
nylas email send \
  --to "client@example.com" \
  --subject "Follow-up" \
  --body "Checking in on the proposal." \
  --schedule "tomorrow 9am" \
  --yes

# Automatisierte Postfachschleife mit Rate-Limiting
while read -r recipient; do
  nylas email send --to "$recipient" --subject "Status update" --body "See attached notes." --yes
  sleep 2
done < recipients.txt

7. JSON-Ausgabe für Scripting und Audit-Trails

Das Hinzufügen von --json zu jedem nylas email send-Befehl gibt das vollständige Nachrichtenobjekt als strukturiertes JSON zurück, einschließlich Message-ID, Grant-ID, Thread-ID, Zeitstempel und Absender-/Empfängeradressen. Diese Ausgabe eignet sich für das Protokollieren von Sendeereignissen, die Weitergabe von Message-IDs an nachgelagerte Queue-Prozessoren oder die Erfüllung von Compliance-Audit-Trails, die einen Zustellversuch-Nachweis mit exakten Zeitstempeln erfordern.

Die JSON-Antwort wiegt typischerweise 400-600 Bytes pro Nachricht und folgt dem Nylas-API-Message-Schema. Die Ausgabe durch jq zu leiten extrahiert spezifische Felder — die Message-ID zur Nachverfolgung, die Thread-ID für Konversations-Threading oder das Datum für Audit-Logs.

nylas email send \
  --to "user@example.com" \
  --subject "Test" \
  --body "Hello." \
  --json --yes

{
  "id": "a1b2c3d4e5f6g7h8",
  "grant_id": "d3f4a5b6-c7d8-9e0f-a1b2-c3d4e5f6g7h8",
  "thread_id": "x9y8z7w6v5u4t3s2",
  "subject": "Test",
  "from": [{"name": "Dev User", "email": "dev@company.com"}],
  "to": [{"name": "", "email": "user@example.com"}],
  "date": "2026-03-28T10:30:00-04:00",
  "object": "message"
}

In Shell-Skripten können Sie die Message-ID aus der JSON-Ausgabe mit jq erfassen und für die Weiterverarbeitung nutzen — Zustellstatus prüfen, an eine Audit-CSV anfügen oder an ein Ticket-System übergeben. Das .id-Feld ist ein eindeutiger 16-Zeichen-String, der die Nachricht in der Nylas API referenziert.

# Message-ID nach dem Senden erfassen
msg_id=$(nylas email send \
  --to "user@example.com" \
  --subject "Automated" \
  --body "This is automated." \
  --json --yes | jq -r '.id')

echo "Sent message: $msg_id"

Graph API vs. Nylas CLI

Microsoft Graph API erfordert 50-100 Zeilen Python- oder Node.js-Code, um eine einzelne Outlook-E-Mail zu senden — wenn man Azure-AD-App-Registrierung, MSAL-Token-Beschaffung, Token-Refresh-Handling und den eigentlichen POST-Request einrechnet. Nylas CLI reduziert das auf 1 Befehl mit null Codezeilen und ohne Azure-Portal-Konfiguration. Der folgende Vergleich schlüsselt jeden Schritt für beide Ansätze auf.

Outlook-spezifische Tipps

Microsoft 365 verfügt über mandantenweite Richtlinien, Compliance-Funktionen und Postfachtypen, die bei Consumer-E-Mail-Anbietern wie Gmail oder Yahoo nicht existieren. Die folgenden Tipps behandeln Outlook-spezifisches Verhalten — Lesebestätigungen, Vertraulichkeitsbezeichnungen, Shared Mailboxes, Rate-Limits und Transportregeln — das beeinflusst, wie gesendete E-Mails nach dem Verlassen des CLI verarbeitet werden.

Lesebestätigungen

Outlook unterstützt Lesebestätigungsanfragen über den Disposition-Notification-To-Header. Wenn Sie über Nylas CLI senden, wird der Outlook-Client des Empfängers diesen je nach Einstellungen möglicherweise auffordern, eine Lesebestätigung zu senden. Laut Microsofts Dokumentation können Empfänger Lesebestätigungsanfragen ablehnen — verlassen Sie sich daher in automatisierten Workflows nicht darauf als Zustellbestätigung.

Vertraulichkeitsbezeichnungen

M365-Vertraulichkeitsbezeichnungen (Confidential, Internal usw.) werden auf Mandantenebene durch Microsoft Information Protection angewendet. Über Nylas CLI gesendete Nachrichten respektieren die standardmäßige Bezeichnungsrichtlinie Ihres Mandanten. Wenn Ihre Organisation eine bestimmte Bezeichnung erfordert, kann Ihr Exchange-Administrator Auto-Labeling-Regeln festlegen, die für alle ausgehenden E-Mails unabhängig vom sendenden Client gelten.

Shared-Mailbox-Versand

Um von einer Shared Mailbox zu senden, verbinden Sie diese als separaten Grant über den OAuth-Flow. Jede Shared Mailbox erhält eine eigene Grant-ID, die Sie beim Senden referenzieren. Das verbindende Benutzerkonto muss Full-Access- oder Send-As-Berechtigungen in Exchange Online haben — Delegierungsänderungen können bis zu 60 Minuten benötigen, um sich zu verbreiten.

# Shared Mailbox verbinden
nylas auth login
# OAuth-Flow für die Shared Mailbox durchlaufen

# Von der Shared Mailbox mit ihrer Grant-ID senden
nylas email send <shared-mailbox-grant-id> \
  --to "vendor@partner.com" \
  --subject "PO #4521" \
  --body "Purchase order 4521 is ready for review."

Outlook-Sendelimits

Microsoft 365 begrenzt die meisten Tarife auf 10.000 Empfänger pro Tag und 30 Nachrichten pro Minute. Laut Microsofts Exchange-Online-Limits-Dokumentation löst das Überschreiten eine temporäre Sperre aus. Für Massenversand fügen Sie ein sleep 2 zwischen den Nachrichten in Ihrem Skript ein.

Transportregeln, Journaling und Send-As-Richtlinien

Microsoft-365-Mailflows werden durch mandantenweite Exchange-Online-Regeln gesteuert, die Nachrichten verarbeiten, bevor sie den Empfänger erreichen. Transportregeln können Nachrichten basierend auf Absender, Empfänger, Betreff oder Inhaltsmustern umleiten, blockieren oder verändern. Journaling kopiert alle E-Mails in ein Compliance-Postfach. DLP-Richtlinien scannen Anhänge und Body-Inhalt gegen über 100 eingebaute Typen sensibler Informationen. Laut Microsofts Mailflow-Regeln-Dokumentation werden Transportregeln in Prioritätsreihenfolge ausgewertet, und die erste übereinstimmende Regel kann die weitere Verarbeitung stoppen.

Wenn ein Outlook-Versand sich bei zwei Postfächern unterschiedlich verhält, liegt die Ursache normalerweise an Postfachrichtlinien oder mandantenweiten Routing-Richtlinien, nicht an der CLI-Befehlssyntax.

Shared-Mailbox- und Team-Queue-Workflows

Microsoft-365-Organisationen verwenden Shared Mailboxes für Beschaffung, Support, Recruiting und Executive Operations. Laut Microsofts Shared-Mailbox-Dokumentation benötigen Shared Mailboxes unter 50 GB keine separate Lizenz. Der Versand von support@company.com oder ap@company.com über Nylas CLI funktioniert, indem die Shared Mailbox als separater Grant verbunden und die Grant-ID im Sendebefehl angegeben wird.

Nächste Schritte

Sobald Sie Outlook-E-Mails vom Terminal senden können, erweitern Sie Ihren Workflow: Outlook-Posteingang lesen und filtern, Kalendereinträge verwalten, AI-Agents mit Ihrem Postfach verbinden oder komplett den Provider wechseln — Nylas CLI unterstützt 6 Provider mit derselben Befehlssyntax.

• E-Mail vom Terminal senden — providerübergreifender Guide für Linux, macOS und Windows
• Outlook-E-Mails im Terminal auflisten — Outlook-Posteingang lesen, suchen und filtern
• Outlook-Kalender per CLI verwalten — Termine erstellen, Verfügbarkeit prüfen, Meetings planen
• AI-Agents per MCP E-Mail-Zugriff geben — Claude, Cursor oder VS Code mit Ihrem Outlook-Postfach verbinden
• Vollständige Befehlsreferenz — jedes Flag und jeden Unterbefehl dokumentiert