Correo desde tu propio dominio

Tu bot puede escribir a tus clientes por correo electrónico desde una dirección de tu dominio, como noreply@example.com. El mensaje, sin embargo, lo envía nuestro servidor. Por eso, antes del primer envío hay que añadir una vez tres registros al DNS de tu dominio. A continuación: por qué hace falta, qué añadir exactamente y qué ocurre después.

Por qué sin registros DNS el correo no llega

Míralo desde el lado receptor: Gmail, Outlook o el servidor de correo de tu cliente. Les llega un mensaje que dice venir de tu dominio, pero que llega desde un servidor que no pertenece a tu dominio. Es exactamente el aspecto de una falsificación: así funciona el phishing.

La única forma que tiene el receptor de distinguirlas es preguntar al propio dominio: «¿este remitente actúa realmente en tu nombre?». La respuesta la publicas en el DNS de tu dominio, porque el DNS es el único lugar del que dispones solo tú y, por tanto, el único al que el receptor cree.

Mientras no exista esa respuesta, un servidor de correo responsable está obligado a considerar el mensaje sospechoso. En el mejor caso acaba en Spam; en el peor se rechaza y el destinatario nunca sabe que existió.

Así que los tres registros de abajo no son un trámite ni una casilla en una interfaz. Son tu autorización.

Los tres registros y qué hace cada uno

DKIM: la firma que demuestra autenticidad

DKIM es una firma criptográfica que se añade a cada mensaje saliente. La plataforma genera para tu dominio un par de claves: la privada se queda con nosotros y firma el correo, la pública la publicas en el DNS. El receptor toma la clave pública de tu DNS y verifica la firma. Si cuadra, el mensaje lo envió quien tiene la clave privada y su contenido no se alteró por el camino.

Sin DKIM: no hay contra qué comprobar la firma. El mensaje parece sin firmar y sin confianza, y ningún otro ajuste lo compensa. DKIM es el más importante de los tres.

SPF: qué servidores pueden enviar en tu nombre

SPF responde a otra pregunta: desde qué servidores se admite correo de este dominio. Es una lista de orígenes: los servidores de correo de tu hosting, los servicios de envío que ya usas y, para que el bot pueda escribir, nuestros servidores de envío.

Sin SPF: el mensaje llega desde un servidor que tu dominio no reconoce. Para un filtro es un indicio clásico de falsificación, y se suma a todas las demás sospechas.

DMARC: qué debe hacer el receptor cuando las comprobaciones fallan

DKIM y SPF responden a «¿es auténtico el mensaje?». DMARC responde a la siguiente: qué hacer si no lo es. Es tu instrucción al receptor: no hacer nada y solo informar, mandarlo a spam o rechazarlo. Además, DMARC es la dirección a la que los receptores envían informes agregados sobre el correo en tu nombre, incluidos los intentos ajenos de falsificación.

Empieza por la política más suave, «solo informes». Endurécela más tarde, cuando compruebes que todos tus remitentes legítimos (contabilidad, CRM, boletines, este bot) pasan las verificaciones. Una política estricta activada demasiado pronto empieza a comerse tu propio correo.

Sin DMARC: cada receptor decide por su cuenta y tú nunca te enteras de qué ocurre con el correo enviado en tu nombre.

Qué registros añadir

Primero da de alta el dominio en el panel: sección Email → «Sending domains» → botón «Add domain». El diálogo tiene tres campos: el dominio en sí (por ejemplo shop.example.com), la parte local de la dirección (lo que va antes de @, normalmente noreply) y el nombre del remitente, que el destinatario ve en lugar de una dirección. Al guardar aparecen en pantalla tus registros DNS.

Los tres son registros TXT en el DNS de tu dominio. Se añaden donde gestionas el dominio: el panel de tu registrador o tu proveedor de DNS.

Los valores de abajo usan example.com como ejemplo; sustitúyelo por el tuyo. Los valores exactos para tu dominio se muestran en la ficha del dominio en el panel: cópialos de allí, especialmente DKIM, cuyo valor contiene tu propia clave pública, distinta para cada dominio e imposible de sacar de la documentación.

En pantalla cada registro está partido en dos campos separados —«Host» y «Value»—, cada uno con su botón «Copy». Cópialos de uno en uno a los campos correspondientes de tu proveedor de DNS: las dos partes no se pegan como un bloque único.

Dos cosas con las que se tropieza más a menudo:

• Muchos paneles añaden el dominio al nombre por su cuenta. Si el campo del nombre ya muestra «.example.com», escribe solo mybot._domainkey y no el nombre completo; si no, acabarás con mybot._domainkey.example.com.example.com.
• El valor de DKIM es largo y no debe contener saltos de línea ni espacios dentro de la clave. Cópialo con el botón, no arrastrando con el ratón.

Si el dominio ya tiene un registro SPF

Un dominio solo puede tener un registro SPF. Si ya envías correo desde tu hosting, un CRM u otro servicio de boletines, ya lo tienes. No añadas un segundo: amplía el existente con otro include, antes del ~all final:

v=spf1 include:spf.tuproveedor.com include:esp.getmybot.dev ~all

Dos registros SPF en un dominio es el mismo fallo que ninguno: la verificación no pasa, porque el receptor no puede saber a cuál de los dos creer.

Ojo: estar «cubierto» a través del registro de otro no basta. Aunque tu proveedor actual nos incluya en su propio SPF, nuestro include tiene que estar en tu registro directamente; el porqué está más abajo, en la sección de verificación del dominio.

Por qué SPF lleva un include y no una dirección IP

El error más frecuente es pegar una dirección IP vista en la cabecera de un mensaje o en un foro. No lo hagas.

include:esp.getmybot.dev es un puntero a nuestra propia lista mantenida de servidores de envío. Hoy ese nombre resuelve a un único relé. Mañana pueden ser más, pueden mudarse o ser reemplazados. Cuando eso ocurra actualizaremos la lista por nuestro lado y tu registro seguirá funcionando sin que toques nada. Ese es todo el sentido: la dirección cambia en un solo lugar y no en el DNS de cada cliente.

Una IP escrita a mano deja simplemente de ser cierta en ese momento. El correo empieza a fallar SPF sin ningún aviso: ni error en el panel ni notificación. Te enteras por clientes que «no recibieron nada».

Escribe exactamente include:esp.getmybot.dev y no le añadas nada.

Verificación del dominio

Verificar el dominio es que la plataforma mire por sí misma el DNS de tu dominio y confirme que los tres registros están en orden. Si los tres pasan, el dominio queda verificado y se permite enviar. Mientras uno falle, queda pendiente.

Se comprueba bastante más que «el registro existe»:

Por qué DMARC se comprueba con menos rigor: indica a los receptores qué hacer con los resultados de DKIM y SPF, pero no nos otorga el derecho a enviar en tu nombre. Ese derecho lo dan solo los dos primeros registros, y ambos se comprueban por contenido de forma completa.

Un include ajeno no cuenta

include:esp.getmybot.dev debe estar en tu propio registro SPF. Si tu SPF incluye a un proveedor externo cuyo registro a su vez nos incluye, la verificación no lo aceptará: la plataforma no resuelve cadenas de includes ajenos. La razón es simple: así la respuesta a «¿este dominio concreto nos autorizó?» queda sin ambigüedad.

En la práctica: aunque estés convencido de estar «cubierto a través del proveedor», añade nuestro include directamente a tu propio registro. Eso mismo dice la propia pantalla en la explicación del registro SPF: si el dominio ya tiene un registro SPF, añádele el valor include:... en vez de reemplazar el registro entero, porque el dominio puede enviar correo también por otros medios. Ese aviso está siempre visible, no aparece solo tras una comprobación fallida.

El DNS no se actualiza al instante. Tras guardar los registros en el registrador tienen que propagarse por los servidores de nombres: normalmente minutos, a veces horas, ocasionalmente hasta un día. Depende de tu proveedor y del TTL. Es normal y no está en nuestra mano.

Aun así no hace falta esperar de brazos cruzados. La plataforma revisa los dominios pendientes una vez por hora, pero la ficha del dominio tiene el botón «Verify now»: la misma verificación ejecutada al momento, con el resultado en pantalla. Úsalo justo después de guardar los registros: si hay una errata te enteras en un segundo y no en una hora. Puedes repetirlo cuantas veces quieras.

El estado del dominio se ve en la ficha: «Pending verification», «Verified» o «Not verified». Mientras no esté verificado, la ficha muestra además el aviso «Sending from this domain is disabled until it is verified.»

El resultado no es un simple «no pasó». Cada uno de los tres registros tiene su propio estado en pantalla —«Passing», «Not passing» o «Not checked yet»— y su propia línea explicando qué falla.

Para SPF la pantalla distingue dos situaciones, y es la distinción que más importa en todo el proceso:

• El dominio no tiene ningún registro SPF. Publícalo, con el valor de la tabla de arriba.
• Existe un registro SPF pero no contiene nuestro include. Añade el include al registro existente: no crees un segundo ni lo reemplaces entero. El mismo mensaje contempla además el caso encadenado de forma explícita: si el include solo nos alcanza a través del registro SPF de otro proveedor, no cuenta, porque las cadenas no se resuelven.

El segundo caso es el momento más confuso de todo el proceso: el registro ya está ahí, acabas de releerlo tú mismo y la verificación sigue rechazándolo. El mensaje de error dice ahora exactamente lo mismo que el aviso siempre visible junto al registro: añade nuestro include a lo que ya tienes.

Si la verificación no pasa:

1. Lee cuál de los tres registros está marcado «Not passing» y qué dice su explicación, y actúa en consecuencia.
2. Asegúrate de que los registros están realmente publicados; muchos paneles exigen pulsar aparte «aplicar cambios».
3. Revisa el nombre del registro por si el dominio quedó duplicado (ver arriba).
4. Comprueba que solo hay un registro SPF y que nuestro include está dentro de ese mismo registro.
5. Espera un poco y vuelve a comprobar: puede que el cambio aún no se haya propagado.

Hasta la verificación el envío no funciona

Mientras el dominio no esté verificado, el correo no se envía. No «se envía y cae en spam»: no sale en absoluto, el intento falla con un error de dominio no verificado, visible en el registro.

Es deliberado y no es un fallo. El correo de un dominio que no ha respondido por sí mismo se convierte en quejas de spam, y las quejas dañan la reputación de una infraestructura de envío compartida por todos los clientes de la plataforma. Sale más barato no enviar un mensaje que enviarlo y pasar medio año saliendo de listas negras. De ahí la prohibición en lugar de un aviso.

Si ves este error, revisa los registros DNS y pulsa la comprobación antes de escribir a soporte. En la inmensa mayoría de los casos es una errata en el nombre de un registro.

Bajas, quejas y rebotes

Tres reglas que sorprenden si no se conocen de antemano.

Todo mensaje comercial lleva baja en un clic. La plataforma añade por su cuenta un enlace de baja en el pie y las cabeceras técnicas con las que el cliente de correo dibuja un botón «Cancelar suscripción» junto a la dirección del remitente. No se puede quitar: ni con un ajuste ni maquetando el mensaje. La baja surte efecto de inmediato, sin abrir el mensaje y sin paso de confirmación. Gmail y los demás grandes proveedores lo exigen a los remitentes masivos: un mensaje sin esa opción va a spam con toda seguridad.

La baja es definitiva y no se puede deshacer desde la interfaz. Una dirección dada de baja no recibe más correo de este bot. No hay botón de «restaurar» ni atajo vía reimportar una lista: la baja nunca se anula por encima de la persona. Volver solo puede hacerlo ella misma, apuntándose de nuevo en tu formulario de suscripción.

Hay un caso aún más estricto: si alguien pulsó «Esto es spam» en su cliente de correo, la dirección queda cerrada para siempre. Ni siquiera una nueva alta desde tu formulario la reabre, porque ya sabemos cómo terminó el intento anterior y escribir a esas direcciones es lo que más rápido destruye la reputación de un dominio. Las direcciones cerradas manualmente por requerimiento legal se comportan igual.

Un rebote duro suprime la dirección para siempre. Si el servidor del destinatario responde que ese buzón no existe, la dirección se marca como no entregable y se excluye de los envíos futuros. No es un estado temporal: seguir insistiendo con un buzón inexistente es la vía más rápida a los filtros de spam, arrastrando a todas las demás direcciones.

Los rebotes blandos (buzón lleno, servidor caído temporalmente) no cierran la dirección: el envío continúa.

Por qué las aperturas salen a la baja

La estadística de correo incluye una cifra de aperturas, y siempre es menor que la realidad. No es un error de conteo, sino cómo se miden las aperturas.

Una apertura se registra cuando el cliente de correo carga desde un servidor una imagen diminuta de seguimiento al mostrar el mensaje. Los clientes modernos no cargan imágenes remotas por defecto; y los que sí lo hacen (Apple Mail y funciones de privacidad similares) las cargan por adelantado para todo el mundo, incluidos quienes nunca abrieron el mensaje. En el primer caso la apertura se pierde; en el segundo se atribuye a alguien que no estuvo. No hay forma de contar aperturas con más precisión: ni nosotros ni nadie.

Por eso la interfaz lleva una advertencia junto a la cifra: es una cota inferior, no un número exacto. Úsala para comparar mensajes entre sí, donde la misma distorsión afecta a todos, pero no como respuesta a «cuánta gente leyó esto».

Si necesitas una métrica fiable de interés, mira «Link clicks». Un clic en un enlace es una acción real de una persona real; nadie la realiza por adelantado en su lugar. «Delivered», «Unsubscribes», «Complaints» y «Bounces» también se cuentan con exactitud: los reportan servidores de correo, no una imagen dentro de un mensaje. Todo ello está en el bloque «Sending stats» de la misma pantalla Email.

Qué sigue

• Canales — multicanalidad y capacidades de los canales.
• Difusiones — envío masivo de mensajes.
• Analítica — dónde ver las cifras.