So erstellst du benutzerdefinierte E-Mail-Health-Regeln: Erweiterte Monitoring-Konfiguration

Von Standard- zu benutzerdefinierten E-Mail-Health-Regeln#

Standard-E-Mail-Health-Checks prüfen die Basics: „Hast du einen MX-Record? Hast du SPF? Hast du DKIM?"

Aber echte E-Mail-Infrastruktur ist deutlich komplexer:

• Du nutzt 5 verschiedene E-Mail-Dienste (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Jeder braucht SPF-Includes
• Du hast mehrere DKIM-Selektoren (einen pro Dienst)
• Du migrierst gerade deinen E-Mail-Anbieter (alter DKIM-Selektor noch da, neuer wird gerade aufgesetzt)
• Du erzwingst eine strenge DMARC-Richtlinie (p=reject), willst aber legitime E-Mails nicht abwürgen

Standard-Checks sind pass/fail. Benutzerdefinierte Regeln meistern Komplexität.

Dieser Guide zeigt dir, wie du erweiterte E-Mail-Health-Regeln für anspruchsvolle E-Mail-Infrastruktur einrichtest.

Custom Rule #1: Multi-Selektor-DKIM-Konfiguration#

Wenn du mehrere E-Mail-Dienste nutzt, hast du auch mehrere DKIM-Selektoren.

Das Problem#

Szenario: Du nutzt SendGrid für Transaktions-E-Mails und Mailgun für Marketing-E-Mails.

DNS-Konfiguration:

s1._domainkey.yourdomain.com → SendGrid DKIM key
s2._domainkey.yourdomain.com → Mailgun DKIM key

Standard-Monitoring sagt „DKIM konfiguriert" (pass), prüft aber nicht:

• Ob beide Selektoren aktiv sind
• Ob beide Selektoren gültige Keys haben
• Ob beide korrekt rotiert werden

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert, wenn ein DKIM-Selektor fehlt"

Rule Name: DKIM Redundancy Check
Condition: s1._domainkey must exist AND s2._domainkey must exist
Alert If: Either selector is missing
Severity: Warning (not critical)
Notification: "DKIM redundancy compromised. SendGrid selector missing."

Implementierung (sofern Nova Uptime das unterstützt):

curl -X POST https://api.novauptime.com/api/v1/domains/yourdomain.com/rules \
  -H "X-API-Key: your-key" \
  -d '{
    "name": "DKIM Redundancy",
    "type": "dkim_selector_count",
    "condition": {
      "minSelectors": 2,
      "requiredSelectors": ["s1", "s2"]
    },
    "alert": {
      "threshold": "below",
      "severity": "warning"
    }
  }'

Custom Rule #2: Monitoring des SPF-Lookup-Limits#

SPF hat ein Limit von 10 DNS-Lookups (RFC 7208). Überschreitest du die 10 Lookups, schlägt deine SPF-Authentifizierung still fehl.

Das Problem#

Dein SPF-Record:

v=spf1 \
  include:sendgrid.net \
  include:mailgun.org \
  include:_spf.google.com \
  include:amazonses.com \
  include:mailchimp.org \
  include:zoho.com \
  include:github.com \
  include:discourse.org \
  ip4:192.0.2.1 \
  -all

Jede include:-Direktive verbraucht 1 DNS-Lookup:

• sendgrid.net: 1 Lookup
• mailgun.org: 1 Lookup
• _spf.google.com: 1 Lookup
• amazonses.com: 1 Lookup
• mailchimp.org: 1 Lookup
• zoho.com: 1 Lookup
• github.com: 1 Lookup
• discourse.org: 1 Lookup
• ip4: 0 Lookups (direkte IP, kein DNS)

Gesamt: 8 Lookups (unter dem Limit, du bist safe)

Aber was passiert, wenn du noch einen Dienst dazunimmst?

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert, wenn SPF-Lookups sich dem Limit nähern"

Rule Name: SPF Lookup Limit
Condition: Count DNS lookups in SPF record
Alert If: Lookups > 8 (leaving 2-lookup buffer)
Severity: Warning
Recommendation: Consolidate SPF includes or use SPF flattening service

Warum das wichtig ist:

• Standard-Monitoring: SPF konfiguriert ✅
• Custom Rule: SPF konfiguriert, ABER nähert sich dem Lookup-Limit ⚠️

Die Custom Rule fängt ein Problem ab, das Standard-Monitoring übersieht.

Custom Rule #3: DMARC-Report-Monitoring#

DMARC liefert Reports, die zeigen, wie viele E-Mails die Authentifizierung nicht bestanden haben. Diese Reports solltest du im Auge behalten.

Das Problem#

Deine DMARC-Richtlinie:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

DMARC schickt täglich Reports an dmarc@yourdomain.com. Diese Reports zeigen:

• % der E-Mails, die SPF bestehen
• % der E-Mails, die DKIM bestehen
• % der E-Mails, die beides nicht bestehen (Spoofing-Versuche)

Wenn du nie in diese Reports schaust, entgehen dir wichtige Security-Insights.

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert, wenn der DMARC-Report eine ungewöhnliche Fehlerrate zeigt"

Rule Name: DMARC Failure Rate Monitoring
Check: DMARC reports received daily
Alert If: Legitimate mail failure rate > 1% (suggests SPF/DKIM issue)
Alert If: Spoofing attempt rate > 5% (suggests domain is being targeted)
Severity: Warning for failures, Critical for high spoof attempts

Beispiel-Alert:

⚠️ DMARC Alert: Unusual Activity Detected
Domain: yourdomain.com
Report Date: Feb 20, 2026

Legitimate Mail Failures: 12% (normal: <1%)
Probable Cause: New email service added without SPF/DKIM
Action: Verify SendGrid DKIM is rotating correctly

Spoofing Attempts: 2% (normal: <0.1%)
Probable Cause: Domain is being used in phishing campaigns
Action: Check DMARC policy (currently p=reject, good)

Custom Rule #4: Workflow für E-Mail-Dienst-Rotation#

Wenn du von einem E-Mail-Dienst zu einem anderen migrierst, brauchst du eine Übergangsphase, in der die DKIM-Selektoren beider Dienste parallel existieren.

Das Problem#

Szenario: Migration von SendGrid zu Mailgun.

Alter Stand (vor der Migration):

s1._domainkey (SendGrid DKIM)

Übergangsstand (während der Migration):

s1._domainkey (SendGrid DKIM) ← Alter Dienst, wird ausgephased
s2._domainkey (Mailgun DKIM) ← Neuer Dienst

Während dieser Phase:

• Dein SPF enthält beide Dienste
• Beide DKIM-Selektoren existieren
• E-Mails von beiden Diensten authentifizieren sich erfolgreich

Neuer Stand (nach dem Cutover):

s1._domainkey (SendGrid DKIM) ← Diesen entfernen
s2._domainkey (Mailgun DKIM)

Wenn du nach dem Cutover vergisst, den alten DKIM-Selektor zu entfernen, hast du Configuration Drift.

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert nach Migrations-Deadline"

Rule Name: SendGrid DKIM Removal Deadline
Type: Migration Tracking
Setup Date: Feb 15, 2026 (migration start)
Expected Cutover: Feb 22, 2026
Alert If: SendGrid DKIM still present after Feb 25, 2026
Severity: Warning
Message: "SendGrid DKIM selector (s1) should have been removed 3 days ago"

Custom Rule #5: Workflow für die Weiterentwicklung der DMARC-Policy#

Unternehmen entwickeln ihre DMARC-Richtlinie oft schrittweise weiter:

1. Tag 1: p=none (kein Enforcement, nur Monitoring)
2. Woche 2: p=quarantine (Fehler in Spam, nicht ablehnen)
3. Monat 2: p=reject (Fehler ablehnen, striktes Enforcement)

Diese Evolution erlaubt dir, die Auswirkungen zu beobachten, bevor du strikt wirst.

Das Problem#

Du planst den Wechsel von p=quarantine auf p=reject. Bevor du den harten Schnitt machst, willst du sicherstellen, dass alles läuft.

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert bei DMARC-Policy-Änderung"

Rule Name: DMARC Policy Evolution Tracking
Phase 1 (Feb 1): Deploy p=quarantine
  Milestone: Monitor for 2 weeks
  Alert If: Legitimate mail failure rate > 1% (suggests SPF/DKIM issues)

Phase 2 (Feb 15): Move to p=reject
  Pre-requisite: Confirm no legitimate failures in phase 1
  Alert If: Not all prerequisite checks passed

Phase 3 (Mar 1): Verify adoption
  Alert If: Spoofing attempts detected (suggests reject working)

Custom Rule #6: Verifikation von Drittanbieter-E-Mail-Diensten#

Du lagerst E-Mail-Versand an Dienste wie Twilio, SendGrid oder Mailgun aus. Du musst prüfen, ob die korrekt konfiguriert sind.

Das Problem#

SendGrid verspricht: „Wir versenden E-Mails von deiner Domain mit korrektem SPF/DKIM."

Aber was, wenn die auf ihrer Seite was falsch konfigurieren? Oder ihr DNS aktualisieren und dir Bescheid zu geben vergessen?

Die Lösung: Custom Rule#

Erstelle eine Regel: „Verifiziere, dass Drittanbieter-E-Mail-Dienste korrekt authentifiziert sind"

Rule Name: SendGrid Configuration Verification
Check: SendGrid's DKIM key matches your DNS record
Check: SendGrid's SPF include is in your SPF record
Check: SendGrid domain authentication is "verified" (not pending)
Alert If: Any check fails
Severity: Critical
Action: "Contact SendGrid support. Domain auth may have expired."

Custom Rule #7: E-Mail-Health-Baseline-Vergleich#

E-Mail-Health verändert sich. Du willst wissen, wenn sich gegenüber der Baseline etwas geändert hat.

Das Problem#

Letzten Monat war dein E-Mail-Health-Score 92. Diesen Monat sind es 88. Ist da was kaputtgegangen?

Standard-Monitoring alarmiert bei absoluten Werten. Custom Rules alarmieren bei Veränderungen.

Die Lösung: Custom Rule#

Erstelle eine Regel: „Alert bei signifikanter Abweichung von der Baseline"

Rule Name: Email Health Regression Detection
Baseline: Feb 1 score (92/100)
Threshold: Alert if score drops >5 points
Alert If: Current score < 87
Severity: Warning
Message: "Email health degraded from 92 to 88 (likely cause: DKIM key rotation)"

Custom Rule #8: Compliance-Audit-Regeln#

Wenn du regulatorischen Anforderungen unterliegst (HIPAA, SOC2, PCI-DSS), brauchst du spezifische Konfigurationen.

Beispiel: Healthcare-Compliance#

Anforderungen:

• DMARC p=reject (striktes Enforcement)
• SPF -all (keine Soft Failures)
• DKIM auf primärer und Backup-Domain
• TLS für sämtliche ausgehende E-Mails
• E-Mail-Verschlüsselung für sensible Daten

Custom Rule:

Rule Name: HIPAA Email Compliance Check
Requirement 1: DMARC policy must be p=reject
  Alert If: Policy is p=quarantine or p=none

Requirement 2: SPF must end with -all
  Alert If: SPF ends with ~all (soft fail)

Requirement 3: Must have DKIM on backup domain
  Alert If: Backup domain missing DKIM

Requirement 4: TLS required for all email
  Alert If: Non-TLS email from system

Requirement 5: Sensitive email must use encryption
  Alert If: Email containing PII doesn't use S/MIME or PGP

Custom Rules in der Praxis umsetzen#

Option 1: Built-in-Regeln des Monitoring-Tools nutzen#

Wenn dein Monitoring-Tool (zum Beispiel Nova Uptime) Custom Rules unterstützt, nutze das Dashboard:

1. Geh zu den Domain-Einstellungen
2. Klick auf „Custom Rules"
3. Wähle den Regeltyp (SPF-Lookup-Anzahl, DKIM-Selektor usw.)
4. Setze die Schwellwerte
5. Konfiguriere die Alerts
6. Speichern

Option 2: Webhooks an ein eigenes System#

Wenn dein Monitoring-Tool keine Custom Rules unterstützt, nutze Webhooks:

# Monitoring tool sends webhook:
POST /your-system/webhooks/email-health
{
  "domain": "yourdomain.com",
  "email_health": {
    "score": 88,
    "spf_lookups": 9,
    "dkim_selectors": 2,
    "dmarc_policy": "reject",
    "blacklist_status": "clean"
  }
}

# Your system evaluates rules:
if (email_health.spf_lookups > 9) {
  alert("SPF lookup limit approaching");
}
if (email_health.dmarc_policy !== "reject") {
  alert("DMARC policy not strict");
}

Option 3: Manuelles Monats-Audit#

Wenn keine der beiden Optionen oben verfügbar ist:

1. Exportiere E-Mail-Health-Daten aus dem Monitoring-Tool
2. Erstelle eine Tabelle mit eigenen Spalten
3. Monatlicher Review gegen die Anforderungen
4. Team alarmieren, wenn sich etwas verändert hat

Häufige Fehler bei Custom Rules#

Fehler 1: Zu viele Custom Rules#

Problem: Du erstellst 50 Custom Rules, wirst von Alerts überrollt und ignorierst dann alle.

Lösung: Starte mit 3–5 kritischen Regeln. Erweitere bei Bedarf.

Fehler 2: Regeln ohne Action Items#

Problem: „Alert, wenn SPF-Lookups > 8" feuert, aber das Team weiß nicht, was zu tun ist.

Lösung: Jede Regel sollte Action Items enthalten:

If: SPF lookups > 8
Alert Message: "SPF lookup limit approaching.
To fix: Consolidate includes using SPF flattening service.
More info: https://knowledge.spf-flattening.com"

Fehler 3: Regeln nicht testen#

Problem: Custom Rule vor 6 Monaten eingerichtet. Nie verifiziert, ob sie tatsächlich feuert, wenn die Bedingung erfüllt ist.

Lösung: Teste die Regeln vierteljährlich:

1. Bedingung absichtlich auslösen (z. B. manuell ein zusätzliches SPF-Include hinzufügen)
2. Auf den Alert warten
3. Verifizieren, dass der Alert korrekt ist
4. Test-Trigger entfernen

Fehler 4: Regeln driften von der Realität ab#

Problem: DMARC-Evolution-Regel im Februar gesetzt. Vergessen zu aktualisieren. Jetzt ist Juni und die Regel ist überholt.

Lösung: Review der Custom Rules vierteljährlich. Update, wenn sich Business-Anforderungen geändert haben.

Zusammenfassung: Checkliste für Custom E-Mail-Health-Regeln#

• ✅ Identifiziere deine E-Mail-Infrastruktur (wie viele Dienste? Selektoren?)
• ✅ Richte eine DKIM-Redundanz-Regel ein (mehrere Selektoren)
• ✅ Richte eine SPF-Lookup-Limit-Regel ein (Warnung bei 8 Lookups)
• ✅ Richte eine DMARC-Report-Monitoring-Regel ein (ungewöhnliche Fehlerraten)
• ✅ Richte Regeln für E-Mail-Dienst-Migrationen ein (falls du Anbieter wechselst)
• ✅ Richte Regeln für die DMARC-Policy-Evolution ein (falls du die Richtlinie schrittweise verschärfst)
• ✅ Richte Compliance-Regeln ein (in regulierten Branchen)
• ✅ Teste jede Regel auf Funktionsfähigkeit
• ✅ Dokumentiere die Regeln für dein Team
• ✅ Vierteljährliches Audit und Refresh

Heute starten#

Standard-E-Mail-Health-Monitoring ist gut. Custom E-Mail-Health-Regeln machen es richtig stark.

Wenn du Nova Uptime nutzt, geh in deine Domain-Einstellungen und erstelle Custom Rules basierend auf deiner individuellen Infrastruktur. Falls dein Tool noch keine Custom Rules unterstützt, nutze Webhooks oder manuelle Audits.

Deine E-Mail-Infrastruktur ist zu wichtig, um sich nur auf Standard-Checks zu verlassen. Custom Rules stellen sicher, dass du Probleme, die spezifisch für dein Setup sind, abfängst, bevor sie deine Kunden treffen.