Hablemos de DNS - Parte 2: Correo Electrónico

La configuración de registros DNS para la entrega de correo electrónica puede ser algo confusa, en este artículo, voy a intentar explicarte qué registros tener en cuenta para que tus mensajes lleguen.


6 min de lectura
Hablemos de DNS - Parte 2: Correo Electrónico

La configuración de registros DNS para la entrega de correo electrónica puede ser algo confusa, en este artículo, voy a intentar explicarte qué registros tener en cuenta para que tus mensajes lleguen.

Hace unas semanas, escribí un artículo explicando los registros básicos de DNS, lo hice porque sigo viendo mucha confusión sobre cómo funcionan, así que por eso hice esta serie que empezó con el siguiente artículo.

Hablemos de DNS - Parte 1: Registros básicos
En este artículo, explicaré los registros DNS básicos. Si tenés dudas sobre como funcionan, acá encontrarás información.

Pero en este, vamos a hablar sobre los registros de DNS específicos para correo electrónico. De alguna manera, los podemos dividir en dos, el esencial, para que el servidor reciba y envíe correo y los registros de seguridad que van a contribuir en gran parte a que nuestro servidor efectivamente pueda enviar correos electrónicos y estos no caigan en SPAM.

Registros Esenciales

Hay dos registros que son claves para configurar en nuestra zona de DNS que son claves para que el servidor mande y reciba correo. Ellos son...

Registro MX

El registro MX (Mail Exchanger) es el más importante de todos, porque acá, debemos especificar, cuál va a ser el host, que se ve encargar del correo electrónico de nuestro dominio. En nuestro registro MX, no podemos poner direcciones IP, solo van nombres de dominio, un ejemplo puede ser:

record               ttl  class   rr  pref name
example.com          3w   IN      MX  10   mail.example.com.

Este registro, que está en formato bind, le va a decir que nuestro servidor de intercambio de email para el dominio example.com es mail.example.com.

Registro A

Otro registro clave para que funcione es un registro A que diga que, usando el ejemplo anterior, mail.example.com, sea determinada dirección IP. En formato Bind, este registro debería ser algo así:

record               ttl  class   rr  pref name
mail                 10d  IN      A   10   IP Address

Esto quiere decir que el registro A, llamado mail, dentro de la zona example.com va a parar a la dirección IP de nuestro servidor.

Estos son los registros claves para que el servidor reciba y envíe correo electrónico, ahora veremos, cuales son los registros, que también son muy importantes para que los mensajes que mandamos a través de nuestro servidor, no caigan a SPAM o vuelvan rebotados.

Registros de seguridad

Lo que yo llamo registros de seguridad, son los registros que necesitamos para asegurarnos de que nuestros mensajes lleguen a quien corresponda, directamente a su Inbox y no a la carpeta de SPAM.

SPF

Un registro SPF, es un registro del tipo TXT y es en donde debemos definir cuáles direcciones IP y Hostnames son los autorizados para mandar email de ese dominio. Si no configuramos este registro cualquier otro servidor puede mandar mensajes en nuestro "nombre" y otra cosa que puede pasar es que el servidor que recibe no pueda validar este registro SPF, consideré el email como no seguro, lo rebote o caiga en SPAM.

El formato de este registro, debería verse algo así:

@    86400    IN TXT   "v=spf1 ip4:10.0.0.1 a mx ~all"

Lo que estamos indicando acá es que el servidor que está en esa IP es la que manda mensajes en nuestro nombre y los servidores cuando reciban correo electrónico de ese dominio, verán este registro y si coincide con el servidor que está mandando, lo dejará pasar. Caso contrario, lo enviará a SPAM o rebotara.

DMARC

Un registro DMARC es un registro TXT, se encarga de autenticar y reportar que sucede cuando un mensaje no puede ser autenticado. Básicamente, el registro DMARC sirve para lo siguiente:

  • Evitar que nos hagan spoofing, que básicamente es que alguien envíe un correo electrónico a nuestro nombre. El spoofing se usa mucho para scams o phishing, ¿Alguna vez has visto un correo electrónico que parece que te lo enviaste tu mismo diciéndote que te hackearon la cuenta? bueno, no te la hackearon, te hicieron spoofing.
  • Reportar qué hacer con un mensaje de correo electrónico que sale desde nuestro servidor y el que recibe no puede autenticar ese mensaje.

El registro DMARC, como les decía, se encarga de autenticar, pero no es quien pasa los métodos de autenticación, para eso está el registro SPF y el DKIM.

Un registro DMARC consta de tres valores claves, uno es especificar la versión de DMARC que se usa y la otra es especificar que se hace cuando no se puede validar un mensaje y la otra es a quien notifica cuando algo de lo especificado antes sucede.

Un registro DMARC se ve así:

@    86400    IN TXT   "v=DMARC1; p=reject; rua=mailto:postmaster@example.com"

Lo que estoy diciendo acá es que es un registro TXT, para el dominio, supongamos, example.com y el valor de ese registro se compone de la siguiente manera:

  • v=DMARC1: Indica que usa la versión uno de DMARC.
  • p=reject: Indica que si un mensaje no puede ser autenticado, lo rebote. Otras opciones puede ser quarantine (que lo mande a cuarentena) o none para que lo entregue al destinatario sin más.
  • rua=mailto: es el email a donde va a ser el reporte del rebote o de la puesta en cuarentena de ese mensaje.

DKIM

Otro registro que es clave, es el DKIM, también es un registro TXT y se encarga también de validar que quien mandar ese correo electrónico, es realmente quien dice ser. Esto lo hace, firmando digitalmente los mensajes salientes, luego quien recibe, revisa y valida esa firma. Si esta todo bien, deja pasar al inbox del destinatario el/los mensaje/s.

DKIM es clave para evitar el spoofing y por ejemplo, es requerido para mandar emails a dominios @gmail.com. Sin este registro, tu mensaje, va derechito a SPAM.

DKIM se compone de dos partes, una llave privada y una llave pública. La llave privada es la que se genera únicamente para tu servidor de correo electrónico y la llave pública es la que se aloja en el registro, si las dos hacen match ante una validación, el correo electrónico será entregado.

Algo importante a tener en cuenta sobre este registro, es que necesita de un selector, este selector es el que va a tener nuestro registro DKIM y es el que va a consultar los servidores que intentan validar nuestro mensaje.

Un registro DKIM se ve más o menos así:

selector._domainkey.example.com. 600 IN TXT "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;"

Ahora veamos qué quiere decir cada uno:

  • selector._domainkey.example.com: Es nuestro selector, debe configurarse como si fuera un subdominio dentro de nuestra zona DNS.
  • v=DKIM1\: Es la versión de DKIM que estamos usando.
  • p=: Es nuestra llave pública.

Si te estás preguntando, qué hacemos con la llave privada, la misma la debemos configurar en nuestro MTA y depende de este servidor como se configurará, si por ejemplo, usaste la utilidad de Zimbra para generar el registro DKIM, la llave privada queda configurada.

PTR

El registro PTR no es propio de la configuración de un email server, en un registro que hace lo inverso a un registro A. Un registro reverso (PTR) se encarga de resolver que determinado dominio resuelve determinada IP.

Este registro, se usa como un método más de validación que algunos servidores de correo electrónico aplican sobre los mensajes que recibe, es una comprobación que valida si efectivamente mail.example.com (nuestro servidor) tiene la dirección IP que dice tener en el registro A.

El registro inverso, quien lo configura muchas veces es tu proveedor, pero si tenés acceso total a la zona de DNS, este, se ve más o menos así:

34.216.184.93.in-addr.arpa. IN PTR example.com.

Para ir cerrando

Como ves, son varias las cosas a tener en cuenta a la hora de configurar un servidor de correo electrónico, así y todo, esto no te asegura que tus mensajes no van a ser marcados como SPAM, porque por ejemplo, en una máquina infectada de la red, un bot puede usar la computadora de algún usuario para mandar miles de emails y quedas en las listas negras de las cuales muchos servidores de email se alimentan para clasificar los emails que reciben.

Si hoy me preguntan si quiero administrar un servidor de correo, les digo que no, prefiero contratar un servicio externo, ya que depende del tamaño de tu organización puede ser un trabajo más que interesante.

Como siempre, cualquier duda o consulta, pueden dejarla en los comentarios.


baehost

SUBIR

🎉 Te has suscrito con éxito a CDUser - El Blog de Ignacio Van Droogenbroeck!
OK