SPF, DKIM y DMARC para Zendesk.
Zendesk envía tus respuestas a tickets, notificaciones y automatizaciones desde tu dirección de soporte (support@yourdomain.com), así que autenticarlo es lo que evita que esos mensajes acaben en las carpetas de spam de tus clientes o luzcan una etiqueta "via zendesk.com". La autenticación se reparte entre tu proveedor de DNS y el Admin Center de Zendesk. SPF es un include compartido de verdad — añades include:mail.zendesk.com al único registro SPF de tu dominio — y DKIM son dos registros CNAME de "firma digital" que publicas y luego activas en Channels → Talk and email → Email. DMARC es un tercer registro aparte que Zendesk nunca crea por ti. Hay un requisito previo que importa: la autenticación DNS solo se aplica cuando envías desde un dominio de correo externo tuyo; las direcciones del dominio por defecto yourbrand.zendesk.com ya vienen firmadas por Zendesk y no necesitan nada.
¿Por qué autenticar Zendesk?
Autenticar Zendesk no es cuestión de mantenimiento — decide si tus respuestas de soporte llegan siquiera a los clientes. Una cola de soporte con mucho movimiento supera con facilidad el umbral de 5.000 mensajes al día que, desde febrero de 2024, obliga a los remitentes masivos de Gmail y Yahoo a pasar SPF, DKIM y DMARC con alineación; Microsoft empezó a aplicar reglas similares para remitentes de alto volumen en 2025. Hasta que autentiques un dominio de soporte externo, Zendesk envía respuestas que solo se te atribuyen débilmente: los destinatarios ven una nota "via zendesk.com", tu dirección From no es criptográficamente tuya, DMARC no puede pasar, y cualquier queja por spam se acumula contra la infraestructura compartida de Zendesk en lugar de construir tu propia reputación. Además hay un matiz específico de Zendesk que hace que DKIM sea innegociable aquí: el SPF de Zendesk nunca se alinea con tu dominio (rebota el correo en su propio Return-Path de zendesk.com), así que a diferencia de Google Workspace o Microsoft 365, no puedes apoyarte en SPF para llevar DMARC — DKIM es el único mecanismo que se alinea. Configura el include de SPF, los dos CNAME de DKIM y una política DMARC, y tus respuestas saldrán firmadas como tu propio dominio, la etiqueta "via" desaparecerá, DMARC pasará, y la reputación que ganes será tuya.
La realidad del SPF con Zendesk
Zendesk es un proveedor de tipo "include" de verdad — añades un mecanismo compartido real, include:mail.zendesk.com, al único registro SPF TXT de tu dominio, y Zendesk recomienda oficialmente el registro completo v=spf1 include:mail.zendesk.com -all (recomienda el fallo estricto -all para la máxima protección antisuplantación). Verificado contra DNS en vivo, mail.zendesk.com se resuelve en un registro plano que contiene solo rangos ip4: y su propio ~all, sin includes anidados, así que cuesta exactamente UNA de tus 10 búsquedas DNS de SPF. Aquí viene la parte que casi todos los tutoriales se saltan, y es lo más importante que hay que entender sobre el SPF de Zendesk: pasa pero NO se ALINEA. Por defecto, Zendesk envía el correo saliente con el Return-Path del sobre (el MAIL FROM contra el que los receptores ejecutan realmente el SPF) en uno de los propios dominios de rebote zendesk.com de Zendesk, no en tu dominio — y Zendesk no ofrece ningún mecanismo para mover ese Return-Path a tu dominio. Así que SPF se autentica contra la infraestructura de Zendesk y pasa, pero como el dominio comprobado es un subdominio de zendesk.com en lugar de tu dominio From, no está alineado, y DMARC solo cuenta el SPF cuando está alineado. Eso significa que include:mail.zendesk.com no puede llevar por sí solo un DMARC en estado pass. Aun así merece la pena añadirlo — Zendesk lo recomienda, algunos receptores hacen una comprobación de SPF no alineado sobre el dominio From visible, y evita los rebotes relacionados con SPF y el envío a la carpeta de spam — pero el mecanismo que de verdad hace que DMARC pase para Zendesk es la alineación de DKIM, no la de SPF. Mantén exactamente un registro SPF en el dominio (fusiona el include si ya envías vía Google Workspace, Microsoft 365, etc.), conserva include:mail.zendesk.com como mecanismo de primera capa en ese registro, y empieza con ~all en lugar de -all hasta que hayas enumerado todos los demás remitentes legítimos.
Dos formas de configurarlo
Dominio de correo externo — include de SPF + DKIM (recomendado)
- Las respuestas salen de tu propia marca (support@yourdomain.com), no de una dirección de zendesk.com
- DKIM firma como d=yourdomain.com, así que DMARC pasa por alineación de DKIM
- Añade include:mail.zendesk.com más los dos CNAME de DKIM zendesk1/zendesk2 a tu DNS
- Cuesta una búsqueda DNS de SPF; las claves rotan automáticamente una vez que los CNAME están activos
Dirección por defecto yourbrand.zendesk.com — nada que configurar
- Zendesk ya autentica y firma su propio dominio zendesk.com
- Ningún registro SPF, DKIM ni DMARC que tengas que publicar
- Pero los clientes ven una dirección From genérica de zendesk.com en lugar de tu marca
- Sin control sobre la reputación — compartes el dominio de Zendesk con todos los demás inquilinos
Paso a paso
- 1
Añade y verifica tu dirección de soporte externa
En el Admin Center, abre Channels → Talk and email → Email y añade una dirección de soporte en tu propio dominio (p. ej. support@yourdomain.com), luego verifícala — bien reenviando el correo entrante de ese buzón a tu dirección yourbrand.zendesk.com, o conectando Google Workspace / Microsoft 365. Esto importa porque la autenticación DNS (include de SPF + CNAME de DKIM) solo se aplica a dominios externos; las direcciones del dominio por defecto yourbrand.zendesk.com ya vienen firmadas por Zendesk.
- 2
Añade o fusiona el include de SPF
En tu dominio raíz, añade un registro TXT con v=spf1 include:mail.zendesk.com -all (Zendesk recomienda el fallo estricto -all). Si ya existe un registro SPF, no publiques un segundo — fusiona include:mail.zendesk.com en la línea v=spf1 existente, manteniéndolo como mecanismo de primera capa, y usa ~all hasta que todos los demás remitentes estén listados.
- 3
Añade los dos registros CNAME de DKIM
Crea dos registros CNAME: host zendesk1._domainkey.yourdomain.com apuntando a zendesk1._domainkey.zendesk.com, y host zendesk2._domainkey.yourdomain.com apuntando a zendesk2._domainkey.zendesk.com. Hay dos porque Zendesk rota las claves de DKIM por seguridad. Deben ser registros CNAME, no TXT — Zendesk guarda las claves detrás de esos nombres de host.
- 4
Publica un registro DMARC
Añade un registro TXT en _dmarc.yourdomain.com con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización — no cambia nada en la entrega mientras confirmas que Zendesk está pasando DKIM alineado con tu dominio. Mantén un único registro _dmarc para todo el dominio.
- 5
Espera a que los registros se propaguen
Da al DNS unas horas (a veces hasta un día) para propagarse antes del siguiente paso. NO actives todavía la firma DKIM en Zendesk — activarla antes de que los CNAME resuelvan es la causa más común de los fallos de entrega en Zendesk.
- 6
Activa la firma DKIM (debe ser el paso final)
De vuelta en Admin Center → Channels → Talk and email → Email, encuentra el ajuste de DKIM / firma digital y selecciona Custom domain for DKIM, luego haz clic en Save. Zendesk es explícito en que esto debe ser lo último que hagas: activarlo antes de que los registros CNAME de tu dominio estén activos provocará fallos de entrega.
- 7
Envía una respuesta de prueba y lee las cabeceras
Responde a un ticket de prueba para que Zendesk envíe un mensaje saliente real, ábrelo en Gmail y usa ⋮ → Show original. Confirma DKIM: PASS firmado por yourdomain.com (selector zendesk1 o zendesk2) y DMARC: PASS. SPF mostrará pass pero no alineado (Return-Path en un dominio de zendesk.com) — eso es lo esperado y correcto; DKIM es quien lleva DMARC.
- 8
Repite para cada marca y dominio de soporte
Cada dirección de soporte externa en un dominio distinto necesita su propio include de SPF, sus propios CNAME de DKIM zendesk1/zendesk2, su propio registro DMARC, y la opción Custom domain for DKIM activada. Autenticar un dominio no cubre los demás.
Registros que añadir
Zendesk genera los valores exactos en su asistente de configuración; estos muestran la forma de lo que añadirás en tu proveedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:mail.zendesk.com -allSPF raíz — mantén un único registro SPF y fusiona include:mail.zendesk.com en él. Pasa pero NO se alinea (el Return-Path de Zendesk es un dominio de zendesk.com), así que no lleva DMARC por sí solo. Cuesta 1 búsqueda DNS. |
| CNAME | zendesk1._domainkey | zendesk1._domainkey.zendesk.comClave DKIM 1. Este destino es el mismo para todos los clientes de Zendesk (no es un valor por cuenta); solo el dominio del host es tuyo. Zendesk rota la clave que hay detrás automáticamente. |
| CNAME | zendesk2._domainkey | zendesk2._domainkey.zendesk.comClave DKIM 2 — ambas son obligatorias porque Zendesk rota las claves. También es un destino compartido, idéntico para todos los clientes. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn registro DMARC por dominio. Esto es lo que lleva el DMARC pass de Zendesk — mediante la alineación de DKIM. Empieza en p=none, luego endurece a quarantine/reject una vez confirmado DKIM. |
Mantén exactamente un registro TXT de SPF (v=spf1) en tu dominio raíz: fusiona en él todos los remitentes. Tener dos registros SPF es en sí mismo un error.
El presupuesto de 10 consultas
El SPF tiene un límite estricto de 10 consultas DNS: si lo superas, devuelve un permerror y deja de validar en todas partes. Esto es lo que la configuración de Zendesk consume de ese presupuesto.
Zendesk añade 1 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
DKIM es donde el correo de Zendesk se gana de verdad su DMARC pass, así que es el registro que más importa. Publicas dos registros CNAME — zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.com y zendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.com — y luego activas la firma en el Admin Center. Hay unas cuantas cosas específicas de Zendesk que conviene saber. Primero, estos son CNAME, no claves TXT que pegas: Zendesk guarda las claves privadas y publica las claves públicas detrás de zendesk1._domainkey.zendesk.com y zendesk2._domainkey.zendesk.com, así que puede rotarlas (aproximadamente cada trimestre) sin que tú vuelvas a tocar el DNS nunca más — la búsqueda del CNAME siempre resuelve a la clave vigente. Segundo, ambos nombres de host apuntan a los mismos destinos compartidos de zendesk.com para todos los clientes; no hay un valor por cuenta, así que no intentes personalizar el destino ni pegar un ID de cuenta en él. La razón de que haya dos selectores (zendesk1 y zendesk2) es precisamente para que esa rotación sea transparente — uno está activo mientras el otro se prepara. Tercero, DKIM solo funciona para un dominio de correo externo; no puedes firmar con DKIM como tu propio dominio el correo enviado desde una dirección yourbrand.zendesk.com. Por último, publicar los CNAME no hace nada hasta que activas la firma: ve a Admin Center → Channels → Talk and email → Email y selecciona Custom domain for DKIM, luego Save — pero solo después de que los CNAME se hayan propagado, porque activarlo antes de tiempo provoca fallos de entrega. Una vez en funcionamiento, Zendesk firma con d=yourdomain.com, que se alinea con tu dominio From y pasa DMARC.
DMARC
DMARC es un registro de política aparte que Zendesk nunca crea por ti — lo publicas tú mismo como un registro TXT en _dmarc.yourdomain.com, empezando por v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización: no cambia nada en la entrega, pero pide a los receptores que te envíen informes agregados para que puedas confirmar que el correo de Zendesk está pasando. La salvedad específica de Zendesk es que tu DMARC pass depende por completo de DKIM, porque el SPF de Zendesk nunca se alinea (su Return-Path vive en un dominio de rebote de zendesk.com). Así que antes de endurecer la política, usa los informes rua para asegurarte de que Zendesk aparece como alineado con DKIM y pasando — si saltas a p=quarantine o p=reject mientras DKIM está mal configurado, SPF no puede cubrirlo y tus respuestas de soporte empezarán a ir a cuarentena o a ser rechazadas. Vigila los informes durante una o dos semanas, confirma que Zendesk y todos los demás remitentes legítimos se alinean, y luego pasa a p=quarantine y finalmente a p=reject. Mantén exactamente un registro _dmarc para todo el dominio por muchos remitentes que tengas; nunca añadas un segundo solo para Zendesk.
Comprueba que de verdad funcionó
No te fíes solo del estado que muestra el Admin Center — confírmalo en un mensaje real. Responde a un ticket de prueba para que Zendesk envíe un correo saliente desde tu dirección de soporte externa, ábrelo en Gmail y elige ⋮ → Show original. Quieres ver DKIM: PASS con signed-by: yourdomain.com (selector zendesk1 o zendesk2) y DMARC: PASS. SPF marcará pass pero no alineado — el mailed-by/Return-Path será un dominio de zendesk.com — y eso es lo esperado en Zendesk, no un error de configuración, así que no persigas la alineación de SPF. Puedes hacer una comprobación puntual de los registros en crudo con dig CNAME zendesk1._domainkey.yourdomain.com (debería resolver hasta zendesk.com) y dig TXT _dmarc.yourdomain.com. Luego pasa tu dominio por el análisis de salud del dominio de Qualisend para confirmar que todos los registros resuelven y que tu SPF se mantiene por debajo del límite de 10 búsquedas, y en cuanto empiecen a llegar los informes agregados de DMARC, mete uno en el analizador de informes DMARC — Zendesk debería aparecer como fuente alineada con DKIM y pasando, aunque su SPF esté sin alinear.
Errores habituales
- Configuración de DNS
Activa DKIM al final. Zendesk es explícito en que seleccionar Custom domain for DKIM antes de que tus CNAME zendesk1/zendesk2 se hayan propagado provocará fallos de entrega — publica y deja que el DNS se asiente (de unas horas a un día) primero, y luego activa el interruptor.
- Cobertura
SPF no se alineará, por diseño. Zendesk rebota el correo saliente en su propio Return-Path de zendesk.com, así que include:mail.zendesk.com hace que la comprobación cruda de SPF pase pero nunca se alinea con tu dominio ni puede llevar DMARC por sí solo. DKIM es lo que se alinea — no pierdas el tiempo intentando forzar la alineación de SPF; Zendesk no ofrece forma de hacerlo.
- Cobertura
DKIM solo funciona en un dominio de correo externo. El correo enviado desde una dirección yourbrand.zendesk.com no puede firmarse como tu dominio — primero debes añadir y verificar una dirección de soporte en tu propio dominio (support@yourdomain.com).
- Configuración de DNS
Los destinos CNAME de DKIM son compartidos, no únicos. Ambos apuntan a zendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.com para todos los clientes de Zendesk — no intentes añadir un ID de cuenta ni 'personalizar' el destino, y no los publiques como registros TXT.
- Rompe la autenticación
Mantén exactamente un registro SPF y conserva el include en la primera capa. Si ya envías vía Google Workspace, Microsoft 365, etc., fusiona include:mail.zendesk.com en esa única línea v=spf1 — dos registros SPF son un PermError, y enterrar el include dentro de una búsqueda anidada puede impedir que resuelva en la primera capa.
- Cobertura
-all vs ~all. Zendesk recomienda el fallo estricto -all, pero si tu SPF aún no lista todos los remitentes legítimos, -all hará fallar de forma estricta ese otro correo. Usa ~all hasta que hayas enumerado todos los remitentes, y luego endurece a -all.
- Configuración de DNS
Duplicación del campo de host. Muchos registradores añaden automáticamente tu dominio, así que introducir zendesk1._domainkey.yourdomain.com produce zendesk1._domainkey.yourdomain.com.yourdomain.com. Introduce solo la etiqueta zendesk1._domainkey si el panel añade el dominio por ti.
- Configuración de DNS
Varias marcas y dominios necesitan cada uno el conjunto completo. Cada dominio de soporte externo necesita su propio include de SPF, sus propios dos CNAME de DKIM, su propio registro DMARC, y Custom domain for DKIM activado — la configuración de un dominio no cubre los demás.
Crea tu registro SPF
Zendesk ya viene preseleccionado abajo. Añade cualquier otra plataforma desde la que envíes y luego publica el registro fusionado único.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF de Zendesk — Preguntas frecuentes
Lecturas relacionadas
Una vez publicado, confirma que todo se resuelve con el chequeo de salud del dominio y luego averigua quién envía en tu nombre con el analizador de informes DMARC. Explora todas las fuentes de envío en el generador. Eso sí, la autenticación es solo la mitad de la entregabilidad: una IP o un dominio de envío incluidos en una lista negra te llevan igualmente a spam por muy limpio que esté tu SPF, así que conviene vigilar las listas negras con monitorización de listas negras.
Autenticado: ahora mantén la lista limpia
Pasar SPF, DKIM y DMARC te lleva a la bandeja de entrada; una lista limpia te mantiene ahí. Verifica la tuya: empieza gratis con 100 créditos, sin tarjeta.