Un remitente puede demostrar el control de su propio dominio. Aun así, puede mostrar tu dominio en la dirección From. La autenticación exitosa por sí sola no establece permiso para usar esa identidad visible.
¿Por qué SPF y DKIM pueden pasar mientras DMARC falla?
Ambas verificaciones pueden autenticar dominios que no coinciden con el dominio visible de From.
SPF verifica si el servidor que se conecta está autorizado para el dominio del remitente del sobre, usado para avisos de fallos de entrega. DKIM valida una firma criptográfica asociada a un dominio firmante, identificado por la etiqueta d de la firma.
El remitente del sobre se proporciona durante la conversación SMTP. Es independiente del encabezado From que muestra el cliente de correo del destinatario.
Por ejemplo, un remitente que controla attacker.example puede pasar SPF y DKIM para ese dominio. El remitente puede poner billing@example.com en From. Ninguno de los dos resultados valida example.com, por lo que DMARC falla.
Un dominio organizacional es el límite administrativo que contiene un dominio y sus subdominios, como example.com para news.example.com.
¿Qué cuenta como alineado?
La alineación relajada requiere un dominio organizacional compartido. La alineación estricta requiere dominios idénticos.
RFC 9989 define cómo los receptores descubren ese límite.
| Dominio autenticado | Dominio From | Alineación |
|---|---|---|
foo.example.com | news.example.com | Relajada, porque ambos comparten example.com |
news.example.com | news.example.com | Estricta, porque los dominios son idénticos |
foo.example.net | news.example.com | Ninguna, porque los dominios organizacionales difieren |
La etiqueta adkim controla la alineación de DKIM. La etiqueta aspf controla la alineación de SPF. Cada una acepta r para relajada o s para estricta, con relajada como valor predeterminado.
Usa la alineación estricta solo cuando necesites dominios idénticos, porque excluye coincidencias válidas entre subdominios hermanos. Un servicio que firma como foo.example.com no puede satisfacer la alineación estricta para From en news.example.com.
La especificación indica que casi todos los propietarios de dominios consideran suficiente la alineación relajada. Tus requisitos de coincidencia de dominios determinan si la alineación relajada es apropiada.
¿Necesita DMARC que ambos métodos estén alineados?
No: un pase alineado de SPF o de DKIM es suficiente.
El receptor evalúa los métodos de forma independiente. Un resultado que pasa pero no está alineado no puede proporcionar el pase DMARC.
El reenvío puede romper SPF al cambiar el servidor que se conecta. DKIM puede sobrevivir si el reenviador preserva el contenido firmado. Una firma intacta de un dominio alineado permite entonces que el mensaje pase DMARC a pesar del fallo de SPF.
Si el reenvío modifica el contenido firmado, DKIM también puede fallar. Cómo corregir fallos de DMARC explica el diagnóstico.
¿Por qué un servicio de envío puede romper la alineación SPF?
La alineación SPF falla cuando el servicio usa un dominio de remitente del sobre que no se alinea con tu dominio visible de From.
Si el servicio usa su propio dominio de rebote no relacionado, SPF puede pasar para ese dominio. DMARC rechaza ese resultado como no alineado. Agregar el servicio a un registro SPF en tu dominio no cambia el dominio que verifica el receptor.
Configura un return path personalizado, el dominio usado para avisos de fallos de entrega, bajo tu propio dominio. Con alineación relajada, bounce.example.com puede coincidir con From en example.com.
DKIM ofrece una ruta separada: configura el servicio para que firme usando un dominio alineado. Puedes confirmar ambos resultados en los informes agregados, que resumen las verificaciones del receptor.
¿Cómo configuras el return path con Bird?
Publicas el alias de return path de Bird bajo tu dominio de envío.
Publica ese alias como un registro CNAME. El alias de return path proporciona la configuración SPF de Bird, así que no necesitas un registro SPF separado en la raíz del dominio para los envíos de Bird.
El campo return_path.name de API acepta de 1 a 63 letras, dígitos o guiones, con una letra o dígito en cada extremo. Una etiqueta más larga o que comience con un guion no es válida.
Bird agrega tu dominio de envío. Por ejemplo, send en mail.example.com se convierte en send.mail.example.com. Ese return path puede alinearse con From en mail.example.com en modo relajado.
La guía de dominio de rebote cubre el registro. También publicas el registro DKIM. Bird acepta una política DMARC válida en el dominio de envío o en su dominio organizacional. Una política de monitoreo de p=none, que no expresa preferencia de manejo para los fallos, es suficiente.
¿Cómo encuentra la especificación los dominios organizacionales?
RFC 9989 busca en la jerarquía de dominios registros que establezcan la política aplicable y el límite de dominio. Esta búsqueda se denomina recorrido del árbol DNS.
La especificación reemplaza el enfoque de la Public Suffix List descrito por RFC 7489. Esa lista identifica sufijos de registro compartidos como com y co.uk.
La distinción afecta la alineación relajada porque el dominio organizacional descubierto determina si los nombres relacionados coinciden. También afecta qué política del dominio padre se aplica a un subdominio. Una especificación publicada no establece qué método de descubrimiento implementa un receptor en particular.
¿Puede una etiqueta de porcentaje controlar la aplicación?
La etiqueta de porcentaje pct no proporciona una aplicación parcial confiable. RFC 9989 la excluye.
El Apéndice A.6 describe el manejo inconsistente de porcentajes intermedios. Un valor de pct=50 no puede asegurarte que el manejo más estricto afecte exactamente la mitad de los mensajes que fallan.
Los valores excepcionales eran cero y cien, correspondientes a ninguna aplicación basada en porcentaje y aplicación completa. Algunos intermediarios también trataban pct=0 como una señal para reescribir la dirección From visible y evitar fallos posteriores.
Usa los informes para reparar fallos legítimos antes de cambiar la política mediante none, quarantine y reject. El valor none no expresa preferencia de manejo. El valor quarantine marca los fallos como sospechosos. El valor reject identifica uso no autorizado del dominio. La guía de políticas explica el despliegue.
¿Un pase alineado demuestra que el mensaje es seguro?
Un pase alineado demuestra el uso autorizado del dominio From, sin establecer si el mensaje es deseado o seguro.
Un receptor puede rechazar o poner en cuarentena un mensaje que pasa usando sus propias reglas de filtrado. También puede aceptar un mensaje que falla cuando otra evidencia respalda la entrega.
La autorización de dominio y la reputación del remitente, la evaluación que hace el receptor del tráfico de un remitente, responden preguntas diferentes. Verifica ambas cuando investigues la entrega.
En resumen
La autenticación debe coincidir con el dominio visible.
SPF y DKIM pueden pasar para dominios no relacionados, por lo que DMARC requiere un pase alineado para el dominio en From.
Cualquiera de los dos métodos alineados puede proporcionar un pase.
Una firma DKIM alineada e intacta puede preservar un pase DMARC cuando el reenvío rompe SPF.
La alineación relajada y la estricta usan reglas de coincidencia diferentes.
La alineación relajada acepta un dominio organizacional compartido. La alineación estricta requiere dominios idénticos.
El descubrimiento de dominios y la aplicación de políticas son mecanismos separados.
RFC 9989 usa un recorrido del árbol DNS para descubrir los límites de dominio. Excluye la etiqueta de porcentaje, poco fiable, de su formato de política.