Pueden salir correos de phishing en nombre de tu dominio sin que lo sepas. SPF / DKIM / DMARC frenan eso. Aquí tienes el papel de cada uno y cómo configurarlos con seguridad.
El papel de cada uno
| Ajuste | Papel (en una línea) |
|---|---|
| SPF | Declara en DNS qué servidores pueden enviar por este dominio |
| DKIM | Añade una firma criptográfica que prueba que el correo está inalterado y proviene de una fuente legítima |
| DMARC | Declara qué hacer si SPF/DKIM fallan y recibe informes (el ajuste que une a los tres) |
Los tres son registros de texto (TXT) en DNS. Para example.com tienen este aspecto (los valores son de ejemplo).
| Ajuste | Dónde va | Valor de ejemplo |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | selector._domainkey.example.com | v=DKIM1; k=rsa; p=(clave pública emitida por tu servicio de envío) |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Para el include: de SPF, usa el valor que te indique tu servicio de envío de correo. La clave pública de DKIM también la emite el servicio de envío, así que no la creas tú.
Cómo se verifica el correo
Los receptores (Gmail, etc.) comprueban SPF y DKIM en un mensaje entrante y luego aplican tu política DMARC para decidir «aceptar / poner en cuarentena / rechazar».
Así que SPF y DKIM por sí solos pueden «comprobar pero no hacer nada»; solo con una política DMARC «frenan» de verdad la falsificación.
Lo que se suele pasar por alto: la alineación de dominios
La clave de un veredicto DMARC es que los dominios coincidan. DMARC solo pasa cuando el dominio del remitente que el destinatario ve en su programa de correo (el encabezado From) coincide con un dominio verificado por SPF o DKIM.
SPF no comprueba el remitente visible; comprueba el dominio del remitente de sobre (envelope sender), el que se usa por detrás para la entrega. Así, un atacante puede pasar SPF con su propio dominio y escribir el tuyo solo en el campo From. Si SPF pasa pero no coincide con el dominio del From, y DKIM tampoco aporta una coincidencia, DMARC da el mensaje por fallido. Comprobar esa coincidencia es justo lo que permite a DMARC frenar la falsificación de la dirección From.
Cómo configurarlos con seguridad
Un único registro SPF correcto
Autoriza a todos los remitentes legítimos (los tuyos, servicios de correo, etc.). Mantén un registro SPF por dominio (varios registros tienden a romperlo).
Habilita la firma DKIM
Activa DKIM en tu plataforma de correo y publica la clave pública en DNS, para que el correo legítimo quede firmado.
Empieza DMARC en p=none
No rechaces de inmediato. Empieza con p=none (solo monitorizar) + informes para confirmar que el correo legítimo no se descarta.
Endurece gradualmente
Cuando los informes muestren que no se pierde ningún remitente legítimo, pasa a p=quarantine → p=reject, llegando finalmente a «la falsificación se rechaza».
El «exactamente uno» del paso 1 viene de la especificación. El RFC 7208 dice que, si un dominio tiene más de un registro SPF, el resultado es permerror (un error permanente). La misma especificación limita a 10, en toda la evaluación, las consultas DNS de include y términos similares; superarlo también es permerror. Cuando añadas un servicio de correo, amplía el único registro existente en lugar de crear otro.
Errores habituales
| Error | Qué pasa | Solución |
|---|---|---|
| Dos registros SPF | SPF devuelve permerror | Únelos en uno |
Demasiados include anidados | Las consultas DNS superan 10 → permerror | Elimina los include de servicios que no uses |
| DKIM sin habilitar en un servicio de envío | El correo de ese servicio falla DMARC | Habilita DKIM en el servicio y publícalo en DNS |
| DMARC olvidado en p=none | El correo falsificado sigue pasando | Lee los informes y súbelo a reject |
| Nada configurado en un dominio que no envía correo | No se puede frenar la falsificación en nombre de ese dominio sin uso | Publica v=spf1 -all y DMARC p=reject |
Cómo revisar tu propio dominio
- Introduce tu dominio en el verificador de SPF / DKIM / DMARC para ver si existen los tres registros y qué falla en ellos
- Para mirarlo directamente desde la línea de comandos, ejecuta
dig +short TXT example.com(SPF) ydig +short TXT _dmarc.example.com(DMARC) - Envía un mensaje desde tu dominio a una dirección de Gmail y usa «Mostrar original» en Gmail para confirmar que
SPF,DKIMyDMARCindicanPASS - Cuando empiecen a llegar los informes DMARC (rua), revisa cada semana si aparecen remitentes que no reconoces
Para un sitio cuya propiedad hayas verificado, la auditoría de seguridad del sitio revisa estos registros junto con los ajustes del lado web.
Un caso real: correo falsificado «desde tu propia dirección»
«Recibí un correo amenazante de mi propia dirección a mí mismo» es un caso típico sobre el que han advertido la IPA de Japón y otros organismos. La mayoría no son cuentas robadas: simplemente se reescribió el campo del remitente. Como el remitente puede poner lo que quiera en ese campo, ese correo puede llegar a la bandeja de entrada en dominios que no han subido DMARC a reject. Cómo distinguirlo y qué hacer se explica aquí:
- Spam desde tu propia dirección de correo (en inglés; comprueba en cinco minutos si te hackearon)
- Correo falsificado con tu propio dominio (leer los encabezados y frenarlo con SPF, DKIM y DMARC)
Actualización de la especificación (mayo de 2026)
DMARC se revisó en mayo de 2026 como RFC 9989, que deja obsoleto el anterior RFC 7489. Las tres políticas —p=none, p=quarantine y p=reject— no cambian. Lo que cambió: se eliminó la etiqueta pct (el porcentaje a aplicar) y se sustituyó por una etiqueta t que indica el modo de prueba, y se añadió una etiqueta np para la política de los subdominios inexistentes. Los registros existentes no dejan de funcionar de un día para otro, pero no uses pct al escribir uno nuevo.
La visión de este sitio: también estás protegiendo a tus usuarios
SPF/DKIM/DMARC no es solo que tu correo llegue; también protege a tus usuarios del phishing que suplanta tu dominio. El phishing es, en última instancia, una forma de robar credenciales y claves.
Muchos dominios se quedan en SPF/DKIM y nunca suben DMARC a aplicación (reject). No te quedes en p=none; lee los informes y sube hasta reject para que tenga efecto.
Fuentes (primarias)
- IETF RFC 7208, «Sender Policy Framework (SPF)» (en inglés) — datatracker.ietf.org (un registro por dominio; 10 consultas DNS como máximo)
- IETF RFC 6376, «DomainKeys Identified Mail (DKIM) Signatures» (en inglés) — datatracker.ietf.org
- IETF RFC 9989, «Domain-Based Message Authentication, Reporting, and Conformance (DMARC)» (mayo de 2026; deja obsoleto el RFC 7489; en inglés) — datatracker.ietf.org
- Google, «Email sender guidelines» (en inglés) — support.google.com (requisitos desde el 1 de febrero de 2024; requisitos para quienes envían 5.000 o más mensajes al día)
Sigue leyendo
- Qué hacer: Distinguir y frenar el correo falsificado · Spam desde tu propia dirección de correo (en inglés)
- Glosario: Qué es el phishing · Qué es .env
- Herramienta: Verificador de SPF / DKIM / DMARC