Custom email health rules maken: geavanceerde monitoringconfiguratie

Van standaard naar custom email health rules#

Standaard email health checks verifiëren basisrecords: "Heb je MX? Heb je SPF? Heb je DKIM?"

Maar e-mailinfrastructuur in de praktijk is genuanceerder:

• Je gebruikt 5 verschillende e-maildiensten (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Elk heeft SPF-includes nodig
• Je hebt meerdere DKIM-selectors (één per dienst)
• Je migreert van e-mailprovider (oude DKIM-selector staat er nog, nieuwe wordt opgezet)
• Je dwingt een strikte DMARC-policy af (p=reject) maar moet voorkomen dat je legitieme e-mail blokkeert

Standaard checks slagen of falen. Custom rules pakken complexiteit aan.

Deze gids laat zien hoe je geavanceerde email health rules opzet voor geavanceerde e-mailinfrastructuur.

Custom rule #1: multi-selector DKIM-configuratie#

Als je meerdere e-maildiensten gebruikt, heb je meerdere DKIM-selectors.

Het probleem#

Scenario: Je gebruikt SendGrid voor transactionele e-mail en Mailgun voor marketing-e-mail.

DNS-configuratie:

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

Standaard monitoring zegt "DKIM configured" (pass), maar verifieert niet:

• Of beide selectors actief zijn
• Of beide selectors geldige sleutels hebben
• Of beide netjes geroteerd worden

De oplossing: een custom rule#

Maak een rule: "Alert als een DKIM-selector ontbreekt"

Rule Name: DKIM Redundancy Check
Condition: s1._domainkey moet bestaan EN s2._domainkey moet bestaan
Alert If: Een van beide selectors ontbreekt
Severity: Warning (niet critical)
Notification: "DKIM-redundantie aangetast. SendGrid-selector ontbreekt."

Implementatie (indien Nova Uptime ondersteund):

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: SPF lookup-limiet monitoren#

SPF heeft een limiet van 10 DNS-lookups (RFC 7208). Bij meer dan 10 lookups faalt SPF-authenticatie stilletjes.

Het probleem#

Je 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

Elke include:-directive gebruikt 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 (direct IP, geen DNS)

Totaal: 8 lookups (onder de limiet, je zit veilig)

Maar wat als je nog een dienst toevoegt?

De oplossing: een custom rule#

Maak een rule: "Alert als SPF-lookups de limiet naderen"

Rule Name: SPF Lookup Limit
Condition: Tel DNS-lookups in SPF-record
Alert If: Lookups > 8 (buffer van 2 lookups overlaten)
Severity: Warning
Recommendation: SPF-includes consolideren of SPF-flattening service gebruiken

Waarom dit ertoe doet:

• Standaard monitoring: SPF configured ✅
• Custom rule: SPF configured MAAR lookup-limiet wordt benaderd ⚠️

De custom rule vangt een probleem dat standaard monitoring mist.

Custom rule #3: DMARC-rapporten monitoren#

DMARC levert rapporten met daarin hoeveel e-mails authenticatie hebben gefaald. Deze rapporten moeten gemonitord worden.

Het probleem#

Je DMARC-policy:

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

DMARC stuurt dagelijks rapporten naar dmarc@yourdomain.com. Deze rapporten tonen:

• % e-mails die SPF passeren
• % e-mails die DKIM passeren
• % e-mails die op beide falen (spoofing-pogingen)

Als je nooit naar deze rapporten kijkt, mis je security-inzichten.

De oplossing: een custom rule#

Maak een rule: "Alert als DMARC-rapport een ongebruikelijk failure rate toont"

Rule Name: DMARC Failure Rate Monitoring
Check: DMARC-rapporten dagelijks ontvangen
Alert If: Failure rate van legitieme mail > 1% (wijst op SPF/DKIM-issue)
Alert If: Spoofing-pogingen > 5% (wijst erop dat domein een doelwit is)
Severity: Warning bij failures, Critical bij veel spoof-pogingen

Voorbeeldalert:

⚠️ DMARC Alert: Ongebruikelijke activiteit gedetecteerd
Domein: yourdomain.com
Rapportdatum: 20 feb 2026

Legitieme mail-failures: 12% (normaal: <1%)
Waarschijnlijke oorzaak: Nieuwe e-maildienst toegevoegd zonder SPF/DKIM
Actie: Verifieer dat SendGrid DKIM correct rouleert

Spoofing-pogingen: 2% (normaal: <0,1%)
Waarschijnlijke oorzaak: Domein wordt gebruikt in phishingcampagnes
Actie: Check de DMARC-policy (momenteel p=reject, goed)

Custom rule #4: e-maildienst rotatie-workflow#

Als je migreert van de ene e-maildienst naar de andere, heb je een tijdelijke periode nodig waarin de DKIM-selectors van beide diensten naast elkaar bestaan.

Het probleem#

Scenario: Migratie van SendGrid naar Mailgun.

Oude staat (vóór migratie):

s1._domainkey (SendGrid DKIM)

Overgangsstaat (tijdens migratie):

s1._domainkey (SendGrid DKIM) ← Oude dienst, wordt uitgefaseerd
s2._domainkey (Mailgun DKIM) ← Nieuwe dienst

Tijdens deze periode:

• Je SPF includeert beide diensten
• Beide DKIM-selectors bestaan
• E-mails van beide diensten authenticeren

Nieuwe staat (na cutover):

s1._domainkey (SendGrid DKIM) ← Verwijder dit
s2._domainkey (Mailgun DKIM)

Als je de oude DKIM-selector vergeet te verwijderen na cutover, heb je configuratie-drift.

De oplossing: een custom rule#

Maak een rule: "Alert na migratiedeadline"

Rule Name: SendGrid DKIM Removal Deadline
Type: Migration Tracking
Setup Date: 15 feb 2026 (start migratie)
Expected Cutover: 22 feb 2026
Alert If: SendGrid DKIM nog aanwezig na 25 feb 2026
Severity: Warning
Message: "SendGrid DKIM-selector (s1) had 3 dagen geleden verwijderd moeten zijn"

Custom rule #5: DMARC-policy evolutieworkflow#

Bedrijven laten hun DMARC-policy vaak in stappen evolueren:

1. Dag 1: p=none (geen handhaving, alleen monitoring)
2. Week 2: p=quarantine (failures naar spam, niet rejecten)
3. Maand 2: p=reject (failures rejecten, strikte handhaving)

Deze evolutie laat je impact monitoren voordat je strict gaat.

Het probleem#

Je bent van plan om van p=quarantine naar p=reject te gaan. Je moet verifiëren dat alles werkt voordat je de harde lijn trekt.

De oplossing: een custom rule#

Maak een rule: "Alert bij wijziging van de DMARC-policy"

Rule Name: DMARC Policy Evolution Tracking
Phase 1 (1 feb): Deploy p=quarantine
  Milestone: Monitor 2 weken
  Alert If: Failure rate legitieme mail > 1% (wijst op SPF/DKIM-issues)

Phase 2 (15 feb): Naar p=reject
  Vereiste: Bevestigen geen legitieme failures in fase 1
  Alert If: Niet alle vereiste checks passeren

Phase 3 (1 mrt): Verifieer adoptie
  Alert If: Spoofing-pogingen gedetecteerd (suggereert dat reject werkt)

Custom rule #6: third-party e-maildiensten verifiëren#

Je besteedt e-mailverzending uit aan diensten als Twilio, SendGrid of Mailgun. Je moet verifiëren dat ze correct geconfigureerd zijn.

Het probleem#

SendGrid belooft: "We versturen e-mails vanaf jouw domein met correcte SPF/DKIM."

Maar wat als ze het aan hun kant verkeerd configureren? Of hun DNS bijwerken zonder het je te vertellen?

De oplossing: een custom rule#

Maak een rule: "Verifieer dat third-party e-maildiensten correct authenticeren"

Rule Name: SendGrid Configuration Verification
Check: SendGrid's DKIM-key matcht jouw DNS-record
Check: SendGrid's SPF-include zit in jouw SPF-record
Check: SendGrid domain authentication is "verified" (niet pending)
Alert If: Een van de checks faalt
Severity: Critical
Action: "Neem contact op met SendGrid-support. Domain auth is mogelijk verlopen."

Custom rule #7: email health baseline-vergelijking#

Email health verandert. Je wilt weten wanneer er iets is veranderd ten opzichte van de baseline.

Het probleem#

Je email health score was vorige maand 92. Deze maand is hij 88. Is er iets stuk?

Standaard monitoring alert op absolute scores. Custom rules alert op veranderingen.

De oplossing: een custom rule#

Maak een rule: "Alert bij significante afwijking van de baseline"

Rule Name: Email Health Regression Detection
Baseline: Score van 1 feb (92/100)
Threshold: Alert als score >5 punten daalt
Alert If: Huidige score < 87
Severity: Warning
Message: "Email health is verslechterd van 92 naar 88 (waarschijnlijke oorzaak: DKIM-key rotatie)"

Custom rule #8: compliance-audit rules#

Als je gereguleerd bent (HIPAA, SOC2, PCI-DSS), heb je specifieke configuraties nodig.

Voorbeeld: zorgsector-compliance#

Vereisten:

• DMARC p=reject (strikte handhaving)
• SPF -all (geen soft failures)
• DKIM op zowel primair als backup-domein
• TLS voor alle uitgaande e-mail
• E-mailversleuteling voor gevoelige data

Custom rule:

Rule Name: HIPAA Email Compliance Check
Vereiste 1: DMARC-policy moet p=reject zijn
  Alert If: Policy is p=quarantine of p=none

Vereiste 2: SPF moet eindigen op -all
  Alert If: SPF eindigt op ~all (soft fail)

Vereiste 3: DKIM op backup-domein verplicht
  Alert If: Backup-domein mist DKIM

Vereiste 4: TLS verplicht voor alle e-mail
  Alert If: Niet-TLS e-mail vanuit het systeem

Vereiste 5: Gevoelige e-mail moet versleuteld
  Alert If: E-mail met PII gebruikt geen S/MIME of PGP

Custom rules in de praktijk implementeren#

Optie 1: Gebruik ingebouwde rules van je monitoringtool#

Als je monitoringtool (zoals Nova Uptime) custom rules ondersteunt, gebruik je hun dashboard:

1. Ga naar de domein-instellingen
2. Klik op "Custom Rules"
3. Kies een rule-type (SPF lookup count, DKIM selector, enz.)
4. Stel thresholds in
5. Configureer alerts
6. Opslaan

Optie 2: Gebruik webhooks naar een custom systeem#

Ondersteunt je monitoringtool geen custom rules, gebruik dan 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");
}

Optie 3: Handmatige maandelijkse audit#

Als geen van bovenstaande opties beschikbaar is:

1. Exporteer email health-data uit je monitoringtool
2. Maak een spreadsheet met custom kolommen
3. Maandelijkse review tegen de vereisten
4. Waarschuw het team als er iets is veranderd

Veelgemaakte fouten met custom rules#

Fout 1: Te veel custom rules#

Probleem: 50 custom rules aanmaken, overspoeld worden door alerts, ze allemaal negeren.

Oplossing: Begin met 3-5 kritieke rules. Voeg er naar behoefte meer toe.

Fout 2: Rules zonder action items#

Probleem: "Alert if SPF lookups > 8" gaat af, maar het team weet niet wat te doen.

Oplossing: Elke rule moet action items bevatten:

If: SPF lookups > 8
Alert Message: "SPF lookup-limiet wordt benaderd.
Oplossing: Consolideer includes via een SPF-flattening service.
Meer info: https://knowledge.spf-flattening.com"

Fout 3: Rules niet testen#

Probleem: 6 maanden geleden een custom rule opgezet. Nooit geverifieerd of hij echt afgaat als de conditie wordt gehaald.

Oplossing: Test rules elk kwartaal:

1. Trigger de conditie bewust (bv. handmatig een extra SPF-include toevoegen)
2. Wacht op de alert
3. Verifieer dat de alert klopt
4. Verwijder de testtrigger

Fout 4: Rules drijven af van de werkelijkheid#

Probleem: DMARC-evolution rule in feb opgezet. Vergeten te updaten. Het is nu juni en de rule is verouderd.

Oplossing: Review custom rules elk kwartaal. Update als de business changed.

Samenvatting: checklist custom email health rules#

• ✅ Identificeer je e-mailinfrastructuur (hoeveel diensten? selectors?)
• ✅ Zet een DKIM-redundantie-rule op (meerdere selectors)
• ✅ Zet een SPF-lookup-limit rule op (waarschuwen bij 8 lookups)
• ✅ Zet DMARC-rapport monitoring op (ongebruikelijke failure rates)
• ✅ Zet rules op voor migraties van e-maildiensten (bij providerwissel)
• ✅ Zet rules op voor DMARC-policy evolutie (bij geleidelijke aanscherping)
• ✅ Zet compliance-rules op (in een gereguleerde sector)
• ✅ Test elke rule om te verifiëren dat hij werkt
• ✅ Documenteer rules voor het team
• ✅ Audit en refresh elk kwartaal

Begin vandaag#

Standaard email health monitoring is goed. Custom email health rules maken het top.

Als je Nova Uptime gebruikt, ga naar je domein-instellingen en maak custom rules op basis van jouw unieke infrastructuur. Als je tool nog geen custom rules ondersteunt, gebruik webhooks of handmatige audits.

Je e-mailinfrastructuur is te belangrijk om alleen op standaard checks te vertrouwen. Custom rules zorgen ervoor dat je problemen specifiek voor jouw setup oppikt voordat ze je klanten raken.