Como Criar Regras Personalizadas de Email Health: Configuração de Monitoramento Avançado

Do Padrão para Regras Personalizadas de Email Health#

As verificações padrão de email health verificam registros básicos: "Você tem MX? Você tem SPF? Você tem DKIM?"

Mas a infraestrutura de e-mail do mundo real é mais sutil:

• Você usa 5 serviços de e-mail diferentes (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Cada um precisa de includes de SPF
• Você tem múltiplos seletores DKIM (um por serviço)
• Você está migrando de provedores de e-mail (o seletor DKIM antigo ainda está lá, o novo está sendo configurado)
• Você está aplicando uma política DMARC rigorosa (p=reject), mas precisa ter cuidado para não quebrar e-mails legítimos

As verificações padrão são pass/fail. As regras personalizadas lidam com a complexidade.

Este guia mostra como configurar regras avançadas de email health para infraestruturas de e-mail sofisticadas.

Regra Personalizada #1: Configuração DKIM com Múltiplos Seletores#

Se você usa múltiplos serviços de e-mail, tem múltiplos seletores DKIM.

O Problema#

Cenário: Você usa SendGrid para e-mails transacionais e Mailgun para e-mails de marketing.

Configuração DNS:

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

O monitoramento padrão diz "DKIM configurado" (pass), mas não verifica:

• Se ambos os seletores estão ativos
• Se ambos os seletores têm chaves válidas
• Se ambos estão sendo rotacionados corretamente

A Solução: Regra Personalizada#

Crie uma regra: "Alertar se um seletor DKIM estiver faltando"

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

Implementação (se a Nova Uptime suportasse):

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

Regra Personalizada #2: Monitoramento do Limite de Lookups de SPF#

O SPF tem um limite de 10 lookups de DNS (RFC 7208). Ultrapasse 10 lookups e sua autenticação SPF falha silenciosamente.

O Problema#

Seu 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 diretiva include: usa 1 lookup de 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 direto, sem DNS)

Total: 8 lookups (abaixo do limite, você está seguro)

Mas o que acontece se você adicionar mais um serviço?

A Solução: Regra Personalizada#

Crie uma regra: "Alertar se os lookups de SPF se aproximarem do limite"

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 Que Isso Importa:

• Monitoramento padrão: SPF configurado ✅
• Regra personalizada: SPF configurado, MAS se aproximando do limite de lookups ⚠️

A regra personalizada captura um problema que o monitoramento padrão deixa passar.

Regra Personalizada #3: Monitoramento de Relatórios DMARC#

O DMARC fornece relatórios mostrando quantos e-mails falharam na autenticação. Esses relatórios devem ser monitorados.

O Problema#

Sua política DMARC:

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

O DMARC envia relatórios diários para dmarc@yourdomain.com. Esses relatórios mostram:

• % de e-mails passando no SPF
• % de e-mails passando no DKIM
• % de e-mails falhando em ambos (tentativas de spoofing)

Se você nunca olha esses relatórios, está perdendo insights de segurança.

A Solução: Regra Personalizada#

Crie uma regra: "Alertar se o relatório DMARC mostrar uma taxa de falha incomum"

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

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

Regra Personalizada #4: Workflow de Rotação de Serviços de E-mail#

Quando você migra de um serviço de e-mail para outro, precisa de um período temporário em que os seletores DKIM de ambos os serviços coexistem.

O Problema#

Cenário: Migrando do SendGrid para o Mailgun.

Estado antigo (antes da migração):

s1._domainkey (SendGrid DKIM)

Estado de transição (durante a migração):

s1._domainkey (SendGrid DKIM) ← Serviço antigo, sendo descontinuado
s2._domainkey (Mailgun DKIM) ← Novo serviço

Durante esse período:

• Seu SPF inclui ambos os serviços
• Ambos os seletores DKIM existem
• E-mails de ambos os serviços são autenticados

Novo estado (após o cutover):

s1._domainkey (SendGrid DKIM) ← Remover este
s2._domainkey (Mailgun DKIM)

Se você esquecer de remover o seletor DKIM antigo após o cutover, terá um drift de configuração.

A Solução: Regra Personalizada#

Crie uma regra: "Alertar após o prazo de migração"

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"

Regra Personalizada #5: Workflow de Evolução da Política DMARC#

As empresas frequentemente evoluem a política DMARC ao longo do tempo:

1. Dia 1: p=none (sem aplicação, apenas monitoramento)
2. Semana 2: p=quarantine (mover falhas para o spam, não rejeitar)
3. Mês 2: p=reject (rejeitar falhas, aplicação rigorosa)

Essa evolução permite que você monitore o impacto antes de adotar uma postura rigorosa.

O Problema#

Você está planejando passar de p=quarantine para p=reject. Precisa verificar se tudo está funcionando antes de adotar a linha dura.

A Solução: Regra Personalizada#

Crie uma regra: "Alertar em mudanças de 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)

Regra Personalizada #6: Verificação de Serviços de E-mail de Terceiros#

Você terceiriza o envio de e-mails para serviços como Twilio, SendGrid ou Mailgun. Precisa verificar se eles estão devidamente configurados.

O Problema#

A SendGrid promete: "Vamos enviar e-mails do seu domínio com SPF/DKIM apropriados."

Mas e se eles configurarem mal do lado deles? Ou atualizarem o DNS deles e esquecerem de te avisar?

A Solução: Regra Personalizada#

Crie uma regra: "Verificar se os serviços de e-mail de terceiros estão devidamente 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."

Regra Personalizada #7: Comparação de Baseline do Email Health#

O email health muda. Você quer saber quando algo mudou em relação ao baseline.

O Problema#

Sua pontuação de email health era 92 no mês passado. Este mês está em 88. Algo quebrou?

O monitoramento padrão alerta com base em pontuações absolutas. Regras personalizadas alertam sobre mudanças.

A Solução: Regra Personalizada#

Crie uma regra: "Alertar em mudanças significativas em relação ao 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)"

Regra Personalizada #8: Regras de Auditoria de Conformidade#

Se você é regulado (HIPAA, SOC2, PCI-DSS), precisa de configurações específicas.

Exemplo: Conformidade na Saúde#

Requisitos:

• DMARC p=reject (aplicação rigorosa)
• SPF -all (sem soft failures)
• DKIM no domínio primário e de backup
• TLS para todos os e-mails de saída
• Criptografia de e-mail para dados sensíveis

Regra 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

Implementando Regras Personalizadas na Prática#

Opção 1: Use as Regras Embutidas da Ferramenta de Monitoramento#

Se sua ferramenta de monitoramento (como a Nova Uptime) suporta regras personalizadas, use o dashboard dela:

1. Vá para as configurações do domínio
2. Clique em "Custom Rules"
3. Escolha o tipo de regra (contagem de lookups SPF, seletor DKIM, etc.)
4. Defina os thresholds
5. Configure os alertas
6. Salve

Opção 2: Use Webhooks para um Sistema Personalizado#

Se sua ferramenta de monitoramento não suporta regras personalizadas, use 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");
}

Opção 3: Auditoria Mensal Manual#

Se nenhuma das opções acima estiver disponível:

1. Exporte os dados de email health da ferramenta de monitoramento
2. Crie uma planilha com colunas personalizadas
3. Revisão mensal em relação aos requisitos
4. Alerte a equipe se algo mudou

Erros Comuns em Regras Personalizadas#

Erro 1: Regras Personalizadas Demais#

Problema: Criar 50 regras personalizadas, ficar sobrecarregado com alertas e ignorar todos.

Solução: Comece com 3-5 regras críticas. Adicione mais conforme a necessidade.

Erro 2: Regras Sem Itens de Ação#

Problema: "Alertar se lookups de SPF > 8" dispara, mas a equipe não sabe o que fazer.

Solução: Toda regra deve incluir itens de ação:

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"

Erro 3: Não Testar as Regras#

Problema: Configurou uma regra personalizada há 6 meses. Nunca verificou se ela realmente dispara quando a condição é atendida.

Solução: Teste as regras trimestralmente:

1. Acione a condição intencionalmente (ex: adicione manualmente um include extra de SPF)
2. Aguarde o alerta
3. Verifique se o alerta está correto
4. Remova o trigger de teste

Erro 4: Regras Desatualizadas em Relação à Realidade#

Problema: Configurou a regra de evolução do DMARC em fevereiro. Esqueceu de atualizá-la. Agora é junho e a regra está obsoleta.

Solução: Revise as regras personalizadas trimestralmente. Atualize se as necessidades do negócio mudaram.

Resumo: Checklist de Regras Personalizadas de Email Health#

• ✅ Identifique sua infraestrutura de e-mail (quantos serviços? seletores?)
• ✅ Configure a regra de redundância DKIM (múltiplos seletores)
• ✅ Configure a regra de limite de lookups SPF (avisar em 8 lookups)
• ✅ Configure a regra de monitoramento de relatórios DMARC (taxas de falha incomuns)
• ✅ Configure regras de migração de serviços de e-mail (se estiver migrando provedores)
• ✅ Configure regras de evolução de política DMARC (se estiver endurecendo a política gradualmente)
• ✅ Configure regras de conformidade (se for um setor regulado)
• ✅ Teste cada regra para verificar se funciona
• ✅ Documente as regras para a equipe
• ✅ Auditoria e atualização trimestrais

Comece Hoje#

O monitoramento padrão de email health é bom. Regras personalizadas de email health o tornam excelente.

Se você usa a Nova Uptime, acesse as configurações do seu domínio e crie regras personalizadas com base na sua infraestrutura única. Se sua ferramenta ainda não suporta regras personalizadas, use webhooks ou auditorias manuais.

Sua infraestrutura de e-mail é importante demais para confiar apenas em verificações padrão. Regras personalizadas garantem que você capture problemas específicos da sua configuração antes que eles afetem seus clientes.