"¿Por qué SPF y DKIM tienen que estar correctamente configurados antes de DMARC?"
DMARC valida que un email pase autenticación SPF o DKIM con alignment al dominio del From: header. Si SPF está mal configurado (supera 10 lookups, omite senders legítimos, sintaxis errónea), DMARC reportará alignment fallido y, en enforcement, bloqueará email legítimo del cliente. Si DKIM no firma correctamente (selector inexistente, clave expirada, configuración del MTA incorrecta), pasa lo mismo. La consecuencia operacional de migrar a DMARC enforcement sin SPF/DKIM limpios es bounce masivo de email legítimo. Por eso el orden de implementación es: primero SPF + DKIM correctos y verificados, después DMARC en p=none por 4-8 semanas observando reports, finalmente DMARC en p=quarantine o p=reject. Saltarse el primer paso convierte el proyecto DMARC en incident response.
"¿Qué es el límite de 10 lookups y cómo lo resuelven?"
El RFC 7208 limita el SPF a 10 lookups DNS por evaluación. Cuando una operación usa múltiples ESPs externos (ej. SendGrid + Mailgun + Mailchimp + Salesforce + Zendesk + HubSpot), cada include suma lookups. SendGrid include solo suma 1-2 lookups, pero Salesforce.com puede sumar 4-6 dependiendo de la cadena, HubSpot 3-4. Sumando todos los senders, fácilmente se llega a 12-15 lookups, lo cual viola el estándar y los receivers tratan SPF como permerror. Tres técnicas de remediación: flattening (resolver los includes a IPs directas, mantenido manualmente), filtering (eliminar senders que no envían realmente), sub-domain delegation (separar marketing.tudominio.com con su propio SPF). EMP usa la combinación adecuada al caso del cliente. Flattening puro está en declive porque requiere mantenimiento manual y las IPs de los ESPs cambian sin aviso.
"¿DKIM 1024-bit que ya tengo configurado sirve o tengo que migrar?"
DKIM 2048-bit es el estándar de la industria desde 2018 y el mínimo aceptable en 2026. DKIM 1024-bit todavía funciona técnicamente pero Google empezó a marcarlo como warning en Gmail Postmaster Tools y algunos receivers lo penalizan en reputational scoring. DKIM 4096-bit es matemáticamente más fuerte pero la firma resultante puede exceder el límite de DNS TXT estándar (255 caracteres por chunk) y requiere split en múltiples chunks, lo cual algunos resolvers legacy manejan mal. Recomendación EMP 2026: DKIM 2048-bit como default para todos los selectors nuevos. La rotación periódica de claves (6-12 meses) es más importante que el tamaño absoluto, porque mitiga el riesgo de compromise de clave. Si tu DKIM actual es 1024-bit, el setup incluye migración a 2048-bit con double-signing durante la transición para evitar bounce de email en flight.
"¿Pueden hacer el inventario si no sé exactamente qué senders tengo?"
Sí, eso es parte del scope. Técnicas combinadas que aplicamos: análisis del registro DNS actual con queries a SPF, DKIM, DMARC para detectar includes y selectors publicados, parseo de DMARC RUA reports si DMARC está en cualquier modo, lo cual revela todos los senders que envían con tu dominio (autorizados o no), revisión de los últimos 30 días de logs SMTP del MTA principal si aplica, entrevistas con marketing y desarrolladores del cliente para identificar herramientas SaaS conectadas que envían email (CRM, helpdesk, forms, billing systems), análisis de los Slack canales con webhooks de notificación si aplica. El inventario típico de una operación B2B media identifica 8-15 senders activos, de los cuales 3-5 son legítimos no documentados y 1-3 son senders no autorizados que deberían bloquearse.
"¿Necesito un DKIM por ESP o uno solo me sirve?"
Un DKIM por sender autorizado, no uno solo para todo. Cada ESP firma con su propio selector específico del cliente: Mailchimp usa k1._domainkey y k2._domainkey, SendGrid usa s1._domainkey y s2._domainkey, Mailgun usa mxa._domainkey y mxb._domainkey, HubSpot usa hs1-_._domainkey, etc. El cliente publica los selectors de cada ESP en el DNS para que esos ESPs puedan firmar emails con tu dominio. Adicionalmente, los MTAs propios (PowerMTA, KumoMTA, Postfix) firman con tu propio selector específico bajo tu control. La configuración del registro SPF declara qué senders están autorizados; la firma DKIM por selector garantiza criptográficamente que el email viene del sender declarado.
"¿La rotación de DKIM rompe el envío en producción?"
No si se hace correctamente con double-signing durante la transición. Procedimiento técnico: generar nueva clave 2048-bit, publicar nuevo selector con número incrementado, configurar el MTA para firmar con el nuevo selector mientras el viejo selector sigue publicado en DNS, monitorear DMARC reports durante 7-14 días, eliminar el selector viejo del DNS cuando ya no quedan emails en flight firmados con él. Durante el período de double-signing ambas claves son válidas y los receivers validan con cualquiera. Las claves DKIM no expiran automáticamente; la rotación es disciplina operacional. EMP entrega el procedure documentado al cierre del setup para que el equipo cliente lo ejecute internamente, o agrega el add-on DKIM Rotation Managed ($890 por rotación) para que EMP la ejecute coordinadamente.
