SPF, DKIM y DMARC para Front.
Front (front.com) es una plataforma de bandeja de entrada compartida y comunicación con clientes, no un proveedor de alojamiento de correo, por lo que «enviar como tu dominio» a través de Front tiene un significado concreto. Cuando conectas un canal SMTP personalizado, Front retransmite tu correo saliente a través de SendGrid, su infraestructura de correo subyacente (las cuentas más antiguas retransmitían a través de Mandrill, y por eso es posible que hayas visto una etiqueta heredada «via mandrillapp.com»). Hasta que autentiques esa ruta, los destinatarios ven una nota «via sendgrid.net» en tu dirección De y tu correo tiene muchas más probabilidades de acabar en spam. Los ajustes de entregabilidad (Deliverability) de Front te facilitan tres registros DNS —un MX, un SPF (como TXT) y un DKIM (como TXT)— que añades a un subdominio de envío dedicado llamado front-mail. Como esos registros viven en el subdominio en lugar de en tu dominio raíz, autorizan a SendGrid a enviar en tu nombre, eliminan la etiqueta «via» y alinean tu correo con tu dominio para DMARC, todo ello sin tocar tu SPF existente ni cambiar dónde se entrega tu correo entrante.
¿Por qué autenticar Front?
Autenticar tu dominio de envío de Front determina si tus respuestas llegan siquiera a la bandeja de entrada. Desde febrero de 2024, Gmail y Yahoo exigen a todo remitente masivo (aproximadamente 5.000 o más mensajes al día) que supere SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo a los remitentes de alto volumen en 2025, y los equipos de soporte y de éxito de cliente que trabajan en Front alcanzan de forma rutinaria esos volúmenes. Hasta que añadas los registros, Front envía tu correo por la infraestructura compartida de SendGrid: los destinatarios ven la etiqueta «via sendgrid.net», tu dirección De no se alinea con tu dominio, DMARC no puede pasar por SPF y tu reputación de envío se agrupa con la de todos los demás inquilinos sin autenticar de esa plataforma. Autenticar lo soluciona todo de una vez: SendGrid firma con una clave DKIM publicada bajo tu subdominio front-mail (de modo que la firma se alinea con tu dominio), el Return-Path del sobre vive en ese mismo subdominio (de modo que SPF se alinea en modo relajado), la etiqueta «via» desaparece, DMARC pasa y la reputación que construyes se acumula en tu propio dominio en lugar de en el conjunto compartido.
La realidad del SPF con Front
Front es una configuración de delegación de subdominio, no un proveedor de tipo «include»: NO hay ningún include:sendgrid.net que debas pegar en tu dominio raíz. En su lugar, toda la ruta autenticada vive en un subdominio de envío dedicado que Front etiqueta como front-mail. Ese subdominio recibe tres registros directamente desde el panel de entregabilidad de Front: un registro MX que apunta al host de correo de SendGrid (mx.sendgrid.net) para que SendGrid pueda procesar los rebotes, un registro SPF TXT (v=spf1 include:sendgrid.net ~all) acotado al subdominio y una clave pública DKIM TXT en un selector bajo ese mismo subdominio. El propio registro SPF de tu dominio organizativo se deja exactamente como está: el include de Front vive en front-mail.yourdomain.com, así que no cuesta nada del presupuesto de 10 búsquedas DNS de tu SPF raíz. DMARC sigue pasando, pero fíjate en el detalle específico de Front: como TANTO el Return-Path del sobre COMO la clave DKIM viven en el subdominio front-mail, tanto SPF como DKIM se alinean con tu dominio organizativo en modo relajado (el subdominio comparte tu dominio registrable), y ninguno se alinea en modo estricto. El modo relajado es el predeterminado de DMARC, así que Front pasa de fábrica; simplemente no fuerces la alineación estricta (aspf=s o adkim=s) para este dominio. Por último, esto solo se aplica a los canales SMTP de Front; si tu canal de Front es una bandeja de entrada conectada de Gmail o Microsoft 365, Front envía a través de los propios servidores de ese proveedor y te autenticas en Google/Microsoft en su lugar, y ninguno de los registros de front-mail se aplica.
Dos formas de configurarlo
Canal SMTP de Front: añade los registros de SendGrid (esta guía)
- Se aplica cuando tu canal es un canal SMTP personalizado: Front retransmite tu correo saliente a través de SendGrid y debes autenticarlo.
- Añade MX + SPF (TXT) + DKIM (TXT) a un subdominio de envío dedicado front-mail, copiados del panel de entregabilidad de Front.
- Los tres registros viven en el subdominio, así que el SPF de tu dominio raíz queda intacto: cero de tus 10 búsquedas SPF consumidas.
- Hasta que Front muestre los registros como Verified, el correo se envía «via sendgrid.net» en el conjunto compartido y arriesga la carpeta de spam.
Canal conectado de Gmail / Microsoft 365: autentícate allí en su lugar
- Se aplica cuando añadiste tu buzón a Front mediante la integración de Google o Microsoft 365: Front envía a través de ese proveedor, no de SendGrid.
- La autenticación se hereda del SPF, DKIM y DMARC de tu Google Workspace o Microsoft 365: configúralos en ese proveedor.
- No hay subdominio front-mail, ni MX hacia mx.sendgrid.net, y ninguno de los registros SPF/DKIM de SendGrid se aplica.
- La etiqueta «via sendgrid.net» nunca aparece porque SendGrid no está en la ruta de envío.
Paso a paso
- 1
Confirma que el canal es un canal SMTP
Estos registros solo se aplican a los canales SMTP de Front (correo retransmitido a través de SendGrid). Si tu canal es una bandeja de entrada conectada de Gmail o Microsoft 365, Front envía a través de ese proveedor: detente aquí y autentícate en Google/Microsoft en su lugar. Comprueba el tipo de canal en Settings → Channels.
- 2
Abre los ajustes de entregabilidad
Para canales de toda la empresa, haz clic en el engranaje Settings → Company settings → Security en la barra lateral → la pestaña Deliverability. Esta página solo aparece para los administradores de la empresa una vez que existe al menos un canal SMTP compartido. Para el canal de un compañero individual, abre Settings → el canal SMTP del compañero → pestaña Settings → la sección «Improve delivery rates - SPF / DKIM».
- 3
Selecciona el dominio de envío
En Domains, elige el dominio desde el que envías. Cualquier dominio al que le falte SPF/DKIM muestra un icono de advertencia amarillo. Front muestra entonces el Name y el Value de tres registros a añadir: un MX, un SPF (TXT) y un DKIM (TXT). Mantén este panel abierto para copiar de él: el selector, el host y los valores de clave exactos son únicos de tu cuenta.
- 4
Añade el registro MX en el subdominio front-mail
Crea un registro MX: Host/Name = la etiqueta de subdominio que muestra Front (p. ej. front-mail), Value/Target = el host de correo de SendGrid (p. ej. mx.sendgrid.net), Priority = como se muestre (Front suele usar 10). Este es un MX NUEVO en el subdominio para la gestión de rebotes de SendGrid: NO cambia tu MX principal (host @) ni dónde se entrega tu correo entrante.
- 5
Añade el registro SPF (TXT)
Crea un registro TXT: Host/Name = front-mail, Value = exactamente lo que muestra Front (p. ej. v=spf1 include:sendgrid.net ~all). Este SPF está acotado solo al subdominio de envío: NO añadas include:sendgrid.net al registro SPF de tu dominio raíz.
- 6
Añade el registro DKIM (TXT)
Crea un registro TXT con el host de selector que muestra Front (p. ej. s1._domainkey.front-mail) y pega el largo valor de clave pública de Front exactamente, sin espacios ni saltos de línea añadidos. Front usa el whitelabel clásico de SendGrid, así que esta es una única clave TXT estática, no los CNAME de rotación automática de la autenticación de dominio moderna de SendGrid.
- 7
Introduce los hosts solo como etiquetas y no toques los registros existentes
Escribe solo la etiqueta (front-mail, s1._domainkey.front-mail): la mayoría de los registradores añaden automáticamente tu dominio, e introducir el front-mail.yourdomain.com completo produce un nombre duplicado que no resolverá. Añade solo estos tres registros NUEVOS; no edites ni elimines ningún registro DNS existente, ya que puede romper la entrega.
- 8
Publica tu política DMARC (si no tienes una)
En tu dominio raíz añade un registro TXT en _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Conserva exactamente un registro _dmarc para todo el dominio. Deja la alineación en su valor relajado predeterminado: el subdominio front-mail de Front lleva tanto SPF como DKIM en modo relajado, así que no establezcas aspf=s ni adkim=s, cualquiera de los cuales rompería la autenticación de Front.
- 9
Haz clic en «Check DNS settings» en Front
Vuelve al panel de entregabilidad de Front y haz clic en Check DNS settings: esto desencadena una verificación a través de SendGrid. Cuando los registros resuelven, cada uno cambia a Verified y el icono de advertencia amarillo desaparece del canal. La propagación DNS suele ser de minutos, pero puede tardar hasta 24–48 horas.
- 10
Envía una prueba real y confirma la alineación
Envíate un mensaje desde el canal de Front, ábrelo en Gmail y usa ⋮ → Mostrar original. Confirma SPF: PASS, DKIM: PASS signed-by front-mail.yourdomain.com, DMARC: PASS, y que la etiqueta «via sendgrid.net» ha desaparecido de la línea De.
Registros que añadir
Front 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 | front-mail | mx.sendgrid.netReturn-Path del subdominio de envío: el host de rebotes de SendGrid, con la prioridad que muestre Front (habitualmente 10). El subdominio y el host exactos provienen del panel de entregabilidad de Front. Este NO es tu MX principal y no afecta al correo entrante. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF solo para el subdominio de envío: nunca se añade a tu dominio raíz, así que cuesta 0 de las 10 búsquedas de tu SPF raíz. Copia el valor exacto de Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Clave pública DKIM (única TXT estática). Front/SendGrid proporciona el selector y la clave exactos: el host y el valor son únicos de tu cuenta; esto es ilustrativo. Como la clave vive bajo front-mail, el d= de la firma es el subdominio y se alinea con tu dominio en modo relajado. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comTu política DMARC: una por dominio raíz. Front se autentica por completo a través del subdominio front-mail, así que mantén la alineación relajada (el valor predeterminado); estricta (aspf=s o adkim=s) rompe Front. |
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 Front consume de ese presupuesto.
La configuración recomendada de Front añade 0 consultas: las 10 quedan libres para los remitentes que sí necesitan un include.
DKIM
El DKIM para Front es un único registro TXT estático de clave pública que Front genera a través de SendGrid y te muestra en el panel de entregabilidad. Lo publicas en el selector del subdominio de envío (algo como s1._domainkey.front-mail.yourdomain.com); SendGrid conserva la clave privada correspondiente y firma cada mensaje que Front retransmite. Como la clave vive bajo front-mail, la firma DKIM lleva d=front-mail.yourdomain.com, que se alinea con tu dominio organizativo en modo relajado —el predeterminado de DMARC— igual que lo hace el Return-Path de SPF. No se alinea en modo estricto, así que no establezcas adkim=s para este dominio. Dos cosas diferencian el DKIM de Front de la autenticación de dominio moderna de SendGrid. Primero, es una clave TXT estática, no un CNAME de rotación automática: Front usa el whitelabel clásico de SendGrid, así que pegas la clave una vez y no rota por sí sola (no se delega nada que deba volver a resolverse, pero tampoco nadie rota las claves por ti). Segundo, como es una clave pública completa en un valor TXT, puede superar el límite de una sola cadena de 255 caracteres; la mayoría de los paneles DNS la almacenan automáticamente como un único registro troceado, pero si más adelante un verificador informa de que la clave no es válida, la causa habitual es un valor alterado o truncado: vuelve a pegarlo exactamente como lo muestra Front. El selector asignado por SendGrid no colisiona con tus selectores DKIM de Google (google) ni de Microsoft (selector1/selector2), así que el DKIM de Front coexiste con el de tu proveedor de buzón. DKIM sigue siendo la más resistente al reenvío de tus dos señales —sobrevive al reenvío de mensajes cuando SPF se rompe— pero para la alineación DMARC va en el mismo modo relajado que SPF, así que mantén relajada la alineación de tu política.
DMARC
DMARC es un registro de política aparte que publicas en tu dominio raíz: Front no lo crea por ti, aunque su documentación de entregabilidad te guía por la interacción. 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, así que no afectará a la entrega mientras confirmas que el correo de Front se autentica. La particularidad de Front es la alineación: como SendGrid usa el subdominio front-mail TANTO para el Return-Path del sobre COMO para el dominio d= de DKIM, el correo de Front se alinea con tu dominio organizativo en modo RELAJADO tanto en SPF como en DKIM, y en modo ESTRICTO en ninguno de los dos. El modo relajado es el predeterminado de DMARC, así que una política estándar pasa Front de fábrica; no necesitas añadir nada. Los problemas solo aparecen si tu DMARC existente fuerza la alineación estricta: aspf=s rompe la alineación SPF de Front y adkim=s rompe su alineación DKIM, y estricto en ambos hace fallar a Front por completo. Mantén la alineación relajada (puedes hacerla explícita con aspf=r; adkim=r). Conserva exactamente un registro _dmarc para todo el dominio sin importar cuántos remitentes (Front, tu proveedor de buzón, herramientas de marketing) utilices: nunca añadas un segundo registro DMARC para Front. Una vez que los informes agregados confirmen que Front/SendGrid se autentica limpiamente, endurece de p=none a p=quarantine y finalmente p=reject.
Comprueba que de verdad funcionó
No te fíes solo del distintivo Verified de Front: confírmalo en un mensaje real. Después de que Check DNS settings muestre los registros como Verified, envíate un correo desde el canal de Front, ábrelo en Gmail y elige ⋮ → Mostrar original. Quieres ver SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS con signed-by: front-mail.yourdomain.com y DMARC: PASS, y la etiqueta «via sendgrid.net» debería haber desaparecido de la línea De. Puedes hacer una comprobación puntual de los registros en bruto con dig MX front-mail.yourdomain.com (espera mx.sendgrid.net), dig TXT front-mail.yourdomain.com (espera la línea v=spf1 include:sendgrid.net), dig TXT s1._domainkey.front-mail.yourdomain.com (espera la clave DKIM) y dig TXT _dmarc.yourdomain.com. Luego pasa tu dominio por el {healthCheck} de Qualisend para confirmar que todos los registros resuelven y que tu SPF raíz se mantiene por debajo del límite de 10 búsquedas, y en cuanto empiecen a llegar los informes agregados de DMARC, introduce uno en el {dmarcAnalyzer}: Front debería aparecer como una fuente alineada y aprobada (infraestructura de SendGrid firmando como tu dominio).
Errores habituales
- Cobertura
El registro MX que Front pide NO es tu MX principal. Se asienta en el subdominio front-mail y solo permite a SendGrid procesar rebotes del correo saliente de Front: no redirige tu bandeja de entrada ni cambia dónde se entrega el correo entrante. Tu MX existente en el host @ queda intacto.
- Cobertura
Introduce los hosts solo como la etiqueta —front-mail, s1._domainkey.front-mail— no el front-mail.yourdomain.com completo. La mayoría de los registradores añaden automáticamente tu dominio, y el nombre duplicado (front-mail.yourdomain.com.yourdomain.com) no resolverá, así que Check DNS settings falla.
- Cobertura
Añade solo tres registros NUEVOS. Front advierte explícitamente que no edites ni elimines registros DNS existentes durante este proceso: modificar tu SPF, MX o DKIM actual puede romper la entrega.
- Configuración de DNS
No añadas include:sendgrid.net a tu SPF RAÍZ. Front acota el SPF al subdominio front-mail, así que un include raíz es redundante, consume innecesariamente una de tus 10 búsquedas SPF y no es lo que SendGrid comprueba para Front.
- Cobertura
La alineación DMARC estricta rompe Front. Tanto el Return-Path del sobre como la clave DKIM viven en el subdominio front-mail, así que SPF y DKIM se alinean cada uno con tu dominio solo en modo relajado. Establecer aspf=s rompe la alineación SPF de Front y adkim=s rompe su alineación DKIM: estricto en ambos hace fallar a Front por completo. El relajado es el predeterminado, así que deja la alineación en paz.
- Cobertura
Los canales conectados de Gmail / Microsoft 365 no usan estos registros en absoluto. Si Front envía a través de tu buzón de Google o Microsoft en lugar de un canal SMTP, no hay subdominio front-mail ni etiqueta via: autentícate en ese proveedor en su lugar.
- Configuración de DNS
Los registros MX y TXT no se pueden proxear, así que en Cloudflare no hay aquí ningún paso de nube naranja/nube gris (a diferencia de la autenticación de dominio de SendGrid basada en CNAME). Solo asegúrate de haberlos creado como MX y TXT, no como algún otro tipo.
- Cobertura
Cada dominio y canal de envío SMTP se autentica por separado. Configurar un dominio no cubre los demás: el panel de entregabilidad marca cualquier dominio al que aún le falten registros con un icono de advertencia amarillo.
Crea tu registro SPF
Front 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 Front — 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.