SPF, DKIM y DMARC para SparkPost.
SparkPost (ahora parte de Bird, antes MessageBird) autentica tu dominio desde Configuration → Sending Domains, donde genera una clave DKIM que publicas como registro TXT en tu dominio de envío. Esa firma DKIM —firmada como d=yourdomain.com— es el mecanismo que realmente hace que tu DMARC pase. El SPF es el matiz específico de SparkPost: por defecto, SparkPost envía el bounce/envelope desde su propio dominio compartido (sparkpostmail.com), de modo que una comprobación SPF sencilla pasa en el dominio de SparkPost, pero nunca se alinea con el tuyo. La solución es un Bounce Domain personalizado —un CNAME que apunta un subdominio tuyo a sparkpostmail.com y se convierte en tu Return-Path, para que el SPF también se alinee. Añade un registro de política DMARC y tendrás los tres, alineados, sin haber añadido nada a tu SPF raíz.
¿Por qué autenticar SparkPost?
Autenticar tu dominio de SparkPost no es una tarea de mantenimiento cualquiera: decide si tu correo transaccional y de marketing de alto volumen llega siquiera a la bandeja de entrada. Desde febrero de 2024, Gmail y Yahoo exigen que todo remitente masivo (aproximadamente 5.000+ mensajes al día) pase SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo en las bandejas de consumidor de Outlook/Hotmail/Live en 2025 —exactamente los volúmenes para los que SparkPost está diseñado. Hasta que autentiques, SparkPost firma tu correo con una clave compartida y lo devuelve (bounce) desde sparkpostmail.com: tu dirección From no es criptográficamente tuya, DMARC no puede pasar y tu reputación queda mezclada con la de cualquier otro remitente sin autenticar de esa infraestructura. Hay un giro específico de SparkPost que hace que DKIM sea innegociable: como SparkPost es el propietario del Return-Path por defecto, el SPF pasa pero no se alinea con tu dominio, así que DKIM es el único mecanismo que sostiene tu paso de DMARC hasta que también configures un bounce domain personalizado. Configurar DKIM más un bounce domain alinea ambos mecanismos contigo, elimina las dudas que los receptores tienen sobre tu identidad, permite que DMARC pase y construye reputación de envío bajo tu propio nombre en lugar del grupo compartido.
La realidad del SPF con SparkPost
SparkPost es nominalmente un proveedor de tipo "include" —include:sparkpostmail.com (e include:_spf.sparkpostmail.com, que resuelve al registro idéntico) existen ambos y se verifican por DNS—, pero añadir ese include a tu SPF raíz es una práctica heredada y NO hace que DMARC pase. Aquí está el porqué. El registro real es v=spf1 exists:%{i}._spf.sparkpostmail.com ~all —una macro exists: que autoriza las IP de salida de SparkPost por IP (%{i} es la IP de envío, comprobada contra una zona comodín) en lugar de listar rangos ip4: fijos. El SPF siempre se evalúa contra el dominio del MAIL FROM / Return-Path del envelope, y por defecto ese dominio es sparkpostmail.com, propiedad de SparkPost. Así que el SPF resuelve y pasa en el dominio de SparkPost, pero nunca se alinea con tu dominio From organizativo —y DMARC solo cuenta el SPF cuando está alineado. Publicar include:sparkpostmail.com en tu propio dominio raíz no cambia esto, porque tu dominio raíz nunca es el dominio del envelope; solo quema dos de tus diez búsquedas SPF (el include en sí más el mecanismo exists anidado dentro del registro de sparkpostmail.com) sin ningún beneficio de alineación. La ruta SPF alineada es un Bounce Domain personalizado: apuntas un subdominio tuyo (p. ej. bounces.yourdomain.com) a sparkpostmail.com con un CNAME, SparkPost usa ese subdominio como Return-Path, y ahora la comprobación SPF se ejecuta contra tu subdominio (alineado en modo relajado con tu dominio organizativo) mientras sigue heredando el SPF de sparkpostmail.com vía el CNAME. Por eso el propio flujo de SparkPost te da un registro TXT de DKIM y un CNAME de bounce domain, no una línea SPF para pegar en tu apex. Reserva tu registro SPF raíz para los remitentes que realmente ponen tu dominio en el Return-Path (Google Workspace, Microsoft 365, un relay que controles), y deja que el CNAME de bounce + DKIM hagan el trabajo de SparkPost.
Dos formas de configurarlo
Bounce domain personalizado + DKIM (recomendado, alineado)
- El TXT de DKIM con un selector scph firma el correo como d=yourdomain.com —el mecanismo que realmente hace pasar DMARC
- Un CNAME de bounce domain personalizado (p. ej. bounces.yourdomain.com → sparkpostmail.com) hace que el SPF también se alinee con tu dominio
- Añade cero búsquedas DNS a tu SPF raíz —el registro de bounce vive en su propio subdominio, no en tu apex
- Funciona igual en SparkPost US y EU (EU solo apunta el CNAME a eu.sparkpostmail.com)
Include SPF en la raíz (heredado, no alinea)
- Añades tú mismo v=spf1 include:sparkpostmail.com ~all a tu SPF raíz
- SparkPost es propietario del envelope (bounce por defecto = sparkpostmail.com), así que este SPF nunca se alinea con tu dominio
- No hace nada por DMARC —DKIM y el bounce domain siguen haciendo todo el trabajo
- Cuesta dos de tus 10 búsquedas SPF (el include más el mecanismo exists anidado) sin beneficio de alineación; es seguro dejarlo fuera por completo
Paso a paso
- 1
Abre Sending Domains y añade tu dominio
Inicia sesión en SparkPost (app.sparkpost.com, o app.eu.sparkpost.com para cuentas de EU) y ve a Configuration → Sending Domains → Add Domain. Introduce el dominio o subdominio desde el que enviarás (un subdominio como mail.yourdomain.com es habitual y mantiene la reputación de envío separada) y guarda.
- 2
Copia el registro DKIM que genera SparkPost
En la pantalla de configuración del dominio, SparkPost muestra un registro DKIM bajo 'Set up for DKIM signing'. Es un registro TXT: el host es un selector autogenerado como scph0421._domainkey.yourdomain.com y el valor empieza por v=DKIM1; k=rsa; h=sha256; p=… seguido de tu clave pública. SparkPost usa por defecto una clave de 2048 bits, así que el valor es largo —cópialo todo exactamente.
- 3
Publica el registro TXT de DKIM
En tu proveedor de DNS, crea un registro TXT con host scph0421._domainkey (bajo tu dominio/subdominio de envío) y pega el valor completo v=DKIM1… Mantenlo como registro TXT —el DKIM de SparkPost no es un CNAME. Como es una clave de 2048 bits, algunos paneles limitan una cadena TXT a 255 caracteres y te obligan a dividirla en varias cadenas entrecomilladas —divídela, no elimines caracteres. Si tu panel añade el dominio automáticamente, introduce solo la etiqueta (scph0421._domainkey) para evitar duplicarlo.
- 4
Verifica el dominio de envío
De vuelta en la pantalla de Sending Domains, marca la casilla que confirma que añadiste el registro y haz clic en Verify Domain. Una vez que resuelva, el dominio figura como verificado y 'DKIM Signing' aparece como listo —SparkPost no firmará con tu clave hasta que esto cambie. La propagación suele ser de minutos, pero puede tardar hasta 24–48 horas.
- 5
Añade un Bounce Domain personalizado
Ve a Configuration → Bounce Domains (o elige la opción Bounce Domain al añadir un dominio) y añade un subdominio que sea propietario del Return-Path —p. ej. bounces.yourdomain.com para alineación relajada, o reutiliza tu subdominio de envío exacto (mail.yourdomain.com) para alineación estricta. Este es el paso que te da la alineación SPF.
- 6
Publica el CNAME del bounce domain
Crea un registro CNAME: host = tu subdominio de bounce (bounces), valor = sparkpostmail.com (para SparkPost EU, apúntalo a eu.sparkpostmail.com en su lugar). En Cloudflare, configura el registro como 'DNS only' (nube gris) —un CNAME con proxy de nube naranja no resolverá a SparkPost y la verificación fallará.
- 7
Verifica el bounce domain
Vuelve a Bounce Domains y haz clic para verificar. Una vez en verde, SparkPost usa tu subdominio como el MAIL FROM del envelope, de modo que el SPF ahora pasa Y se alinea con tu dominio organizativo —un segundo mecanismo alineado junto a DKIM.
- 8
Añade un registro de política DMARC
SparkPost no crea el DMARC por ti. Añade un registro TXT en el host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización, así que nada cambia en la entrega mientras confirmas que SparkPost pasa SPF y DKIM alineados; lo endurecerás más adelante.
- 9
Envía una prueba y lee las cabeceras
Envíate un mensaje a través de SparkPost desde una dirección del dominio autenticado, ábrelo en Gmail y elige ⋮ → Mostrar original. Quieres ver DKIM: PASS firmado por yourdomain.com (selector scph…), SPF: PASS con el mailfrom en tu subdominio de bounce (no sparkpostmail.com), y DMARC: PASS. Después confirma que cada registro resuelve con una comprobación de salud del dominio.
Registros que añadir
SparkPost 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 | scph0421._domainkey | v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIM —el mecanismo alineado que hace pasar DMARC. El selector scph se autogenera por cuenta (p. ej. scph0421, scph0717); valor ilustrativo —copia el registro exacto desde Configuration → Sending Domains. SparkPost usa por defecto una clave de 2048 bits, así que divídela en varias cadenas entrecomilladas si tu panel limita el TXT a 255 caracteres. Publícalo bajo tu dominio/subdominio de envío, p. ej. scph0421._domainkey.mail.yourdomain.com. |
| CNAME | bounces | sparkpostmail.comBounce Domain personalizado (Return-Path) —esto es lo que hace que el SPF SE ALINEE con tu dominio. Usa un subdominio, no tu apex. SparkPost EU apunta esto a eu.sparkpostmail.com. Configura 'DNS only' (nube gris) en Cloudflare. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comEsto lo añades tú mismo —SparkPost nunca lo crea. Uno por dominio; empieza en p=none, luego sube gradualmente a quarantine/reject. |
| TXT | @ | v=spf1 include:sparkpostmail.com ~allHEREDADO / OPCIONAL —NO crea alineación DMARC porque SparkPost es propietario del envelope. El CNAME de bounce de arriba es la ruta SPF alineada; añade esto solo si quieres que tu SPF en bruto haga referencia a SparkPost, y si lo haces, fusiónalo en tu único registro SPF raíz. Cuesta dos búsquedas —el include más la macro exists anidada dentro del registro de sparkpostmail.com. |
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 SparkPost consume de ese presupuesto.
La configuración recomendada de SparkPost añade 0 consultas: las 10 quedan libres para los remitentes que sí necesitan un include.
DKIM
DKIM es el registro que carga todo el peso en SparkPost, porque es el mecanismo que se alinea por defecto. Cuando añades un dominio de envío, SparkPost genera un par de claves RSA (2048 bits por defecto) y te muestra un registro TXT para publicar: el host es un selector autogenerado con la forma scphNNNN._domainkey.yourdomain.com (por ejemplo scph0421._domainkey —los cuatro dígitos se asignan por cuenta/clave), y el valor es v=DKIM1; k=rsa; h=sha256; p=<tu clave pública>. Publicas ese TXT en tu proveedor de DNS; SparkPost conserva la clave privada correspondiente y firma con ella cada mensaje de salida, de modo que la firma DKIM lleva d=yourdomain.com y se alinea con tu dirección From. Dos cosas distinguen el DKIM de SparkPost de los proveedores que delegan por CNAME (SendGrid, Mailchimp, Klaviyo). Primero, es un registro TXT que pegas —no un CNAME— así que publicar un CNAME donde se espera el TXT de scph romperá la firma; mantén el tipo de registro como TXT. Segundo, como tú conservas la clave publicada en lugar de delegarla, no hay rotación de claves automática: si alguna vez necesitas rotar, generas una clave nueva en SparkPost y republicas tú mismo el nuevo TXT de scph. Un detalle práctico del valor por defecto de 2048 bits: la clave pública supera el límite de 255 caracteres de una única cadena TXT, así que muchos paneles de DNS te obligan a dividirla en varias cadenas entrecomilladas (SparkPost puede emitir una clave de 1024 bits en su lugar si tu proveedor no admite TXT de varias cadenas). Publicar el registro no basta por sí solo —debes volver a Configuration → Sending Domains y hacer clic en Verify Domain para que el dominio figure como verificado y 'DKIM Signing' aparezca como listo; SparkPost no firmará con tu clave hasta que eso cambie.
DMARC
DMARC es un registro de política aparte que añades tú mismo —SparkPost no lo crea. Publica un registro TXT en _dmarc.yourdomain.com que empiece por v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización: no cambia nada en la entrega mientras los receptores te envían por correo informes agregados (rua) para que puedas confirmar que el correo de SparkPost está pasando SPF y DKIM alineados con tu dominio. Aquí es donde la configuración en dos partes de SparkPost da sus frutos —una vez que tu registro DKIM scph esté verificado obtienes alineación DKIM, y una vez que tu bounce domain personalizado esté verificado obtienes también alineación SPF, de modo que un dominio de SparkPost bien configurado pasa DMARC en ambos mecanismos en lugar de apoyarse solo en DKIM. Vigila los informes durante una o dos semanas, asegúrate de que todo remitente legítimo (SparkPost más cualquier otro que uses) se está autenticando, y luego endurece a p=quarantine y finalmente p=reject. Mantén exactamente un registro _dmarc para todo el dominio organizativo, sin importar cuántos remitentes tengas —nunca publiques un segundo registro DMARC específico para SparkPost.
Comprueba que de verdad funcionó
No te fíes solo de las marcas verdes del panel —confírmalo en un mensaje real. Envíate una prueba a través de SparkPost desde una dirección del dominio autenticado, ábrela en Gmail y elige ⋮ → Mostrar original. Quieres ver DKIM: PASS firmado por yourdomain.com con el selector scph (no un dominio compartido de SparkPost), SPF: PASS donde el mailfrom/Return-Path muestra tu subdominio de bounce (bounces.yourdomain.com —la señal delatora de un fallo es un mailfrom que sigue en sparkpostmail.com, lo que significa que tu bounce domain personalizado no está configurado), y DMARC: PASS. En SparkPost, Configuration → Sending Domains debería mostrar el dominio verificado con DKIM Signing listo, y Bounce Domains debería mostrar tu subdominio de bounce verificado. Después pasa tu dominio por la comprobación de salud del dominio de Qualisend para confirmar que el TXT de DKIM, el CNAME de bounce y el registro DMARC resuelven todos sin problemas, y en cuanto empiecen a llegar los informes agregados de DMARC, mete uno en el analizador de informes DMARC —SparkPost debería aparecer como una fuente alineada y que pasa.
Errores habituales
- Configuración de DNS
La gran trampa: añadir include:sparkpostmail.com a tu SPF raíz NO hace que DMARC pase. SparkPost es propietario del envelope (bounce domain por defecto = sparkpostmail.com), así que tu SPF raíz nunca se consulta para el correo de SparkPost. La alineación viene del TXT de DKIM scph más un CNAME de bounce domain personalizado —no de un include SPF.
- Cobertura
Con el bounce domain por defecto, el SPF pasa en sparkpostmail.com pero no se alinea contigo, así que DMARC se apoya por completo en DKIM. Añade un Bounce Domain personalizado para tener un segundo mecanismo alineado y sobrevivir a receptores más estrictos.
- Configuración de DNS
El DKIM de SparkPost es un registro TXT (selector scph), no un CNAME. No cambies el tipo —un CNAME donde debería ir el TXT de scph rompe la firma DKIM. Y no hay rotación de claves automática: para rotar, genera una clave nueva en SparkPost y republica el TXT.
- Configuración de DNS
SparkPost usa por defecto una clave DKIM de 2048 bits, cuyo valor es más largo que el límite TXT de 255 caracteres. Algunos paneles de DNS te obligan a dividirla en varias cadenas entrecomilladas —divídela, no la trunques ni añadas espacios sueltos dentro del valor p=.
- Configuración de DNS
El proxy de Cloudflare rompe el CNAME de bounce. Configura el registro del bounce domain como 'DNS only' (nube gris) —un CNAME con proxy de nube naranja no resolverá a sparkpostmail.com y el dominio no se verificará.
- Configuración de DNS
No puedes usar tu raíz/apex como bounce domain —un CNAME en el apex colisiona con tus otros registros. Usa un subdominio (bounces.yourdomain.com para alineación relajada, o reutiliza tu subdominio de envío exacto para alineación estricta).
- Configuración de DNS
SparkPost EU es un stack separado: inicia sesión en app.eu.sparkpost.com, envía vía smtp.eu.sparkpostmail.com / api.eu.sparkpost.com y apunta el CNAME de bounce a eu.sparkpostmail.com (no sparkpostmail.com). El mismo dominio en US y EU son dos registros independientes con sus propios registros DNS.
- Rompe la autenticación
Mantén exactamente un TXT de SPF y un TXT de _dmarc en tu dominio. Si por algún motivo conservas el include heredado de SparkPost, fusiónalo en tu única línea v=spf1 —dos registros SPF son en sí mismos un PermError.
- Configuración de DNS
Verifica en el panel tras publicar —SparkPost no firmará con DKIM hasta que Configuration → Sending Domains muestre el dominio verificado. La propagación puede tardar hasta 24–48 horas; si la verificación se atasca, vuelve a revisar el host del registro por si hay un dominio añadido/duplicado.
Crea tu registro SPF
SparkPost 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 SparkPost — 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.