Cualquiera puede escribir su dominio en la línea From de un correo electrónico. SPF, DKIM y DMARC permiten al servidor receptor comprobar si un mensaje procede realmente de usted y le indican qué hacer cuando no es así. Bien configurados, dificultan mucho la suplantación del dominio exacto. Configurados con prisas, pueden bloquear sus propias facturas.
Qué hace cada mecanismo
SPF (Sender Policy Framework, RFC 7208) es un registro DNS TXT que enumera los servidores autorizados a enviar correo en nombre de un dominio. El receptor compara la dirección IP del servidor que se conecta con esa lista. SPF comprueba el remitente del sobre (las identidades MAIL FROM y HELO), no la dirección From que ve el destinatario.
DKIM (DomainKeys Identified Mail, RFC 6376) añade una firma criptográfica a cada mensaje. La etiqueta d= indica el dominio firmante y s=, un selector. La clave pública se publica en el DNS en selector._domainkey.domain. Una firma válida demuestra que las partes firmadas del mensaje no han cambiado desde que ese dominio lo firmó.
DMARC vincula ambos con el dominio From visible. En mayo de 2026 se publicó una versión revisada como RFC 9989, un documento de la vía de estándares (Standards Track) que sustituye al RFC 7489. Un registro DMARC declara su política y pide a los receptores que le envíen informes.
| Mecanismo | Qué demuestra | Dónde se publica | Carencia si se usa solo |
|---|---|---|---|
| SPF | La IP de envío está autorizada para el dominio del sobre | En el propio dominio | No dice nada de la dirección From que lee la gente |
| DKIM | Un dominio avala el mensaje | selector._domainkey.domain | El dominio firmante puede ser cualquiera |
| DMARC | SPF o DKIM se superaron para un dominio que coincide con el dominio From | _dmarc.domain | Depende de que SPF y DKIM estén bien antes |
La alineación es lo que se suele pasar por alto
Un mensaje supera DMARC cuando SPF o DKIM se superan y el dominio autenticado está alineado con el dominio From. La alineación flexible (relaxed), la predeterminada, acepta que coincida el dominio organizativo, de modo que mail.example.eu está alineado con example.eu. La alineación estricta (adkim=s o aspf=s) exige una coincidencia exacta.
Los remitentes externos son donde esto suele fallar. Una plataforma de boletines puede usar un dominio de sobre como bounces.platform.example. SPF se supera para el dominio de la plataforma, pero ese dominio no está alineado con example.eu, así que no aporta nada a su resultado DMARC.
La solución es que la plataforma firme con DKIM usando d=example.eu, o configurar una dirección de retorno (return-path) personalizada en uno de sus propios subdominios. El RFC 9989 recomienda a los titulares de dominios usar tanto SPF como DKIM. Así, uno de ellos puede sostener el resultado cuando el otro falla, por ejemplo tras un reenvío.
Qué aspecto tienen los registros
Los ejemplos siguientes usan una dirección IP de documentación y un proveedor ficticio. Sustitúyalos por sus propios valores.
example.eu. TXT "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"El registro DMARC anterior está en modo de supervisión. Solicita informes agregados, pero no pide ninguna acción sobre el correo que falla. Los informes agregados, especificados ahora en el RFC 9990, muestran qué servidores envían correo usando su dominio y si superan las comprobaciones.
En cuanto a las claves DKIM, el RFC 6376 exige claves RSA de al menos 1024 bits para las claves de larga duración. Google exige al menos 1024 bits para el correo dirigido a cuentas personales de Gmail y recomienda 2048 bits si su proveedor lo admite.
Un despliegue seguro de p=none a p=reject
- Haga una lista de todos los remitentes. Incluya su plataforma de correo, el CRM, los sistemas de facturación y de nóminas, el servicio de asistencia, los formularios web y dispositivos como los escáneres que envían documentos por correo.
- Configure SPF y DKIM para cada uno. Pida a cada servicio que firme con DKIM bajo su propio dominio siempre que lo permita.
- Publique
p=nonecon una direcciónrua. El RFC 9989 lo describe como el punto de partida habitual, para que pueda encontrar los remitentes que se le pasaron por alto durante la configuración. - Lea los informes y corrija las carencias. Dedíquele al menos varias semanas, y más si tiene envíos mensuales o trimestrales, como las nóminas o los extractos anuales.
- Pase a
p=quarantiney después ap=reject. El RFC 9989 eliminó la antigua etiquetapct. La sustituye el modo de prueba:t=ypide a los receptores que apliquen la política un nivel por debajo, de modo quep=reject; t=yse trata como cuarentena. - Cubra los subdominios y los dominios aparcados. La etiqueta
spfija la política de los subdominios existentes, y la nueva etiquetanpcubre los subdominios que no existen.
Considere t=y una forma de suavizar, no una garantía. Tanto el RFC 7489 como el RFC 9989 indican a los receptores que ignoren las etiquetas que no reconocen. Por tanto, un receptor que aún no haya adoptado la nueva especificación puede aplicar la política publicada en su totalidad.
En cuanto al paso 6, un dominio que nunca envía correo debe decirlo de forma explícita. Publique un registro SPF que no autorice a nadie y una política de rechazo:
parked-example.eu. TXT "v=spf1 -all"
_dmarc.parked-example.eu. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu. TXT "v=DMARC1"El tercer registro es importante porque los informes van a otro dominio. El RFC 9990 exige a los receptores comprobar, antes de enviar los informes, que el dominio de destino ha aceptado recibir informes del dominio de la política.
Los grandes proveedores de buzones ya esperan este trabajo. Desde el 1 de febrero de 2024, Google exige a los remitentes masivos (más de 5000 mensajes al día a Gmail) que usen SPF, DKIM y DMARC con alineación. Una política p=none cumple ese mínimo, pero no protege su dominio.
Errores habituales
Dos registros SPF
Un dominio solo puede publicar un registro SPF. Si un receptor encuentra más de uno, el resultado SPF es permerror en lugar de pass. Cuando añada un servicio nuevo, incorpore su include al registro existente en lugar de crear uno segundo.
Más de diez consultas DNS
El RFC 7208 limita la evaluación de SPF a 10 términos que generan consultas DNS: include, a, mx, ptr, exists y el modificador redirect. Los include anidados dentro de los suyos también cuentan. Si supera el límite, el resultado es permerror.
Los términos ip4, ip6 y all no cuentan, así que enumerar sus propios servidores por dirección ayuda. Elimine los include de servicios que ya no use. El RFC también sugiere limitar a dos las «consultas vacías» (void lookups), es decir, las que no devuelven respuesta.
+all y ?all
El mecanismo all coincide siempre, y su calificador decide el resultado. Por eso +all autoriza a todos los servidores de internet: no lo publique nunca. ?all devuelve neutral, y el RFC 7208 indica que debe tratarse exactamente igual que la ausencia de resultado SPF. Use ~all (softfail) o -all (fail).
¿Cuál de los dos? La especificación original de DMARC (RFC 7489, apartado 6.7) señala que rechazar ante un fallo de SPF impide al receptor evaluar DKIM. Eso puede perjudicar al correo reenviado, en el que SPF falla pero la firma DKIM sigue siendo válida. Una vez que DMARC se aplica, ~all deja que sea DMARC quien tome la decisión final.
Olvidarse del reenvío y de las listas de correo
Un mensaje reenviado llega desde la dirección IP del reenviador, que no figura en su registro SPF. Una firma DKIM suele sobrevivir al reenvío si el mensaje no se modifica. Sin embargo, las listas de correo que editan el asunto o añaden un pie pueden romperla. Por eso, al pasar a p=reject, una firma DKIM fiable bajo su propio dominio importa más que SPF.
Usar ptr
El RFC 7208 indica que el mecanismo ptr no debe publicarse. Es lento, menos fiable y además cuenta para el límite de consultas.
Aplicar la política sin leer los informes
Saltar directamente a p=reject es una forma fácil de bloquear sus propios restablecimientos de contraseña, facturas o respuestas de soporte. Los informes le dicen qué remitentes ha olvidado. Léalos antes de aplicar la política y siga leyéndolos después, porque se van añadiendo servicios nuevos.
Por dónde empezar
- Compruebe lo que publica hoy su dominio con nuestro análisis de seguridad del correo.
- Cree o ponga en orden sus registros con el generador de SPF y DMARC.
- Anote todos los sistemas que envían correo como su dominio. Necesitará esta lista antes de aplicar la política.
- Publique ya
p=nonecon una dirección para los informes y reserve una fecha para revisar los primeros. - Añada
v=spf1 -ally un registro DMARC conp=rejecta todos los dominios de su propiedad que no envíen correo.
Si prefiere delegar el análisis de los informes y el paso a la aplicación de la política, nuestro servicio de seguridad gestionada puede ayudarle con ambas cosas.
