Come creare regole email health personalizzate: configurazione monitoraggio avanzata

Da regole email health standard a personalizzate#

I controlli email health standard verificano i record di base: "Hai MX? Hai SPF? Hai DKIM?"

Ma l'infrastruttura email reale è più sfumata:

• Usi 5 servizi email diversi (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Ognuno ha bisogno di include SPF
• Hai più selettori DKIM (uno per servizio)
• Stai migrando provider email (vecchio selettore DKIM ancora presente, nuovo in fase di setup)
• Stai applicando una policy DMARC rigida (p=reject) ma devi stare attento a non rompere email legittime

I controlli standard passano/falliscono. Le regole personalizzate gestiscono la complessità.

Questa guida ti mostra come configurare regole email health avanzate per infrastrutture email sofisticate.

Regola personalizzata #1: configurazione DKIM multi-selettore#

Se usi più servizi email, hai più selettori DKIM.

Il problema#

Scenario: usi SendGrid per email transazionali e Mailgun per email marketing.

Configurazione DNS:

s1._domainkey.fliplink.me → SendGrid DKIM key
s2._domainkey.fliplink.me → Mailgun DKIM key

Il monitoraggio standard dice "DKIM configurato" (passato), ma non verifica:

• Entrambi i selettori sono attivi
• Entrambi hanno chiavi valide
• Entrambi vengono ruotati correttamente

La soluzione: regola personalizzata#

Crea una regola: "Avvisa se manca un selettore DKIM"

Nome regola: DKIM Redundancy Check
Condizione: s1._domainkey deve esistere AND s2._domainkey deve esistere
Avvisa se: uno dei selettori manca
Severità: avvertimento (non critico)
Notifica: "Ridondanza DKIM compromessa. Manca il selettore SendGrid."

Implementazione (se Nova Uptime supportata):

curl -X POST https://api.novauptime.com/api/v1/domains/fliplink.me/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"
    }
  }'

Regola personalizzata #2: monitoraggio limite di lookup SPF#

SPF ha un limite di 10 lookup DNS (RFC 7208). Superi i 10 lookup e l'autenticazione SPF fallisce silenziosamente.

Il problema#

Il tuo record SPF:

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

Ogni direttiva include: usa 1 lookup DNS:

• 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 lookup (IP diretto, no DNS)

Totale: 8 lookup (sotto il limite, sei al sicuro)

Ma se aggiungi un altro servizio?

La soluzione: regola personalizzata#

Crea una regola: "Avvisa se i lookup SPF si avvicinano al limite"

Nome regola: SPF Lookup Limit
Condizione: conta i lookup DNS nel record SPF
Avvisa se: lookup > 8 (lasciando un buffer di 2 lookup)
Severità: avvertimento
Raccomandazione: consolida gli include SPF o usa un servizio di SPF flattening

Perché è importante:

• Monitoraggio standard: SPF configurato (OK)
• Regola personalizzata: SPF configurato MA si avvicina al limite di lookup (attenzione)

La regola personalizzata cattura un problema che il monitoraggio standard si perde.

Regola personalizzata #3: monitoraggio dei report DMARC#

DMARC fornisce report che mostrano quante email hanno fallito l'autenticazione. Questi report dovrebbero essere monitorati.

Il problema#

La tua policy DMARC:

_dmarc.fliplink.me TXT "v=DMARC1; p=reject; rua=mailto:dmarc@fliplink.me"

DMARC invia report giornalieri a dmarc@fliplink.me. Questi report mostrano:

• % di email che passano SPF
• % di email che passano DKIM
• % di email che falliscono entrambi (tentativi di spoofing)

Se non guardi mai questi report, ti perdi insight di sicurezza.

La soluzione: regola personalizzata#

Crea una regola: "Avvisa se il report DMARC mostra un tasso di fallimento insolito"

Nome regola: DMARC Failure Rate Monitoring
Controllo: report DMARC ricevuti giornalmente
Avvisa se: tasso di fallimento mail legittime > 1% (suggerisce problema SPF/DKIM)
Avvisa se: tasso tentativi di spoofing > 5% (suggerisce che il dominio è sotto attacco)
Severità: avvertimento per fallimenti, critico per alti tentativi di spoof

Esempio di avviso:

Avviso DMARC: rilevata attività insolita
Dominio: fliplink.me
Data report: 20 Feb 2026

Fallimenti mail legittime: 12% (normale: <1%)
Causa probabile: nuovo servizio email aggiunto senza SPF/DKIM
Azione: verifica che la rotazione DKIM SendGrid funzioni correttamente

Tentativi di spoofing: 2% (normale: <0,1%)
Causa probabile: il dominio è usato in campagne phishing
Azione: controlla la policy DMARC (attualmente p=reject, buono)

Regola personalizzata #4: workflow di rotazione servizio email#

Quando migri da un servizio email a un altro, hai bisogno di un periodo temporaneo in cui i selettori DKIM di entrambi i servizi coesistono.

Il problema#

Scenario: migrazione da SendGrid a Mailgun.

Stato vecchio (prima della migrazione):

s1._domainkey (SendGrid DKIM)

Stato di transizione (durante la migrazione):

s1._domainkey (SendGrid DKIM) ← Vecchio servizio, in fase di dismissione
s2._domainkey (Mailgun DKIM) ← Nuovo servizio

Durante questo periodo:

• Il tuo SPF include entrambi i servizi
• Entrambi i selettori DKIM esistono
• Le email da entrambi i servizi si autenticano

Stato nuovo (dopo il cutover):

s1._domainkey (SendGrid DKIM) ← Rimuovi questo
s2._domainkey (Mailgun DKIM)

Se dimentichi di rimuovere il vecchio selettore DKIM dopo il cutover, hai una deriva di configurazione.

La soluzione: regola personalizzata#

Crea una regola: "Avvisa dopo la deadline di migrazione"

Nome regola: SendGrid DKIM Removal Deadline
Tipo: tracking migrazione
Data setup: 15 Feb 2026 (inizio migrazione)
Cutover previsto: 22 Feb 2026
Avvisa se: SendGrid DKIM ancora presente dopo il 25 Feb 2026
Severità: avvertimento
Messaggio: "Il selettore SendGrid DKIM (s1) doveva essere rimosso 3 giorni fa"

Regola personalizzata #5: workflow di evoluzione policy DMARC#

Le aziende spesso evolvono la policy DMARC nel tempo:

1. Giorno 1: p=none (nessuna applicazione, solo monitoraggio)
2. Settimana 2: p=quarantine (sposta i fallimenti in spam, non rifiuta)
3. Mese 2: p=reject (rifiuta i fallimenti, applicazione rigida)

Questa evoluzione ti permette di monitorare l'impatto prima di diventare rigido.

Il problema#

Stai pianificando di passare da p=quarantine a p=reject. Devi verificare che tutto funzioni prima di prendere la linea dura.

La soluzione: regola personalizzata#

Crea una regola: "Avvisa al cambio di policy DMARC"

Nome regola: DMARC Policy Evolution Tracking
Fase 1 (1 Feb): deploy p=quarantine
  Milestone: monitora per 2 settimane
  Avvisa se: tasso fallimento mail legittime > 1% (suggerisce problemi SPF/DKIM)

Fase 2 (15 Feb): passa a p=reject
  Prerequisito: confermato nessun fallimento legittimo in fase 1
  Avvisa se: non tutti i controlli prerequisiti sono passati

Fase 3 (1 Mar): verifica adozione
  Avvisa se: rilevati tentativi di spoofing (suggerisce che reject funziona)

Regola personalizzata #6: verifica servizi email di terze parti#

Esternalizzi l'invio email a servizi come Twilio, SendGrid o Mailgun. Devi verificare che siano configurati correttamente.

Il problema#

SendGrid promette: "Invieremo email dal tuo dominio con SPF/DKIM corretti".

Ma cosa succede se sbagliano la configurazione dalla loro parte? O aggiornano il loro DNS e dimenticano di dirtelo?

La soluzione: regola personalizzata#

Crea una regola: "Verifica che i servizi email di terze parti siano autenticati correttamente"

Nome regola: SendGrid Configuration Verification
Controllo: la chiave DKIM SendGrid corrisponde al tuo record DNS
Controllo: l'include SPF SendGrid è nel tuo record SPF
Controllo: l'autenticazione di dominio SendGrid è "verified" (non pending)
Avvisa se: uno dei controlli fallisce
Severità: critico
Azione: "Contatta il supporto SendGrid. L'auth dominio potrebbe essere scaduta."

Regola personalizzata #7: confronto baseline email health#

L'email health cambia. Vuoi sapere quando qualcosa è cambiato rispetto alla baseline.

Il problema#

Il tuo punteggio email health era 92 il mese scorso. Questo mese è 88. Si è rotto qualcosa?

Il monitoraggio standard avvisa sui punteggi assoluti. Le regole personalizzate avvisano sui cambiamenti.

La soluzione: regola personalizzata#

Crea una regola: "Avvisa al cambiamento significativo dalla baseline"

Nome regola: Email Health Regression Detection
Baseline: punteggio 1 Feb (92/100)
Soglia: avvisa se il punteggio scende >5 punti
Avvisa se: punteggio attuale < 87
Severità: avvertimento
Messaggio: "Email health degradata da 92 a 88 (causa probabile: rotazione chiave DKIM)"

Regola personalizzata #8: regole di audit di compliance#

Se sei regolamentato (HIPAA, SOC2, PCI-DSS), hai bisogno di configurazioni specifiche.

Esempio: compliance sanitaria#

Requisiti:

• DMARC p=reject (applicazione rigida)
• SPF -all (nessun soft fail)
• DKIM su dominio primario e backup
• TLS per tutta l'email in uscita
• Cifratura email per dati sensibili

Regola personalizzata:

Nome regola: HIPAA Email Compliance Check
Requisito 1: la policy DMARC deve essere p=reject
  Avvisa se: la policy è p=quarantine o p=none

Requisito 2: SPF deve terminare con -all
  Avvisa se: SPF termina con ~all (soft fail)

Requisito 3: deve avere DKIM sul dominio backup
  Avvisa se: dominio backup senza DKIM

Requisito 4: TLS richiesto per tutte le email
  Avvisa se: email non-TLS dal sistema

Requisito 5: email sensibili devono usare cifratura
  Avvisa se: email contenente PII non usa S/MIME o PGP

Implementare regole personalizzate nella pratica#

Opzione 1: usare le regole integrate dello strumento di monitoraggio#

Se il tuo strumento di monitoraggio (come Nova Uptime) supporta regole personalizzate, usa la sua dashboard:

1. Vai alle impostazioni dominio
2. Clicca "Regole personalizzate"
3. Scegli il tipo di regola (conteggio lookup SPF, selettore DKIM, ecc.)
4. Imposta le soglie
5. Configura gli avvisi
6. Salva

Opzione 2: usare webhook verso un sistema personalizzato#

Se il tuo strumento di monitoraggio non supporta regole personalizzate, usa i webhook:

# Monitoring tool sends webhook:
POST /your-system/webhooks/email-health
{
  "domain": "fliplink.me",
  "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");
}

Opzione 3: audit manuale mensile#

Se nessuna delle opzioni sopra è disponibile:

1. Esporta i dati email health dallo strumento di monitoraggio
2. Crea un foglio di calcolo con colonne personalizzate
3. Revisione mensile rispetto ai requisiti
4. Avvisa il team se qualcosa è cambiato

Errori comuni nelle regole personalizzate#

Errore 1: troppe regole personalizzate#

Problema: crei 50 regole personalizzate, vieni sommerso dagli avvisi, le ignori tutte.

Soluzione: inizia con 3-5 regole critiche. Aggiungine altre quando serve.

Errore 2: regole senza azioni concrete#

Problema: "Avvisa se i lookup SPF > 8" scatta, ma il team non sa cosa fare.

Soluzione: ogni regola dovrebbe includere azioni concrete:

Se: SPF lookup > 8
Messaggio avviso: "Limite lookup SPF in avvicinamento.
Per risolvere: consolida gli include usando un servizio di SPF flattening.
Maggiori info: https://knowledge.spf-flattening.com"

Errore 3: non testare le regole#

Problema: hai impostato una regola personalizzata 6 mesi fa. Non hai mai verificato che scatti davvero quando la condizione è soddisfatta.

Soluzione: testa le regole trimestralmente:

1. Innesca la condizione intenzionalmente (es. aggiungi manualmente un include SPF extra)
2. Aspetta l'avviso
3. Verifica che l'avviso sia corretto
4. Rimuovi il trigger di test

Errore 4: regole che si allontanano dalla realtà#

Problema: hai impostato una regola di evoluzione DMARC a febbraio. Hai dimenticato di aggiornarla. Ora è giugno e la regola è obsoleta.

Soluzione: rivedi le regole personalizzate trimestralmente. Aggiorna se le esigenze di business sono cambiate.

Riepilogo: checklist regole email health personalizzate#

• Identifica la tua infrastruttura email (quanti servizi? selettori?)
• Imposta una regola di ridondanza DKIM (più selettori)
• Imposta una regola di limite lookup SPF (avvisa a 8 lookup)
• Imposta una regola di monitoraggio report DMARC (tassi di fallimento insoliti)
• Imposta regole di migrazione servizio email (se migri provider)
• Imposta regole di evoluzione policy DMARC (se irrigidisci gradualmente la policy)
• Imposta regole di compliance (se settore regolamentato)
• Testa ogni regola per verificare che funzioni
• Documenta le regole per il team
• Audit e refresh trimestrale

Inizia oggi#

Il monitoraggio email health standard è buono. Le regole email health personalizzate lo rendono ottimo.

Se usi Nova Uptime, visita le impostazioni del dominio e crea regole personalizzate basate sulla tua infrastruttura unica. Se il tuo strumento non supporta ancora regole personalizzate, usa webhook o audit manuali.

La tua infrastruttura email è troppo importante per essere affidata solo a controlli standard. Le regole personalizzate ti garantiscono di intercettare i problemi specifici del tuo setup prima che impattino sui tuoi clienti.