Iniciar sesión Solicitar demo
Docs / Referencia

Resolución de problemas

Los problemas más frecuentes agrupados por síntoma. Si no está acá, escribinos a [email protected] con el nombre de tu organización y una descripción del síntoma.

No me llegan reportes DMARC después de 3 días

Causas típicas:

  1. TXT no publicado o mal escrito. dig +short TXT _dmarc.tuempresa.com debe devolver algo válido. Sin comillas raras, sin newlines.
  2. Dominio no recibe email real. Los dominios parkeados no generan RUA. Chequeá que el dominio tiene MX y recibe email de destinatarios distintos.
  3. fo=0 (default). Sin fo=1 no llegan failure reports individuales.
  4. DNS con resolución solo IPv4. Google y Microsoft priorizan IPv6 para RUA. Verificá que tu authoritative DNS responde en AAAA.

DMARC compliance cae de golpe

Causas típicas:

  1. DKIM key rotada por un vendor sin avisar. Revisá Domain Detail → DKIM — algún selector cambió de estado. Publicá el TXT nuevo con la key nueva.
  2. SPF pasó el límite de 10 lookups. Un include nuevo (o un vendor que agregó includes internos) rompió la resolución. Ver SPF flattening.
  3. Nuevo vendor no autorizado. Discovery te muestra la fuente. Autorizala en SPF/DKIM.

Reportes de phishing no aparecen en el dashboard

Causas típicas:

  1. Buzón dedicado no configurado. En Human Risk Protection → Buzón de reporte, verificá que el forward hacia report@<tuslug>.report.emate.cloud está activo.
  2. DMARC del buzón rechaza el forward. Google y Microsoft a veces bloquean forwards con DMARC fail. Solución: el buzón intermedio debe re-DKIM (ARC seal) o el user debe usar el Gmail/Outlook add-in.
  3. La fuente de reportes no está habilitada. La ingesta por email requiere Human Risk Protection y un canal de reporte configurado.

Human Risk Protection — la campaña se envió pero cero opens

Causas típicas:

  1. Cae en spam. El sender de display se parece demasiado a un dominio real que ya tiene DMARC estricto. Bajá la agresividad del sender.
  2. Bloqueo en gateway corporativo. Si tenés un secure email gateway (Proofpoint, Mimecast, Barracuda) delante de Exchange/Gmail, agregá el dominio de envío (send.emate.cloud) al allowlist.
  3. Blank tracking pixel bloqueado. Algunos clients bloquean pixels remotos — normal. El conteo real de “clicks” no depende del pixel.

SSPM no muestra ningún user

Causas típicas:

  1. Sync engine deshabilitado. En Integraciones → M365 → Estado, verificá que dice connected y el last_sync_at es reciente.
  2. Cooldown de 5 minutos entre ticks. Si acabás de forzar re-sync, esperá 5 min. Si necesitás un re-sync inmediato, contactá a soporte.
  3. Scope faltante. Sin User.Read.All no hay users. Chequeá que consent fue concedido para todos los scopes.

API devuelve 402

Causa: se alcanzó un límite de uso contratado para esa operación.

Solución: revisá el consumo y la licencia en la plataforma. Si el límite es periódico, esperá su renovación; si necesitás más capacidad, contactá a tu responsable comercial.

API 401 con key válida

Causas típicas:

  1. Key rotada / revocada. Chequeá /settings/api-keys — si la key aparece con estado revoked fue borrada.
  2. IP allowlist. Si la key tiene allowlist configurado y la llamada viene de otra IP → 401.
  3. Header mal formateado. Debe ser Authorization: Bearer <key> — no Authorization: <key> ni X-Api-Key: <key>.

Webhook — mi endpoint recibe la request pero devuelve 200 y sigue en retry

Causa: la plataforma considera “delivery ok” solo con 2xx. Si tu endpoint devuelve un HTML de error (aunque el status sea 200) o el body está vacío, marcamos como delivery ok — no retryamos.

Si estás viendo retries, probablemente tu server devuelve 200 pero también un error async que timeoutea después de 10s. Chequeá los logs del web server, no solo tu handler.

SSO SAML — el user loguea pero cae en el tenant equivocado

Causa: el NameID del assertion no matchea con ningún email de user en el tenant esperado. La plataforma cae en un tenant default o rechaza.

Solución:

  • Verificá que el NameID en la assertion SAML es un email válido.
  • Confirmá que el email está registrado en el tenant destino.
  • Si administrás varias organizaciones, confirmá que ingresaste desde el acceso correspondiente. Para configuraciones especiales, contactá a soporte.

Dashboard tarda mucho en cargar

Causas típicas:

  1. Tenant con mucho tráfico. Un tenant grande con >100 dominios y millones de reportes puede tardar. Los queries están indexados pero algunos requieren agregaciones. Es normal ver 1-2s en la primera carga y <500ms en las siguientes (cache).
  2. Filtro sin límite. Un query de audit log sin from filtra por default últimos 30 días. Si querés más historia, hacé chunks.
  3. JS bloqueado. Cloudflare Bot Management a veces desafía la primera visita. Aceptá el JS challenge una vez y no vuelve a pasar.