Añadí el registro DKIM hace dos días y la consola de administración sigue diciéndome que actualice mis registros DNS. ¿Qué he roto?
Esto lo producen dos cosas distintas. La documentación de Google dice que el mensaje puede persistir hasta 48 horas después de añadir un registro correcto, así que muchas veces la consola sencillamente está desactualizada. La otra causa es saltarse el último clic: generar la clave y publicar el registro TXT no hace nada por sí solo, y el estado solo pasa a Autenticando correo electrónico con DKIM cuando vuelves a Autenticar correo electrónico, haces clic en Iniciar autenticación y Google verifica el registro.
La solución
Comprueba el registro publicado directamente con la herramienta Dig de Google Admin Toolbox en google._domainkey.yourdomain.com, en lugar de fiarte de la consola. Después envía un mensaje a una dirección externa y lee la cabecera Authentication-Results: un DKIM=pass con d= apuntando a tu propio dominio significa que el trabajo está hecho, diga lo que diga el aviso. Si el registro es correcto y ya has hecho clic en Iniciar autenticación, aguanta las 48 horas.
Mi registrador no acepta el valor de DKIM. No para de decirme que el registro es demasiado largo.
Una clave pública de 2048 bits supera el máximo de 255 caracteres de una sola cadena de caracteres DNS, así que la clave hay que guardarla como varias cadenas entrecomilladas dentro de un mismo registro TXT. Algunos paneles de control la parten por ti, otros rechazan la entrada de plano y otros la aceptan y la truncan en silencio, que es el peor caso: el registro existe, en el panel se ve bien y no valida nunca.
La solución
Parte tú mismo la clave en varias cadenas de texto, cada una entre sus propias comillas dentro del mismo registro TXT, que es exactamente lo que indica la página de resolución de problemas de DKIM de Google. Después verifica con Dig que lo que vuelve coincide carácter por carácter con el valor de la consola de administración. Si tu proveedor de verdad no puede guardarla, regenera la clave a 1024 bits, la opción que Google ofrece para los proveedores que no admiten claves de 2048 bits.
Nuestra aplicación debería enviar las facturas como billing@ourdomain.com, pero todo llega desde la cuenta de administrador con la que la configuramos.
La aplicación se está autenticando en smtp.gmail.com con la dirección de un usuario y una contraseña de aplicación. Google documenta que, por esa ruta, la dirección del From tiene que coincidir con la cuenta autenticada, así que cualquier otro From se sustituye. El correo se autentica y se entrega, sencillamente no sale de la dirección que esperan tus clientes, y las respuestas caen en el buzón equivocado.
La solución
Pasa la aplicación al servicio de retransmisión SMTP. En la consola de administración ve a Aplicaciones > Google Workspace > Gmail > Enrutamiento, configura el servicio de retransmisión SMTP y pon Remitentes permitidos en Solo direcciones de mis dominios para que la aplicación pueda enviar como billing@. Apunta la aplicación a smtp-relay.gmail.com en el puerto 587 con TLS y autentícala con Requerir autenticación SMTP o con la opción Aceptar solo correo de las direcciones IP especificadas. Ten en cuenta que las dos páginas de Google enuncian el techo de la retransmisión de forma distinta, una como 10.000 mensajes por usuario en un periodo de 24 horas y la otra como 10.000 destinatarios por usuario y día, así que dimensiona tus lotes contra la lectura más baja.
Gmail nos cortó durante un día y dijo que habíamos alcanzado un límite de envío. Apenas habíamos mandado 600 emails.
El tope que te paró probablemente no era el de mensajes. Una cuenta de pago de Workspace tiene 2.000 mensajes al día, pero solo 3.000 destinatarios externos y 2.000 destinatarios externos únicos, y los mensajes enviados por SMTP, POP o IMAP están limitados a 100 destinatarios cada uno. Una tanda de 600 mensajes que incluya listas de distribución revienta los contadores de destinatarios mucho antes que el de mensajes. Los límites corren sobre una ventana móvil de 24 horas, no sobre el día natural, así que a medianoche no se reinicia nada.
La solución
Cuenta destinatarios, no envíos, y averigua qué contador tocaste antes de cambiar nada. Si el volumen es real y recurrente, sácalo del buzón: la retransmisión SMTP permite 10.000 mensajes por usuario en 24 horas, y el marketing de verdad pertenece a una plataforma hecha para eso. En una cuenta de prueba, cuenta con 500 mensajes y 500 destinatarios únicos al día hasta que el dominio haya pagado $100 USD o el equivalente, y ten presente que Google dice que el aumento puede tardar hasta 75 días en aplicarse a partir de ese umbral.
Tenemos DKIM configurado en Google Workspace, pero nuestra newsletter sigue fallando DMARC.
La clave de Workspace solo firma el correo que sale de los servidores de Google. Una newsletter enviada desde una plataforma de marketing no toca esa clave jamás, así que necesita su propio registro DKIM publicado para tu dominio en el selector que te dé esa plataforma. La página de resolución de problemas de DMARC de Google te manda a la documentación del tercero precisamente para este caso. Lo mismo vale para las herramientas de soporte, los recibos de e-commerce, las notificaciones del CRM y cualquier otra cosa que envíe como tu dominio.
La solución
Haz inventario de todos los sistemas que envían como tu dominio y autentica cada uno: publica el registro DKIM de la plataforma en su propio selector y funde su mecanismo SPF dentro de tu registro SPF único. Usa los informes agregados DMARC que llegan a tu dirección rua para encontrar a los remitentes que se te olvidaron, que es justo para lo que sirven esos informes. Después manda un mensaje de prueba desde cada origen a una dirección de prueba, para leer el dominio d= de cada sistema en lugar de suponerlo.