Un servidor autorizado puede enviar un mensaje no deseado. Una firma válida puede pertenecer a un dominio distinto del que se muestra al destinatario. Cada comprobación responde a una pregunta diferente sobre el mensaje.
¿Qué demuestra cada comprobación?
SPF comprueba la IP de envío, DKIM comprueba una firma y DMARC conecta un resultado positivo con el dominio From visible.
| Comprobación | Identidad comprobada | Qué establece un resultado positivo | Qué no establece |
|---|---|---|---|
| SPF | Dominio envelope-from, usado normalmente para rebotes | La IP que se conecta está autorizada por la política de ese dominio. | El dominio From visible ni la integridad del mensaje. |
| DKIM | Dominio firmante en el valor d= de la firma | La firma se verifica contra su clave publicada y el contenido firmado. | Que todas las partes del mensaje estén firmadas o que los destinatarios lo deseen. |
| DMARC | Dominio From visible | Al menos un resultado positivo de SPF o DKIM se alinea con ese dominio. | Entrega garantizada ni ubicación en la bandeja de entrada. |
¿Cómo funciona SPF?
El receptor compara la IP del servidor que se conecta con la política SPF publicada en DNS para el dominio envelope-from. Puede hacer esa comprobación antes de recibir el cuerpo del mensaje, porque SPF no examina el contenido.
- Publicas los servidores o servicios autorizados para usar ese dominio.
- El receptor consulta la política y evalúa sus reglas contra la IP que se conecta.
- El receptor usa el resultado junto con su propia política de aceptación y filtrado.
Si un buzón de exalumnos reenvía un mensaje a otro proveedor sin cambiar la dirección envelope-from, la IP de reenvío puede carecer de autorización. Una lista de correo puede producir el mismo problema cuando reenvía un mensaje. Un reenviador puede usar Sender Rewriting Scheme (SRS), que cambia la dirección envelope-from a un dominio que puede autenticar.
Un registro SPF especifica los remitentes autorizados. Las políticas anidadas de proveedores cuentan para el límite de consultas DNS.
¿Cómo funciona DKIM?
Tu servidor de envío firma el contenido del mensaje con una clave privada. El receptor usa la clave pública correspondiente en DNS para verificar esa firma.
La firma identifica el dominio firmante con d= y el selector de clave con s=. El selector identifica qué registro DNS contiene la clave pública. El receptor consulta la clave pública y verifica la firma usando ese dominio y selector.
El reenvío por sí solo no invalida DKIM, porque la comprobación no depende de la IP del servidor de reenvío. Modificar el contenido firmado, como añadir un pie de lista de correo, puede invalidar la firma. La firma autentica el contenido que cubre; no cifra el mensaje.
¿Cómo conecta DMARC las identidades?
DMARC requiere un resultado positivo de SPF o DKIM cuyo dominio se alinee con el dominio From visible. Cualquiera de los dos resultados alineados es suficiente.
Por ejemplo, un mensaje que muestra From: billing@example.com puede pasar SPF para send.example.com con alineación relajada. Una firma DKIM que pasa con d=example.com también se alinea. La autenticación para unrelated.example no se alinea con example.com solo porque pase.
Publicas una política DMARC para solicitar el tratamiento de mensajes que fallan e informes de autenticación. Los receptores participantes envían informes; su ausencia no demuestra que ningún correo haya usado tu dominio.
¿Qué debes configurar para Bird?
Publicas DKIM, el CNAME de return-path y DMARC para tu dominio de envío. El CNAME de return-path apunta a la infraestructura de rebotes de Bird, que proporciona autorización SPF sin un registro SPF adicional en el apex.
Copia los registros desde dns_records. Comprueba capabilities.sending.status para ver si el envío está listo. Sus valores indican qué necesitas hacer a continuación:
| Estado | Significado y acción |
|---|---|
pending | La verificación no se ha ejecutado o está en curso; espera el resultado. |
verified | Los registros DNS de la capacidad coinciden con los valores esperados. |
warning | Los registros verificados anteriormente ya no coinciden; corrígelos antes de que termine el período de gracia. El envío aún no se ve afectado. |
failed | Un valor DNS es incorrecto; corrígelo. |
temporary_failure | Una consulta DNS falló de forma transitoria; la verificación reintenta automáticamente. |
not_configured | La capacidad no está configurada para este dominio. |
Publicas los registros de autenticación y verificas tu dominio de envío.
¿Qué comprobaciones debes usar?
Usa SPF y DKIM con DMARC para que las identidades autenticadas se conecten con el dominio que ven tus destinatarios.
- Autoriza la infraestructura de envío del dominio envelope-from con SPF.
- Firma los mensajes salientes con DKIM y publica la clave de verificación.
- Publica DMARC, revisa los fallos de autenticación reportados y corrige los remitentes legítimos antes de aplicar cuarentena o rechazo.