Tutorial: a vueltas con dominios, SPF, DKIM y DMARC en G Suite


SPF, DKIM, DMARC. Léanse con voz ominosa y alargando las pocas vocales disponibles. ¿Acrónimos inefables o herramientas que como administradores de un dominio (no solo) de G Suite debemos conocer y aprender a amar? El objetivo de este artículo, que hace tiempo que quería escribir, es conseguir que si para ti son lo primero, al terminar de leerlo pasen a convertirse en lo segundo.

Hoy por tanto cambiamos de tercio. Abandonamos los verdes valles en los que pacen las herramientas de usuario de Google para educación para adentrarnos en las cavernosas entrañas de la consola de administración de G Suite. No hay nada aquí por tanto que se pueda aplicar en nuestras clases. Me atrevería a decir por ello que este artículo puede resultar de interés a incipientes administradores de un dominio de G Suite (los ya experimentados debería saber todo esto) o quizás a los que estén aspirando a serlo. Y naturalmente a todo aquel con curiosidad biensana por conocer los entresijos técnicos de herramientas que usamos todos los días, como es el caso del correo electrónico en esta ocasión.

¿Qué vamos a hacer? Partiendo de un dominio de nuestra propiedad (ya registrado), vamos a desarrollar, despacito, con buena letra y del mejor modo posible, todo su proceso de activación en el ámbito de una cuenta de G Suite. Concretamente:
  1. Añadiremos un dominio a nuestra cuenta de G Suite para que el correo empiece a fluir, verificando su propiedad y configurando los registros MX del DNS.
  2. Tomaremos las precauciones necesarias para impedir, o al menos dificultar, que terceros envíen correos fraudulentos en el nombre de nuestros usuarios. Aquí es donde entrarán en juego las siglas que protagonizan este artículo.
 Pero primero...

Un poco de teoría sobre los protocolos SPF, DKIM y DMARC

SPF, DKIM y DMARC son protocolos. Simplificando hasta el punto de correr el riesgo de caer en la inexactitud, los protocolos son especificaciones técnicas que establecen cómo deben hacerse las cosas para que varias partes se entiendan entre sí y puedan alcanzar un objetivo común. Así de simple.

¿Y para qué sirven estos tres? Básicamente, para conseguir un sistema global de correo más seguro. Y además tanto más seguro (para el conjunto mundial de usuarios) en cuanto más y más administradores de sistemas se adhieran a la buena práctica que supone configurar sus dominios y servidores de correo para hacer uso de ellos. Ya ves, incluso nos encontramos aquí con una finalidad parcialmente altruista que redunda en el procomún. Si es que no sé a qué estás esperando para configurar tu dominio debidamente... o para darle la tabarra a tu Administrador (ahora con mayúsculas, a ver si así nos hace más caso) para que lo haga.

Lo primero que debemos saber es que la por ahora misión secreta de SPF, DKIM y DMARC es compartida. Son como los Tres Mosqueteros, uno para todos y todos para uno, luchando contra el cardenal Richelieu por el honor de la Reina Ana de Austria. O los usamos todos o más vale que nos olvidemos de ellos. No, D'Artagnan no sale en esta historia. Los Mosqueperros tampoco. Esto último probablemente solo lo entiendas si has hecho la EGB ;-).

Lo segundo, y tal vez más urgente, es que si no los configuramos correctamente podemos (con toda seguridad ocurrirá) interrumpir el funcionamiento del sistema de correo de todo nuestro dominio. Así que ¡cuidado! Se podría decir que lo que se cuenta a partir de dos o tres apartados más abajo es claramente zona hostil para manazas.

Pero ¿qué demonios hacen estos protocolos? Hay infinidad de artículos donde lo explican de un modo mucho más detallado de lo que yo lo voy a hacer, pero así resumiendo:

SPF (Sender Policy Framework) se utiliza para identificar de un modo unívoco (a través de su dirección IP) los servidores autorizados para emitir el correo de un dominio determinado.

DKIM (DomainKeys Identified Mail) es un método de firma digital de los correos salientes desde un dominio concreto que trata de garantizar dos cosas: que nadie los ha modificado en tránsito y que efectivamente proceden de la organización de donde dicen proceder. Se trata de una estrategia tanto de autenticación como de verificación de la integridad del mensaje extremo a extremo. Esto se consigue mediante un sistema criptográfico asimétrico, de clave pública / privada y basado en RSA, que se utiliza para añadir una firma digital única. Mucho ojito, DKIM no puede reemplazar a un sistema de autenticación / cifrado que actúe en el ámbito del usuario, como PGP (aunque este ahora lo está pasando un poco mal). Solo valida el dominio de origen (que no es moco de pavo). Tampoco aplica cifrado sobre el contenido del mensaje, que viaja tan abierto como en un sistema sin DKIM.

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la pieza final del rompecabezas que pone a SPF y DKIM en su lugar. Mediante él podemos establecer y comunicar una política para indicarles a otros sistemas de correo qué deben hacer cuando reciban mensajes que parezcan proceder de nuestro dominio pero fallen alguno de los controles de seguridad implementados por SPF o DKIM. Hermoso (o al menos a mí me lo parece).

Para que esto funcione es necesario que se den dos circunstancias:

La primera, que los servidores encargados del procesamiento del correo electrónico estén configurados del modo debido. Como administradores de un dominio de G Suite esto escapa a nuestro control, pero no temamos, Google se ha encargado ya de eso.

Y la segunda: hay que toquetear algunas cosillas en los registros DNS de nuestros dominios, concretamente en los registros TXT. Y esto sí es cosa nuestra. El proceso de activación y configuración de SPF, DKIM y DMARC se realiza en dos lugares:
  • El panel de control web que nos debe proporcionar el proveedor en el que hemos registrado nuestros dominios.
  • La consola de administración de G Suite.
Una última pregunta antes de empezar...

¿Por qué debemos utilizar este tinglado?

Porque haciéndolo contribuímos a luchar globalmente contra cosas tan desagradables como los correos falsificados, portadores de toda clase de marranadas como virus, gusanos y troyanos o simplemente el SPAM. Los sistemas de filtrado de correo basura de proveedores como Google o Microsoft (y otros servidores no tan extendidos) han evolucionado enormemente en los últimos años. No obstante, un sistema de correo global que utilice SPF, DKIM y DMARC pone unas cuantas piedras en el camino de spammers y otra gente de mal vivir.

No obstante no todo es paz y felicidad. Este tinglado tiene limitaciones y debilidades que pueden ser explotadas por astutos malvados. No es el momento ni el lugar de entrar en ellas, aunque sí me gustaría reforzar la idea, una vez más, de que uno de sus principales problemas es que no todos los sistemas de correo usan SPF, DKIM y DMARC en estos momentos... o lo hacen sin aplicar una política lo suficientemente estricta.

¿Tengo entonces que preocuparme yo por hacerlo? La respuesta corta es: .


 Seguro que ya tienes ganas de meterle mano a esto ¿verdad? Vamos pues.

¿Utiliza mi sistema de correo estos sistemas de protección?

Eso tiene un respuesta sencilla. Para averiguarlo utilizaremos una herramienta web de diagnóstico denominada Check MX que está incluida en la caja de herramientas de G Suite que nos proporciona Google. Escribiremos el nombre de nuestro dominio...



...y haremos clic en Realizar comprobaciones.



Como puedes ver, este dominio falla las tres comprobaciones (SPF, DKIM y DMARC). También parece haber algún problemilla con la prioridad de los registros MX (los que especifican los servidores encargados de gestionar el correo del dominio), aunque esto no es importante. Fíjate en el mensaje que muestra la herramienta: "problemas no críticos". A pesar de los perturbadores cartelitos amarillos el correo funciona perfectamente. Si no tenemos mayores inquietudes, fin de la historia.

Pero no es el caso ¿verdad?

Por cierto, parece que en Google hay algún que otro ingeniero cachondo. Mirad lo que pasa si tratamos de fisgar en gmail.com. No, Google no es mi peor enemigo, pero tenía curiosidad...



Claro, claro ¿cómo podría estar mal configurado? Pero bueno, pongámonos manos a la obra porque tenemos bastante trabajo. Siguen una cantidad probablemente indecente de capturas de pantalla, así que si tienes poca batería enchufa el cargador.

Paso 1 de 4. Añadir un dominio a la cuenta de G Suite

Partimos de una cuenta de G Suite operativa. En mi caso, varios dominios han sido ya agregados a ella, por lo que desarrollaré el ejemplo suponiendo que el nuevo se añadirá como secundario. Es un detalle sin importancia, en cualquier caso.

Abrimos la consola de administración de G Suite.


Nos dirigimos a la sección Dominios:


Hacemos clic en:

Añadir o quitar dominios  → Añadir un dominio o un alias de dominio Añadir otro dominio 

Recuerda, en este ejemplo ya tengo varios administrados desde la consola. Escribimos su nombre y hacemos clic en Continuar y verificar la propiedad del dominio.


Ahora deberemos verificar la propiedad del dominio. Podemos buscar en la lista desplegable el nombre del proveedor en el que lo hemos registrado para que aparezcan en pantalla instrucciones específicas. Si no lo encontramos siempre podemos seleccionar Otros para obtener indicaciones genéricas.


La comprobación de propiedad pasa por introducir ciertos cambios en los registros DNS del dominio a verificar. Si hemos escogido otros lo conseguiremos añadiendo un registro TXT, aunque también es posible lograrlo mediante uno de tipo CNAME. 


En ambos casos en pantalla se mostrará el valor del registro TXT o la etiqueta y destino CNAME correspondientes. Escoger un método u otro en principio debería ser indiferente, aunque lo cierto es que el proceso en ocasiones será más o menos indoloro dependiendo de las manías del proveedor de hospedaje utilizado.

A continuación deberemos acceder al panel de control de nuestro proveedor de hospedaje y localizar la sección en la que se efectúa la configuración de los registros DNS. El procedimiento puede variar ligeramente (o no tan ligeramente) en cada caso. Ante la imposibilidad de facilitar unas instrucciones inequívocas solo puedo mostrarte cómo se hace en el mío (Strato) y desearte que la fuerza te acompañe. Si lo intentas y no te aclaras seguro que alguien en la comunidad GEG podrá echarte un cable.

En Strato la cosa funciona más rápidamente por la vía CNAME. Agregaremos primeramente un subdominio coincidente con la cadena de texto hasta el primer punto (.) por la izquierda del valor etiqueta / host de CNAME que se facilita en las instrucciones proporcionadas por la consola de administración.


Una vez creado hay que ajustar su registro CNAME (ojo, operamos sobre el subdominio, no en el dominio general).



Y aquí colocamos el valor correspondiente a Destino / Orientación CNAME obtenido anteriormente. Sin dejarnos el punto (.) final (¡cuidado!).


Solo queda volver a la consola de administración justo donde lo dejamos y hacer clic en el botón rojo Verificar.


En principio la verificación puede demorarse un tiempo. Depende de la velocidad de propagación de los cambios efectuados en los registros DNS (que no deja de ser una enorme base de datos distribuida a escala mundial). Por mi experiencia con Strato, cuando se siguen los pasos descritos (CNAME), en la práctica es casi instantáneo. Si todo ha ido correctamente veremos esto:


Con esto alcanzamos el ecuador (de la fase 1). Haremos ahora clic en Configurar registros MX de Google en la entrada correspondiente al dominio cuya propiedad acabamos de verificar.


Aparecerán nuevas instrucciones. Podemos buscar en la lista nuestro proveedor o bien optar por las genéricas. Lo que nos interesa es la tabla del apartado 4.


Pertrechados con esa información regresaremos al panel de control del proveedor donde hemos registrado el dominio para configurar sus registros MX de modo consecuente.


Aquí introduciremos los valores indicados. Una vez más, ojo con los puntos finales. Yo solo utilizo los 4 primeros, configurándolos secuencialmente como servidores primario con prioridades alta y baja y secundario (del mismo modo).
  • Primario, alta ASPMX.L.GOOGLE.COM.
  • Primario, baja ALT1.ASPMX.L.GOOGLE.COM.
  • Secundario, alta ALT2.ASPMX.L.GOOGLE.COM.
  • Secundario, baja ASPMX2.GOOGLEMAIL.COM.


La cosa debe quedar así:


Volvemos a la consola de administración. Clic en He realizado estos pasos. Un poquito de paciencia (de nuevo cosas de la propagación DNS)... et voilá.




Comprobemos ahora la salud de los ajustes DNS del dominio con Check MX.



El resultado es el esperado. Todo estupendo excepto en lo que respecta a SPF, DKIM y DMARC. Ya podemos utilizar el nuevo dominio en nuestra cuenta G Suite.



¡Enhorabuena! A por el paso 2.

Paso 2 de 4. Configurar SPF

Esto es facilito. Nuevamente hay que dirigirse al panel de control web del proveedor donde se ha registrado el dominio.


Ahora intervendremos sobre los registros TXT. En el caso de Strato hay que dejar el prefijo en blanco e incluir esta cadena como valor:

v=spf1 include:_spf.google.com ~all


Comprobemos de nuevo la salud de nuestros registros MX:


¡Listo! SPF en marcha. Podemos pasar a la fase 3, aunque quizás quieras leerte antes este interesante artículo sobre SPF en la ayuda para admins de G Suite para entender mejor lo que estamos haciendo.

Paso 3 de 4. Configurar DKIM

La configuración de DKIM arranca en la consola de administración de G Suite.

Aplicaciones → G Suite Configuración de Gmail


Clic en Autenticar el correo electrónico.


Seleccionaremos en el desplegable el dominio sobre el que deseamos actuar y haremos clic en Generar un registro nuevo. Sí, como habrás adivinado, todas estas configuraciones son por domino. Dentro de la consola de admin de G Suite puedes tener algunos funcionando con toda esta artillería de seguridad y otros mondos y lirondos en los que no se tomen precauciones especiales.


Ahora entra en juego el vudú de la criptografía. Sugiero mantener la longitud de la clave en el valor propuesto, lo normal es que no ocasione problemas. Clic en Generar para obtener las claves de cifrado DKIM. Se desplegarán el nombre y valor del registro TXT a utilizar, valor que contiene la clave pública que identificará a nuestro dominio.


Aquí la tenemos. Añadimos esta información como registro TXT en el panel de control web de nuestro proveedor. Aparece junto al correspondiente a SPF.


Nuevo chequeo de salud para asegurarnos de que los cambios en el DNS se han propagado. Comprobamos que la advertencia sobre DKIM ha desaparecido y  solo queda una relativa a DMARC.


Todo por tanto bajo control. Ahora en la consola de administración de G Suite procederemos a activar la autenticación DKIM (clic en Iniciar autenticación).


Debería aparecer un mensaje como el que se muestra con una tranquilizadora marca de verificación.



Otra etapa quemada. Ya casi hemos acabado. No obstante, antes de proseguir te recomiendo una nueva lectura acerca de DKIM.

Paso 4 de 4. Configurar DMARC

Hasta ahora difícilmente podríamos romper nada. Pero llega la hora de la verdad. SPF y DKIM están despiertos, pero no totalmente activos.

¿Qué pasa si tenemos SPF y DKIM correctamente configurados en nuestro dominio pero no hemos definido una política DMARC? Bueno, lo primero podría ayudar a que los sistemas de detección de correo fraudulento y filtrado de los servidores de correo donde se recibieran nuestros mensajes los identificaran como válidos. Pero la cosa no está completa.

Definiendo y publicando explícitamente una política DMARC haremos saber a los servidores de correo del mundo mundial qué queremos que pase cuando un correo que llegue a ellos aparentemente procedente de nuestros dominios falle total o parcialmente las verificaciones que realizan SPF y DKIM. DMARC nos aporta por tanto control sobre nuestro dominio de correo.

Atención, a partir de ahora sí podemos romper el funcionamiento del correo de nuestro dominio.

Por ello, comenzamos en esta ocasión con la literatura. Échale un vistazo a estos dos artículos. No me atrevo a seguir adelante sin pedirte encarecidamente que leas ambos con detenimiento. Estás en lo cierto, esta es la parte técnicamente más complicada.
El primero explica el funcionamiento general de DMARC y presenta la anatomía de la reglas que definen el comportamiento del protocolo. El segundo, que forma parte de la ayuda de Google para admins, propone además algunos registros de ejemplo.

Por tanto, lo que vamos a hacer ahora es añadir un nuevo registro TXT en el que, mediante una cadena de texto especialmente construida, le gritaremos al Universo cómo deben tratarse nuestros mensajes de correo electrónico. Los parámetros y sintaxis de esta cadena se resumen en esta tabla tomada del segundo artículo:


Voy a ver si consigo explicar esto de las políticas DMARC de un modo rápido y sin meterme en un jardín.

El primer concepto que debemos entender es el de verificación. ¿Qué quiere decir que un correo supera la verificación DMARC? Que procede de un servidor autorizado por nuestro dominio (SPF) y / o está firmado digitalmente de modo que se puede comprobar que no ha sido alterado en su trayecto y tiene su origen en el dominio que aparentemente lo ha emitido (DKIM).

Ahora bien, podemos establecer una política relajada (basta con superar uno de los dos chequeos para dar el correo por bueno) o estricta (si falla cualquiera de ellos se considera que globalmente no supera la verificación). 

Esto se configura con la etiqueta opcional aspf.
  • Política relajada (relaxed) aspf=r
  • Política estricta (strict)  aspf=s
El establecimiento de este parámetro tiene alguna que otra implicación adicional, realmente esto es un pelín más complicado, pero no ahondaremos más.

¿Y qué ocurre cuando un correo electrónico falla la verificación DMARC?  Esto lo controlaremos con el parámetro obligatorio p.
  • Se entrega a su destinatario p=none
  • Se pone en cuarentenap=quarentine
  • Se rechazap=reject
Es opcional pero absolutamente recomendable establecer también una dirección de email a la que se enviarán periódicamente informes en formato XML del funcionamiento del sistema. Esto se consigue con:

rua=dirección_de_email

Todas las guías de implantación de DMARC recomiendan hacer una puesta en marcha gradual del sistema para evitar problemas con la entrega del correo que sale de nuestro dominio. Eso supone comenzar con una política que acepte todos los mensajes (p=none). La distribución del correo no se limitará aunque no supere el filtro DMARC. Durante un tiempo utilizaremos la información recibida en los informes periódicos para detectar problemas.

¿Problemas como cuáles?

Por ejemplo, puede que no recordáramos al montar todo este tinglado que teníamos un dispositivo multifunción o quizás un servidor de seguridad o de backups escondido en un despacho. Cualquier de ellos podría estar tratando de enviar notificaciones relacionadas con su funcionamiento a través de su propio servidor de correo electrónico integrado utilizando una dirección de email de nuestro dominio. Con DMARC en modo batalla (cuarentena o rechazo) sus correos no serían admitidos, puesto que fallarían todas las comprobaciones, ni tan siquiera por los servidores de correo de Google de nuestro propio dominio.

Una vez se hubieran identificado y corregido posibles problemas ya se podría pasar a aplicar una política más dura, poniendo en cuarentena o rechazando los correos que fallasen cualquiera de las verificaciones y controles DMARC.

Una configuración final de la política DMARC podría ser simplemente esta:

v=DMARC1; p=reject; rua=mailto:postmaster@midominio.es

En este caso dejaríamos al libre albedrío de cada servidor de correo que recibiera mensajes procedentes de nuestro dominio la aplicación de una política estricta o relajada, en función de su configuración predeterminada.


Si, en cambio, quisiéramos forzar una política estricta (aunque lo recomendable por ahora es aplicar en su lugar una relajada) nuestro registro TXT debería pasar a ser:

v=DMARC1; p=reject; aspf=s; rua=mailto:postmaster@midominio.es

 Veamos si todo está en su sitio ahora...


Pues sí lo está. ¡Prueba superada!

Comentarios finales

El final siempre acaba llegando. Como ves esta "bestia" tiene cierta complejidad, aunque una vez entendidos los conceptos y sabiendo dónde debe realizarse cada ajuste no es tan fiera como la pintaban.

No puedo concluir sin aconsejar máxima precaución a la hora de jugar con estos juguetes.

Mi recomendación pasa ineludiblemente por crear un subdominio en un dominio ya registrado y configurado en nuestra cuenta de G Suite, activar la entrega de correo sobre él siguiendo lo indicado en este artículo y practicar sin miedo en ese entorno de prueba antes de lanzarte a poner todo esto en funcionamiento en el sistema de correo utilizado en producción.

Comentarios

  1. Perfectamente explicado. Voy a echar un ojo al dmarc.

    ResponderEliminar
  2. Esta es justo la explicación que necesitaba para configurar SPF /DKIM / DMARC y además paso a paso con pantallazos. Me has salvado de estar dando mil vueltas por la web, muchísimas gracias. Muy buen trabajo.

    ResponderEliminar
  3. Genial, muchas gracias por la explicación, muy útil

    ResponderEliminar
  4. Qué increíble post!!!!!!!!!!!!!!!!!
    Gracias por compartir tu conocimiento de esta forma. Un abrazo.

    ResponderEliminar
  5. no consigo aclararme, demasiada locura para pasar una cuenta a workspace, pero se agradece el tutorial

    ResponderEliminar

Publicar un comentario