Iniciar sesión Solicitar demo
Docs / Referencia

Los problemas más frecuentes agrupados por síntoma. Si no está acá, escribinos a [email protected] con el tenant_id 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 Awareness → 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. Feature flag no activa el intake. En tier free no hay ingesta por email. Requiere Awareness activado.

Awareness — 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 me devuelve 402 en un endpoint que ayer funcionaba

Causa: llegaste al 100% de la quota mensual de algún contador. La respuesta 402 indica cuál — leer el field quota_name del body.

Solución:

  • Esperar al día 1 del próximo mes (auto-reset).
  • Upgradear tier.
  • Comprar addon de quota para ese contador específico.

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 tenés múltiples tenants con el mismo email (poco común, pero posible en corporativo), agregá el RelayState con tenant_id=<uuid> para forzar.

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.