Cuando hace clic en un botón para enviar un correo electrónico, su cliente de correo electrónico se conecta al servidor de correo. Los servidores son ordenadores que manejan servicios específicos. Un servidor de correo electrónico está destinado a tratar con correos electrónicos. 

Al mismo tiempo, podemos dividir los servidores de correo electrónico en dos categorías: salientes y entrantes. Hoy, estamos hablando de un concepto relacionado con un servidor de correo saliente, conocido como servidor SMTP.

¿Qué es un servidor SMTP? 

Un servidor SMTP es un ordenador o una aplicación que se encarga de enviar correos electrónicos. Funciona siguiendo el Protocolo Simple de Transferencia de Correo (SMTP). Un servidor SMTP recibe correos electrónicos del cliente de correo electrónico. Luego los pasa a otro servidor de correo electrónico SMTP y los retransmite al servidor de correo entrante.

¿Cómo funciona un servidor SMTP? 

Mira los pasos básicos de la ruta de envío de correo electrónico y qué papel desempeña el servidor SMTP.

• Un agente de usuario de correo (MUA), que puede ser su cliente de correo electrónico o una aplicación, se conecta al servidor SMTP de su dominio (por ejemplo, live.mailtrap.io) para iniciar la conexión SMTP. Esto se llama un apretón de manos SMTP. La conexión se realiza a través de un puerto SMTP, que normalmente es de 25. Sin embargo, también podrían usarse otros puertos, tales como 465, 587, 2525 en diferentes casos. Puede obtener más información sobre ellos en nuestra publicación de blog sobre puertos SMTP. Una vez conectado, comienza la sesión SMTP.
• El cliente envía las direcciones de correo electrónico del remitente y del destinatario, así como el cuerpo del correo electrónico y los archivos adjuntos, al servidor. 
• El servidor SMTP, o más precisamente el agente de transferencia de correo (MTA), comprueba si el nombre de dominio del destinatario y el remitente es el mismo. Si es así, el correo electrónico va directamente al servidor POP3 o IMAP del destinatario. Si los dominios son diferentes, el servidor SMTP tiene que comunicarse con el servidor de nombres de dominio (DNS).
• El DNS proporciona la dirección IP del destinatario. 
• El servidor SMTP del remitente se conecta al servidor SMTP del destinatario y retransmite el correo electrónico. Si el servidor del destinatario no está disponible (abajo u ocupado), el correo electrónico se pondrá en una cola SMTP. Este es un búfer donde se almacenan los correos electrónicos antes de que lleguen al punto final. Para obtener más información sobre esto, lea nuestro blog sobre la cola de correo electrónico. Alternativamente, el correo electrónico se puede enviar a un servidor de copia de seguridad.
• El servidor SMTP del destinatario verifica el correo electrónico entrante. Si el dominio y el nombre de usuario han sido reconocidos, el servidor reenvía el correo electrónico a los servidores de recepción, POP3 o servidor IMAP.

¿El servidor SMTP es seguro? 

Sorprendentemente, el servidor SMTP no es inherentemente seguro. No tiene ningún mecanismo de encriptación o seguridad incorporado. Esto lo hace vulnerable a la suplantación de identidad, el spam o la fuga de datos. Para evitar todos esos eventos desafortunados, los proveedores de correo electrónico han agregado capas de seguridad a la infraestructura. 

El primer mecanismo que incorporaron fue el Secure Sockets Layer (SSL), pero tenía importantes fallas de seguridad. Como resultado, Internet Engineering Task Force (IETF) desaprobó su versión final, SSL 3.0 en 2015 al hacer cumplir RFC 7568.

4 años después de la creación de SSL, otro estándar de seguridad, Transport Security Layer (TLS) fue introducido al público. Inicialmente, tampoco era perfecto, pero se mejoró a lo largo de los años. A partir de 2022, la versión TLS 1.3 se considera el protocolo más seguro para el cifrado de correo electrónico.Todo eso es genial, pero ¿en qué punto de la conexión SMTP entra TLS en el juego? De forma predeterminada, la mayoría de los clientes de correo electrónico inician una conexión TLS durante el apretón de manos. Lo hacen utilizando el comando SMTP STARTTLS, que inicia el cambio a una conexión cifrada. Para obtener más información, consulte nuestra publicación de blog sobre seguridad SMTP.

¿Qué es la autenticación SMTP? 

La autenticación SMTP o SMTP AUTH es el mecanismo utilizado para proteger el servidor de correo electrónico saliente. Es el servicio proporcionado por el Protocolo de Transferencia de Correo Simple Extendido (ESMTP) que agrega nuevas funcionalidades al protocolo SMTP, incluida la autenticación. 

SMTP AUTH “exige” que el remitente esté autorizado a utilizar el servidor para enviar correos electrónicos. Hace que sea más difícil hacerse pasar por usuarios reales, protegiéndolos de suplantadores y spammers. SMTP AUTH aprovecha el mecanismo SASL para la autenticación, que especifica el nivel de seguridad y los métodos de inicio de sesión. Mecanismos tales como PLAIN, LOGIN, y CRAM-MD5 se utilizan comúnmente en ese proceso. Para profundizar en la autenticación SMTP, consulte nuestra guía dedicada.

¿Debería usar servidores SMTP locales o basados en la nube? 

Tu propio servidor SMTP 

Configurar tu propio servidor SMTP puede ser una opción si deseas enviar correos electrónicos masivos. No impone ningún límite en la cantidad de correos electrónicos que envía por hora/día y garantiza el control de todo su correo saliente. 

Sin embargo, esto viene con un inconveniente ya que la tasa de rebote puede aumentar en un 20-30%, lo cual es una consideración importante para la capacidad de entrega de las campañas de marketing transaccional o por correo electrónico. Si deseas conocer todos los entresijos de la configuración de su propio servidor SMTP, lee este blog post.

API de envío de correo electrónico de terceros 

En nuestra guía sobre los mejores servidores SMTP gratuitos, presentamos una lista de API de correo electrónico de terceros basadas en la nube que la mayoría de las nuevas empresas y proyectos eligen. Estos son servicios de retransmisión SMTP que incluyen Gmail, Amazon ses, Elastic Email, Mailtrap y otros. 

El principal beneficio de usar proveedores de servicios SMTP en lugar del SMTP local es que no tienes que construir y mantener toda la infraestructura de correo electrónico por tu cuenta. Esto significa que puedes ahorra en recursos. 

Sin embargo, es importante elegir un proveedor de correo electrónico confiable como Mailtrap Email Sending. Es una solución integral que puede enviar mensajes de correo electrónico de forma segura a las bandejas de entrada de los destinatarios. 

Incluye un montón de características útiles, tales como análisis procesables, SDK para una amplia gama de lenguajes de programación, entrega de correo electrónico a tiempo, configuración suave y segura, y mucho más. Los análisis mencionados se pueden utilizar para rastrear y controlar la entregabilidad de todos sus correos electrónicos salientes.

Lo más importante es que Mailtrap Email Sending facilita enormemente el uso de su servicio SMTP o API de correo electrónico. Una vez que verifique su dominio con los protocolos de autenticación SPF, DKIM y DMARC, verá inmediatamente las credenciales SMTP y de la API de correo electrónico para el flujo de envío de correo transaccional y masivo.

Al configurarlos en la configuración del servidor, podrás comenzar a usar la API de correo electrónico para enviar mensajes desde tu dominio. El servidor SMTP de Mailtrap Email Sending aprovecha los mecanismos de autenticación PLAIN y de LOGIN y requiere cifrado STARTTLS.

Ahora que sabes qué es un servidor SMTP y cómo funciona, profundicemos y respondamos a las otras preguntas que puedas tener.

Servidor de SMTP relay o API HTTP: ¿cuál es mejor y cuándo? 

Un agente de usuario de correo (el cliente) envía correos electrónicos al servidor a través de SMTP. Es un protocolo independiente de la plataforma ampliamente utilizado para enviar correos electrónicos. Al mismo tiempo, puedes enviar correos electrónicos desde tu aplicación utilizando un protocolo específico de la web: HTTP. En este caso, no hay cliente-servidor o servidor-servidor de ida y vuelta. Tu aplicación envía solicitudes HTTP a un servicio de terceros que realiza el envío de correo electrónico. Esta forma de envío de correo se conoce como HTTP API o Web API.

No podemos afirmar que las Web API excedan el servicio de los servidores de retransmisión SMTP. Cada opción tiene sus pros y sus contras.

Opta por un servidor SMTP si:

• prefieres la simplicidad para las tareas básicas 
• necesitas integrabilidad con su sistema CRM o cliente de correo
• estás buscando una solución fiable y sostenible

Opta por Web API si:

• tratas con correos electrónicos masivos
• necesita una mayor funcionalidad
• no te importa trabajar codificando

Para obtener más información sobre las diferencias entre el servidor de retransmisión SMTP y la API HTTP, lee nuestra publicación en el blog.

¿Qué es una dirección de servidor SMTP? 

Un servidor SMTP tiene una dirección web para comunicarse con otros servidores y clientes en Internet. Por lo general, e constituye por smtp. o mail. más el nombre de dominio. Aquí algunos ejemplos

Si configuraste tu propio servidor SMTP, puedes usar tu dirección IP, por ejemplo, 192.0.2.0, en lugar de la dirección web. 

Los usuarios de servicios de correo electrónico compartidos pueden encontrar información sobre el nombre y la dirección del servidor SMTP buscando los registros MX del dominio.

¿Un servidor SMTP y un SMTP relay son lo mismo? 

SMTP relay es el proceso de transferencia de correos electrónicos entre servidores SMTP (o MTA si se quiere). Un relay ocurre si el remitente y el destinatario provienen de diferentes dominios. En la práctica, sin embargo, el término SMTP relay a menudo se refiere a los servidores SMTP que permiten la retransmisión. Los proveedores de correo electrónico como Mailtrap Email Sending ofrecen tales servidores de retransmisión para correo electrónico masivo y envío de correo electrónico transaccional. En este contexto, podemos decir que un servidor SMTP y un SMTP relay son lo mismo.

¿Qué es un servidor SMTP falso? 

• Un servidor SMTP real acepta correos electrónicos del cliente y los envía al servidor de correo entrante. 
• Un servidor SMTP falso acepta correos electrónicos del cliente y emula el envío sin entrega real. 

¿Por qué necesitaría uno falso entonces? – Para probar el envío de correo electrónico, por supuesto!

En una determinada etapa de su proyecto, deberás enviar un par de correos electrónicos de prueba desde tu aplicación o sitio web. Puedes hacer esto usando un servidor SMTP real. En este caso, tendrías que jugar con cuentas de correo electrónico ficticias, o sea crear cientos de direcciones de correo electrónico que desaparecerán en unas pocas horas. 

Siendo completamente honestos, los correos electrónicos ficticios no son la mejor solución para las pruebas. Requieren demasiados recursos, tienen capacidades limitadas de pruebas de diseño y contienen el riesgo de enviar spam a usuarios reales. ¡Ahí es donde entra en juego un servidor SMTP falso!Además de Mailtrap Email Sending, Mailtrap Email Delivery Platform consiste en Email Testing, una solución de pruebas basada en la nube que captura el tráfico SMTP saliente.

Con Mailtrap Email Testing, los correos electrónicos de prueba que envíes desde tu aplicación quedarán atrapados utilizando un servidor SMTP falso y se colocarán en una bandeja de entrada virtual. Puedes estar seguro de que ninguno de los correos electrónicos llegará a tus usuarios. A diferencia de los correos electrónicos ficticios, el Email Testing permite la automatización de QA y elimina la mayor parte del trabajo manual. 

Además, puede previsualizar los correos electrónicos, comprobar si contienen spam y si el dominio/IP del remitente está en la lista negra, inspeccionar el HTML/CSS y mucho más.

También puedes considerar configurar un servidor SMTP falso local como MailHog o MailCatcher o incluso una aplicación de escritorio, por ejemplo, FakeSMTP o DevNull SMTP. Describimos las razones para elegir entre opciones SMTP falsas en la nube o locales en la publicación del blog dedicada a esto.

¿Cuál es la diferencia entre un servidor SMTP y un servidor IMAP/POP3? 

SMTP es un protocolo de envío de correo electrónico, mientras que IMAP4 y POP3 son protocolos para recibir correos electrónicos. Por lo tanto, un servidor de correo entrante puede usar uno de esos protocolos para la entrega de correo electrónico. Así es como funcionan:

La principal diferencia entre estos protocolos es que los servidores IMAP siempre almacenan copias de correos electrónicos, mientras que los servidores POP3 los eliminan una vez que se recuperan. Para obtener más información sobre las diferencias entre los servidores entrantes y salientes, consulte nuestra publicación de blog IMAP vs POP3 vs SMTP.

¿En qué se diferencia un MTA de un servidor SMTP? 

Es una práctica común utilizar el término “agente de transferencia de correo” en lugar de “servidor SMTP”. Pero, ¿no son estas nociones diferentes? Un MTA es un software instalado en el servidor SMTP. En general, una MTA recibe correos electrónicos de un MUA y los reenvía a:

• un agente de entrega de correo (MDA), si el remitente y el destinatario tienen el mismo dominio, o
• otro MTA (servidor SMTP) 

En algunos casos, también podría haber un agente de envío de correo (MSA) entre el MUA y la MTA. Sin embargo, muchos MTA llevan a cabo la función MSA, por lo que a menudo se omite la mención de agentes de envío de correo. Los MTA más utilizados son Postfix, Sendmail y Exim.

Por lo tanto, si llamas al servidor SMTP de MTA o incluso de MSA, esto no será un error. La diferencia radica en la nomenclatura que utilices.

Lista de verificación de solución de problemas del servidor SMTP 

Digamos que probaste el envío de correo electrónico de tu aplicación y funciona bien. Esperamos que la plataforma de entrega de correo electrónico Mailtrap te haya ayudado con eso :). Pero cuando comenzaste a usar un servidor SMTP real para enviar correos electrónicos, no se entregaron. La siguiente lista de verificación te ayudará a detectar lo que puede estar mal:

• Comprueba la conexión a Internet
• comprobar la configuración del servidor SMTP (nombre del servidor, puerto, nombre de usuario, contraseña)
• probar diferentes puertos SMTP

probar la conexión del servidor SMTP. Para ello, puedes utilizar un servicio en línea como MXToolbox o realizar una sesión de telnet manual. Lee nuestra publicación de blog sobre cómo probar el servidor SMTP para aprender cómo hacer esto. Es posible que también necesites conocer los comandos SMTP y los códigos de respuesta para la solución de problemas.

Conclusión

Eso es todo lo que queríamos cubrir en esta guía sobre servidores SMTP. Hemos cubierto todas las preguntas frecuentes, incluyendo qué es un servidor SMTP, cómo funciona, cómo se compara con otros servidores SMTP y cómo solucionar los errores. También discutimos los SMTP relays de terceros y servidores SMTP falsos para pruebas. 

Para aprovechar los servidores SMTP falsos y luego enviar correos electrónicos a través de un SMTP basado en la nube, recomendamos usar la plataforma de entrega de correo electrónico Mailtrap. Es una solución única para todas sus necesidades de SMTP. 

Para una mirada en profundidad a los diferentes aspectos del servidor SMTP, mira las publicaciones que hemos recomendado anteriormente en el blog. Si hay algún otro tema que te gustaría que cubriéramos, háznoslo saber en Twitter.

Cuál es el propósito de DMARC, cómo se ve y funciona, así como muchas más preguntas relacionadas con el famoso protocolo de autenticación se responden en el texto a continuación. ¡Asegúrate de seguir leyendo!

¿Qué es DMARC?

Comenzaremos este artículo con la pregunta presente en la mente de la mayoría de los lectores: “¿Qué significa DMARC?”. Y la respuesta es: Autenticación de mensajes basada en dominio, informes y conformidad.

DMARC no solo tiene el nombre más complicado de los tres principales protocolos de autenticación de correo electrónico, sino que también es el más efectivo. Y es bastante fácil entender por qué. 

DMARC aprovecha las comprobaciones DKIM (DomainKeys Identified Mail) y/o SPF (Sender Policy Framework) para realizar una validación más avanzada en cada mensaje de correo electrónico recibido.

La autenticación DKIM utiliza firmas DKIM para verificar la integridad del contenido de un correo electrónico y su origen. SPF, por otro lado, permite a un propietario de dominio autorizar direcciones IP para enviar correo electrónico bajo el nombre de dominio y es utilizado por proveedores de servicios de Internet como Gmail, Yahoo, etc.

Con la autenticación DMARC, un propietario de dominio puede especificar su propio procedimiento de autenticación, también conocido como política DMARC. Usando la directiva, instruyen a un servidor entrante sobre qué hacer si un correo electrónico no pasa la prueba DMARC. 

Finalmente, la política también puede proporcionar informes con los detalles de cada verificación para mejorar los procesos y proporcionar una advertencia inmediata si alguien falsifica el dominio.

¿Cómo funciona DMARC?

La clave para comprender DMARC y cómo funciona DMARC es saber que requiere un registro SPF o un registro DKIM, o, mejor aún, ambos, para establecerse. 

Cuando se recibe un correo electrónico, un servidor receptor realiza una búsqueda DNS (Sistema de nombres de dominio) y comprueba si hay un registro DMARC existente. 

DKIM/SPF se realiza como de costumbre. 

A continuación, el servidor receptor realiza una denominada “prueba de alineación DMARC” para verificar si:

• En el caso de SPF, la dirección de correo electrónico “envelope from” dentro del encabezado técnico oculto del correo electrónico coincide con la dirección “return-path”. En otras palabras, comprueba si la dirección de correo electrónico desde la que se envió el mensaje es la misma que la dirección a la que iría una posible respuesta.
• En el caso de DKIM, el valor detrás de la etiqueta “d” (dominio del remitente del correo electrónico) coincide con el dominio desde el que se envió el correo electrónico.

Por supuesto, si se establecen ambas autenticaciones, se realizan ambas pruebas de alineación.

Los requisitos de alineación pueden ser “strict” (los dominios deben coincidir con precisión) o “relaxed” (los dominios base deben coincidir, pero se permiten diferentes subdominios). 

DMARC tendrá éxito en los siguientes escenarios:

• Si solo se configura una de las autenticaciones, su comprobación debe tener éxito, junto con una prueba de alineación respectiva.
• Si se configuran ambas autenticaciones, una de ellas debe tener éxito con la prueba de alineación respectiva, pero ambas no son necesarias.

Observe cómo DMARC seguirá teniendo éxito incluso si, por ejemplo, DKIM junto con la alineación de DKIM falla, pero SPF y su alineación tienen éxito (o al revés).

Ahora, supongamos que un correo electrónico falló una verificación DMARC por cualquier razón. 

DMARC le permite instruir al servidor entrante sobre lo que debería suceder con los correos electrónicos que fallan en la autenticación. 

Hay tres opciones disponibles (se denominan “políticas”):

• “none”: el correo electrónico debe tratarse de la misma manera que si no se configurara DMARC (el mensaje aún se puede entregar, colocar en spam o descartar en función de los otros factores). Esto se utiliza típicamente para observar el entorno y analizar los informes sin influir en la capacidad de entrega.
• “cuarentena”: permite el correo electrónico pero no lo envíes a una bandeja de entrada. Por lo general, estos mensajes van a la carpeta de spam.
• “rechazar”: descarte el correo electrónico que falló la verificación de inmediato.

Estas políticas también se pueden personalizar. Por ejemplo, con una política de “cuarentena”, podría decirle al servidor de correo electrónico que envíe solo el 10% de los correos electrónicos con un cheque fallido a la carpeta de spam e ignorar (“none”) el otro 90%.

Tenga en cuenta que solo porque instruya al servidor sobre qué hacer, no significa que seguirá completamente sus consejos. Aún así, le da mucho más control que en el caso de las autenticaciones DKIM y SPF.

Finalmente, un servidor receptor enviará informes para cada verificación DMARC fallida con datos agregados sobre comprobaciones fallidas. Esto es invaluable para analizar el rendimiento de su mensaje y mantenerlo al tanto si ocurre alguna estafa de phishing.

¿Por qué usar DMARC?

Lo dijimos varias veces, pero vale la pena repetirlo de nuevo: DMARC es la forma más efectiva de protegerse de la suplantación. Punto. 

HMRC  estima que el número de correos electrónicos de phishing enviados desde su dominio disminuyó en 500 millones en solo 1,5 años después de la implementación de DMARC. 

Sin enumerar ningún otro beneficio de DMARC, esto solo debería ser una razón suficiente para agregar la implementación de DMARC a su próximo sprint. 

Pero, si necesita más, hay dos beneficios principales de DMARC a considerar:

• Es mucho más probable que los ciberdelincuentes dejen de intentar falsificar un dominio si ven registros DMARC (configurados correctamente) en el DNS del dominio. La implementación de DMARC aún no está muy extendida, por lo que no será difícil encontrar algo que valga la pena.
• Los servidores receptores también saben que es mucho más probable que los correos electrónicos provenientes de dominios protegidos por DMARC sean legítimos que aquellos protegidos con solo uno de los otros métodos de autenticación (sin mencionar aquellos sin ninguna seguridad).

¿En qué consiste un registro DMARC?

¿Entendiste lo básico? ¡Excelente! Ahora, vamos a explicar un registro de DMARC. 

En lugar de confiar en datos ficticios, usaremos el registro de Square, un proveedor unicornio de servicios financieros para pequeñas empresas. Muchos ciberdelincuentes probablemente sueñan con falsificar su correo electrónico, por lo que no es de extrañar que eligieran protegerse con DMARC.Puede acceder al registro de Square en este enlace que conduce a un sitio que le mostrará registros DMARC para cualquier dominio, dado, por supuesto, que se lo haya configurado.

v=DMARC1; p=reject; rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com; ruf=mailto:dmarc-ruf@squareup.com

Repasemos cada parámetro DMARC del registro anterior, uno por uno.

v=DMARC1

Este es el identificador (una versión DMARC) que siempre debe incluirse en el registro DNS, ya que el servidor de correo receptor siempre lo busca. Si v=DMARC1 falta o se modifica de alguna manera, se omitirá toda la verificación.

p=reject

Esta es la política que Square eligió usar, que rechaza todos los correos electrónicos que fallan la verificación DMARC. Por supuesto, aún pueden ser entregados, pero se enviará una señal fuerte al servidor receptor para no permitir tales mensajes.

rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com

Estas tres direcciones recibirán informes agregados diarios sobre correos electrónicos que fallaron la verificación. Los informes contendrán datos de alto nivel sobre las razones de los fallos sin dar ningún detalle para cada uno. Todas las direcciones añadidas aquí deben ir precedidas de “mailto:” como en el ejemplo anterior.

ruf=mailto:dmarc-ruf@squareup.com

Esta es una dirección de correo electrónico a la que se enviarán informes forenses individuales (también conocidos como informes de fallas) en tiempo real, incluidos los detalles de cada falla.

Otros registros de ejemplo de DMARC

En el ejemplo del registro Square DMARC, mostramos un registro con una política de “rechazo”. Para cubrir las dos variaciones de póliza restantes, ahora usaremos algunos datos ficticios simplemente con fines de demostración.

Registro DMARC con una política de “none”:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Explicación:

• “p=none” especifica una política de “none”, lo que significa que no se debe tomar ninguna acción en los correos electrónicos que fallan la autenticación DMARC.

Registro DMARC con una política de “cuarentena”:

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Explicación:

• “p=quarantine” especifica una política de “cuarentena”, lo que significa que los correos electrónicos que fallan la autenticación DMARC deben ser puestos en cuarentena o marcados como sospechosos por el sistema de correo electrónico del destinatario, pero aún así enviados a la bandeja de entrada del destinatario.

Algunas etiquetas DMARC opcionales para personalización

Como suele ser el caso, también hay varios campos opcionales que se pueden añadir a un registro DMARC para personalizarlo un poco.

Cómo implementar registros DMARC

Todo el proceso de implementación de DMARC se reduce a los siguientes pasos:

• Validación si SPF/DKIM está configurado y los dominios están alineados.
• Generar un registro DMARC y especificar la configuración de DMARC.
• Añadirlo al DNS de su dominio.

Verificar si DKIM y/o SPF están configurados correctamente

Como se mencionó anteriormente, tener DKIM o SPF es obligatorio para que DMARC trabaje. Pero que cualquiera de los dos devuelva resultados negativos para correos electrónicos legítimos tampoco servirá de nada. La prueba DMARC fallará automáticamente si falla el SPF o DKIM.

Si solo tiene SPF configurado, verifique si los siguientes dos coinciden:

• Dirección “Envelope from”: la dirección desde la que se envían los correos electrónicos.
• Dirección “Return-path”: los correos electrónicos de la dirección se dirigirán a si un destinatario responde a un correo electrónico.

Si solo usa DKIM, compruebe si las siguientes dos coinciden:

• Dirección “Envelope from”: la dirección desde la que se envían los correos electrónicos.
• “d” etiqueta de su registro DKIM.

Si utiliza ambos métodos (¡y con razón!), realice ambas comprobaciones, por supuesto. 

Elija una cuenta de correo electrónico para recibir registros DKIM

Una gran cosa sobre DMARC es que, cuando se configura, su servidor comienza a enviarle informes diarios de cómo se desempeñaron sus correos electrónicos (informes forenses y agregados separados). De esta manera, puede detectar rápidamente cualquier anomalía y mejorar su rendimiento utilizando datos. 

Tenga en cuenta que los informes se envían en un formato crudo y difícil de leer, por lo que es posible que desee utilizar herramientas  como Dmarcian o MXToolbox para aprovechar al máximo los datos. 

Generar el registro DMARC

Y ahora, finalmente generemos un registro DMARC.

Dmarc.org recomienda una serie de recursos para esta tarea. Además, hay varias etiquetas mencionadas anteriormente que debe usar en el registro y varias opcionales. 

Tenga en cuenta que la etiqueta “p” (como en “política”) representará directamente el paso anterior.

Añade el registro DMARC al DNS de tu dominio

Una vez que tenga su registro, puede seguir adelante y añadirlo como un registro DNS. Usted puede ser capaz de hacer esto por su cuenta, o, en algunos casos, la ayuda de su proveedor de alojamiento puede ser necesaria. 

En el registrador de dominios, debe añadir el DMARC recién creado como un registro TXT. No revisaremos ningún detalle aquí, ya que el proceso difiere para cada proveedor de alojamiento.

Si hizo todo correctamente, debería recibir sus primeros informes dentro de las próximas 24 horas.

Tres grandes mitos de DMARC reventados

DMARC se establece solo por razones de seguridad

Parcialmente cierto. DMARC tiene como objetivo prevenir la suplantación de identidad de correo electrónico y los ataques de phishing. Sin embargo, hay más en DMARC que eso. 

Las políticas de cumplimiento de DMARC y las capacidades avanzadas de informes mejoran significativamente la entrega legítima de correo. Ayudan a construir y mejorar la confianza y el análisis de la marca. Por lo tanto, DMARC puede proporcionar un gran impulso a cualquier campaña de marketing.

DMARC es solo para dominios que envían correo

No es cierto. El hecho de que su dominio no envíe correos electrónicos no significa que no se pueda suplantar. De hecho, cuanto más famosa sea su marca, empresa, organización o personalidad, mayores serán las posibilidades de que algún spammer quiera falsificar su dominio y usarlo para actividades maliciosas como el envío de correos electrónicos fraudulentos, ya sea de marketing o transaccionales. 

Los destinatarios de correos electrónicos maliciosos enviados desde “su” marca probablemente no podrán identificar que su dominio no está configurado para enviar correo. Como resultado, tendrá que enfrentar muchas consecuencias desagradables relacionadas con su reputación y credibilidad.

Establecer la política de DMARC en “none” es suficiente para la seguridad del correo electrónico

Falso. Establecer la política de DMARC en “none” suele ser el primer paso para asegurarse de que los informes y la entrega de DMARC se establezcan correctamente, pero no mejora su seguridad ni ayuda a proteger su dominio de ser suplantado. 

Eventualmente, para aprovechar al máximo la mejora de la seguridad y el marketing de DMARC, deberá usar la política de (al menos) p=quarantine o (la mejor de todas) p=reject en un pct=100.
Además, si decide actualizarse y adoptar BIMI como la última  estrategia de autenticación de marca, su registro DMARC debe establecerse en la política de “reject” para calificar para la certificación BIMI.

Consideraciones Finales

La seguridad del correo electrónico nunca debe subestimarse. Cuanto más grande eres, más tienes a perder si alguien falsifica tu dominio y engaña a tus clientes en algo que probablemente no aprobarías. 

Dado lo fácil que es agregar cada método de autenticación y cuánto ganas al tenerlos todos configurados correctamente, hay pocas razones para no intentarlo.

Lo que es absolutamente genial de DMARC es que puede comenzar con una política de “none” y observar lo que sucede. Esto básicamente significa que sus correos electrónicos pasarán por las comprobaciones pertinentes en el lado receptor, pero si fallan, no influirá en su capacidad de entrega de correo electrónico. 

Además de eso, recibirá toneladas de datos a través de los informes DMARC que cubren problemas de autenticación. Usando esto, puede identificar rápidamente si alguien está tratando de falsificar su dominio y potencialmente pedir a los destinatarios que proporcionen información confidencial o si hay un problema de su lado para que pueda hacer la resolución de problemas adecuada.

¿Qué es DKIM? 

DomainKeys Identified Mail (DKIM) es una firma digital añadida a cada correo electrónico enviado desde una dirección de correo electrónico determinada. No es una firma como otras que ves en la parte inferior de un correo electrónico corporativo. De hecho, normalmente, ni siquiera ves el DKIM. Es un conjunto aparentemente aleatorio de caracteres ocultos en el código fuente de un correo electrónico, un lugar donde la gente no suele mirar, pero los servidores que aceptan correos electrónicos entrantes si lo hacen. 

Después de todo, DKIM es un estándar de la industria para la autenticación de un correo electrónico. Por supuesto, añadir una firma DKIM no garantiza la entrega, pero aumenta significativamente las probabilidades de un resultado positivo.

¿Por qué usar DKIM?

Imagine el siguiente escenario. Estás enviando un mensaje de seguimiento rápido a un posible inversor después de una reunión: “Yvonne, avísame si te gustaría continuar con lo que discutimos anteriormente”. Pasa algún tiempo, y nunca recibiste la respuesta de Yvonne, pero te encuentras con ella en otra reunión y mencionas discretamente ese correo electrónico.

Desconcertada, Yvonne dice: “Mark, nunca he sabido de ti”.Hay muchas razones potenciales para la falla en la entrega, pero, lo que se verificó es que Mark olvidó configurar la autenticación DKIM para su cuenta de correo electrónico. Como resultado, el servidor de Yvonne no estaba muy seguro de si realmente era Mark enviándole un correo electrónico y descartó el mensaje.

El principal objetivo de DKIM es prevenir la suplantación de identidad. La suplantación de correo electrónico ocurre cuando se cambia el contenido del mensaje original y se lo envia desde un remitente alternativo que parece una fuente confiable. Este tipo de ataque cibernético se usa ampliamente para el fraude, por ejemplo, alguien que envía mensajes de solicitud de pago desde una dirección de correo electrónico que se parece a la tuya (mark@whithercompany.io  vs. mark@whither-company.io).

¿Cómo se ve un encabezado DKIM?

Aquí tienes un ejemplo de un registro de correo identificado con DomainKeys:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;
     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

El DKIM se compone de diferentes elementos, descritos con varias etiquetas y valores correspondientes a cada uno. Vamos a desglosar el significado de cada elemento utilizado anteriormente:

Como puede ver, la firma es solo una pequeña parte de DKIM. Todo lo que está por encima son metadatos, que describen cómo se calcularon los valores hash.

Observe cómo dos de las etiquetas se marcaron como opcionales: no son necesarias para que DKIM se verifique correctamente, pero agregan una capa adicional de seguridad. Hay varias otras etiquetas opcionales que puedes usar: “i” – Identidad de un usuario o un agente (recomendado); “l” – longitud del cuerpo del mensaje y “z”- lista de encabezados originales del mensaje (ambos no recomendados).

¿Cómo funciona DKIM?

La firma y recepción de DKIM se realiza en tres pasos:

1. El remitente decide qué incluir en un registro DKIM

Como remitente, puedes limitarte a solo ciertas partes de los campos de encabezado (“From”, “To”, “Cc”, “Subject”, etc.), y también puedes llegar a incluir todo el encabezado y el cuerpo en DKIM. También puedes optar por añadir algunos o todos los campos opcionales mencionados anteriormente.

Técnicamente, cuanto más detalles específicos se incluyan, más confiable será la autenticación. Pero también debes tener cuidado con esto, ya que incluso los detalles más pequeños cambiados por tu servidor de correo electrónico SMTP conducirán a una autenticación DKIM fallida del lado receptor. Piense, por ejemplo, en los mensajes “reenviados por…” que se agregan a los correos electrónicos al reenviarlos desde clientes de correo electrónico. Si incluyes todo el cuerpo en DKIM, este inevitablemente fallará ya que el cuerpo acaba de ser modificado.

Pero no te preocupes. No es necesario que decidas la forma del DKIM cada vez que envíes un correo electrónico. Un servidor se encarga automáticamente de que debas configurarlo solo una vez. 

2. Se crea el DKIM y se envía un mensaje que lo incluye

Una vez que el servidor sabe qué incluir en el DKIM y se inicia el envío de correo electrónico, comienza a hashear el contenido. Ya sabemos cómo se veían las etiquetas “b” y “bh” en nuestro ejemplo. Para darte un ejemplo más, así es como se vería el paso anterior si se aplicara hash con el método SHA256:

568291DDA7ECE2594254BC8E7D70DA150968D022021081BB6E3FC40DC9C260D6
CE328291830AB02CFB1D8CDEC3C2B35C73F92ADF335BCCF38C6784AC9922A8C1

Aunque puede parecer complejo, tales hashes son extremadamente fáciles de descifrar con varias herramientas en línea (¡pruébalo vos mismo!). Es por eso que, antes de que se envíe un correo electrónico, cada hash se cifra con una llamada clave privada. Puedes tener una clave privada separada para cada selector que utilices, incluso si envías todos los correos electrónicos desde el mismo dominio. Esto puede significar una clave para los correos electrónicos de marketing, otra para los correos electrónicos transaccionales y una tercera para los correos electrónicos enviados a los proveedores. El uso de diferentes claves privadas es importante por razones de seguridad.

Una vez que todo está configurado, ¡se envía el correo electrónico!

3. Se recibe un mensaje y el servidor valida las firmas DKIM

En cuestión de segundos, el servidor de correo receptor recibe un mensaje y debe tomar una decisión importante: permitir o no la entrada del correo electrónico. Cuando ve que se incluye un DKIM con el mensaje, inmediatamente inicia el proceso de validación.

Con los campos de dominio (“d”) y selector (“s”) visibles en DKIM, el servidor puede obtener la clave pública que corresponde a esta combinación ejecutando una consulta de DNS apropiada (dichos datos están disponibles públicamente). Luego, con la clave pública recién adquirida y los campos cifrados “b” y “h”, el servidor receptor crea sus propios hashes y los compara con los recibidos en el mensaje. Si hay una coincidencia, la autenticación es correcta. Si no es así, la autorización de DKIM falla. Eso no significa que el mensaje será descartado, pero reduce sus posibilidades de ser entregado.

¿Cómo añades la firma DKIM a tus correos electrónicos?

La adición de DKIM requiere cambiar algunos detalles de tus registros DNS. Muchos clientes de correo electrónico explican el proceso en detalle, por lo que no nos centraremos en él aquí. Consulte los siguientes enlaces para conocer los detalles específicos de los proveedores más populares:

• Mailtrap Email API
• MailChimp
• SendGrid
• Sendinblue
• Mailjet
• AWeber
• Gmail
• Outlook & Office365

Si tu cliente de correo electrónico no ofrece ninguna ayuda para implementar DKIM, o si estás configurando tu propia infraestructura, consulte la documentación oficial de DKIM. Con Mailtrap Email API, obtienes registros DKIM con una rotación automatizada trimestral que ayuda a mantener tu infraestructura de correo electrónico segura.

¿Cómo puedes testar si DKIM se configuró correctamente?

Una vez que se añade DKIM, asegúrese de validarlo con un analizador DKIM en línea. Utilice, por ejemplo, MXToolbox o Mail-tester.com — este último se puede utilizar para comprobar los registros SPF simultáneamente.

También puedes enviar un correo electrónico de prueba a tu cuenta de Gmail o Yahoo y verificar si el mensaje llegó con tu firma DKIM.

Una vez que llegue el mensaje, expanda el encabezado del correo electrónico con el icono del triángulo debajo del nombre del remitente. Si el dominio del remitente aparece tanto para “mailed-by” como para “signed-by”, el mensaje se verificó con éxito con DKIM.

También puedes hacer clic en los tres puntos en la esquina superior derecha y “Mostrar original”. Aquí vas a ver el resultado de la autenticación DKIM. Si dice ‘PASS‘ y tu dirección de dominio, todo funciona bien. 

Para verificar el registro DKIM en Yahoo, haz clic en “Ver encabezado completo” y busque el rastro de DKIM. Si encuentras dkim=pass (ok), ¡has pasado la prueba!

¿Qué es Gappssmtp? 

gappssmtp es una clave de dominio predeterminada para los correos electrónicos enviados a través del servidor SMTP de gmail. El registro de autenticación DKIM a veces mostrará gappssmtp. Por ejemplo, si recibiste un correo electrónico dename@railsware.com, el registro DKIM mostrará railsware-com.20150623.gappssmtp.com.

Para verificar el registro de autenticación DKIM, por sospecha de phishing o de otro tipo, localice el menú desplegable “mostrar detalles” bajo el nombre del remitente. La sección “firmado por” es lo que está buscando para determinar si el correo electrónico fue enviado desde un servidor seguro. Si dice “gmail”, entonces el registro DKIM incluirá gappssmtp, por lo tanto, el correo electrónico se envió desde un servidor seguro con una clave de autenticación predeterminada.

Los correos electrónicos enviados a través de un servicio, como un calendario, unidad, caja o algo así, no tienen un DKIM. Solo podrás localizar una firma proporcionada por el servicio. Esas firmas, incluido gappssmtp, se asignan automáticamente y simplemente verifican la seguridad del correo electrónico que se recibió. Es un procedimiento estándar y automatizado realizado con fines de verificación.

Tres grandes conceptos erróneos sobre DKIM 

DKIM cifra tu correo

La principal preocupación de DKIM es verificar y confirmar que el mensaje está intacto. Los hashes bajo las etiquetas “bh” y “b” ofrecen protección contra la modificación y reproducción de mensajes, incluida la protección parcial contra el robo de identidad y la falsificación. Una prueba de verificación DKIM aprobada básicamente significa que el correo electrónico enviado tiene permiso para ser enviado desde este dominio y que el contenido del mensaje no fue alterado mientras estaba en tránsito.

Una firma DKIM se puede falsificar ya que sus detalles están disponibles en los registros DNS

No, no se puede falsificar. DKIM se basa en PKI (Infraestructura de clave pública), lo que significa que hay un par de claves involucradas. Una pública y otra privada. Si bien es cierto que la clave pública se publica en los registros DNS (y está disponible para que todos la recuperen), la clave privada se mantiene solo en el servidor del proveedor de servicios de correo electrónico. La clave privada se mantiene en secreto y se utiliza para firmar mensajes. La clave pública no puede firmar mensajes y se utiliza sólo para la verificación. 

DKIM te salva del spam de una vez por todas

¡Eso quisiéramos! Como la firma digital DKIM solo permite probar que el remitente está autorizado a enviar mensajes desde el dominio, y que el mensaje no se entrometió en el camino, DKIM solo reduce las posibilidades de que los spammers usen direcciones de correo electrónico falsificadas o robadas. 

Sin embargo, nada les impide comprar un dominio, configurar un registro DKIM y continuar con sus actividades de spam. De hecho, esto podría incluso, de alguna manera, legitimar el spam. 

Sin embargo, usar un nombre de dominio real en lugar de uno falso puede minimizar los ataques de phishing, como cuando recibes un correo electrónico falso de tu “banco” pidiéndote que confirmes los detalles de tu tarjeta de crédito.

DKIM key rotation: mantenga actualizada la seguridad de su DKIM

Aunque las claves públicas de 1024 bits de DKIM son difíciles de descifrar y las claves de 2048 bits son casi imposibles, todavía se publican en los registros DNS y, por lo tanto, podrían convertirse en un objeto de ataque. Las claves privadas (clave de firma) también podrían ser robadas si el sistema donde se almacena es hackeado.

Para mitigar los riesgos de comprometer las claves DKIM, debes minimizar el tiempo en que se utilizan activamente. El proceso de reemplazo sistemático del antiguo par de teclas DKIM con el nuevo se llama key rotationo rotación de claves DKIM.

En general, el periodo de rotación de claves recomendado es desde la sustitución trimestral hasta cada seis meses. La frecuencia de rotación de claves debe ser establecida por la organización, pero definitivamente, es una necesidad en el flujo de trabajo. 

El proceso de rotación de claves puede volverse bastante complicado dentro de las empresas que tienen múltiples flujos de correo electrónico, subdominios delegados o flujos enviados en su nombre por terceros. Por lo tanto, para mantener el flujo de correo electrónico seguro, el proceso de rotación de claves DKIM debe planificarse con anticipación.

¿Cómo rotar las claves DKIM? 

El proceso de rotación de claves DKIM se divide en dos fases principales: preparación y rotación per se. 

Primero, en la fase de preparación, identificas todos los flujos de correo que se envían desde tu empresa: desde mensajes transaccionales y mensajes conversacionales dentro de la empresa hasta correos electrónicos enviados por proveedores externos. La preparación también incluye informar a las partes interesadas internas, los administradores de correo electrónico, los administradores de DNS y el personal de soporte técnico interno responsable de los flujos de correo electrónico sobre el proceso de rotación de claves. También deben saber qué hacer en caso de rotación de teclas de emergencia si las claves DKIM se ven comprometidas inesperadamente.

En segundo lugar, en la fase de implementación, defines tu esquema de rotación del selector, rotas las claves y posteriormente realizas la auditoría .  

Messaging, Malware y Mobile Anti-Abuse Working Group (M3AAWG) han creado una guía paso a paso para las mejores prácticas de rotación de claves DKIM. Recuerda, la seguridad del correo electrónico siempre debe ser lo primero. 

Otras consideraciones

Esto concluye nuestra guía de DKIM, pero no debería ser el final de tus esfuerzos para mejorar la capacidad de entrega del correo electrónico. Echa un vistazo a nuestra guía sobre entregabilidad, donde enumeramos muchas otras ideas. Asegúrate de autenticar también con SPF (Sender Policy Framework) y DMARC (Domain-based Message Authentication, Reporting, and Conformance) para que tu dominio sea aún más creíble. Sólo se necesita un poco de tiempo y esfuerzo, pero la recompensa puede ser enorme.

En esta publicación, echaremos un vistazo más de cerca a SMTP y exploraremos sus características y funcionalidades principales.

¿Qué es SMTP? 

SMTP o Simple Mail Transfer Protocol es un ‘application layer protocol’ que permite transferir correos electrónicos entre diferentes servidores y redes informáticas. Lo hace definiendo las reglas de la comunicación.

El modelo original fue introducido en 1982. De acuerdo con el RFC 821, el usuario crea la solicitud de conexión. En respuesta, el emisor-SMTP inicia una conexión bidireccional con el receptor-SMTP. En términos modernos, estos son cliente SMTP y servidor SMTP, respectivamente. El cliente SMTP y el servidor SMTP se comunican con comandos y respuestas (más sobre eso abajo), similar a las conversaciones de la vida real.

El RFC 821 también define el modelo para el uso de SMTP. Puedes ver el esquema en la ilustración a continuación.

Una vez establecida la conexión, el cliente SMTP transferirá los encabezados, los destinatarios, el cuerpo de los mensajes (incluidos los archivos adjuntos) y todos los datos al servidor SMTP paso a paso. Cuando se complete la transmisión, la conexión se cerrará. 

Por definición, la forma completa de SMTP es cuando los clientes SMTP admiten la retransmisión, las colas de correo electrónico y las funciones de direcciones alternativas. Esto se llama un SMTP totalmente funcional. Si estas funciones no son compatibles, el SMTP no es totalmente funcional. En ese caso, los RFC relevantes recomiendan usar el protocolo de envío de mensajes en su lugar. 

Tenga en cuenta que SMTP solo puede enviar mensajes simples, es decir, texto sin formato sin archivos adjuntos. Usamos un protocolo separado, Multipurpose Internet Mail Extensions, MIME (RFC 2045), para enviar archivos adjuntos, cuerpos de mensajes que exceden los límites de caracteres impuestos por SMTP, mensajes en idiomas distintos del inglés y formatos HTML/CSS.

MIME es un protocolo de extensión: mejora las capacidades de SMTP, pero no funciona por separado. La mayoría de los servicios de correo electrónico modernos admiten MIME.

¿Qué es el ESMTP?

ESMTP o Extended Simple Mail Transfer Protocol fue introducido por primera vez en 1995 en el RFC 1869. El propósito era crear una estructura unificada para todas las extensiones futuras. Las extensiones tienen como objetivo añadir funcionalidades de las que  SMTP carece. RFC 5321 Los documentos anteriores consolidados y obsoletos.

ESMTP utiliza un nuevo comando EHLO para iniciar la conexión. También permite el uso de parámetros adicionales en el MAIL⁠FROM de SMTP y comandos RCPT TO. Como resultado, ESMTP elimina el límite de 512 caracteres para parámetros adicionales y lo deja solo para casos en los que no se definen parámetros adicionales. 

Tanto ESMTP como SMTP son ampliamente utilizados hoy en día. Si el comando EHLO no es compatible, la conexión debe volver al SMTP y su comando HELO. 

Hablando de extensiones, también debemos mencionar la extensión SMTP-AUTH, que añade un paso de autenticación al proceso. Esto significa que el cliente de correo debe iniciar sesión en el servidor de correo utilizando su nombre de usuario y contraseña. Si bien la autenticación SMTP no puede proteger contra la suplantación de identidad, es una medida de seguridad importante.

¿Qué es SMTPS? 

SMTPS o Simple Mail Transfer Protocol Secure es un método que protege SMTP con la ayuda de los protocolos de seguridad de la capa de transporte (TLS) o Secure Sockets Layer (SSL). Estas capas de seguridad cifran los mensajes para evitar que los spammers o spoofers vean el contenido de los correos electrónicos.

Aunque SSL todavía se usa ampliamente, TLS (más precisamente, en su versión 1.3) se considera el protocolo más seguro para el cifrado de correo electrónico. Para obtener más información sobre la seguridad SMTP, lea nuestro blog post al respecto.

Tipos de SMTP

RFC 5321 diferencia entre cuatro tipos de sistemas SMTP:

• El SMTP original es el primer sistema que interactúa con Internet con la introducción del correo; 
• Delivery SMTP es el sistema que recibe correos electrónicos de Internet y los entrega a los destinatarios; 
• Relay SMTP distribuye correos electrónicos entre servidores SMTP o MTA (más sobre el significado del agente de transferencia a continuación) sin modificar el mensaje de ninguna manera;
• Gateway SMTP o puerta de enlace SMTP también transfiere correos electrónicos entre diferentes servidores, pero, a diferencia de SMTP relay, se le permite transformar el mensaje si es necesario. Las puertas de enlace SMTP suelen ser firewalls que reescriben direcciones o servidores SMTP intermedios.

Infraestructura SMTP 

Como vimos anteriormente, los componentes principales del modelo SMTP son User, Sender-SMTP (cliente SMTP) y Receiver-SMTP (servidor SMTP). Sin embargo, los agentes de correo también participan en el proceso de envío y recepción de correos electrónicos. Además, el modelo SMTP incluye SMTP relay en escenarios específicos. Veamos qué significa cada uno de ellos y qué función tienen.

Servidor SMTP

El servidor SMTP es una aplicación para enviar correos electrónicos. Recibe mensajes electrónicos de clientes de correo electrónico (Gmail, Yahoo! Apple Mail, AOL, etc.) y los transfiere a otros servidores. Estos pueden ser otros servidores SMTP o un servidor de correo entrante. 

El servidor de correo electrónico SMTP puede ser local o basado en la nube. Un servidor SMTP local es una buena opción para aquellos que no quieren depender de servidores de terceros. Por otro lado, un servidor SMTP alojado en la nube requiere menos esfuerzo y puede ser más seguro en la mayoría de los casos.

Agentes de correo 

Hay cuatro agentes principales: 

• MUA (Mail User Agent) es el cliente de correo electrónico que mencionamos anteriormente. Es una aplicación o un sitio web que utilizas para enviar y recibir mensajes de correo electrónico.
• MSA (Mail Submission Agent) recibe correos electrónicos del cliente de correo electrónico, comprueba sus encabezados y verifica que las direcciones estén indicadas correctamente.
• MTA (Mail Transfer Agent) es un programa de sendmail que procesa y transfiere correos electrónicos. Recibe mensajes de la MSA. La mayoría de los MTA modernos asumen las responsabilidades de MSA. En ese caso, la transferencia de mensajes no incluirá MSA. Los MTA más populares son Sendmail, Postfix y Exim.
• MDA (Mail Delivery Agent) es el agente final antes de que sus correos electrónicos se entreguen al servidor SMTP del destinatario y luego se recuperen a través de servidores de correo electrónico entrantes (IMAP o POP3).

Tenga en cuenta que, muchas veces, los limites entre las responsabilidades de los agentes pueden ser borrosas, sin embargo, siguen siendo útiles para fines ilustrativos. En el mundo real, los servidores MUA, MTA y SMTP son los componentes más esenciales de la entrega de correo electrónico. 

SMTP Relay

SMTP relay es el proceso de transmisión de correos electrónicos entre servidores SMTP alojados en diferentes dominios (de @gmail.com a @yahoo.com, por ejemplo). 

Los MTA comprueban si los nombres de dominio son los mismos. Si lo son, el SMTP relay no sucederá. Pero si los dominios no son los mismos, las MTA consultarán los registros del Sistema de nombres de dominio (DNS) para encontrar la dirección IP del dominio del destinatario. Una vez que se localiza la IP, enrutarán el mensaje entre uno o varios MTA (SMTP relay) hasta que finalmente se entregue al servidor SMTP del destinatario.

¿Cómo funciona SMTP?

Una sesión SMTP comienza cuando el cliente abre una conexión de Protocolo de Control de Transmisión (conexión TCP, a veces llamada TCP/IP) al servidor SMTP. El servidor responde con un mensaje de apertura, expresado con el código 250. Este proceso a menudo se nombra como un apretón de manos SMTP. 

A continuación, el cliente envía un comando HELO (EHLO para ESMTP) y se identifica a sí mismo. A menudo sigue el comando con el nombre de dominio o la dirección IP. En palabras no técnicas, el cliente dice: “Hola, mi nombre es John El Cliente, estoy enviando un correo electrónico desde gmail.com, y mi IP es 192.0.2.0”. El servidor responderá de nuevo con el código 250.

Después de eso, comenzará la etapa de transferencia de correo electrónico. El contenido del correo electrónico se transferirá paso a paso con MAIL⁠FROM (john@gmail.com), RCPT TO (oliver@gmail.com) y DATA (‘Oye, ¿cómo has estado?’) . Si el servidor acepta la transacción, el cliente transferirá los encabezados de correo electrónico. Es necesario utilizar un indicador de fin de línea (punto ‘.’) una vez que todo ha sido transmitido.

El servidor responderá con el código 250 si la transacción tiene éxito. El cliente iniciará la terminación de la conexión SMTP con el commando QUIT, y el servidor cerrará el canal de transmisión con el código 221. Este es, por supuesto, un ejemplo simplificado sin un SMTP relay, reenvío, puertas de enlace o códigos de error. Para obtener más información sobre estos, consulte RFC 5321.

¿Qué pasa con la queue del SMTP? 

La cola de SMTP es un conjunto de correos electrónicos que están a la espera de ser entregados. Los correos electrónicos generalmente se ponen en la cola cuando el servidor SMTP receptor no está listo para aceptar correos electrónicos, o está enviando grandes volúmenes a la vez. Cuando el servidor responda, los correos electrónicos se entregarán uno por uno. La cola SMTP es una especie de búfer entre vos y el servidor receptor.

Comandos y respuestas SMTP

Mencionamos algunos de los comandos y respuestas SMTP en el ejemplo anterior. Pero, al enviar correos electrónicos con SMTP, es posible que encuentre otros comandos y respuestas. 

En general, los comandos son cadenas de caracteres alfabéticos que terminan con<CRLF>. Si se siguen parámetros adicionales, los caracteres serán terminados por<SP>.

Las respuestas (o comentários) son códigos de finalización numéricos que pueden ser positivos o negativos. Por lo general, son seguidos por una cadena de texto. 

Los comandos y las respuestas se componen de un conjunto de caracteres ASCII.

Comandos

• HELO/EHLO – arranca el inicio de la sesión SMTP.
  
  Sintaxis: "EHLO" SP ( Domain / address-literal ) <CRLF> o "HELO" SP Domain <CRLF>
  
• MAIL FROM – inicia la transacción de correo e incluye la ruta inversa y, a veces, parámetros opcionales.
  
  Sintaxis: MAIL⁠FROM:<reverse-path> [SP<mail-parameters>] <CRLF>
  
• RCPT TO – indica el (los) destinatario(s) e incluye su dirección de correo electrónico (también conocida como ruta de reenvío) como argumento.
  
  Sintaxis: RCPT TO:<forward-path> [ SP<rcpt-parameters>] <CRLF>
  
• DATA: solicita el permiso del servidor para transferir datos y lo hace una vez que recibe una respuesta positiva.
  
  Sintaxis:  "DATA" <CRLF>
  
• VRFY – pide al servidor que verifique si el buzón en el argumento existe en el host local.
  
  Sintaxis: "VRFY" SP String <CRLF>
  
• EXPN: hace lo mismo que VRFY, pero para la lista de correo.
  
  Sintaxis: "EXPN" SP String <CRLF>
  
• NOOP – comprueba la capacidad del servidor para responder.
  
  Sintaxis: "NOOP" [ SP String ] <CRLF>
  
• QUIT – inicia la terminación de la conexión.
  
  Sintaxis: "QUIT" <CRLF>
  
• HELP: pide al servidor que verifique qué comandos admite. Puede incluir un comando específico como argumento.
  
  Sintaxis: "HELP" [ SP String ] <CRLF>
  
• RSET – restablece la conexión SMTP y borra todos los buffers y tablas de status. La conexión SMTP se invertirá al estado inicial.
  
  Sintaxis: "RSET" <CRLF>

El protocolo SMTP también puede admitir algunos comandos ESMTP, como STARTTLS, AUTH y otros. 

Respuestas

Respuestas positivas comunes 

• 250 – la acción solicitada está bien o completada 
• 211 – estado del sistema o respuesta a HELP
• 220 –  <domain> el servicio está listo
• 221 – <domain> cierre del canal de transmisión
• 354 – Iniciar entrada de correo (generalmente responde al comando DATA) 

Respuestas negativas o códigos de error

• 500 – error de sintaxis o comando no se pudo reconocer 
• 503 – secuencia incorrecta de comandos
• 252 – el servidor no puede verificar al usuario. Seguirá aceptando el mensaje e intentará la entrega (responde al comando VRFY)
• 450 – buzón no disponible 
• 510 – Dirección de correo electrónico no válida

Puertos SMTP

Los puertos SMTP son puntos finales de comunicación que ayudan a identificar la ubicación exacta de las direcciones de Internet. Los puertos más comunes utilizados con SMTP son 25, 465, 587 y 2525. 

• 25 es el puerto SMTP más antiguo, pero usarlo para enviar correos electrónicos ya no es común. Como no tiene mecanismos de seguridad, los spammers abusan de el en gran medida. Por esa razón, los proveedores de servicios de Internet (ISP) generalmente bloquean el puerto número 25. Se recomienda usarlo solo como puerto de relay. 
• 465 es más seguro en comparación con 25, pero no es un puerto SMTP oficial y ahora está en desuso. Soporta encriptación SSL. Sin embargo, se recomienda evitar su uso siempre que sea posible. 
• 587 es el puerto SMTP predeterminado recomendado con STARTTLS. Casi todos los proveedores de servicios de correo electrónico lo admiten. 
• 2525 es una alternativa a 587. Se puede usar cuando 587 está bloqueado o no está disponible. 2525 nunca ha sido reconocido como un puerto SMTP oficial. Sea como sea, la mayoría de los ISP permiten transacciones a través de este puerto. 

Comparación de SMTP, IMAP y POP3

Aparte de SMTP, los protocolos de correo electrónico más comunes son IMAP y POP3. SMTP es un servidor de correo electrónico de salida utilizado para enviar y entregar correos electrónicos. IMAP y POP3 son protocolos de acceso a mensajes utilizados para recuperar mensajes entrantes del servidor de correo electrónico. 

IMAP es un protocolo de acceso a mensajes de Internet que se conecta al servidor y descarga mensajes bajo pedido. Los mensajes no se eliminarán una vez que se finalice la conexión. Con IMAP, los usuarios pueden acceder a sus correos electrónicos desde cualquier ordenador o dispositivo. 

POP3 o Post Office Protocol 3 también se conecta al servidor, pero descarga todos los mensajes recibidos. Una vez que se haya completado, eliminará todos los correos electrónicos del servidor. A diferencia de IMAP, POP3 depende del dispositivo. Más información sobre las diferencias entre estos protocolos está disponible aquí.

Cómo enviar correos electrónicos con SMTP 

Uno de los principales beneficios de SMTP es que facilita el envío de correos electrónicos desde diferentes aplicaciones o dispositivos. La mayoría de los lenguajes de programación permiten a los usuarios enrutar correos electrónicos salientes a través de SMTP de forma nativa o con la ayuda de diferentes bibliotecas. A diferencia de la API web (o Email API), la integración SMTP no requiere habilidades avanzadas de codificación. Vas a necesitar trabajar con credenciales SMTP (como host, puerto, nombre de usuario, contraseña y cifrado) y el lenguaje de programación relevante para completar esa tarea. Podes consultar nuestra publicación más reciente en el blog para obtener más detalles sobre eso.

SMTP como servicio: prueba y envío

SMTP (o, más precisamente, el servidor SMTP) se proporciona a los usuarios como un servicio para dos propósitos principales: pruebas y envío. 

En términos de pruebas, el servicio SMTP implica un servidor SMTP falso que captura el correo saliente. De esa manera, los correos electrónicos no llegan a las bandejas de entrada reales, creando un entorno seguro para las pruebas. 

Cuando se trata de envío de correo electrónico, el servicio SMTP es sinónimo de servicio de retransmisión SMTP. Los proveedores de correo electrónico tienen sus propios servidores SMTP que permiten a los usuarios enviar correos electrónicos de marketing o transaccionales. 

Idealmente, estos dos servicios SMTP se pueden combinar en una herramienta robusta como Mailtrap.

Mailtrap es una plataforma de entrega de correo electrónico que combina pruebas de correo electrónico y envío de correo electrónico. Es una infraestructura de correo electrónico completa que permite a los usuarios probar el servidor SMTP, enviar correos electrónicos con él y monitorear su rendimiento con análisis procesables.

Email Testing es un Sandbox que captura todo el tráfico SMTP en una bandeja de entrada virtual y elimina las posibilidades de spam de los usuarios. Puede inspeccionar y depurar fácilmente sus correos electrónicos en staging con HTML/CSS o verificaciones de spam, ver información técnica o usar funciones de reenvío manual/automático. Las pruebas de correo electrónico proporcionan múltiples bandejas de entrada para diferentes proyectos y etapas del producto. 

Email Sending es una infraestructura con altas tasas de entrega de correo electrónico por si mismo. Con su API de correo electrónico y servicio SMTP, la integración es fluida y sin esfuerzo. Todo lo que necesitas hacer es verificar su dominio y elegir el método preferido de integración. Una vez hecho esto, puedes llegar a las bandejas de entrada de los destinatarios en cuestión de segundos. 

El envío de correo electrónico también tiene análisis en profundidad procesables con informes detallados y paneles de vista en helicóptero que lo mantienen al tanto de sus métricas de entregabilidad.