SPF: quién tiene derecho a enviar
La RFC 7208 parte de una constatación: nada en el protocolo de correo impide que un servidor anuncie cualquier dirección de remitente. SPF permite al propietario de un dominio publicar en el DNS la lista de servidores autorizados a enviar en su nombre, y al servidor que recibe comprobar esa autorización.
Dos precisiones lo cambian todo:
- SPF comprueba la dirección de sobre (la del diálogo entre servidores, llamada «MAIL FROM») y el nombre que anuncia el servidor, no la dirección que el destinatario lee en «De».
- SPF evalúa el último servidor que ha entregado el mensaje. Cuando otro servidor reenvía un mensaje, ya no lo entrega un servidor autorizado por el dominio de origen: la comprobación puede fallar aunque el mensaje sea legítimo.
Un dominio solo publica un registro SPF. En él figuran todas las fuentes de envío: el correo, el programa de facturación, la herramienta de boletines, el CRM, la fotocopiadora que escanea al correo.
DKIM: el mensaje va firmado
Según la RFC 6376, DKIM permite al propietario de un dominio firmante asumir una parte de responsabilidad sobre un mensaje, mediante una firma criptográfica. La clave pública está en el DNS. Verificar la firma demuestra que las partes firmadas no han cambiado desde la firma.
La firma viaja con el mensaje. Por eso sobrevive mejor que SPF a un relé o a un reenvío, siempre que ese relé no modifique el asunto o el cuerpo. Una lista de distribución que añade una nota al pie del mensaje la rompe.
Lo que DKIM no hace, según la misma RFC: no cifra el mensaje, un fallo no obliga a rechazarlo y el dominio que firma no tiene por qué ser el que aparece en «De». Es precisamente el hueco que llena DMARC.
DMARC: la alineación y la política
La RFC 7489 define DMARC como un medio para que el propietario de un dominio exprese una política a nivel de dominio. El mecanismo se basa en la alineación: el dominio de la dirección mostrada en «De» debe corresponder al dominio validado por SPF o por DKIM. Si ninguno de los dos está alineado, DMARC falla.
El dominio publica entonces lo que desea:
- none: no se solicita ninguna acción, se observa;
- quarantine: tratar el mensaje como sospechoso;
- reject: rechazar el mensaje.
DMARC también prevé informes: informes agregados, que resumen qué servidores han enviado en nombre del dominio y con qué resultado, e informes de fallo, mensaje por mensaje. Son ellos los que permiten descubrir una herramienta olvidada que envía en su nombre, o a alguien que suplanta su dominio.
| Mecanismo | Qué comprueba | Qué no mira |
|---|
| SPF | El servidor que entrega el mensaje está autorizado para el dominio de sobre | La dirección mostrada, el contenido |
| DKIM | El mensaje firmado no se ha modificado; un dominio asume su responsabilidad | La dirección mostrada, la honestidad del contenido |
| DMARC | El dominio mostrado está alineado con SPF o DKIM; política en caso de fallo | Los dominios parecidos, el nombre visible, el texto |
¿Bloquea DMARC el phishing?
Bloquea una parte de la suplantación del dominio, no el phishing en general. La RFC 7489 lo dice explícitamente: DMARC no trata los nombres de dominio visualmente parecidos ni el abuso del nombre visible, y el análisis del contenido queda fuera de su ámbito. No pretende resolver todos los problemas del correo fraudulento.
En concreto, DMARC no ve:
- un dominio parecido: el estafador autentica perfectamente su propio dominio, que se parece al suyo;
- un nombre visible suplantado: «Departamento de contabilidad» escrito desde una dirección sin relación alguna;
- una cuenta comprometida que firma correctamente, puesto que es el servidor real el que envía;
- un mensaje sin relación con su dominio: una falsa alerta de una empresa de transporte llega desde un dominio que no tiene nada que ver con el suyo;
- un dominio sin política: si el dominio imitado publica «none», el destinatario no tiene ninguna instrucción de rechazo.
Estos casos corresponden a otros análisis: parecido de los dominios, reputación, contenido, comportamiento. Véase spam, phishing, malware y cuenta comprometida.
Reenvíos y listas de distribución: ARC
Un reenvío suele romper SPF, una lista que modifica el mensaje rompe DKIM, y DMARC falla entonces con un mensaje legítimo. ARC, descrito en la RFC 8617 (estado experimental), permite a cada intermediario dar fe del resultado de autenticación que ha constatado. El servidor final puede decidir tenerlo en cuenta.
Proteger el propio dominio, filtrar lo que llega
Son dos temas que a menudo se confunden.
- Proteger el dominio que envía: publicar SPF, DKIM y DMARC para su dominio, para que los demás puedan rechazar los mensajes que lo suplantan. Usted publica; los destinatarios aplican.
- Filtrar lo que llega: comprobar los registros de los demás dominios en el correo que usted recibe y aplicar después todos los demás análisis.
Implantación progresiva
- Inventario de todo lo que envía en nombre del dominio.
- Un único registro SPF que los autorice; una firma DKIM para cada servicio capaz de firmar.
- DMARC en «none», con una dirección de recepción de los informes.
- Lectura de los informes durante varias semanas; corrección de las fuentes olvidadas.
- Paso a «quarantine» y después a «reject» cuando todos los envíos legítimos estén alineados.
Ejemplo, a título ilustrativo. Un despacho publica DMARC en «none» y lee sus primeros informes. Descubre tres fuentes: su correo, bien alineado; su programa de facturación, que envía las facturas con el dominio del despacho sin firma DKIM; y un servidor desconocido en el extranjero que envía cientos de mensajes en su nombre. Corrige el programa de facturación, espera un ciclo de informes limpio y pasa a «quarantine»: los destinatarios que aplican DMARC tratan ahora como sospechosos los mensajes del servidor desconocido.
El día que se cambia de correo, estos registros se preparan antes del cambio de MX. La guía migrar un correo sin interrupción describe ese momento; no se repite aquí.
Preguntas frecuentes
¿Protege una política DMARC «none»?
No. Permite observar gracias a los informes. La protección empieza con «quarantine» o «reject».
¿Por qué falla DMARC con un mensaje legítimo?
Lo más frecuente: un reenvío, una lista de distribución o un servicio que envía en su nombre sin estar declarado en SPF ni firmar con DKIM.
Nuestro correo no firma con DKIM: ¿qué hacemos?
Una pasarela situada en el recorrido de los envíos puede firmar en su lugar. Véase Proteger el correo que ya tiene.
¿Dónde se lee el resultado de estos controles en un mensaje recibido?
En los encabezados del mensaje. Para Klytic MTA, véase Leer y exportar una decisión del filtro.
Dónde se sitúa Klytic
Klytic MTA trata los dos temas, delante de cualquier correo:
- Esencial y Avanzado: control de SPF, DKIM y MX; verificación DMARC, incluso para los mensajes reenviados gracias a ARC; firma DKIM de los envíos, aunque su correo no lo haga.
- Avanzado: consola DMARC, con los informes de sus dominios, alertas y propuestas de corrección, para llevar a cabo el paso progresivo a «reject».
DMARC es solo una capa: Klytic MTA añade la detección de los dominios similares, del nombre visible y de los escenarios de fraude, descrita en suplantación y fraude del CEO.
Si utiliza Klytic Mail, SPF, DKIM y DMARC están configurados para su dominio: es la protección del dominio que envía. Klytic MTA, por su parte, se contrata con o sin Klytic Mail.
Fuentes
Consultadas en octubre de 2026.
- RFC 7208, SPF: el propietario de un dominio publica los hosts autorizados a utilizar su dominio en la identidad «MAIL FROM» o «HELO», y el receptor comprueba esa autorización. rfc-editor.org
- RFC 6376, DKIM: un dominio asume la responsabilidad de un mensaje mediante una firma criptográfica; sin cifrado, sin rechazo obligatorio, con un dominio firmante que puede ser distinto del autor mostrado. rfc-editor.org
- RFC 7489, DMARC: alineación del dominio de «From» con SPF o DKIM, políticas none, quarantine y reject, informes agregados y de fallo; dominios visualmente parecidos, nombre visible y análisis del contenido fuera de su ámbito. rfc-editor.org
- RFC 9989 (mayo de 2026), que sustituye a la RFC 7489: mismos valores de política y mismas exclusiones (dominios parecidos, nombre visible). rfc-editor.org
- RFC 8617, ARC (experimental): cadena de transmisión autenticada; un receptor DMARC puede aceptar las evaluaciones que transmite una cadena ARC válida. rfc-editor.org
- Klytic, página Klytic MTA: controles de autenticación, firma DKIM saliente y consola DMARC de las ofertas Esencial y Avanzado, opciones, modos de despliegue, puesta en servicio mediante el MX. klytic.com
