Lo comentaba la semana pasada en el envío de los lunes, y al final he tenido que esperar hasta el siguiente envío para en efecto estar seguro de que los cambios se habían propagado de forma correcta.
Desde que migré al nuevo hosting (¡hace ya un año, madre mía!) había dejado de lado la configuración necesaria para evitar que los envíos que realizo a los miembros de la Comunidad sean tachados como spam por algunos gestores de email.
Sinceramente, hasta ahora no he tenido problemas con esto (toco madera). El que periódicamente realice borrados de inactivos (en el último me cargué 310 miembros) seguramente ayuda, como también lo hace entender el mundo de las newsletters como un espacio bidireccional cuyo objetivo es aportar, y no simplemente vender.
No tengo constancia de que a nadie de la Comunidad le estén llegando mis correos a la carpeta de spam, pero aun así, me dio por probar mail-tester (ES), un servicio gratuito que te permite ver qué valoración media tiene su email respecto a lo óptimo (un email enviado por una persona a otra), encontrándome con un alarmante 4 sobre 10.
Era algo que esperaba, no obstante. Entre las múltiples variables que un gestor de emails como GMail o Outlook utilizan para discriminar el contenido de calidad del spam publicitario están una serie de elementos técnicos que permiten a estos sistemas saber que quien envía ese correo en efecto es el dueño del dominio, o al menos alguien que cuenta con el beneplácito de este.
No es el único criterio, y ya le recalco que lo verdaderamente importante es que el email sea de interés a quienes lo van a recibir. Que éstos lo abran, que clicken en sus enlaces o sus adjuntos (si compete), y que también respondan. Pero sí es algo que se hace una vez y lo más probable es que no tengamos que volver a tocarlo (a no ser que cambiemos de proveedor de dominios, claro), por lo que me puse en el fin de semana, y este es el resultado: 9,5/10.
No tengo el 10 porque el widget de Mailchimp que permite compartir el email en diferentes redes sociales hace uso de imágenes (los logos de cada red social) que no llevan atributo ALT. Un atributo que como seguramente sepa sirve para definir el contenido de una imagen, en vista a que por un lado el propio gestor sepa de qué se trata, y por otro una lectura en formato texto, o un lector de contenido escrito (usado por ejemplo por personas con visibilidad reducida) pueda entenderlo.
Pero vamos, que puedo vivir con ese -0,5 :).
Así que por aquí va la explicación de qué son estos tres elementos, y cómo deberíamos configurarlos para aparentar salir, aunque sea a nivel técnico, lo más “guapos posible” frente a los filtros anti-spam.
Primera parada: El SPF
Sender Policy Framework (SPF) es un sistema de validación de correos diseñado para prevenir los correos no deseados detectando técnicas habitualmente utilizadas por cibercriminales como el spoofing, una vulnerabilidad común, mediante la verificación de la dirección IP del remitente.
Este elemento lo que intenta evitar es que cualquiera pueda usurpar nuestra identidad con el uso de nuestro dominio para enviar contenido de la índole que sea a terceros. Algo que ya le digo que es tan sencillo de realizar como preparar un script corto en PHP con la función mail() (EN) y ejecutarlo en un servidor.
Con el SPF lo que definimos es qué IPs y/o dominios pueden hacerse pasar por nosotros, de manera que todo email que venga de esas direcciones contará en teoría con el beneplácito nuestro, y todo aquel que venga de otro lugar no.
Para configurarlo, es tan sencillo como entrar en nuestro gestor de dominios, en la sección de zona DNS avanzada (o el nombre que tenga, que cada proveedor es un mundo), y crear, sino existe ya, un nuevo registro de tipo TXT, con el nombre nuestrodominio.extension. (ojo al punto final) y contenido “v=spf1 ip4:IPDeNuestroServidor include:DominioODominiosAAutenticar ?all”
En mi caso, y como utilizo Mailchimp, la sentencia quedó de la siguiente manera:
pabloyglesias.com. TXT v=spf1 ip4:MiIP include:servers.mcsv.net ?all
El servers.mcsv.net es el dominio que utiliza Mailchimp para realizar los envíos. Con esta sentencia le estoy informando a los proveedores de correo que cualquier correo enviado desde una cuenta @pabloyglesias.com contará con mi beneplácito siempre y cuando provenga de la IP de mi servidor o del dominio servers.mcsv.net. El ?all lo que evita es que el resto de dominios e IPs no definidas sean consideradas no verificadas.
Por defecto los proveedores de dominio ya suelen incluir su propio SPF enlazado al dominio del hosting o servidor. Cada sistema de email marketing utilizará su propio dominio, así que simplemente tenemos que buscar en su página o preguntar a soporte cuál es.
Por cierto, que como cualquier cambio en las DNS, puede que tarde en propagarse hasta 72 horas, así que sea paciente.
Siguiente parada: El DKIM
DomainKeys Identified Mail (DKIM) es un método para asociar un nombre de dominio a un mensaje, lo que permite a una persona u organización responsabilizarse del mismo.
Suele ir acompañado del SPF, siendo estos dos los principales aspectos técnicos de autenticación de emails. Y de nuevo, para su configuración dependemos del proveedor de email marketing que vayamos a utilizar.
En el caso de Mailchimp, y como explican en su página de configuración avanzada, basta con crear un dominio k1._domainkey.nuestrodominio.extension. (ojo al punto final) de tipo CNAME con el contenido dkim.mcsv.net.
El resultado, en mi caso:
k1._domainkey.pabloyglesias.com. CNAME dkim.mcsv.net
Tercera validación: El DMARC
Una política DMARC permite a un emisor indicar que sus correos electrónicos están protegidos por SPF y/o DKIM, y dar instrucciones si ninguno de esos métodos de autenticación pasa. Esto significa que para poder tener DMARC en nuestros correos es necesario que primero esté ya funcionando (se hayan propagado adecuadamente) al menos uno de los dos anteriores.
Y realmente, como política que es, no es estrictamente necesaria. Solo marca la manera que tendrían los proveedores de ponerse en contacto contigo en caso de encontrarse con problemas. De hecho, las dos anteriores bajan cada una 3 puntos el valor que mail-tester da al envío final, mientras que un DMARC inexistente o mal configurado creo recordar que solo bajaba 1 punto.
Pero ya puestos no nos cuesta nada dejarlo bien configurado.
Para ello, esta vez necesitaremos crear el DMARC oportuno en algún proveedor como UnlockTheInbox (EN). En todos estos servicios nos pedirán, vía formulario, que completemos una serie de campos con nuestro dominio, con el SPF y/o el DKIM que tengamos, para luego devolvernos un código que tendremos que incluir de nuevo en la configuración avanzada de DNS, bajo el dominio _dmarc.nuestrodominio.extension. (punto final…) y con el tipo TXT.
En mi caso ha quedado una cosa tal que así:
_dmarc.pabloyglesias.com. TXT v=DMARC1; p=none; sp=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; pct=100; ri=86400
Ya solo con hacer estos tres sencillos pasos tenemos asegurado hasta 7 puntos de 10 en mail-tester.
Aún así, recalco. Criterios propios del contenido (que nuestros envíos tenga muy poco texto y mucho código o imágenes), del uso que reciban los envíos por parte del receptor (tasa de apertura, tasa de click, marcado como spam, dominio agregado a la agenda…) o que alguno de los grandes proveedores nos haya marcado como spam (normalmente tendremos forma de volver a pedirles que revisen una vez creamos que ya estamos haciendo las cosas correctamente) afectan a la tasa de rebote que puedan tener nuestros envíos, en muchísima mayor medida que la que realmente afectarán estas tres configuraciones.
Pero vaya, que como ya dije esto lo hacemos una vez y nos olvidamos, mientras que lo otro ya depende más del buen quehacer en todos y cada uno de nuestros envíos.
Hola Pablo. Me gustó mucho cómo abordaste los temas de SPF, DKIM y DMARC. Sin duda es que necesitamos enviar emails a clientes y debemos evitar que nuestros correos lleguen a la bandeja de SPAM del cliente. Esto nos resta auditorio y por ende menos ventas o visitas a nuestros proyectos. El tema de la seguridad en email marketing es muy interesante y cuando nos vamos a la parte técnica como tu ya lo explicaste, nos metemos en un mundo en que no cualquiera sale vivo. Prueba de esto es cómo muchos que se inician en este mundo mandan emails que Gmail o Hotmail los clasifican como SPAM. Tuve una experiencia hace como 3 años con un cliente en la que su dominio al enviar emails a destinatarios de Hotmail no les llegaban ni siquiera como SPAM. Después resolví este problema utilizando un servidor SMTP con un plugin en WordPress. Te envío saludos desde Guadalajara, México.
Exacto Ángel.
El otro día tuve que llamarle la atención a un compañero de profesión, que hacía “email marketing” con listas de correos desde Gmail…
Estimado Pablo,
excelente articulo por lo demás.
Pero tengo una duda. ojala me puedas orientar
Hoy tenemos muchos hosting y todos con sus correos, resulta que los envíos de correos a través de mi aplicación usan un código hecho por mi bajo los standares microsoft usando una cuenta de otro server (propio) por ejemplo XXXXX.cl(servidor de correo masivo) por lo que el sender usa el correo del hosting que lo llama por ejemplo [email protected] pero al enviar un correo a mi gmail esta saliendo un error
Failed Recipient: [email protected]
Reason: Remote host said: 550 5.7.1 Unauthenticated email from XXXX.cl is not accepted due to domain’s
5.7.1 DMARC policy. Please contact the administrator of XXXXX.cl domain
5.7.1 if this was a legitimate mail. Please visit
5.7.1 https://support.google.com/mail/answer/2451690 to learn about the
5.7.1 DMARC initiative. j6si12257173otc.118 – gsmtp
Me podrías orientar¿?
Buenas Alexis, y muchas gracias!
La verdad es que es difícil decirlo simplemente mirando lo que me has pasado. Supongo no obstante que puede deberse a alguna mala configuración a nivel de servidor o de la configuración de autenticación del correo, como dice por ahí.
¿Te pasa solo con tu correo GMail o también desde cualquier otro que reciba o intente enviar un correo desde ese dominio? Por si el problema es de configuración de GMail, que entonces quizás podría ser un error en la autenticación de los servidores para que Google pueda hacer envíos bajo ese dominio.
Pablo…
El tema radica en otra cosa.
Tengo un servidor de correos que se llama mail2.xxx.cl En varios de mis sitios uso ese servidor de correo, cuando el correo sale de uno de estos sitios ejemplo ofinet.cl a una cuenta gmail X este rebota con el problema de DMARC
Por que? por que ofinet.cl envia los correos usando mail2.xxx.cl y no una cuenta ofinet.cl
La idea es centralizar todos los envios de correo a un puro servidor y por eso quiero hacer seguro el envio a cada uno de los distintos host (dominios) que poseo que usen seguro el mail2.xxx.cl
Saludos