Pregunta y escenario
Una empresa está consolidando varios proveedores de correo electrónico bajo un único dominio de envío. Explique la alineación de DMARC y las funciones de RFC 9989, 9990 y 9991, y luego diseñe la validación y el rollback desde p=none hasta reject.
Esto se adapta a roles de plataforma, seguridad, infraestructura de correo electrónico y diagnóstico de incidentes entre equipos. Evalúa el razonamiento sobre protocolos y el control de despliegues; no requiere afirmar que todos los receptores ya implementan cada nueva RFC de manera idéntica.
Qué está evaluando el entrevistador
- Si separa las funciones y las entradas de SPF, DKIM y DMARC.
- Si sabe que DMARC necesita al menos una ruta de SPF o DKIM que sea aprobada y esté alineada.
- Si puede distinguir el núcleo de DMARC de RFC 9989, los informes agregados de RFC 9990 y los informes de fallos de RFC 9991.
- Si puede endurecer la política a partir de observaciones en lugar de cambiar directamente a
p=reject. - Si puede manejar reenvíos, terceros, subdominios, la privacidad de los informes y el rollback.
Preguntas para clarificar antes de responder
- ¿La identidad protegida es un dominio organizacional o varios subdominios, y cuáles son los dominios From, Return-Path y d de DKIM para cada remitente?
- ¿Cómo se ven las tasas de aprobación y alineación de SPF, DKIM y DMARC por proveedor y subdominio, y se pueden recibir informes agregados?
- ¿Los mensajes de marketing, transaccionales y de empleados se envían desde el mismo dominio, o pueden separarse?
- ¿Se ha verificado el comportamiento del receptor mediante pruebas y documentación del proveedor, o solo estamos asumiendo el soporte de los estándares?
Marco de respuesta de 30 segundos
DMARC comprueba si el dominio From visible se alinea con un dominio SPF autenticado o un dominio d de DKIM; al menos una ruta debe aprobarse y alinearse. RFC 9989 define el núcleo de DMARC, mientras que RFC 9990 y RFC 9991 definen los informes agregados y de fallos. Comience con p=none como modo de observación, analice los informes, repare la alineación por proveedor, subdominio y tipo de mensaje, y luego avance gradualmente a quarantine y reject. Cada paso necesita métricas, pruebas representativas y un rollback rápido. Un nuevo número de RFC no es evidencia de que todos los receptores produzcan informes idénticos hoy en día.
Respuesta detallada paso a paso
1. Dibujar las tres rutas de identidad
SPF autentica si un servidor de envío está autorizado, usualmente utilizando el dominio MAIL FROM del sobre SMTP. DKIM verifica una firma, con su dominio d participando en la alineación. DMARC evalúa el dominio From visible para el destinatario y aplica la política según la alineación. Estas entradas difieren, por lo que una línea Authentication-Results no sustituye la comprobación de los dominios reales.
2. Evaluar la alineación en lugar de una simple aprobación
La condición clave de DMARC es que SPF o DKIM se aprueben y su dominio autenticado se alinee con From bajo el modo relajado o estricto de la organización. Un proveedor puede tener SPF aprobado mientras que su envelope-from está desalineado, o DKIM aprobado con un dominio d perteneciente al proveedor. Ambos requieren cambiar el dominio, la firma o el límite de envío.
3. Explicar el límite de las RFC de 2026
RFC 9989 es la especificación central de DMARC y reemplaza el posicionamiento histórico de RFC 7489. RFC 9990 describe los informes agregados para distribuciones de fuentes a largo plazo, mientras que RFC 9991 describe los informes de fallos. Mantenga separado "la especificación está publicada" de "cada receptor emite los mismos informes"; verifique el soporte concreto mediante pruebas y documentación del proveedor.
4. Diseñar un cambio de política gradual
Publique p=none primero con un destino rua controlado y un buzón o canalización de análisis con control de acceso. Agregue las dimensiones de SPF, DKIM, From, subdominio y fallos por remitente, luego repare las fuentes legítimas. Use sp para subdominios con alcance cuidadosamente definido o separe los subdominios transaccionales y de marketing. Pase a quarantine solo después de que el tráfico legítimo sea estable y las fuentes desconocidas sean explicables, luego considere reject.
5. Incluir la verificación y el rollback en el registro de cambios
Guarde los registros DNS, la configuración del proveedor y la línea base de informes antes de cada cambio. Después del endurecimiento, observe la entrega legítima, la aprobación de DMARC, los fallos de alineación, las quejas y el retraso en los informes. Pruebe el reenvío, las listas de correo y los archivos adjuntos con buzones reales. Si la entrega legítima cae, revierta la política anterior o limite el subdominio primero, y luego determine si la propagación, la firma DKIM, las reescrituras por reenvío o la falta de informes lo causaron.
Respuesta de muestra de alta calidad
Haría un inventario de los dominios From, MAIL FROM y d de DKIM de cada remitente, y luego calcularía la aprobación y la alineación por proveedor y subdominio. DMARC no requiere que SPF y DKIM se aprueben juntos; una sola ruta aprobada y alineada es suficiente. RFC 9989 rige la política central, mientras que RFC 9990 y RFC 9991 cubren los dos tipos de informes, cuya cobertura por parte de los receptores debe medirse en lugar de asumirse. Comenzaría en p=none, recopilaría informes agregados, corregiría problemas de terceros, reenvío y subdominios, y luego endurecería un segmento delimitado a quarantine antes de reject. Cada paso recibe umbrales de entrega legítima, alineación y fuentes no explicadas, además de una ruta de rollback de DNS y aislamiento de subdominios. Eso hace que el cambio sea auditable y limita los daños cuando una suposición es incorrecta.
Errores comunes
- Declarar que DMARC pasó tras la aprobación de SPF o DKIM sin verificar la alineación del dominio From.
- Tratar MAIL FROM de SPF, d de DKIM y el From visible como el mismo campo.
- Llamar a las tres RFC de 2026 "el núcleo de DMARC" sin separar las responsabilidades de los informes.
- Cambiar a
p=rejectsin una línea base de informes y bloquear correo legítimo de terceros. - Asumir que el reenvío preserva SPF o DKIM sin probar listas y rutas de reenvío.
- Publicar datos de informes sin considerar la información de direcciones y de la organización en dichos informes.
Preguntas de seguimiento y respuestas
SPF se aprueba pero DMARC falla. ¿Qué inspecciona primero?
Compare el dominio autenticado por SPF con From y confirme la alineación relajada o estricta. Luego inspeccione la herencia de subdominios, las reescrituras y los encabezados de mensajes reales; una IP de envío autorizada por sí sola no es suficiente.
DKIM se aprueba pero falla después del reenvío. ¿Qué sigue?
Verifique si el reenviador reescribe el cuerpo o los encabezados firmados y si el dominio d y el selector aún resuelven. Para reenvíos no controlados, evalúe la firma estable, el manejo de listas y un subdominio aislado en lugar de ocultar fuentes desconocidas debilitando la política.
¿Cómo decide pasar de quarantine a reject?
Utilice segmentos de informes por proveedor, subdominio y tipo de mensaje para demostrar una alineación sostenida, y complete pruebas de reenvío, marketing y transaccionales. Establezca umbrales para la entrega legítima, los fallos de alineación, las quejas y las fuentes inexplicables, con una ventana de rollback.
¿Qué importa cuando la dirección de informe está en otro dominio?
Confirme que el dominio receptor autoriza explícitamente la relación de informes, y restrinja el acceso y la retención en la canalización de informes. Los informes entre dominios no son automáticamente una exportación de datos de confianza.
Fuentes: RFC 9989, RFC 9990, RFC 9991, Google Gmail “Email sender guidelines” y Dataford “Explaining Email Authentication Clearly” (las URLs completas están registradas en meta.json).