Cómo mejorar la entrega de correos en Salesforce: introducción a SPF, DKIM, DMARC y Email Relay

Salesforce permite enviar correos de varias formas, pero muchas veces todo el esfuerzo invertido, puede verse al traste, porque el correo no llega a su destino. En este artículo, explico varios de los conceptos que influyen en el nivel de entrega de los mensajes.

Introducción

Existen muchas opciones para enviar correos desde Salesforce:

1. Mediante Workflow rules
2. Mediante APEX
3. Directamente en la UI (en Contactos ó Leads por ejemplo)
4. Mediante Marketing Cloud (via Journeys por ejemplo)
5. Mediante integración con servicios extenos como Twilio

Incluso para los correos enviados mediante HTML se puede rastrear las aperturas, cuantas veces fueron abiertos, la fecha de máxima apertura, etc.

Todas estas y otras posibilidades serán inútiles si nuestro correo no llega a su destinatario, porque se han incumplidos ciertas reglas que de haberlas conocido hubiera mejorado el ratio de entrega.

Los conceptos que voy a describir en esta entrada son:

• SPF: como indicar a los servidores destinatarios que se permite el envío desde IPs distintas a las de la empresa
• DKIM: firma de correos para validar el origen y la no variación del contenido generado
• DMARC: políticas que se aplican cuando no se cumplen los requerimientos de SPF ó DKIM
• Email Relay: enviar correo a través de los servidores de mi empresa

No es objetivo de esta entrada entrar en el detalle de cómo Salesforce aplica los límites de envío de mensajes desde la ORG, pero que evidentemente debes tenerlos siempre en cuenta.

Un ejemplo de cabecera de correo headers es (y se leen de abajo a arriba):

Ejemplo de cabeceras de un mensaje enviado desde una ORG de Salesforce a mi cuenta de correo personal en gmail. La mayoría de los servicios de correo, como gmail, live.com, yahoo o clientes de correo como outlook, etc., permiten ver el contenido completo de las cabeceras de un correo.

SPF

El Sender Policy Framework es una técnica utilizada para evitar SPAM, que intenta suplantar al emisor, es decir, enviar correos en nombre de alguien que no lo ha autorizado.

Esta técnica creada en el año 2000, y mejorada en 2006 con recursos de Microsoft y finalmente publicada en 2014 y actualmente se usa ampliamente, aunque se combina con otras 2 técnicas: DKIM y DMARC.

¿Qué es?

Es un registro de DNS en el que se especifica las IPs para las cuales se permite enviar correo en nombre de.

Este es un ejemplo sencillo de un registro SPF para un dominio de una empresa que permite el envio en nombre de, para indicar que los correos enviados por la IP del thirdpartydomain.com son correctos:

v=spf1 include:thirdpartydomain.com

Al recibir un correo, se comprueba que el valor de la cabecera «return-path» exista en la lista de IPs permitidas en el registro SPF del dominio del emisor. Si no existe registro SPF en el dominio del emisor, o la IP no está en la lista de las permitidas, el correo se marcará como sospechoso (aunque pueda que no Spam) y no se descargará el cuerpo del mensaje.

SPF no permite la validación cuando se realiza un Re-envío y no realiza ciertas comprobaciones complementarias sobre otras cabeceras.

DKIM

El Domain Keys Identified Mail consiste en añadir una cabecera al mensaje, con la firma del mensaje. Esta firma permite validar el emisor y la inviolabilidad del contenido del mensaje desde que fue enviado.

El proceso es el siguiente:

1. Los apartados que serán considerados para la generación del hash de la firma electrónica, son seleccionados por el emisor, aunque usualmente será el cuerpo del mensaje y algunas de las cabeceras estándar.
2. Para la generación del hash, se utiliza un certificado cuya clave privada se utilizará en el cifrado del hash.
3. La clave pública del certificado debe ser accesible para que los servidores receptores la puedan obtener para validar la firma.
   1. Para obtenerlo debe indicarse en el DNS.
4. Cuando el servidor del remitente recibe el mensaje, comprueba si ha sido firmado mediante DKIM y lo valida.
   1. La validación de la firma se lleva a cabo, obteniendo la clave pública del certificado y obteniendo el hash de los apartados designado .
   2. Si el hash generado y el hash obtenido aplicando la clave publica coinciden se considera que el mensaje no fue modificado y que fue generado con un certificado aceptado por el emisor.

Un ejemplo de registro DKIM creado en el DNS, donde p es la clave pública que se descargará para validar la firma:

dk1024-2012._domainkey.returnpath.com. 600 IN TXT "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;"

En el caso de Salesforce la entrada no contendrá la clave pública, sinó un CNAME dado que la entrada que genera Salesforce consiste en un CNAME y no ofrece directamente la clave pública.

¿Cómo se configura en Salesforce?

En Salesforce la creación de claves DKIM es muy simple. Mediante la entrada Setup->DKIM Keys se accede a su creación.

Debes crear las entradas Inactivas, y pasar la información generada al administrador del DNS para que cree las entradas en el DNS.

En este proceso se generarán las claves privadas que servirán para crear las claves privadas con las que crear las firmas electrónicas y que el sistema destino podrá validar obteniendo la clave pública, que obtendrá consultando el DNS.

Por eso, hasta que el administrador del DNS no te avise, no actives las entradas de DKIM configuradas en Salesforce, o se firmarán los mensajes y no se podrán validar sus firmas.

DMARC

El Domain-based Message Authentication Reporting and Conformance fue publicado en 2012 con la colaboración de Google, Microsoft y Paypal, entre otros.

El proceso es el siguiente:

1. DMARC utiliza las técnicas SPF y DKIM para reportar sobre la legitimidad del envío realizado en nombre de otro.
2. La empresa genera un registro DMARC en su DNS indicando cómo deberán actuar los servidores intermedios y el servidor remitente ante los correos que no superen las comprobaciones de SPF y DKIM.
3. Si se detectan violaciones, los servidores consultan el registro DMARC y actúan en consecuencia.

Existen 3 policies aplicables:

• reject: indica rechazar todos los mensajes de ese destinatario (esto frena un ataque de phising de forma eficaz) y marcarlos como spam
• quarantine: en la práctica los correos se marcan como spam
• none: no realizar ninguna acción

Crédito: https://www.dmarcanalyzer.com/

DMARC no tiene configuración en Salesforce, ya que se configura a nivel del DNS de la empresa y es un estándar implantado por la mayoría de empresas de Marketing e IPSs.

El registro DMARC que se incluye en el DNS tiene este aspecto, adjunto 3 ejemplos de los registros DMARC para Twitter, Gmail y Salesforce respectivamente (se obtienen via línea comandos mediante dig +short txt _dmarc.salesforce.com):

"v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"

"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

"v=DMARC1;p=reject;pct=100;sp=none;fo=1;ruf=mailto:d@ruf.agari.com;rua=mailto:d@rua.agari.com"

Podemos ver que gmail tiene una policy algo más permisiva que Twitter y Salesforce.

Los buzones de mail indicados de la entrada de rua (aggregate, normalmente diario) y la de ruf (failure forensic, supuestas ilegitimidades), indican dónde recibir los informes de DKIM y analizar las causas de los incumplimientos.

Poder obtener estos informes y forensics de los rechazos para que puedas analizarlos puede serte muy útil para entender cómo está evolucionando y si deben aplicarse modificaciones sobre los registros SPF, o si DKIM está funcionando correctamente.

La recomendación habitual, es que cuando se creen los registros de DMARC por primera vez la policy sea None, para empezar a recibir los reports de nuestros mensajes enviados, pero sin rechazar ninguno de ellos. Tenlo en cuenta cuando comentes con los administradores del servidor de mail de la empresa.

Email Relay

En lugar de enviar los correos directamente desde los servidores de Salesforce, podemos desear enviar los correos generados en Salesforce a través de los servidores de la empresa.

Esta característica denominada Email Relay, presenta varias ventajas:

• Previene que nuestros correos sean marcados como Spoofing, cuando en las cabeceras de los mensajes se intenta suplantar la identidad del emisor.
• Permite cumplir ciertas regulaciones sectoriales/gubernamentales a las que deben adherirse ciertas empresas, ya que permite guardar un log del envío en los servidores de la empresa
• Permite aplicar las reglas de cancelación de envío establecidas en los servidores de la empresa y permite validar que los correos no contienen elementos maliciosos como virus, etc.
• Permite adornar/cumplimentar los correos con horribles logos, disclaimers infinitos en varios idiomas que consuman recursos innecesarios y dificultan las búsquedas en tu cliente de correo.

Salesforce permite el establecimiento del Email Relay, pero es requisito indispensable que la empresa sea propietaria de un dominio, lo que es muy habitual.

Opciones que perjudican Email Relay

Aunque pueda parece extraño, podemos perjudicar nuestros envíos si utilizamos ciertas características del envío de correo en Salesforce conjuntamente con Email Relay (no son perjudiciales, sino totalmente recomendables cuando NO usamos Email Relay).

Por tanto, estas son las características y condiciones que pueden perjudicar la entrega de correos al utilizar Email Relay:

• Bounce Management: la activación de esta opción requiere que Salesforce modifique la cabecera «return-path» a la dirección bnc.salesforce.com. El mecanismo de SPF (explicado más adelante en este artículo) extraerá del dominio de esta cabecera, que será bnc.salesforce.com y al validar si es una de las direcciones permitidas, no encontrará la IP, con lo que se producirá un «soft failure«, con lo que muy probablemente ese correo irá a la carpeta de Spam.
• Cualquier setting que modifique la cabecera envelope-from: debes recordar que el correo enviado por Salesforce siempre contiene la dirección del correo del usuario. Si se modifica ese valor con Email Relay activo, se identifica el correo como sospechoso de Spoofing. Una de estas características es Enable compliance with Standard email security mechanisms, por lo que Salesforce recomienda no activarla con Email Relay.

Como es un informe de DMARC?

En la imagen a continuación puedes ver como Google envía un informe agregado. Recibirás una ristra de validaciones en forma de registro por cada correo enviado.

En el siguiente puedes ver cómo el correo fue correctamente aceptado dado que en la sección <auth_results> se muestra el resultado de las validaciones de SPF y DKIM.

…y en Marketing Cloud

En Marketing Cloud el proceso se simplifica ya que durante el setup del Sender Authentication Package (SAP), la activación del private domain, comporta que el equipo de ExactTarget ya realizará las configuraciones necesarias de SPF y DKIM.

Por supuesto deberán introducir las entradas del DNS igualmente, con los dominios utilizados en ExactTarget (https://help.salesforce.com/articleView?id=mc_es_sender_authentication_package.htm&type=5).

Conclusiones

Según datos de Marzo de 2019, el 56% del correo enviado a nivel mundial fue marcado como Spam. Esto comporta que existan falsos positivos y que no existan medidas 100% efectivas para asegurar que los correos enviados desde Salesforce puedan llegar a sus destinatarios.

Pero con los mecanismos y los condicionantes explicados en esta entrada, podrás mejorar sustancialmente el ratio de entrega, aunque mucha parte de la configuración y de la efectividad, no dependerá de ti, ni está en tus manos mantenerla, sino trabajarla con los responsables IT de la empresa.

Recuerda el proceso es:

1. Acuerda cuales son los dominios desde los que se enviaran correos desde Salesforce «en nombre de».
2. Solicita la creación de las entradas SPF en el DNS.
3. Solicita la creación de las entradas DMARC en el DNS.
   1. (opcional pero muy conveniente para análisis y reporting) Solicita que se incluyan buzones en rua y ruf para recibir los informes agregados y de rechazos.
4. Crea las entradas de DKIM en Salesforce, pero inactivas.
5. Solicita la creación de las entradas de DKIM en el DNS.
6. Activa las claves de DKIM configuradas en Salesforce.
7. Descarga periódicamente el log de los mensajes enviados desde Salesforce para comparar y complementar los informes recibidos.

Enlaces interesantes

1. Which Option for Sending Email from Salesforce Is Best for Your Organization?
2. Send Email Through Email Relay
3. Considerations for Using Enhanced Email
4. How to configure Gmail & Email Relay to avoid deliverability issues with emails sent from Salesforce.
5. Outbound Email (Apex)
6. Enable Email Tracking for All Customers Opening Email from Your Company
7. What is Dkim
8. What is SPF
9. DMARC – How it works and what it does (Video)
10. Una experiencia en el uso de DMARC (Video)
11. Ejemplo de cambio de política de DMARC que aplicó Gmail en 3014
12. Salesforce Outbound Emails Impacted by Google DMARC Policy Adoption

Anuncio publicitario