SPF, DKIM y DMARC para SocketLabs.
SocketLabs autentica tu dominio dentro de su On-Demand Portal, y su configuración es genuinamente distinta a la de un proveedor de tipo «pega esta línea SPF». Cada mensaje que envías ya está autenticado con SPF y firmado con DKIM en el momento en que sale de la plataforma, pero por defecto esa autenticación pertenece al propio dominio de SocketLabs, email-od.com, que es la razón por la que el correo sin configurar lleva una nota «via email-od.com» y no puede alinearse con tu dominio para DMARC. Para que SocketLabs envíe como tu dominio, añades dos registros en Configuration → Domain Management: un CNAME de Custom Bounce Domain (que traslada el return-path a tu propio subdominio para que SPF se alinee) y un registro DKIM (un único CNAME, o un selector TXT generado, para que DKIM firme como tu dominio). Una política DMARC aparte completa el conjunto. El matiz importante: la ruta SPF recomendada por SocketLabs es el CNAME del dominio de rebote, no añadir include:email-od.com a tu SPF raíz.
¿Por qué autenticar SocketLabs?
Autenticar SocketLabs no es una tarea rutinaria de mantenimiento: decide si tu correo 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) supere SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo al correo de alto volumen hacia Outlook.com/Hotmail en 2025. La particularidad específica de SocketLabs: de fábrica, autentica SPF contra su dominio de rebote email-od.com y firma DKIM con d=email-od.com. Ambas comprobaciones dan PASS sobre email-od.com, pero ninguna se alinea con tu dominio del From, así que DMARC falla la alineación, los destinatarios ven una etiqueta «via email-od.com», y la reputación de envío que construyes se acumula junto a la de cualquier otro remitente de SocketLabs sin autenticar en lugar de acumularse en tu propio dominio. Configurar un dominio de rebote personalizado (SPF se alinea) más DKIM personalizado (DKIM se alinea) cierra esa brecha en dos registros: DMARC pasa entonces por ambos mecanismos, la etiqueta «via» desaparece y tu dominio se apropia de su reputación.
La realidad del SPF con SocketLabs
SocketLabs es técnicamente un proveedor de tipo «include» —include:email-od.com existe y verifica en DNS (se resuelve a un único registro plano, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, con solo rangos ip4 y sin includes anidados, de modo que costaría exactamente UNA de tus 10 búsquedas SPF)— pero NO es la ruta SPF recomendada por SocketLabs y, por sí solo, no produce alineación DMARC. Aquí está el porqué: SPF se evalúa contra el dominio del return-path (rebote/sobre), no contra tu dirección From visible. Por defecto, el return-path de SocketLabs es email-od.com, así que la comprobación SPF consulta el registro de email-od.com y tu SPF raíz nunca se consulta para el correo de SocketLabs. SocketLabs implementa SPF en su lugar mediante un Custom Bounce Domain: publicas un CNAME en un subdominio de tu propio dominio —p. ej. email.yourdomain.com CNAME tracking.socketlabs.com— y, dado que tracking.socketlabs.com publica a su vez v=spf1 include:email-od.com ~all, trasladar el return-path a tu subdominio hace tanto que SPF dé PASS (hereda las IPs incluidas en la lista blanca de SocketLabs a través de ese CNAME) COMO que se ALINEE con tu dominio organizativo, todo ello sin editar tu registro SPF raíz existente. Por eso la configuración recomendada añade cero búsquedas a tu SPF raíz. El mecanismo include:email-od.com es una opción de refuerzo por partida doble: puedes añadirlo a tu SPF raíz (autoriza también ahí las IPs de envío, a un coste de una búsqueda), pero no aporta alineación por sí mismo y no es necesario una vez que el dominio de rebote personalizado está en su sitio. Como siempre, mantén exactamente UN registro TXT de SPF por dominio: si añades el include, fusiónalo en tu única línea v=spf1 en lugar de publicar un segundo registro.
Dos formas de configurarlo
CNAME de Custom Bounce Domain (recomendado)
- Traslada el return-path a un subdominio de tu dominio, de modo que SPF tanto pasa como se ALINEA para DMARC
- Añade cero búsquedas de DNS a tu SPF raíz: no hay nada que fusionar ni aplanar
- El CNAME a tracking.socketlabs.com hereda automáticamente las IPs de SocketLabs incluidas en la lista blanca; nunca lo vuelves a editar cuando cambian las IPs
- El mismo CNAME de subdominio puede reutilizarse para marcar con tu propia marca (white-label) tus enlaces de seguimiento de aperturas/clics
include:email-od.com en tu SPF raíz (opcional)
- Añades tú mismo v=spf1 include:email-od.com ~all a tu SPF raíz
- Cuesta una de tus 10 búsquedas de DNS de SPF (email-od.com es un registro plano de solo ip4, así que exactamente una)
- Autoriza las IPs de envío bajo tu dominio pero NO alinea SPF por sí solo: el return-path sigue siendo email-od.com a menos que también configures el CNAME de rebote
- Un complemento en el mejor de los casos, nunca un sustituto del dominio de rebote personalizado
Paso a paso
- 1
Abre Domain Management
Inicia sesión en el On-Demand Portal, haz clic en Configuration en el menú de la izquierda, elige Domain Management, y luego selecciona el dominio de envío que quieres autenticar (o haz clic para añadirlo). Todo lo que sigue vive en la tarjeta de este dominio.
- 2
Inicia Custom Bounce Domain y SPF
En el dominio, abre «Custom Bounce Domain and SPF Authentication». SocketLabs genera un registro CNAME en un subdominio de tu dominio (algo como email.yourdomain.com o bounce.yourdomain.com) cuyo destino es tracking.socketlabs.com. Así es como SocketLabs implementa SPF: traslada tu return-path a tu propio dominio para que SPF se alinee.
- 3
Publica el CNAME del dominio de rebote
En tu proveedor de DNS, crea un CNAME: Host = el subdominio que SocketLabs muestra (p. ej. email), Value = tracking.socketlabs.com. No lo cambies a un registro TXT ni A, y no toques tu registro SPF raíz existente: este CNAME es el que transporta SPF.
- 4
Elige tu método de DKIM
De vuelta en el dominio, abre la sección DKIM. Tienes dos opciones: la función CNAME DKIM Signing (la más sencilla: SocketLabs posee y rota la clave por ti) o el método Advanced/TXT a través del DKIM Key Generator (tú eliges un selector y publicas un registro TXT de clave pública). Elige uno; no necesitas ambos.
- 5
Publica el registro DKIM
Para el método CNAME, añade un CNAME: Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. Para el método TXT, añade un registro TXT en Host = <selector>._domainkey (el selector que elegiste en el generador, alfanumérico y de menos de 10 caracteres) con el valor v=DKIM1; k=rsa; p=… que SocketLabs muestra. En cualquier caso, DKIM firmará ahora como tu dominio.
- 6
Añade el registro DMARC
SocketLabs no crea DMARC por ti. Añade un registro TXT en Host = _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es de solo monitorización, así que nada de la entrega cambia mientras confirmas la alineación; lo endurecerás más tarde.
- 7
Verifica en el portal
Vuelve a Domain Management y haz clic en «Verify Bounce» para el dominio de rebote personalizado y en «Verify» para DKIM. El estado del dominio de rebote debería marcar authenticated y DKIM debería marcar active. La propagación suele ser de minutos, pero SocketLabs puede tardar hasta 24–48 horas en confirmar los registros.
- 8
Envía una prueba y lee las cabeceras
Envía un mensaje desde una dirección del dominio configurado a una cuenta de Gmail, ábrelo y elige ⋮ → Mostrar original. Quieres ver SPF: PASS mostrando tu subdominio de rebote (no email-od.com), DKIM: PASS con d=yourdomain.com, y DMARC: PASS. La nota «via email-od.com» debería haber desaparecido.
Registros que añadir
SocketLabs 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 |
|---|---|---|
| CNAME | tracking.socketlabs.comCustom Bounce Domain: esto es lo que transporta y ALINEA SPF. La etiqueta del subdominio (email/bounce/…) es la que SocketLabs asigne; reutilízala también para el white-labeling del seguimiento de interacción. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (recomendado, el más sencillo): SocketLabs posee y rota la clave. El selector es dkim; d= pasa a ser tu dominio de modo que DKIM se alinea. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternativa al método CNAME: usa la ruta Advanced/TXT de DKIM solo si quieres controlar la clave. El selector (sl2026 aquí) es de tu elección: alfanumérico, menos de 10 caracteres. Valor ilustrativo: el generador usa por defecto una clave de 2048 bits, generada por cuenta. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comEsto lo añades tú mismo: SocketLabs nunca lo crea. Uno por dominio; empieza en p=none, luego endurece a quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allRefuerzo por partida doble SOLO OPCIONAL. No es necesario si configuras el dominio de rebote personalizado, y no alinea SPF por sí solo. Cuesta 1 búsqueda; fusiónalo en tu única línea de SPF raíz si lo usas. |
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 SocketLabs consume de ese presupuesto.
La configuración recomendada de SocketLabs añade 0 consultas: las 10 quedan libres para los remitentes que sí necesitan un include.
DKIM
SocketLabs firma cada mensaje por defecto, pero con d=email-od.com, que no se alinea con tu dominio, así que el DKIM personalizado es lo que hace que DKIM funcione realmente para ti, y hay dos maneras de configurarlo. La función CNAME DKIM Signing es la más sencilla: publicas un único CNAME, Host = dkim._domainkey.yourdomain.com apuntando a dkim._domainkey.email-od.com, y dado que es un CNAME (no una clave que pegas) SocketLabs mantiene el control tanto de la clave privada como de la pública y las rota por ti; nunca vuelves a editar el DNS. El selector es simplemente dkim, y una vez verificado SocketLabs firma tu correo con d=yourdomain.com de modo que DKIM se alinea. El método Advanced/TXT te da más control: en Domain Management ejecutas el DKIM Key Generator, eliges un selector (alfanumérico, menos de 10 caracteres, p. ej. sl2026) y SocketLabs genera el par de claves, almacenando la clave privada en tu cuenta y entregándote la clave pública para que la publiques como registro TXT en <selector>._domainkey.yourdomain.com con la forma v=DKIM1; k=rsa; p=…. El generador usa por defecto una clave de 2048 bits (existe una opción de 1024 bits, pero déjala en 2048: la clave más fuerte es el estándar moderno y SocketLabs recomienda no rebajarla). También hay una variante de «trae tu propio registro TXT» en la que aportas una clave privada generada externamente. Un requisito estricto de la ruta TXT: el portal no te dejará guardar hasta que pueda resolver tu clave pública publicada en el DNS, y una vez guardada la clave pública ya no se muestra en el portal, así que publícala primero. Una salvedad que aplica a AMBOS métodos: tu firma DKIM personalizada solo se aplica a los mensajes cuya dirección From (la Purported Responsible Address) coincida exactamente con el dominio configurado; el correo enviado desde cualquier otro dominio From recurre a la firma por defecto email-od.com y no se alineará, así que configura DKIM para cada dominio desde el que envíes.
DMARC
DMARC es un registro TXT de política aparte que SocketLabs no crea: lo publicas tú mismo 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 de solo monitorización: no cambia nada en la entrega mientras observas los informes agregados (rua) para confirmar que el correo de SocketLabs pasa SPF y DKIM alineados con tu dominio. Dado que el dominio de rebote personalizado te da alineación SPF y el DKIM personalizado te da alineación DKIM, un dominio de SocketLabs correctamente configurado pasa DMARC por AMBOS mecanismos: la configuración resiliente que sobrevive al reenvío, ya que un reenvío que rompe SPF aún deja una firma DKIM alineada. Vigila los informes durante una semana o dos, asegúrate de que todos los remitentes legítimos (SocketLabs más cualquier otra herramienta del dominio) se autentican, y luego endurece la política a p=quarantine y finalmente a p=reject. Mantén exactamente un registro _dmarc para todo el dominio organizativo sin importar cuántos remitentes uses; nunca añadas un segundo registro DMARC solo para SocketLabs.
Comprueba que de verdad funcionó
No confíes solo en las insignias «authenticated» y «active» del portal: confírmalo en un mensaje real. Envía una prueba desde una dirección del dominio configurado a un buzón de Gmail, ábrelo y elige ⋮ → Mostrar original: quieres ver SPF: PASS mostrando tu subdominio de rebote (p. ej. email.yourdomain.com, NO email-od.com), DKIM: PASS con d=yourdomain.com, y DMARC: PASS. La señal reveladora de fallo es que SPF/DKIM sigan mostrando email-od.com, lo que significa que el dominio de rebote y/o el DKIM personalizado aún no están activos, o que enviaste desde un dominio From que no está configurado. Puedes hacer una comprobación puntual de los registros en bruto con dig CNAME email.yourdomain.com (debería resolver a tracking.socketlabs.com), dig CNAME dkim._domainkey.yourdomain.com (o dig TXT <selector>._domainkey.yourdomain.com para el método TXT) y dig TXT _dmarc.yourdomain.com. Luego pasa tu dominio por el {healthCheck} de Qualisend para confirmar que todos los registros resuelven limpiamente, y una vez que empiecen a llegar los informes agregados de DMARC, mete uno en el {dmarcAnalyzer}: SocketLabs debería aparecer como una fuente alineada y que pasa completamente.
Errores habituales
- Cobertura
La etiqueta «via email-od.com» por defecto significa que aún no estás alineado: hasta que configures TANTO un dominio de rebote personalizado COMO un DKIM personalizado, SocketLabs se autentica como email-od.com, de modo que SPF y DKIM pasan pero DMARC falla la alineación. La etiqueta solo desaparece una vez que ambos apuntan a tu dominio.
- Configuración de DNS
Añadir include:email-od.com a tu SPF raíz NO es la solución por sí solo. Autoriza las IPs de envío, pero el return-path sigue siendo email-od.com a menos que publiques el CNAME del dominio de rebote, y es el CNAME de rebote, no el include, lo que realmente alinea SPF. No te saltes el CNAME pensando que el include lo cubre.
- Cobertura
El DKIM personalizado solo firma el correo cuya dirección From coincide exactamente con el dominio configurado (la Purported Responsible Address). Envía desde un dominio From distinto y SocketLabs recurre silenciosamente a la firma por defecto email-od.com, así que DKIM no se alineará: configura cada dominio de envío.
- Configuración de DNS
Algunos proveedores de DNS no aceptan un guion bajo en el host de un CNAME, lo que bloquea el método del CNAME dkim._domainkey. Si el tuyo lo rechaza, usa en su lugar la ruta Advanced/TXT de DKIM (DKIM Key Generator): el registro TXT de clave pública sortea la limitación del guion bajo en CNAME.
- Configuración de DNS
El proxy de Cloudflare rompe ambos CNAME: pon el CNAME del dominio de rebote y el CNAME de DKIM en «DNS only» (nube gris). Un CNAME con proxy en nube naranja no resolverá a tracking.socketlabs.com / email-od.com y la verificación falla.
- Cobertura
Las subcuentas se autentican por separado. El modelo de subcuentas de SocketLabs implica que cada subcuenta necesita su propio dominio de rebote personalizado y su autenticación DKIM: autenticar la cuenta maestra no las cubre.
- Configuración de DNS
La verificación puede retrasarse 24–48 horas. La propagación suele ser de minutos, pero SocketLabs vuelve a comprobar el CNAME/TXT con retardo, así que «authenticated»/«active» puede no cambiar de inmediato aunque tu DNS ya sea correcto: verifica con Mostrar original en lugar de esperar a la insignia.
- Configuración de DNS
Duplicación del campo Host: los registradores que autocompletan tu dominio convierten dkim._domainkey.yourdomain.com en dkim._domainkey.yourdomain.com.yourdomain.com. Introduce solo la etiqueta (email, dkim._domainkey, <selector>._domainkey) si tu panel añade el dominio por ti.
- Rompe la autenticación
Mantén exactamente un registro SPF y un registro DMARC por dominio. Si añades el include:email-od.com opcional, fusiónalo en tu única línea v=spf1: dos registros SPF son un PermError, y también lo es un segundo registro _dmarc.
Crea tu registro SPF
SocketLabs 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 SocketLabs — 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.