SPF, DKIM y DMARC para Customer.io.
Customer.io autentica tu dominio a la antigua usanza, de forma transparente: sin asistente de un solo clic y sin delegación de todo a través de CNAME. Te entrega un pequeño conjunto de registros DNS que debes publicar en un subdominio de envío dedicado y luego los verifica. Añades un único registro MX con dos nombres de host (lo que le da a Customer.io un Return-Path personalizado en tu dominio para el feedback de rebotes y spam), un registro SPF TXT que usa el mecanismo compartido include:customeriomail.com y un registro DKIM TXT cuya clave genera Customer.io por ti. DMARC es un cuarto registro que añades tú mismo, en tu dominio raíz. Todo se gestiona en Workspace Settings, dentro de Email, en la página Sending Domains. Una vez que tanto SPF como DKIM aparecen en verde, Customer.io envía plenamente como tu propio dominio en lugar de apoyarse en customeriomail.com.
¿Por qué autenticar Customer.io?
Customer.io es una plataforma de mensajería basada en comportamiento y de alto volumen —newsletters, campañas de ciclo de vida, journeys transaccionales—, por lo que casi todas las cuentas superan los umbrales de remitente masivo que ahora deciden la ubicación en la bandeja de entrada. Desde febrero de 2024, Gmail y Yahoo exigen a todo remitente masivo (aproximadamente más de 5.000 mensajes al día) superar SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo al correo de alto volumen hacia Outlook.com/Hotmail/Live en 2025. Customer.io es más estricto que la mayoría de los ESP en esto: no enviará desde un dominio hasta que tanto SPF como DKIM estén verificados —un dominio sin autenticar sencillamente no puede enviar, y si más adelante cualquiera de los registros se rompe, las entregas fallan—. También hay una auténtica ventaja de alineación que merece la pena configurar. Como Customer.io aprovisiona un Return-Path personalizado en tu propio subdominio de envío (para eso está el registro MX), la comprobación SPF se ejecuta contra tu dominio, no solo contra customeriomail.com —así que, a diferencia de la configuración por defecto de Mailchimp o Klaviyo, donde solo DKIM puede sostener DMARC, un dominio de Customer.io correctamente configurado puede pasar DMARC por ambos mecanismos—. Esa es la configuración resiliente que sobrevive al reenvío, y significa que la reputación de envío que construyes se acumula en tu propio dominio.
La realidad del SPF con Customer.io
Customer.io es un auténtico proveedor de tipo «include»: publicas un único registro SPF TXT que contiene el mecanismo compartido include:customeriomail.com (el registro completo es v=spf1 include:customeriomail.com ~all, terminado en ~all exactamente como lo muestra el panel de Customer.io). Pero dos verdades específicas de Customer.io cambian dónde y cómo lo añades. Primera: este registro no va en tu dominio raíz —Customer.io recomienda (y en la práctica espera) un subdominio de envío dedicado como mail.tumarca.com o email.tumarca.com, y los registros SPF, DKIM y MX viven todos ahí—. Es deliberado: como el registro MX pone el Return-Path de Customer.io en tu subdominio, el remitente del sobre (envelope sender) está en tu dominio, de modo que SPF realmente SE ALINEA y puede contribuir a un pase de DMARC —algo que los ESP que poseen el Return-Path no pueden hacer—. Segunda: el include no es plano. Una consulta en vivo de customeriomail.com devuelve v=spf1 ip4:50.31.36.179 include:sendgrid.net ~all, y sendgrid.net a su vez anida include:ab.sendgrid.net —así que include:customeriomail.com se resuelve en unas 3 consultas DNS del límite de 10 de la RFC 7208, no en la 1 que afirman la mayoría de las guías—. Mantenerlo en su propio subdominio de envío aísla ese coste por completo del presupuesto SPF de tu dominio raíz, que es precisamente el objetivo del enfoque de subdominio. Mantén exactamente un registro SPF en el subdominio de envío y no fusiones otros remitentes en él —ese subdominio es de Customer.io—.
Dos formas de configurarlo
Subdominio de envío dedicado (recomendado)
- Todos los registros de Customer.io —MX, SPF y DKIM— viven en un único subdominio como mail.tumarca.com
- El Return-Path personalizado basado en MX se queda en el subdominio, así que nunca puede interferir con tu correo entrante principal
- El include:customeriomail.com anidado, de ~3 consultas, se mantiene fuera del presupuesto SPF de 10 consultas de tu dominio raíz
- El volumen de marketing/ciclo de vida construye reputación en un subdominio aislado, protegiendo tu dominio raíz
Autenticar tu dominio raíz (evítalo)
- Customer.io no requiere el dominio raíz y no lo recomienda
- El registro MX de dos hosts se situaría en tu raíz, compitiendo con tu MX entrante real
- El include anidado se come ~3 de las 10 consultas SPF de tu raíz junto a Google Workspace, M365 y todos los demás remitentes
- Un solo envío de marketing ruidoso puede arrastrar la reputación de envío de todo tu dominio
Paso a paso
- 1
Abre la página Sending Domains
Inicia sesión, haz clic en el icono de Settings y ve a Workspace Settings → Email → Sending Domains. Esta única página se encarga de añadir un dominio, revelar sus registros DNS y verificarlos. SPF, DKIM, MX y el CNAME de seguimiento de enlaces se muestran todos aquí; DMARC no —ese lo añades por separado en tu proveedor de DNS—.
- 2
Añade tu subdominio de envío
Haz clic en Add Sending Domain e introduce un subdominio dedicado, no tu raíz —mail.tumarca.com o email.tumarca.com es la convención—. Enviar desde un subdominio es lo que permite a Customer.io poner ahí un Return-Path personalizado, y mantiene el registro MX fuera de tu dominio raíz.
- 3
Revela los registros DNS
En la pestaña Authentication del dominio, Customer.io muestra los registros exactos que hay que publicar: un registro MX con dos nombres de host, un registro SPF TXT, un registro DKIM TXT (la clave se genera para tu cuenta) y —en la pestaña Link Tracking— un CNAME opcional para el seguimiento de enlaces de marca. Copia cada Host/Name y Value exactamente como se muestra; el selector DKIM y los dos nombres de host MX son específicos de tu cuenta.
- 4
Añade el registro MX de dos hosts
En tu proveedor de DNS, en el subdominio de envío (host mail), crea el único registro MX con ambos nombres de host que lista Customer.io, con la prioridad que especifica. Este MX existe solo para dar a Customer.io un Return-Path/dirección de rebote personalizado en tu dominio —no recibe tu correo normal, y como está en un subdominio no puede afectar a la entrega entrante a tu dominio raíz—.
- 5
Añade el registro SPF TXT
En el mismo subdominio (host mail), añade un registro TXT: v=spf1 include:customeriomail.com ~all. Mantén solo este único registro SPF en el subdominio y no le añadas los mecanismos de otros remitentes —este subdominio pertenece a Customer.io—. Termina en ~all como muestra el panel.
- 6
Añade el registro DKIM TXT
Añade el registro DKIM TXT exactamente como lo generó Customer.io: el host es un selector bajo tu subdominio (como selector._domainkey.mail) y el valor es v=DKIM1; k=rsa; p=<clave pública>. Es un registro TXT que pegas, no un CNAME —así que es estático, y Customer.io no lo rota en silencio por ti—.
- 7
Opcional: añade el CNAME de seguimiento de enlaces
Si quieres que los enlaces con seguimiento de clics lleven la marca de tu dominio en lugar de customeriomail.com, añade el CNAME que se muestra en la pestaña Link Tracking (un subdominio de seguimiento que apunta a Customer.io). No es obligatorio para la autenticación, pero omitirlo deja los enlaces rastreados en customeriomail.com, lo que debilita la alineación de marca.
- 8
Publica tu registro DMARC en la raíz
Customer.io nunca crea DMARC. Añade un registro TXT en _dmarc en tu dominio RAÍZ (no en el subdominio de envío): v=DMARC1; p=none; rua=mailto:dmarc@tumarca.com. p=none es solo de monitorización, así que nada cambia mientras confirmas la alineación; el subdominio de envío hereda esta política automáticamente.
- 9
Haz clic en Verify domain
De vuelta en la pestaña Authentication, haz clic en Verify (las marcas grises se ponen verdes cuando los registros se resuelven). La propagación suele ser de minutos, pero puede tardar hasta 24–48 horas. Necesitas marcas verdes concretamente en SPF y DKIM —Customer.io exige ambos de forma estricta antes de enviar desde el dominio; los registros MX y de seguimiento de enlaces sostienen el Return-Path y la marca, pero SPF+DKIM son la puerta—.
- 10
Envía una prueba y lee las cabeceras
Envía una campaña o un broadcast desde una dirección From del subdominio autenticado, ábrelo en Gmail y elige ⋮ → Show original. Confirma SPF: PASS (envelope en tu subdominio), DKIM: PASS con d=tumarca.com (no customeriomail.com) y DMARC: PASS. Después pasa el subdominio por un chequeo de salud del dominio para confirmar que todos los registros se resuelven.
Registros que añadir
Customer.io 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 |
|---|---|---|
| MX | mxa.customeriomail.comPrimero de dos nombres de host en un único registro MX —el Return-Path personalizado de Customer.io para el feedback de rebotes/spam, en el subdominio de envío—. Ilustrativo: copia los dos nombres de host exactos y la prioridad de la pestaña Authentication. | |
| MX | mxb.customeriomail.comSegundo nombre de host en el mismo registro MX. Ilustrativo —usa el valor y la prioridad exactos que muestra Customer.io—. | |
| TXT | v=spf1 include:customeriomail.com ~allSPF en el subdominio de envío —un registro SPF por host—. include:customeriomail.com se anida hasta ~3 consultas (vía sendgrid.net → ab.sendgrid.net); termina en ~all como muestra el panel. | |
| TXT | selector._domainkey.mail | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from Customer.io)DKIM TXT —Customer.io genera el par de claves y muestra el valor completo para pegar—. Ilustrativo: el selector y la clave reales son por cuenta, en la pestaña Authentication. Es un TXT estático, no un CNAME delegado. |
| CNAME | customeriomail.comSeguimiento de enlaces de marca opcional, en un subdominio de seguimiento —copia el host/destino exacto de la pestaña Link Tracking—. No es obligatorio para la verificación de SPF/DKIM. | |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.comEsto lo añades tú mismo en el dominio RAÍZ —Customer.io nunca lo crea—. Uno por dominio; el subdominio de envío lo hereda. Empieza en p=none. |
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 Customer.io consume de ese presupuesto.
Customer.io añade 3 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
El DKIM de Customer.io es un registro TXT que publicas tú, no un CNAME delegado. Cuando añades un dominio de envío, Customer.io genera un par de claves DKIM para él y te muestra un único registro DKIM TXT: el host es un selector bajo tu subdominio de envío (como selector._domainkey.mail.tumarca.com) y el valor es v=DKIM1; k=rsa; p=<clave pública>. Pegas ese TXT exactamente como se muestra; Customer.io conserva la clave privada correspondiente y firma tu correo saliente con ella como d=tumarca.com —de modo que la firma se alinea con tu dominio y puede sostener un pase de DMARC—. Dos cosas distinguen esto del DKIM delegado por CNAME que usan SendGrid o Microsoft 365. Primera: como es un registro TXT estático en lugar de un CNAME que apunta de vuelta al proveedor, Customer.io no rota la clave en silencio entre bastidores —si regeneras o rotas la clave en el panel, debes volver a publicar tú mismo el nuevo valor TXT, o la firma se rompe—. Segunda: aquí DKIM no es opcional ni un «mejor esfuerzo»: Customer.io exige que tanto SPF como DKIM se verifiquen antes de enviar desde el dominio siquiera, y si el DKIM TXT falta, está truncado o lo altera tu panel de DNS, el dominio vuelve a estado no verificado y las entregas se detienen. Publica el registro en el subdominio de envío exactamente como lo formatea Customer.io, espera a la propagación y luego pulsa Verify.
DMARC
DMARC es un registro de política aparte que Customer.io no crea por ti —lo publicas tú mismo, y va en tu dominio RAÍZ, no en el subdominio de envío—. Añade un registro TXT en _dmarc.tumarca.com que empiece por v=DMARC1; p=none; rua=mailto:dmarc@tumarca.com. p=none es solo de monitorización: no cambia nada en la entrega mientras los receptores te envían informes agregados (rua) para que puedas confirmar que Customer.io está pasando SPF y DKIM alineados con tu dominio. Aquí es donde el diseño de subdominio de Customer.io da sus frutos —DMARC usa alineación relajada por defecto (aspf=r, adkim=r), así que la firma DKIM en mail.tumarca.com y el SPF/Return-Path en ese subdominio se alinean ambos con tu dominio organizativo tumarca.com, y tu correo de Customer.io pasa DMARC por ambos mecanismos—. Mantén exactamente un registro _dmarc en la raíz; tu subdominio de envío hereda automáticamente la política del padre, así que no añadas un segundo registro _dmarc en el subdominio (añadir uno ahí es un error habitual que puede romper la herencia). Vigila los informes rua durante una o dos semanas hasta que todas las fuentes legítimas —Customer.io más tus otros remitentes— se estén autenticando, y luego endurece la política a p=quarantine y con el tiempo a p=reject.
Comprueba que de verdad funcionó
No te fíes solo de las marcas de verificación del panel —confírmalo en un mensaje real—. En la pestaña Authentication de Customer.io quieres marcas verdes en SPF y DKIM (los dos registros con los que Customer.io condiciona el envío); el MX sostiene el Return-Path y el CNAME sostiene los enlaces de marca. Después envía un broadcast o una campaña desde una dirección From del subdominio autenticado, ábrelo en Gmail y elige ⋮ → Show original: buscas SPF: PASS con el envelope/Return-Path en tu subdominio, DKIM: PASS firmado por d=tumarca.com (la señal reveladora de fallo es d=customeriomail.com, que significa que el DKIM personalizado no se aplicó) y DMARC: PASS. Comprueba puntualmente los registros en bruto con dig TXT mail.tumarca.com, dig TXT selector._domainkey.mail.tumarca.com y dig TXT _dmarc.tumarca.com. Por último, pasa el subdominio de envío por el chequeo de salud del dominio de Qualisend para confirmar que el SPF (y sus consultas anidadas), el DKIM TXT, el MX y tu DMARC raíz se resuelven todos limpiamente, y una vez que empiecen a llegar informes agregados, mete uno en el analizador de informes DMARC —Customer.io debería aparecer como una fuente alineada y que pasa—.
Errores habituales
- Rompe la autenticación
Customer.io exige de forma estricta que TANTO SPF como DKIM se verifiquen antes de enviar desde un dominio —la mayoría de los ESP envían con autenticación parcial, Customer.io no—. Si cualquiera de los registros falta o está alterado, el dominio aparece como no verificado y las entregas fallan, no solo se ven sin marca.
- Configuración de DNS
Publica todo en un SUBDOMINIO DE ENVÍO dedicado (mail.tumarca.com), nunca en tu raíz. El registro MX de dos hosts en particular debe quedarse en el subdominio —ponlo en tu raíz y redirigirías la gestión de rebotes de todo tu dominio y pondrías en riesgo tu correo entrante real—.
- Cobertura
El registro MX no es para recibir tu correo normal —existe solo para dar a Customer.io un Return-Path personalizado en tu dominio para el feedback de rebotes y spam—. No te alarmes pensando que estás «cambiando tu MX»; está en un subdominio que ningún buzón humano usa.
- Configuración de DNS
include:customeriomail.com NO es una única consulta DNS —una consulta en vivo lo muestra anidando include:sendgrid.net, que anida include:ab.sendgrid.net, así que se resuelve en unas 3 consultas—. En un subdominio dedicado eso queda aislado; si alguna vez lo metes en un SPF raíz compartido, compite con todos los demás remitentes contra el límite de 10 consultas.
- Configuración de DNS
Aquí el DKIM es un registro TXT estático, no un CNAME que se auto-rota. Customer.io no lo rota por ti —si regeneras la clave en el panel, debes volver a publicar el nuevo valor TXT o la firma se rompe—.
- Configuración de DNS
Duplicación del campo de host en subdominios: muchos registradores auto-añaden tu zona, así que introducir mail.tumarca.com produce mail.tumarca.com.tumarca.com. Introduce solo la etiqueta que espera el panel (mail, selector._domainkey.mail) si te añade el dominio automáticamente.
- Cobertura
Pon DMARC en la RAÍZ (_dmarc.tumarca.com), no en el subdominio de envío. El subdominio hereda la política de la raíz mediante alineación relajada; añadir un segundo _dmarc en el subdominio es un error habitual que puede romper la herencia.
- Configuración de DNS
Omitir el CNAME de seguimiento de enlaces está bien para la autenticación, pero tus enlaces con seguimiento de clics se quedan en customeriomail.com en vez de en tu dominio —lo que debilita la alineación de marca y puede resultar menos fiable para destinatarios y filtros—.
Crea tu registro SPF
Customer.io no necesita un include: de SPF en tu dominio raíz: usa el generador para ensamblar un único registro limpio para tus otros remitentes y mantenlo en una sola línea.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
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).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- 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 Customer.io — 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.