SPF, DKIM y DMARC para SMTP.com.
SMTP.com es un relay SMTP y una API de correo: apuntas tu aplicación, CRM o servidor de correo hacia él y entrega en tu nombre, por lo que tu propio dominio tiene que autorizarlo. La configuración son tres registros DNS más un interruptor del lado de la cuenta: un include SPF genuino (include:_spf.smtp.com) que fusionas en tu SPF raíz, un CNAME de DKIM de dominio personalizado en el selector smtpkey que SMTP.com también debe habilitar en tu cuenta para que el correo firme como tu dominio en lugar del suyo compartido, y un registro de política DMARC que publicas tú mismo. Alinea los tres y SMTP.com hará el relay totalmente autenticado como tú, con DKIM alineado a tu dominio del From para que DMARC pase en lugar de apoyarse en el dominio de firma compartido de SMTP.com.
¿Por qué autenticar SMTP.com?
Autenticar el dominio a través del cual haces relay con SMTP.com decide si tu correo llega a la bandeja de entrada, y para un relay de alto volumen lo que está en juego es mayor que para un proveedor de buzones. 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 al correo de alto volumen hacia Outlook.com/Hotmail/Live en 2025, exactamente los volúmenes por los que la gente usa SMTP.com. El matiz específico del relay: de fábrica, SMTP.com firma con DKIM tu correo saliente usando uno de sus propios dominios compartidos (d=smtpsend.com) y gestiona los rebotes en su propio return-path, así que ni SPF ni DKIM se alinean con tu dominio del From. Eso significa que un dominio de SMTP.com sin configurar no tiene ningún mecanismo alineado: DMARC no puede pasar, los receptores pueden mostrar una nota «via smtpsend.com» y la reputación de envío que estás pagando por construir se mezcla con la de cualquier otro remitente no autenticado en la infraestructura compartida. Habilitar el include SPF y, sobre todo, el DKIM de dominio personalizado es lo que hace que el correo sea criptográficamente tuyo, hace que DMARC pase y permite que la reputación se acumule bajo tu propio dominio.
La realidad del SPF con SMTP.com
SMTP.com es un auténtico proveedor de tipo «include»: añades un mecanismo compartido, include:_spf.smtp.com, al único registro SPF TXT de tu dominio raíz, dando v=spf1 include:_spf.smtp.com ~all. Es un include compartido real —todos los clientes de SMTP.com usan el mismo— y es ligero: el include se resuelve en un registro plano que contiene solo dos rangos IPv4 y su propio softfail (v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all), de modo que cuesta solo UNA de tus 10 búsquedas DNS de SPF, no las dos o tres que reportan algunos verificadores con caché. Aquí está, no obstante, el matiz honesto que despista a la gente: añadir este include autoriza las IP de envío de SMTP.com, pero no hace, por sí solo, que DMARC pase. Por defecto, SMTP.com hace relay con su propio dominio de remitente de sobre / return-path (procesa tus rebotes), y SPF se evalúa siempre contra ese dominio de sobre, así que la comprobación pasa contra la infraestructura de SMTP.com en lugar de alinearse con tu dominio del From. El include sigue siendo el paso SPF correcto, documentado y recomendado (evita fallos SPF en crudo y es lo que espera la configuración de SMTP.com), por lo que deberías publicarlo, pero el mecanismo que realmente lleva tu aprobación de DMARC es el CNAME de DKIM de dominio personalizado, que firma como d=yourdomain.com. Trata el include como necesario pero no suficiente: publícalo y luego apóyate en DKIM para la alineación (la única otra vía hacia un SPF alineado es concertar con SMTP.com un dominio de return-path/rebotes personalizado en tu propio dominio, algo que la mayoría de las cuentas omiten en favor de DKIM). Y mantén exactamente un registro SPF en el dominio: si también envías a través de Google Workspace, Microsoft 365 u otra herramienta, fusiona include:_spf.smtp.com en esa única línea v=spf1 en lugar de publicar un segundo SPF TXT (dos registros SPF son un PermError).
Paso a paso
- 1
Identifica el dominio con el que haces relay
Inicia sesión en el Panel de control de SMTP.com y anota el dominio del From con el que envía tu aplicación/API (el dominio de tu cabecera From:, p. ej. yourdomain.com). SMTP.com hace relay del correo para cualquier dirección From que configures, así que la autenticación se hace sobre ese dominio organizativo, no sobre un host propiedad de SMTP.com. Aquí también viven tus credenciales de Sender/relay y los ajustes de Reputation Defender.
- 2
Añade o fusiona el include SPF
En tu proveedor de DNS, crea UN registro TXT en la raíz (host @ o en blanco) con v=spf1 include:_spf.smtp.com ~all. Si ya existe un registro v=spf1 (Google Workspace, Microsoft 365, otro relay), no añadas un segundo: fusiona include:_spf.smtp.com en ese único registro junto a los demás mecanismos. Mantén el softfail ~all que usa SMTP.com salvo que estés seguro de que todos los remitentes están listados.
- 3
Activa la firma DKIM de dominio personalizado
Por defecto, SMTP.com firma con su dominio compartido (d=smtpsend.com), que NO se alinea. Para que el correo se firme como d=yourdomain.com en el selector smtpkey, la firma DKIM de dominio personalizado tiene que estar habilitada en tu cuenta: este es un interruptor del lado de la cuenta, así que solicítalo a través del soporte de SMTP.com o de tu gestor de cuenta y confirma el selector/destino exacto que te asignen (el par ampliamente publicado está más abajo).
- 4
Añade el CNAME de DKIM
Crea un registro CNAME: host smtpkey._domainkey (para que sea smtpkey._domainkey.yourdomain.com) apuntando a smtpcustomer._domainkey.smtpsend.com. Esto es una delegación: SMTP.com conserva la clave privada detrás de ese destino compartido y firma en tu nombre. Mantén el tipo como CNAME; no lo cambies a TXT ni a A.
- 5
Publica el registro DMARC
SMTP.com no crea 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 de la entrega cambia mientras confirmas que el correo de SMTP.com está firmando y alineando; lo endurecerás más adelante.
- 6
Corrige el doblado del host y el proxy de Cloudflare
Si tu registrador añade el dominio automáticamente, introduce solo la etiqueta (smtpkey._domainkey, y @ para SPF) para no acabar con smtpkey._domainkey.yourdomain.com.yourdomain.com. En Cloudflare, pon el CNAME de DKIM en «DNS only» (nube gris): un CNAME con proxy en nube naranja no se resolverá a smtpsend.com y la validación de DKIM falla.
- 7
Envía una prueba y lee las cabeceras
Una vez que el DKIM personalizado esté habilitado y los registros se propaguen (normalmente minutos, hasta 24–72 horas), haz relay de una prueba a través de SMTP.com a una dirección de Gmail, ábrela y elige ⋮ → Mostrar original. Quieres DKIM: PASS con d=yourdomain.com y selector smtpkey (el fallo revelador es d=smtpsend.com, que significa que la firma personalizada aún no está activa), SPF: PASS y DMARC: PASS.
- 8
Confirma que todos los registros se resuelven
Pasa tu dominio por la verificación de salud del dominio de Qualisend para confirmar que el SPF se mantiene en un registro por debajo del límite de 10 búsquedas, que el CNAME smtpkey._domainkey se resuelve a smtpsend.com y que el registro DMARC está presente. Una vez que empiecen a llegar los informes agregados, deja caer uno en el analizador de informes DMARC para ver aparecer a SMTP.com como una fuente alineada y que pasa.
Registros que añadir
SMTP.com 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:_spf.smtp.com ~allSPF raíz: mantén exactamente UN registro SPF; fusiona este include si ya tienes una línea v=spf1. include:_spf.smtp.com se resuelve plano (dos rangos ip4 + ~all) así que cuesta 1 búsqueda DNS. Autoriza las IP de SMTP.com pero no se alinea por defecto. |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comDKIM de dominio personalizado (el mecanismo alineado). Ilustrativo: este es el destino compartido ampliamente documentado, pero confirma el selector/destino exacto que SMTP.com asigna a tu cuenta. SMTP.com TAMBIÉN debe habilitar la firma personalizada del lado de la cuenta, o el CNAME no hace nada. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comEsto lo añades tú mismo: SMTP.com nunca lo crea. Un registro DMARC por dominio; empieza en p=none y luego endurece a quarantine/reject una vez que DKIM se alinee limpiamente. |
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 SMTP.com consume de ese presupuesto.
SMTP.com añade 1 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
DKIM es la parte que realmente te gana la aprobación de DMARC con SMTP.com, y es el paso que la mayoría de la gente se salta porque SMTP.com «ya está firmando» antes de que hagas nada, solo que con el dominio equivocado. Por defecto, el relay firma con DKIM tu correo saliente usando uno de sus propios dominios compartidos (d=smtpsend.com). Esa firma es criptográficamente válida, pero como no es tu dominio no se alinea, así que no hace nada por DMARC en yourdomain.com. Para arreglarlo, habilitas el DKIM de dominio personalizado, que son dos acciones coordinadas: (1) publicar un CNAME en smtpkey._domainkey.yourdomain.com apuntando a smtpcustomer._domainkey.smtpsend.com, y (2) hacer que SMTP.com cambie tu cuenta para firmar con tu dominio en el selector smtpkey; este es un interruptor del lado de la cuenta que normalmente se gestiona a través del soporte de SMTP.com o de tu gestor de cuenta, así que abre un ticket y confirma el selector/destino exacto que te asignen (a algunas cuentas se les puede dar un par distinto). Como el registro es un CNAME (no una clave TXT que pegas), SMTP.com conserva la clave privada detrás de ese destino compartido y puede rotarla sin que vuelvas a tocar el DNS: el compromiso del modelo de destino compartido es que la clave no es única para ti, pero la alineación no depende de la unicidad de la clave; lo que importa es que el valor d= de la firma sea tu dominio organizativo, lo cual ocurre una vez que la firma personalizada está activada. El registro publicado por tu lado es pequeño y estático; el trabajo pesado (la firma real) ocurre en los servidores de SMTP.com. Hasta que AMBOS el CNAME se resuelva Y la firma personalizada esté habilitada, Mostrar original seguirá reportando d=smtpsend.com y DMARC no tendrá ningún mecanismo alineado.
DMARC
DMARC es un registro TXT de política aparte en tu dominio que SMTP.com no crea: lo publicas tú en tu proveedor de DNS. Añade 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, pero indica a los receptores que te envíen por correo los informes agregados (rua) para que puedas confirmar que el correo de SMTP.com está pasando DKIM alineado con tu dominio antes de aplicar nada. Este paso de monitorización importa más de lo habitual con SMTP.com precisamente porque su SPF no se alinea por defecto: los informes son la manera de verificar que el CNAME de DKIM personalizado está realmente llevando la alineación. Vigílalos durante una o dos semanas, asegúrate de que todas las fuentes legítimas (SMTP.com más cualquier otro remitente) se autentican, y luego endurece la política a p=quarantine y finalmente a p=reject. NO pases directamente a una política estricta antes de confirmar que DKIM firma como d=yourdomain.com: si la firma personalizada aún no está habilitada, un registro p=reject rebotará tu propio correo relayado. Mantén exactamente un registro _dmarc para todo el dominio independientemente de cuántos remitentes uses; nunca añadas un segundo registro DMARC específicamente para SMTP.com.
Comprueba que de verdad funcionó
No te fíes solo del Panel de control ni de un temporizador de propagación: confirma la autenticación en un mensaje real. Haz relay de una prueba a través de SMTP.com a un buzón de Gmail (u Outlook), ábrelo y elige ⋮ → Mostrar original. Quieres DKIM: PASS con d=yourdomain.com y selector smtpkey; si ves d=smtpsend.com, la firma personalizada aún no está activa, así que el CNAME está publicado pero SMTP.com no ha cambiado tu cuenta. También quieres SPF: PASS (pasará, aunque recuerda que está alineado con el dominio de sobre de SMTP.com, no con el tuyo, salvo que hayas concertado un return-path personalizado) y DMARC: PASS, que aquí debe ganarse por la alineación de DKIM. ¿Prefieres un informe completo? Envía una prueba a check-auth@verifier.port25.com y te devolverá por correo un desglose línea por línea. Después pasa el dominio por la verificación de salud del dominio de Qualisend para confirmar que tu SPF es un único registro por debajo del límite de 10 búsquedas, que el CNAME smtpkey._domainkey se resuelve limpiamente a smtpsend.com y que DMARC está presente, y una vez que lleguen los informes agregados, deja caer uno en el analizador de informes DMARC para ver a SMTP.com aparecer como una fuente alineada y que pasa.
Errores habituales
- Configuración de DNS
El include SPF pasa pero NO se alinea por defecto. Por defecto, SMTP.com hace relay con su propio dominio de return-path/sobre, así que include:_spf.smtp.com autoriza las IP y pasa la comprobación SPF en crudo contra SMTP.com, no contra tu dominio del From. Añadir solo el include no te dará una aprobación de DMARC; el CNAME de DKIM personalizado sí.
- Rompe la autenticación
De fábrica, DKIM firma como d=smtpsend.com (el dominio compartido de SMTP.com), que valida pero no se alinea. Debes habilitar el DKIM de dominio personalizado para que el correo firme como d=yourdomain.com en el selector smtpkey; de lo contrario, DMARC no tiene ningún mecanismo alineado.
- Rompe la autenticación
El DKIM personalizado es un interruptor del lado de la cuenta, no solo un registro DNS. Publicar el CNAME smtpkey._domainkey no hace nada hasta que SMTP.com habilita la firma personalizada para tu cuenta: abre un ticket de soporte / pregunta a tu gestor de cuenta y luego confirma el selector y destino exactos que te asignen.
- Configuración de DNS
El destino del CNAME de DKIM es un host compartido (smtpcustomer._domainkey.smtpsend.com) y eso es por diseño, no un error de copiar y pegar. SMTP.com conserva la clave privada detrás de él y la rota por ti; la alineación sigue funcionando porque el d= de la firma es tu dominio. Mantenlo como CNAME, nunca como TXT.
- Configuración de DNS
El proxy de Cloudflare rompe el CNAME de DKIM. Pon smtpkey._domainkey en «DNS only» (nube gris): un CNAME con proxy en nube naranja no se resolverá a smtpsend.com y la habilitación de DKIM falla.
- Rompe la autenticación
Mantén exactamente UN registro SPF TXT en la raíz. Si ya envías vía Google Workspace, Microsoft 365 u otro relay, fusiona include:_spf.smtp.com en esa única línea v=spf1: dos registros SPF son en sí mismos un PermError.
- Configuración de DNS
Doblado del campo host: muchos registradores añaden tu dominio automáticamente, así que introducir smtpkey._domainkey.yourdomain.com produce smtpkey._domainkey.yourdomain.com.yourdomain.com. Introduce solo la etiqueta (smtpkey._domainkey, y @ para el registro SPF) si el panel añade el dominio por ti.
- Cobertura
Usa el ~all con el que viene el include de SMTP.com salvo que hayas inventariado todos los remitentes. Un -all prematuro puede hacer fallar en duro el correo legítimo de una herramienta que olvidaste añadir a la misma línea SPF.
Crea tu registro SPF
SMTP.com 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 SMTP.com — 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.