// page

Anleitung: MailGuard

itdatex MailGuard macht aus deiner WordPress-Seite ein Multi-Tenant-Portal: deine eigenen Kunden registrieren sich, verbinden ihre Postfächer (per OAuth-Klick oder klassischem IMAP mit Auto-Discovery) und lassen sie automatisch gegen sechs parallele Signale prüfen (Heuristik + SPF/DKIM/DMARC + URLhaus + Google Safe Browsing + AbuseIPDB + !tdatex KI-Deep-Mode). Anhänge werden zusätzlich per ClamAV gestreamt. Neben dem Verdict bekommt jeder Kunde eine nach Absender gruppierte Inbox, Bulk-Newsletter-Abmeldung (RFC 8058 mit mailto-Fallback), Quarantäne mit 7-Tage-Undo, „Vernichten” pro Absender (Best-effort-Abmelden + Blacklist-Regel + IMAP-EXPUNGE) und eine Auto-Vernichten-Liste für ganze Absender-Domains — jede eingehende Mail dieser Domains wird bereits beim IMAP-Abruf verworfen und landet nie in der Inbox. Ein Regel-System (Whitelist/Blacklist), eine Live-Notifications-Bell im Portal-Header sowie ein nativer Windows-Desktop-Client (Tray-Icon, Windows-Toasts, Autostart) runden die Endkunden-UX ab. Alle Ordner des Postfachs werden automatisch übernommen — auch neue, die der Kunde später in seinem Mail-Client anlegt. Diese Anleitung richtet sich an dich als Site-Owner.

1. Voraussetzungen

  • WordPress 6.4 oder neuer, PHP 8.1 oder neuer
  • HTTPS auf der eigenen Domain (Pflicht für OAuth-Redirects)
  • WP-Cron muss laufen — echter System-Cron empfohlen (siehe Punkt 9), sonst stocken Pull und Scan bei wenig Traffic
  • Erreichbare ausgehende SMTP-Verbindung für Confirmation-Mails (Resend, SES oder eigener Postfix)
  • Abrechnung läuft pro Site monatlich über Stripe — 49 €/Monat, du legst eigene Preise für deine Endkunden fest

2. Installation

  1. Plugin im !tdatex-Shop als Subscription abschließen — du erhältst Plugin-ZIP und einen Site-Lizenzschlüssel.
  2. WP-Admin → Plugins → Installieren → Plugin hochladen → ZIP auswählen → Installieren und Aktivieren.
  3. Im Admin-Menü erscheint MailGuard.

3. Lizenz aktivieren

  1. MailGuard → Einstellungen → Lizenz öffnen, Schlüssel aus der Bestell-Mail einfügen, speichern.
  2. Die Statusanzeige bestätigt deine Subscription-Periode und den nächsten Stripe-Einzug.
  3. Bei past_due läuft das Portal weiter (Grace-Phase), bei canceled werden neue Customer-Registrierungen blockiert — bestehende Kunden behalten Zugriff bis zum Periodenende.

4. Portal-Seite einrichten

Das Plugin legt automatisch die Endpoints unter /portal/* an:

  • /portal/register — Kundenregistrierung mit E-Mail-Bestätigung
  • /portal/login — Customer-Login (getrennt von WP-Usern)
  • /portal/dashboard — Übersicht für eingeloggte Kunden
  • /portal/accounts — IMAP-/OAuth-Postfächer verbinden, Autoconfig + Auto-Folder-Sync
  • /portal/inbox — gescannte Mails mit Verdict, wahlweise chronologisch oder nach Absender gruppiert
  • /portal/newsletters — Newsletter pro Sender abmelden inkl. mailto-Fallback und DSN-Monitor
  • /portal/actions — Audit-Log aller Aktionen (Quarantäne, Undo, Purge) mit Snapshot
  • /portal/rules — eigene Whitelist/Blacklist (Blacklist > Whitelist)
  • /portal/eradicate-domains — Auto-Vernichten-Liste für Absender-Domains, jede Mail dieser Domains wird beim IMAP-Abruf verworfen (kein Ingest, kein Papierkorb)
  • /portal/plan — Plan-Übersicht, Postfach-Quota und DSGVO-Consent für die KI-Tiefenanalyse
  • /portal/scanner — manueller URL-/E-Mail-Scanner
  • /portal/devices — Endkunden-Verwaltung der eigenen Web-/Mobile-/Desktop-Sessions inkl. Einzel-Revoke

Verlinke /portal/register in deiner Hauptnavigation oder erstelle eine WordPress-Page „Login” mit dem entsprechenden Hinweis.

5. Mail-Versand konfigurieren

  1. MailGuard → Einstellungen → E-Mail-Versand: Absender-Adresse und Anzeigename setzen.
  2. Empfohlen: separates SMTP-Plugin (z.B. WP Mail SMTP) oder eigener Postfix mit DKIM/SPF/DMARC, damit Confirmation-Mails nicht im Spam landen.
  3. Test-Mail an dich selbst senden — wenn sie ankommt, sind Registrierungen für Endkunden bereit.

6. OAuth-Anbieter konfigurieren (optional, aber empfohlen)

Damit deine Endkunden Outlook.com, Office 365, Gmail oder Google Workspace per 1-Klick verbinden können, registrierst du je eine OAuth-App.

6a. Microsoft 365 / Outlook.com

  1. portal.azure.comMicrosoft Entra IDApp registrationsNew registration
  2. Name z.B. „MailGuard auf meine-domain.de”, Account-Types: „Accounts in any organizational directory and personal Microsoft accounts” (Pflicht — sonst funktioniert outlook.com / Microsoft 365 Family nicht)
  3. Redirect URI (Web): aus MailGuard → Einstellungen → Microsoft 365 OAuth kopieren (Format: https://deine-domain/wp-json/itdatex-mailguard/v1/oauth/microsoft/callback)
  4. Certificates & secrets → neues Client Secret erstellen, Value sofort kopieren (wird nur 1× angezeigt)
  5. API permissions → Microsoft Graph → Delegated: IMAP.AccessAsUser.All, offline_access, User.Read, openid, email, profile — und „Grant admin consent” klicken
  6. Application (Client) ID + Client Secret + Tenant common in MailGuard → Einstellungen eintragen

6b. Google / Gmail / Google Workspace

  1. console.cloud.google.com → neues Projekt → APIs & Services → Library → „Gmail API” aktivieren
  2. OAuth consent screen → External → App-Name, Developer-Email, Test-Users eintragen (max 100 ohne Verifikation)
  3. Scope https://mail.google.com/ hinzufügen (Hinweis „restricted scope” ignorieren im Test-Modus)
  4. CredentialsOAuth client ID → Web application → Redirect URI aus MailGuard → Einstellungen → Google OAuth einfügen
  5. Client ID + Client Secret in MailGuard → Einstellungen eintragen
  6. Wichtig: App im OAuth consent screen NICHT auf „In Production” stellen, bevor du nicht das Verification-Verfahren durchlaufen hast — sonst bekommen neue User „access_denied”. Im Test-Modus dürfen die in der Test-Users-Liste eingetragenen Adressen die App nutzen.

7. Endkunden onboarden

Sobald ein Kunde sich unter /portal/register registriert und die E-Mail bestätigt, kann er sich einloggen und Postfächer verbinden:

  • „🔑 Mit Microsoft verbinden” — OAuth-Popup, Login, Consent, fertig
  • „🔑 Mit Google verbinden” — analog
  • „+ IMAP manuell” — Mailadresse eingeben, Host/Port/SSL werden automatisch erkannt (statische DB → Mozilla ISPDB → MS Autodiscover → DNS SRV)

Cron pullt alle 15 Minuten, der Scan-Worker arbeitet alle 5 Minuten Mails ab. Endkunden können in /portal/rules eigene Whitelist-/Blacklist-Regeln anlegen und in /portal/newsletters per Klick komplette Newsletter-Sender abmelden (RFC-8058 One-Click).

8. Site-Owner-Admin verwenden

WP-Admin → MailGuard zeigt alle Endkunden inklusive Stats, Such-/Sperr-/Lösch-Aktionen sowie Lizenz-Status mit Stripe-Subscription-Periode.

9. WP-Cron auf System-Cron umstellen (empfohlen)

Standard-WP-Cron läuft nur bei Page-Requests — bei wenig Traffic stocken Pull und Scan stundenlang. Saubere Lösung: WP-Cron deaktivieren und über systemd-Timer triggern.

  1. In wp-config.php ergänzen: define( 'DISABLE_WP_CRON', true );
  2. systemd-Unit anlegen unter /etc/systemd/system/wp-cron-deine-site.service mit ExecStart /usr/local/bin/wp --skip-themes cron event run --due-now --quiet (User www-data, WorkingDirectory dein WordPress-Root)
  3. systemd-Timer anlegen unter /etc/systemd/system/wp-cron-deine-site.timer mit OnUnitActiveSec=1min
  4. systemctl enable --now wp-cron-deine-site.timer

Alternativ klassisch per crontab: * * * * * cd /pfad/zu/wp && wp cron event run --due-now --quiet

Unterstützte Mail-Anbieter (Auto-Discovery-Datenbank)

Die folgenden Anbieter werden vom Plugin automatisch erkannt, sobald der Endkunde seine E-Mail-Adresse im Verbinden-Formular eingibt. Host/Port/Verschlüsselung werden vorausgefüllt; bei OAuth-Anbietern erscheint stattdessen direkt der „Mit Microsoft/Google verbinden”-Button. Für nicht gelistete Anbieter probiert das Plugin in dieser Reihenfolge: Mozilla ISPDB → Microsoft Autodiscover → DNS SRV-Records — die meisten Custom-Domains auf Hostern wie Mittwald, all-inkl, Hetzner, Plesk, cPanel werden so automatisch konfiguriert.

Anbieter / DomainIMAP-HostPortAuthAnmerkung
Gmail · gmail.com, googlemail.comimap.gmail.com993 SSLOAuth (Google)OAuth-Connect bevorzugt; alternativ App-Passwort + 2FA
Microsoft 365 / Outlook · outlook.com, hotmail.com, hotmail.de, live.com, live.de, msn.com, outlook.deoutlook.office365.com993 SSLOAuth (Microsoft)Basic Auth seit 2022 deaktiviert — OAuth ist Pflicht
GMX · gmx.de, gmx.net, gmx.at, gmx.chimap.gmx.net993 SSLPasswortPOP3/IMAP-Zugang in den GMX-Einstellungen zuerst aktivieren
GMX International · gmx.comimap.gmx.com993 SSLPasswortPOP3/IMAP-Zugang in den GMX-Einstellungen aktivieren
Web.de · web.deimap.web.de993 SSLPasswortPOP3/IMAP-Zugang in den Web.de-Einstellungen aktivieren
mail.de · mail.deimap.mail.de993 SSLPasswort
Telekom / T-Online · t-online.de, magenta.desecureimap.t-online.de993 SSLPasswortE-Mail-Passwort separat im Telekom-Kundencenter setzen
IONOS / 1&1 · ionos.de, 1und1.de (auch Custom-Domains)imap.ionos.de993 SSLPasswort
Strato · strato.de (auch Custom-Domains)imap.strato.de993 SSLPasswort
Mailbox.org · mailbox.orgimap.mailbox.org993 SSLPasswort
Posteo · posteo.de, posteo.net, posteo.orgposteo.de993 SSLPasswort
Yahoo Mail · yahoo.com, yahoo.de, ymail.comimap.mail.yahoo.com993 SSLApp-PasswortApp-Passwort im Yahoo-Konto unter Account Security erstellen
Apple iCloud · icloud.com, me.com, mac.comimap.mail.me.com993 SSLApp-PasswortApp-spezifisches Passwort auf appleid.apple.com erstellen (2FA Pflicht)
FastMail · fastmail.com, fastmail.fmimap.fastmail.com993 SSLApp-PasswortApp-Passwort in den FastMail-Settings erstellen
Zoho Mail (US) · zoho.comimap.zoho.com993 SSLPasswort
Zoho Mail (EU) · zoho.euimap.zoho.eu993 SSLPasswort
Yandex Mail · yandex.comimap.yandex.com993 SSLPasswort
Yandex Mail (RU) · yandex.ruimap.yandex.ru993 SSLPasswort
AOL Mail · aol.comimap.aol.com993 SSLApp-PasswortApp-Passwort im AOL-Konto erstellen
ProtonMail · protonmail.com, proton.meBridgeKein klassisches IMAP — Endkunde braucht die ProtonMail-Bridge-Software (Plus-Plan), die einen lokalen IMAP-Proxy bereitstellt
Tuta / Tutanota · tuta.com, tutanota.comKein IMAP-Support (E2E-verschlüsselt)
Apple Hide-My-Email · privaterelay.appleid.comForwarding-Adresse, kein direktes Postfach

Custom-Domains und unbekannte Anbieter

Für Mailadressen mit eigener Domain (z.B. info@deinefirma.de) probiert das Plugin in dieser Reihenfolge:

  1. Mozilla ISPDB — die offene Thunderbird-Provider-Datenbank kennt mehrere hundert Hoster weltweit (kabelmail, freenet, viele europäische ISPs)
  2. Microsoft Autodiscover — POST gegen autodiscover.{domain}/autodiscover/autodiscover.xml. Greift bei Custom-Domains auf Microsoft 365 (Firmen-Tenant) sowie viele deutsche Hoster mit Exchange-Anbindung
  3. DNS SRV-Records (RFC 6186) — _imaps._tcp.{domain} bzw. _imap._tcp.{domain}. Für selbst gehostete Mailserver mit korrekten SRV-Records (Mittwald, Plesk, cPanel, Hetzner-Premiummail, all-inkl etc.)
  4. !tdatex KI-Discovery — wenn die ersten vier Schritte nichts finden, fragt das Plugin die !tdatex KI, ob sie die IMAP-Settings der Domain kennt. Privacy: nur die Domain wird übermittelt, keine Mailadresse und kein Mail-Inhalt. Niedrige Confidence — das Ergebnis ist als Vorschlag zu verstehen und wird beim ersten Test-Connect auf Plausibilität geprüft.

Wenn auch der !tdatex KI-Schritt nichts brauchbares liefert, kann der Endkunde Host/Port/SSL manuell eintragen. Die Discovery-Lookups der ersten vier Stufen laufen alle auf unserem Server in Deutschland (DNS- und HTTP-Anfragen). Die fünfte Stufe übermittelt nur den Domain-Namen an unsere !tdatex KI (Cloud-Inferenz bei Ollama Inc., USA) — niemals Mail-Inhalte oder Mailadressen.

Häufige Fehler

  • „Registrierung nicht möglich” → Lizenz ist canceled; im Shop unter Mein Konto → Lizenzen Subscription reaktivieren.
  • Kunden bekommen keine Confirmation-Mails → SMTP-Konfiguration prüfen, am besten WP Mail SMTP installieren.
  • Microsoft-OAuth: „unauthorized_client: not enabled for consumers” → Account-Type der Azure-App muss „Accounts in any organizational directory and personal Microsoft accounts” sein. Lässt sich nach Registration meist nicht mehr ändern — neue App anlegen.
  • Microsoft-OAuth: „Office 365 Exchange Online” fehlt in der Permission-Liste → Bei Personal-/Family-Tenants nicht verfügbar. Stattdessen Microsoft Graph → Delegated → IMAP.AccessAsUser.All verwenden, funktioniert genauso.
  • Google-OAuth: „access_denied” → Test-User ist nicht in der OAuth-Consent-Screen-Liste eingetragen. In Google Cloud Console → OAuth consent screen → Test users → Adresse hinzufügen.
  • Google-OAuth: „App not verified” Warning → Normal im Test-Modus. Endkunden klicken „Erweitert → Weiter zu deine-domain (unsicher)”. Verifikation bei Google einreichen, wenn > 100 Test-User produktiv werden sollen (Dauer ~4-6 Wochen).
  • IMAP-Cron läuft nicht alle 15 Minuten → System-Cron einrichten (Punkt 9 oben).
  • Zu viele false-positive „suspicious”-Verdicts → Endkunde legt in /portal/rules Whitelist-Einträge für legitime Sender an. Whitelist gewinnt vor KI-Bewertung.
  • Scan-Worker stockt → Action Scheduler-Upgrade-Pfad ist vorgesehen; bei sehr vielen Kunden Support kontaktieren.

Fragen? Schreib an shop@wp.itdatex.support — wir antworten in der Regel innerhalb eines Werktags.