Eigenen E-Mail-Versandweg über Microsoft 365 einrichten

Eigenen E-Mail-Versandweg über Microsoft 365 einrichten

Schritt für Schritt

Die Einrichtung läuft über fünf Schritte. Die Schritte 1–3 erledigst Du außerhalb von PARITY.med — in Deinem Microsoft-365-/Azure-Umfeld. Die Schritte 4–5 entsprechen der Karte „Eigener Versandweg (Microsoft 365)" im Suite-Portal. Du findest sie unter Einstellungen → Mail-Status (/einstellungen/mail-status); sie ist nur mit Administrator-Rechten bedienbar.

Anders als beim Brevo-Weg gibt es keine DNS-Einträge zu setzen: Microsoft 365 signiert Deine Domain out-of-box per DKIM. „Verifiziert" bedeutet hier nicht DNS-Prüfung, sondern ein erfolgreicher Testversand mit Bestätigungscode.

Schritt 1 — Azure-AD-App registrieren und Client-Secret erzeugen

Diesen Schritt erledigst Du im Azure-Portal (https://portal.azure.com) mit einem Administrator-Konto Deines Microsoft-365-Tenants.

1. Microsoft Entra ID → App-Registrierungen → „Neue Registrierung". Vergib einen sprechenden Namen (z. B. PARITY.med Versand) und registriere die App.
2. Auf der Übersichtsseite der App findest Du die Anwendungs-(Client-)ID und die Verzeichnis-(Mandanten-/Tenant-)ID — beide gleich notieren, Du trägst sie in Schritt 4 in PARITY.med ein.
3. Unter „Zertifikate & Geheimnisse" → „Neuer geheimer Clientschlüssel" ein Client-Secret erzeugen. Den Wert (nicht die „Geheimnis-ID") sofort kopieren — Azure zeigt ihn nur einmal vollständig an.

🔐 Sicherheits-Hinweis: Das Client-Secret ist wie ein Passwort für Deinen Versand. Gib es nicht per unverschlüsselter Mail weiter und checke es nicht in Dokumente ein. PARITY.med speichert es verschlüsselt und zeigt es nie wieder an — bei Verlust erzeugst Du in Azure einfach ein neues und hinterlegst es erneut. Vergib beim Secret nach Möglichkeit eine begrenzte Gültigkeit und erneuere es rechtzeitig.

Schritt 2 — Admin-Consent für Mail.Send erteilen

Damit die App im Namen des Postfachs senden darf, braucht sie die Application-Berechtigung Mail.Send (nicht die delegierte Variante).

1. In der App unter „API-Berechtigungen" → „Berechtigung hinzufügen" → „Microsoft Graph" → „Anwendungsberechtigungen" die Berechtigung Mail.Send hinzufügen.
2. Anschließend „Administratorzustimmung für <Dein Tenant> erteilen" klicken. Der Status der Berechtigung muss auf „Erteilt" wechseln.

⚠️ Anwendungs- statt delegierte Berechtigung: Mail.Send muss unter „Anwendungsberechtigungen" stehen. Die delegierte Berechtigung reicht für den App-only-Versand (ohne angemeldeten Benutzer) nicht aus.

Schritt 3 — App auf das Absender-Postfach beschränken (ApplicationAccessPolicy) — die wichtigste Sicherheitskontrolle

Mail.Send als Anwendungsberechtigung erlaubt der App zunächst, aus jedem Postfach Deines Tenants zu senden. Damit die App ausschließlich aus Deinem Absender-Postfach senden kann, beschränkst Du sie per ApplicationAccessPolicy. Das machst Du in der Exchange Online PowerShell:

# 1. Mit Exchange Online verbinden (Modul ExchangeOnlineManagement)
Connect-ExchangeOnline

# 2. Eine mail-aktivierte Sicherheitsgruppe anlegen, die NUR das Absender-Postfach enthält
New-DistributionGroup -Name "PARITY-Versand-Scope" -Type Security -Members rechnung@mein-fachhandel.de

# 3. Die App auf genau diese Gruppe scopen (Client-ID aus Schritt 1)
New-ApplicationAccessPolicy -AppId <Client-ID> `
  -PolicyScopeGroupId "PARITY-Versand-Scope" `
  -AccessRight RestrictAccess `
  -Description "PARITY.med darf nur aus dem Rechnungspostfach senden"

# 4. Prüfen, dass die Beschränkung greift (Granted = erlaubt, Denied = geblockt)
Test-ApplicationAccessPolicy -AppId <Client-ID> -Identity rechnung@mein-fachhandel.de
Test-ApplicationAccessPolicy -AppId <Client-ID> -Identity irgendein.anderes@mein-fachhandel.de

Die letzte Prüfung sollte für das Absender-Postfach Granted und für jedes andere Postfach Denied liefern.

🛡️ Warum das entscheidend ist: Das Postfach-Scoping ist die primäre Sicherheitskontrolle dieses Versandwegs — ohne sie könnte eine kompromittierte App aus allen Postfächern Deiner Organisation Mails verschicken. PARITY.med kann das Scoping technisch nicht prüfen (eine fehlende Policy erweitert den Zugriff, verhindert den Versand also nicht). Deshalb bestätigst Du es in Schritt 5 ausdrücklich per Häkchen — die Bestätigung ist eine bewusste Zusicherung, dass Du diesen Schritt erledigt hast.

Schritt 4 — Zugangsdaten in PARITY.med hinterlegen

Zurück im Suite-Portal, Karte „Eigener Versandweg (Microsoft 365)" → das Einrichtungs-Formular ausfüllen:

Dann „Zugangsdaten speichern". Das Speichern legt den Weg an und aktiviert ihn zugleich; als Nächstes bestätigst Du Consent/Scoping und sendest die Testmail.

💡 Stimmt die Domain der Absenderadresse nicht mit der Absender-Domain überein (z. B. Adresse @gmx.de, Domain mein-fachhandel.de), lehnt PARITY.med das ab — die beiden müssen zusammenpassen, sonst greift DMARC nicht.

Schritt 5 — Consent/Scoping bestätigen, Testmail bestätigen und Versand freischalten

Nach dem Speichern führt Dich die Karte durch die letzten beiden Punkte:

1. Admin-Consent & Postfach-Scoping bestätigen: Setze das Häkchen „Ich bestätige: Admin-Consent erteilt und die App auf das Absender-Postfach gescopt." Damit bestätigst Du, dass die Schritte 2 und 3 erledigt sind.
2. Testmail bestätigen: „Testmail senden" klicken — PARITY.med schickt über Deine M365-App eine Testmail mit einem 6-stelligen Code an Deine Login-Adresse. Ein erfolgreicher Versand belegt, dass Admin-Consent erteilt und Mail.Send nutzbar ist. Den Code aus der Mail eingeben und „Code bestätigen". Der Code ist 30 Minuten gültig; kam keine Mail an, hilft „Erneut senden".

Nach erfolgreicher Bestätigung trägt der Weg das Badge „Verifiziert".

✅ Dieser Code-Schritt ist die bewusste Sicherheitsschwelle: Er beweist, dass über Deinen eigenen Weg tatsächlich zugestellt werden kann, bevor PARITY.med produktive Belege darüber verschickt.

Überblick

Standardmäßig versendet PARITY.med Deine E-Mails zentral über die verifizierte parity.med-Adresse — zuverlässig, aber der Absender ist nicht Deine eigene Domain. Mit einer eigenen Microsoft-365-App gehen Rechnungen & Co. unter Deiner Absenderadresse (z. B. rechnung@mein-fachhandel.de) über Deinen eigenen Tenant raus.

Azure-AD-App + Client-Secret ──► Admin-Consent für Mail.Send ──► App aufs Postfach scopen
        ──► Zugangsdaten in PARITY hinterlegen ──► Testmail-Code bestätigen ──► eigener Versand aktiv

ℹ️ Model B — Kundeneigene App: Die App-Registrierung und der Admin-Consent entstehen in Deinem Microsoft-365-Tenant; Du bist eigener Vertragspartner Microsofts, PARITY.med ist nur der Versand-Vermittler. Deshalb liegen Registrierung, Consent und Scoping in Deiner Hand.

Voraussetzungen

• Administrator-Rechte im Suite-Portal.
• Ein Microsoft-365-/Entra-ID-Tenant mit Administrator-Rechten (App-Registrierung, Admin-Consent, Exchange Online PowerShell).
• Ein Absender-Postfach auf Deiner eigenen Domain.

Wie schalte ich den eigenen Versandweg wieder ab?

In der Karte gibt es zwei Wege:

• „Deaktivieren (→ zentral)" — der Versand läuft sofort wieder zentral über parity.med, die hinterlegten Zugangsdaten bleiben erhalten. Zum jederzeitigen Umschalten gedacht: mit „Aktivieren" schaltest Du wieder auf M365.
• „Löschen" — die Zugangsdaten (inkl. Client-Secret) werden entfernt. Für einen erneuten Versand richtest Du den Weg neu ein.

FAQ

F: Muss ich DNS-Einträge setzen wie beim Brevo-Weg?

A: Nein. Microsoft 365 signiert Deine Domain out-of-box per DKIM — es gibt keinen DNS-Self-Service-Schritt. Die „Verifizierung" ist hier der erfolgreiche Testversand mit Bestätigungscode.

F: Warum ist das Postfach-Scoping (ApplicationAccessPolicy) so wichtig?

A: Die Anwendungsberechtigung Mail.Send erlaubt der App ohne Beschränkung, aus jedem Postfach Deines Tenants zu senden. Die ApplicationAccessPolicy grenzt das auf genau Dein Absender-Postfach ein. PARITY.med kann diese Beschränkung technisch nicht nachprüfen — deshalb bestätigst Du sie in der Karte ausdrücklich. Ohne Scoping ist der Versandweg ein unnötiges Sicherheitsrisiko.

F: Ich habe das Client-Secret verloren / es wird nicht mehr angezeigt. Was tun?

A: Das ist normal — PARITY.med zeigt das Secret aus Sicherheitsgründen nie wieder an. Erzeuge in Azure unter „Zertifikate & Geheimnisse" ein neues Client-Secret und hinterlege es über „Zugangsdaten ändern" erneut.

F: Die Testmail kommt nicht an bzw. der Testversand schlägt fehl.

A: Häufigste Ursachen: (1) Der Admin-Consent für Mail.Send (Anwendungsberechtigung) ist noch nicht erteilt. (2) Die ApplicationAccessPolicy schließt das Absender-Postfach versehentlich aus — mit Test-ApplicationAccessPolicy prüfen (muss Granted sein). (3) Die Zugangsdaten (Tenant-ID, Client-ID, Client-Secret) sind nicht korrekt hinterlegt. (4) Deine Login-Adresse steht auf der Bounce-/Suppression-Liste — dann würde die Testmail übersprungen; in den Bounce-Einstellungen aufheben.

F: Was ist der Unterschied zwischen „Deaktivieren" und „Löschen"?

A: „Deaktivieren" schaltet nur den aktiven Weg zurück auf zentral, behält aber Deine Zugangsdaten und die Verifizierung — praktisch zum kurzfristigen Umschalten. „Löschen" entfernt die Zugangsdaten (inkl. Secret) vollständig.

F: Kann ich verschiedene Absenderadressen pro Dokumenttyp einstellen (z. B. Rechnung vs. Angebot)?

A: Nein, es gibt aktuell eine aktive Absenderadresse pro Mandant für den eigenen Weg. Versand getrennt nach Filiale oder Dokumenttyp ist derzeit nicht vorgesehen — melde Dich beim Support, wenn Du das benötigst.

Verwandte Themen

• Eigenen E-Mail-Versandweg über Brevo einrichten — der alternative eigene Weg über einen Brevo-Account (mit DNS-Self-Service).
• Mail-Provider-Status verstehen und Bounces aufheben — erklärt, über welchen Weg PARITY.med gerade sendet und wie die Bounce-Liste funktioniert.
• Bei Fragen zur Einrichtung: support@parity-software.com (Betreff: „Eigener M365-Versandweg").

Letzte Aktualisierung: 2026-07-14