configuracion email marketing


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.

Otros artículos relacionados