Nuevo en la biblioteca: Una reserva, dos cosas que tienen que estar libres a la vez. Leer el artículo
yodai Academia Dominio y correo

Academia Publicar Dominio y correo

Por qué no puedes usar la misma firma para todo lo que envías

Sabes identificar cada servicio que manda correo en tu nombre, darle su propia firma sin tocar las demás, y mantener un único SPF que las reúne a todas.

5 min de lectura

Ya ampliaste tu SPF para que reservas y facturas cupieran en el mismo permiso; toca decidir quién firma cada una. Configuraste tu dominio para que los correos de tu buzón normal llegaran bien, y funciona: el presupuesto que mandas por Gmail no cae en spam. Meses después conectas un sistema de reservas que manda la confirmación de la cita en tu nombre, y esa sí se pierde la mitad de las veces. Miras la configuración del dominio y no ha cambiado nada raro. El problema no está en lo que ves: está en que dejaste que el sistema de reservas se apoyara en la misma firma que ya tenías activada para el correo normal, pensando que con una bastaba para todo lo que sale de tu dominio.

Ya sabes que el permiso que le diste a tu web para el formulario de contacto no le vale a tu factura. La razón de fondo es la misma en los dos casos: cada cosa que manda correo en tu nombre necesita su propia firma, no la de otra.

Cada remitente firma con su propia llave

Firmar un correo con DKIM es como plantar un sello dentro del mensaje que solo puede poner quien tiene la llave, y cada aparato que manda correo tiene la suya, no la tuya. Cuando activas DKIM para tu buzón normal, ese buzón recibe una llave privada que nadie más conoce, y en tu dominio dejas la mitad pública para que cualquiera pueda comprobar que el sello es auténtico.

Si después un sistema de reservas manda un correo diciendo que viene de tu dominio pero firma con una llave que nunca registraste para él —o, peor, con la llave que le diste a tu buzón— quien recibe el correo comprueba el sello y no coincide. No es un fallo de conexión ni de contenido: es que ese remitente en concreto nunca quedó autorizado a firmar en tu nombre.

Compartir la firma o activar una por servicio
Copiar o compartir la firma de otro servicio
  • Parece más rápido: no hay que volver a entrar en el DNS
  • Funciona mientras solo mande el primer servicio
  • En cuanto el segundo servicio manda algo, no coincide la llave y lo penalizan
  • Si dejas de usar uno, no sabes qué tocar sin arriesgar los demás
Activar una firma propia por servicio
  • Diez minutos más la primera vez que sumas cada uno
  • Cada servicio entra y sale del DNS sin tocar los demás
  • Si algo falla, sabes exactamente qué registro mirar
  • Puedes retirar uno solo el día que dejes de usarlo, sin tocar el resto

Cual elijo: Activa una firma propia siempre que el remitente sea distinto. Solo comparten firma dos envíos que salen literalmente del mismo motor, por ejemplo dos plantillas distintas dentro del mismo proveedor de correo transaccional.

Cada vez que sumas un remitente nuevo
  1. 1Haz la lista de quién manda en tu nombre
    Tu buzón normal, el formulario de tu web, el sistema de reservas, el programa de facturación. Cualquiera que mande un correo con tu dominio en el remitente cuenta.
  2. 2Busca "autenticar dominio" en ese servicio, no en otro
    Cada servicio tiene su propia pantalla donde te entrega los registros que necesita. Los del sistema de reservas no sirven para el de facturación.
  3. 3Pega sus registros, no los de otro servicio
    Normalmente son dos o tres líneas con un nombre parecido a un código. Van a tu DNS tal cual te las da ese servicio en concreto.
  4. 4Súmalo a tu SPF, no lo sustituyas
    Añade su nombre dentro del único registro SPF que ya tienes activado. No crees uno nuevo ni borres el que había.
  5. 5Manda una prueba y léela remitente por remitente
    Un correo de prueba a una cuenta tuya te dice si ese remitente en concreto pasa DKIM y SPF. Compruébalo uno a uno, no todos a la vez.
Copiar el registro para ir más rápido
El error más caro es coger el registro DKIM que te dio el primer servicio y pegarlo también para el segundo, pensando que "ya está autenticado el dominio". La firma no autentica el dominio en general: autentica a ese remitente en concreto. El segundo servicio firma con una llave que no coincide con lo que pegaste, lo detectan como sospechoso y lo mandan a spam o lo rechazan directamente. Como el primer servicio sigue funcionando sin problema, tardas semanas en notar que el que falla es el segundo.

Un SPF, no una lista de SPF

El SPF funciona distinto: no es una firma por mensaje, es una lista de quién tiene permiso para mandar correo con tu dominio en el remitente. Esa lista vive en un único registro de tu dominio, y solo puede haber uno. Si en algún momento añades un segundo registro SPF pensando que así sumas el nuevo servicio, quien recibe el correo ve dos listas contradictorias y descarta las dos: el primer servicio, que llevaba meses funcionando, deja de pasar también.

Por eso, cada vez que sumas un remitente no tocas la firma DKIM de los demás, pero sí tocas ese SPF: añades el nombre del nuevo servicio dentro de la misma línea, con la palabra include delante.

Cómo se ve un SPF con varios remitentes
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all — ahí dentro convive tu correo normal (Google), tu sistema de reservas (SendGrid) y tu facturación (Mailgun), todos en el mismo registro, uno detrás de otro.
Lo que te llevas
  • Tienes la lista de todo lo que manda correo en tu nombre: buzón, web, reservas, facturación
  • Cada uno de esos servicios tiene su propia firma DKIM activada, sin copiar la de ningún otro
  • Tu dominio tiene un único registro SPF con todos ellos metidos dentro como include
  • La próxima vez que sumes un servicio nuevo, sabes que toca repetir este mismo paso, no reutilizar el de otro
  • Lo siguiente en el curso: la regla que conviene esperar a activar, no ponerla el primer día
SiguienteQuién puede entrar hoy en tu dominio y tu correo sin pedirte permiso