Cómo crear reglas personalizadas de email health: configuración avanzada de monitoring

De estándar a reglas personalizadas de email health#

Los controles estándar de email health verifican registros básicos: "¿Tienes MX? ¿Tienes SPF? ¿Tienes DKIM?"

Pero la infraestructura de email del mundo real es más matizada:

• Usas 5 servicios de email distintos (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Cada uno necesita includes SPF
• Tienes varios selectores DKIM (uno por servicio)
• Estás migrando de proveedor de email (el selector DKIM antiguo sigue ahí, el nuevo se está configurando)
• Estás aplicando una política DMARC estricta (p=reject) pero debes tener cuidado de no romper email legítimo

Los controles estándar pasan o fallan. Las reglas personalizadas gestionan la complejidad.

Esta guía te muestra cómo configurar reglas avanzadas de email health para infraestructuras de email sofisticadas.

Regla personalizada #1: configuración DKIM multi-selector#

Si usas varios servicios de email, tienes varios selectores DKIM.

El problema#

Escenario: usas SendGrid para email transaccional y Mailgun para email marketing.

Configuración DNS:

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

El monitoring estándar dice "DKIM configurado" (correcto), pero no verifica:

• Ambos selectores están activos
• Ambos selectores tienen claves válidas
• Ambos se rotan correctamente

La solución: regla personalizada#

Crea una regla: "Alertar si falta un selector DKIM"

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."

Implementación (si Nova Uptime lo soportara):

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"
    }
  }'

Regla personalizada #2: monitoring del límite de lookups SPF#

SPF tiene un límite de 10 lookups DNS (RFC 7208). Si superas los 10 lookups, tu autenticación SPF falla en silencio.

El problema#

Tu registro 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

Cada directiva include: consume 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 lookups (IP directa, sin DNS)

Total: 8 lookups (por debajo del límite, estás a salvo)

¿Pero qué pasa si añades un servicio más?

La solución: regla personalizada#

Crea una regla: "Alertar si los lookups SPF se acercan al límite"

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

Por qué importa:

• Monitoring estándar: SPF configurado ✅
• Regla personalizada: SPF configurado PERO acercándose al límite de lookups ⚠️

La regla personalizada detecta un problema que el monitoring estándar pasa por alto.

Regla personalizada #3: monitoring de informes DMARC#

DMARC proporciona informes que muestran cuántos emails fallaron la autenticación. Estos informes deberían monitorizarse.

El problema#

Tu política DMARC:

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

DMARC envía informes diarios a dmarc@yourdomain.com. Estos informes muestran:

• % de emails que pasan SPF
• % de emails que pasan DKIM
• % de emails que fallan ambos (intentos de spoofing)

Si nunca miras estos informes, te estás perdiendo información de seguridad.

La solución: regla personalizada#

Crea una regla: "Alertar si el informe DMARC muestra una tasa de fallos inusual"

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

Ejemplo de alerta:

⚠️ 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)

Regla personalizada #4: workflow de rotación de servicios de email#

Cuando migras de un servicio de email a otro, necesitas un periodo temporal en el que coexistan los selectores DKIM de ambos servicios.

El problema#

Escenario: migración de SendGrid a Mailgun.

Estado anterior (antes de la migración):

s1._domainkey (SendGrid DKIM)

Estado de transición (durante la migración):

s1._domainkey (SendGrid DKIM) ← Servicio antiguo, en proceso de retirada
s2._domainkey (Mailgun DKIM) ← Servicio nuevo

Durante este periodo:

• Tu SPF incluye ambos servicios
• Existen ambos selectores DKIM
• Los emails de ambos servicios se autentican

Estado nuevo (tras el cutover):

s1._domainkey (SendGrid DKIM) ← Hay que eliminar esto
s2._domainkey (Mailgun DKIM)

Si te olvidas de eliminar el selector DKIM antiguo tras el cutover, tienes una desviación de configuración.

La solución: regla personalizada#

Crea una regla: "Alertar tras la fecha límite de migración"

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"

Regla personalizada #5: workflow de evolución de la política DMARC#

Las empresas suelen hacer evolucionar su política DMARC con el tiempo:

1. Día 1: p=none (sin aplicación, solo monitoring)
2. Semana 2: p=quarantine (mover los fallos a spam, no rechazar)
3. Mes 2: p=reject (rechazar fallos, aplicación estricta)

Esta evolución te permite monitorizar el impacto antes de pasar al modo estricto.

El problema#

Estás planeando pasar de p=quarantine a p=reject. Necesitas verificar que todo funciona antes de adoptar la línea dura.

La solución: regla personalizada#

Crea una regla: "Alertar al cambiar la política DMARC"

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)

Regla personalizada #6: verificación de servicios de email de terceros#

Externalizas el envío de email a servicios como Twilio, SendGrid o Mailgun. Tienes que verificar que están correctamente configurados.

El problema#

SendGrid promete: "Enviaremos emails desde tu dominio con SPF/DKIM correctos."

¿Pero qué pasa si lo configuran mal por su lado? ¿O si actualizan su DNS y se olvidan de avisarte?

La solución: regla personalizada#

Crea una regla: "Verificar que los servicios de email de terceros están correctamente autenticados"

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."

Regla personalizada #7: comparación con la línea base de email health#

El email health cambia. Quieres saber cuándo algo cambia respecto a la línea base.

El problema#

Tu puntuación de email health era 92 el mes pasado. Este mes es 88. ¿Se ha roto algo?

El monitoring estándar alerta sobre puntuaciones absolutas. Las reglas personalizadas alertan sobre cambios.

La solución: regla personalizada#

Crea una regla: "Alertar ante un cambio significativo respecto a la línea base"

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)"

Regla personalizada #8: reglas de auditoría de cumplimiento#

Si estás regulado (HIPAA, SOC2, PCI-DSS), necesitas configuraciones específicas.

Ejemplo: cumplimiento sanitario#

Requisitos:

• DMARC p=reject (aplicación estricta)
• SPF -all (sin soft fails)
• DKIM tanto en el dominio principal como en el de respaldo
• TLS para todo el email saliente
• Cifrado de email para datos sensibles

Regla personalizada:

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

Implementar reglas personalizadas en la práctica#

Opción 1: usa las reglas integradas de la herramienta de monitoring#

Si tu herramienta de monitoring (como Nova Uptime) soporta reglas personalizadas, usa su dashboard:

1. Ve a la configuración del dominio
2. Haz clic en "Custom Rules"
3. Elige el tipo de regla (recuento de lookups SPF, selector DKIM, etc.)
4. Define los umbrales
5. Configura las alertas
6. Guarda

Opción 2: usa webhooks hacia un sistema personalizado#

Si tu herramienta de monitoring no soporta reglas personalizadas, usa 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");
}

Opción 3: auditoría manual mensual#

Si ninguna de las opciones anteriores está disponible:

1. Exporta los datos de email health desde la herramienta de monitoring
2. Crea una hoja de cálculo con columnas personalizadas
3. Revisión mensual frente a los requisitos
4. Avisa al equipo si algo ha cambiado

Errores comunes con las reglas personalizadas#

Error 1: demasiadas reglas personalizadas#

Problema: creas 50 reglas personalizadas, te abrumas con las alertas y acabas ignorándolas todas.

Solución: empieza con 3-5 reglas críticas. Añade más según las necesites.

Error 2: reglas sin acciones a tomar#

Problema: "Alertar si los lookups SPF > 8" se dispara, pero el equipo no sabe qué hacer.

Solución: cada regla debería incluir acciones a tomar:

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"

Error 3: no probar las reglas#

Problema: configuraste una regla personalizada hace 6 meses. Nunca verificaste que realmente se dispara cuando se cumple la condición.

Solución: prueba las reglas trimestralmente:

1. Provoca la condición a propósito (p. ej., añade manualmente un include SPF extra)
2. Espera la alerta
3. Verifica que la alerta es correcta
4. Elimina el disparador de prueba

Error 4: las reglas se desincronizan de la realidad#

Problema: configuraste una regla de evolución DMARC en febrero. Olvidaste actualizarla. Ahora estamos en junio y la regla está obsoleta.

Solución: revisa las reglas personalizadas trimestralmente. Actualízalas si las necesidades del negocio han cambiado.

Resumen: checklist de reglas personalizadas de email health#

• ✅ Identifica tu infraestructura de email (¿cuántos servicios? ¿cuántos selectores?)
• ✅ Configura una regla de redundancia DKIM (varios selectores)
• ✅ Configura una regla de límite de lookups SPF (avisar a los 8 lookups)
• ✅ Configura una regla de monitoring de informes DMARC (tasas de fallo inusuales)
• ✅ Configura reglas de migración de servicios de email (si estás migrando proveedor)
• ✅ Configura reglas de evolución de política DMARC (si endureces la política gradualmente)
• ✅ Configura reglas de cumplimiento (si estás en un sector regulado)
• ✅ Prueba cada regla para verificar que funciona
• ✅ Documenta las reglas para el equipo
• ✅ Auditoría y refresco trimestrales

Empieza hoy#

El monitoring estándar de email health está bien. Las reglas personalizadas de email health lo llevan a otro nivel.

Si usas Nova Uptime, ve a la configuración de tu dominio y crea reglas personalizadas basadas en tu infraestructura específica. Si tu herramienta aún no soporta reglas personalizadas, usa webhooks o auditorías manuales.

Tu infraestructura de email es demasiado importante como para confiarla solo a controles estándar. Las reglas personalizadas garantizan que detectes los problemas específicos de tu setup antes de que afecten a tus clientes.