¿Necesito SPF y DKIM si Tiendanube envía desde su propia dirección?

No. Mientras la tienda envía desde una dirección del dominio de Tiendanube, la autenticación de ellos cubre esos correos y tu DNS no participa. Los registros se vuelven necesarios en el momento en que cambias el remitente a una dirección de tu propio dominio, porque ahí eres tú quien responde por un servidor que no administras.

¿Por qué dejó de funcionar el correo de mi empresa después de conectar el dominio a la tienda?

Conectar un dominio a Tiendanube cambia su configuración de DNS, y su centro de ayuda advierte que el correo de ese dominio deja de enviarse y recibirse de inmediato si no vuelves a crear tus registros MX, TXT y CNAME en la zona nueva. Recupera los valores originales, publícalos donde ahora vive el DNS autoritativo, y el correo regresa cuando propague el cambio.

¿Puedo saltarme DMARC y quedarme solo con SPF y DKIM?

Puedes enviar correo sin él, pero pierdes el único canal de retroalimentación que te muestra qué sistemas envían como tu dominio, y sigues siendo suplantable. Google además exige SPF, DKIM y DMARC juntos a quienes envían 5,000 mensajes o más por día a cuentas personales de Gmail. Publicar p=none no cuesta nada y no bloquea nada.

Tiendanube: SPF, DKIM y DMARC paso a paso

Qué envía tu tienda en tu nombre

Tiendanube manda correos sin que tú hagas nada. Confirmación de compra, cuenta creada, pago recibido, pedido en camino: la plataforma genera esos mensajes y se los entrega a un servicio de correo. De fábrica salen desde una dirección del dominio de Tiendanube, y funciona bien. Simplemente no es tu marca.

En el momento en que cambias el remitente a una dirección de tu propio dominio, la responsabilidad pasa a ser tuya. Le estás diciendo a Gmail, a Outlook y a todos los demás que un servidor que no es tuyo tiene permiso para enviar correo con tu nombre. Si tu DNS nunca lo declara, el receptor ve un mensaje sin autenticar que dice venir de tu dominio y lo trata como tal. La propia ayuda de Tiendanube lo dice sin rodeos: publica los registros SPF y DKIM para que las cuentas destinatarias reconozcan tus correos y dejen de caer en spam.

Hay un detalle que explica casi todo lo que sigue. El correo transaccional de Tiendanube sale a través de Amazon SES, y por eso sus instrucciones te piden agregar include:amazonses.com a tu registro SPF en lugar de un dominio propio de ellos.

Antes que nada: conectar tu dominio puede dejarte sin correo

Este es el paso que le cuesta días a la gente, y ocurre antes de que la autenticación siquiera entre en escena.

Cuando conectas tu dominio a Tiendanube, la configuración de DNS de ese dominio cambia. Su centro de ayuda es explícito sobre lo que eso implica: si ya usas cuentas profesionales en ese dominio con un servicio como Google Workspace o Zoho, no hagas la vinculación sin antes tener tus registros DNS a la mano, porque dejarás de enviar y recibir mensajes de inmediato.

Así que primero haz un inventario. Abre tu zona DNS actual y anota, carácter por carácter:

cada registro MX con su valor de prioridad
cada registro TXT, en especial el que empieza con v=spf1 y cualquier cosa publicada en _dmarc
cada CNAME relacionado con correo, que es donde suele vivir el DKIM
cualquier registro de un subdominio que use tu webmail, tu CRM o tu sistema de facturación

Después decide quién administra la zona luego del cambio y vuelve a crear esos registros ahí el mismo día. Una tienda que sale al aire mientras el correo del dueño está muerto es un mal negocio.

Dónde agregas los registros depende de tu dominio

La guía de Tiendanube para esto aplica a clientes con dominios terminados en .ar, .co o .cl que ya apuntaron ese dominio a Tiendanube usando sus registros DNS. Si tu dominio es de otro tipo, la plataforma te indica agregar los registros SPF y DKIM directamente en el hosting externo donde realmente vive tu DNS.

Los valores son los mismos en ambos casos. Lo que cambia es el panel. Averigua en cuál estás antes de empezar a hacer clic, porque editar la zona equivocada produce registros que se ven perfectos y no hacen absolutamente nada.

SPF: fusiona Amazon SES con el registro que ya tienes

Un dominio lleva exactamente un registro SPF. Publicar un segundo no suma cobertura, invalida los dos, y los receptores tratan el resultado como un error permanente. Esta es la forma más común en que un dueño de tienda rompe el correo que ya le funcionaba.

La instrucción de Tiendanube va en esa línea: edita la zona DNS de tu dominio, busca el registro TXT que comienza con v=spf1 y agrega include:amazonses.com antes del ~all final. Si todavía no tienes ningún SPF, lo creas. Si ya tienes uno, lo extiendes.

Con Google Workspace sosteniendo tus casillas y Tiendanube enviando el correo de la tienda, el registro fusionado queda así:

Tipo:   TXT
Nombre: @
Valor:  v=spf1 include:_spf.google.com include:amazonses.com ~all

Si en cambio usas Zoho Mail, Zoho te pide actualizar tu registro existente con include:zoho.com, de modo que el mismo dominio termina con:

Tipo:   TXT
Nombre: @
Valor:  v=spf1 include:zoho.com include:amazonses.com ~all

Ahora la parte que casi ninguna guía menciona. SPF se evalúa contra el remitente del sobre, la dirección que el servidor emisor declara durante la conversación SMTP, no contra el From que lee tu cliente. Cuando una plataforma envía en tu nombre y conserva su propia ruta de retorno, tu include autoriza la entrega, pero el dominio que SPF validó es el de la plataforma, no el tuyo. Eso deja a DMARC insatisfecho, porque DMARC quiere que el dominio autenticado coincida con el del From. Justamente por eso el siguiente paso no es opcional.

DKIM: el registro que Tiendanube genera para ti

En el administrador de tu tienda entra a Dominios y abre Configuración de correo electrónico. La pantalla siguiente te muestra un registro DKIM: un nombre TXT y un valor TXT generados para tu dominio. Según las propias instrucciones de Tiendanube, les envías esos dos datos en forma de texto a su equipo de soporte y ellos hacen la configuración correspondiente en sus servidores de envío.

DKIM es lo que te cruza la meta aquí. Firma el mensaje con una llave publicada bajo tu dominio, así la firma y la dirección del From coinciden, y DMARC tiene algo alineado con qué aprobar. Donde SPF se pone incómodo con remitentes de terceros, DKIM es directo.

Mantén esto separado en tu cabeza del DKIM de tu proveedor de casillas, porque vas a tener los dos al mismo tiempo y no se estorban. Google Workspace genera su llave en la consola de administración y la publica bajo el selector google por defecto, así que el registro queda en google._domainkey, y Google recomienda la opción de 2048 bits cuando tu proveedor de DNS la soporta. Zoho publica bajo un selector que tú eliges, comúnmente zmail, así que el nombre del host es zmail._domainkey, y después de guardarlo haces clic en Verificar en la consola de Zoho y esperas de 12 a 24 horas según tu TTL.

Dos remitentes, dos llaves, dos selectores, un dominio. Ese es el resultado normal y correcto.

Zoho Mail o Google Workspace conviviendo con la tienda

Tiendanube no te da casillas de correo con tu dominio propio. Su centro de ayuda lo dice sin ambigüedad: ese servicio lo contratas por fuera. Así que la forma habitual en una tienda pequeña es un proveedor de casillas para las personas y Tiendanube para el correo automático de la tienda, ambos autenticados sobre el mismo dominio.

Dos cosas que vigilar cuando apilas remitentes. Primero, cada uno necesita su propia llave DKIM, no solo una mención en SPF. Segundo, SPF tiene un presupuesto duro de diez consultas DNS, y cada include gasta al menos una. Dos remitentes es cómodo. Agrega una herramienta de newsletter, un proveedor de facturación y un CRM y cruzas la línea sin darte cuenta, momento en el cual el registro completo falla. Si andas cerca, lee nuestra guía sobre cómo bajar de las diez consultas DNS en SPF antes de agregar cualquier otra cosa.

DMARC, paso a paso

DMARC amarra las dos piezas. Le dice a los receptores qué hacer cuando un mensaje dice venir de tu dominio pero ni SPF ni DKIM pasan de una forma que coincida con ese dominio, y les pide que te manden reportes de lo que vieron. La alineación es la idea completa: no basta con que SPF o DKIM pasen, el dominio que pasó tiene que ser el dominio del From.

Empieza en modo monitoreo. Publica esto y no cambies nada más:

Tipo:   TXT
Nombre: _dmarc
Valor:  v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; fo=1

Con p=none no se bloquea nada. Los reportes empiezan a llegar en uno o dos días, y te van a mostrar todos los sistemas que envían como tu dominio, incluida esa herramienta de facturación que nadie recordaba. Dale dos semanas, confirma que el correo de la tienda y el de tus casillas aparecen alineados, y recién ahí sube a p=quarantine, y solo después a p=reject.

Hay una fecha límite escondida aquí para quien hace marketing por correo desde la tienda. Google exige que todo remitente tenga SPF o DKIM configurado, y a quienes envían 5,000 mensajes o más por día a cuentas personales de Gmail les exige SPF, DKIM y DMARC, mantener la tasa de spam reportada en Postmaster Tools por debajo del 0.30 por ciento, y soportar la baja en un clic en los mensajes de marketing. Las confirmaciones de pedido rara vez llegan a ese volumen. Una campaña a tu lista de clientes sí puede.

Mercado Shops: mismas reglas, otro panel

Si tu tienda corre en Mercado Shops en lugar de Tiendanube, nada de los estándares cambia. Sigues conectando un dominio, lo que sigue moviendo o alterando la delegación de DNS, lo que sigue poniendo en riesgo tus registros MX y TXT actuales si no los anotaste antes. Sigues necesitando un solo registro SPF fusionado que cubra a todo lo que envía en tu nombre, una llave DKIM por cada remitente, y un registro DMARC en _dmarc.

Lo que cambia es dónde documenta la plataforma su servicio de envío y qué valores te pide publicar. Sácalos de Mercado Shops directamente en lugar de asumir que el include de Tiendanube aplica, y luego sigue el mismo orden: inventario, SPF, DKIM, DMARC en p=none, leer reportes, endurecer.

Verifica en vez de suponer

Los paneles de DNS son excelentes aceptando registros sutilmente equivocados. Así que revisa el resultado publicado, no el formulario que llenaste.

Consulta los registros TXT de tu dominio y confirma que hay exactamente una entrada v=spf1 y que contiene a todos los remitentes que esperas. Consulta _dmarc y confirma que la política está ahí. Después haz un pedido real en tu propia tienda, abre el correo de confirmación en Gmail y lee la cabecera Authentication-Results: quieres ver SPF o DKIM en pass con tu dominio, y DMARC en pass. Nuestro diagnóstico de correo gratuito revisa la parte de DNS en segundos, y el analizador de cabeceras decodifica lo que realmente devolvió el mensaje.

Los errores que más tiempo cuestan

Dos registros SPF. Agregaste una nueva línea v=spf1 en lugar de editar la existente. Fusiónalas en una sola y borra la sobrante.
El registro en el nombre equivocado. Muchos paneles de DNS agregan el dominio automáticamente, así que escribir zmail._domainkey.tudominio.com produce un registro en zmail._domainkey.tudominio.com.tudominio.com. Escribe solo la parte del host y revisa el resultado guardado.
DMARC en la raíz. El registro de política va en _dmarc, nunca en @.
Editar la zona que ya no controlas. Después de conectar el dominio a la plataforma de la tienda, el DNS autoritativo pudo haberse movido. Los registros agregados en el proveedor anterior no hacen nada.
Ir directo a p=reject. Endurecer antes de leer reportes es la forma en que las facturas y las confirmaciones de pedido empiezan a desaparecer en silencio.

Cómo ayuda Guanacos Tech

La mayoría de los dueños de tienda que vemos no hicieron nada mal. Conectaron un dominio a una plataforma que reescribió el DNS, y el correo que antes funcionaba dejó de funcionar, y como los dos eventos ocurrieron con una semana de diferencia nadie los relacionó. Nosotros mapeamos cada sistema que envía como tu dominio, publicamos un solo registro SPF que los cubra a todos sin reventar el presupuesto de consultas, dejamos DKIM firmando en cada remitente, y llevamos DMARC de monitoreo a aplicación leyendo los reportes contigo. Si tus confirmaciones de pedido están cayendo en spam, o tu bandeja se quedó muda después de migrar la tienda, agenda una llamada y lo rastreamos juntos.

Tiendanube: cómo configurar SPF, DKIM y DMARC para que tus correos con dominio propio no lleguen a spam