Un SPF pass significa que DMARC tambien pasa?

No necesariamente. Para aportar a DMARC, el dominio validado por SPF tambien debe quedar alineado con el dominio visible en From. DKIM puede ser la otra via de alineacion.

Cuando conviene cambiar DMARC a quarantine o reject?

Despues de inventariar remitentes, verificar SPF y DKIM, revisar reportes y corregir fuentes legitimas. La aplicacion debe ser gradual para no bloquear correo valido.

Qué son SPF, DKIM y DMARC y cómo funcionan

Q: Que significa DMARC p=none?

Es una politica de observacion. Solicita reportes y no pide al receptor poner en cuarentena o rechazar mensajes solo por DMARC. Se usa para conocer las fuentes antes de endurecer la politica.

Q: Que es un selector DKIM?

Es el nombre que identifica una clave publica DKIM dentro del DNS. Permite que un dominio use y rote distintas claves, por ejemplo para proveedores diferentes.

SPF, DKIM y DMARC suelen aparecer juntos porque resuelven partes complementarias del mismo problema: permitir que un receptor evalúe si un mensaje puede usar el dominio que declara y qué hacer cuando esa identidad no coincide.

La idea centralSPF revisa si la infraestructura está autorizada. DKIM comprueba una firma asociada al dominio. DMARC evalúa si SPF o DKIM están alineados con el dominio visible en el campo From y publica una política.

Qué valida cada mecanismo.

Mecanismo	Comprueba	Ubicación DNS habitual	No resuelve por sí solo
SPF	Si la IP puede usar el dominio del remitente SMTP o retorno.	TXT en el dominio evaluado.	No firma el contenido ni valida directamente el From visible.
DKIM	Si una firma del mensaje corresponde a una clave pública publicada por el dominio.	TXT en `selector._domainkey.dominio`.	No autoriza todas las IP ni exige por sí solo que el dominio coincida con el From visible.
DMARC	Si SPF o DKIM pasan y quedan alineados con el dominio visible en From.	TXT en `_dmarc.dominio`.	No mejora reputación ni corrige una fuente legítima mal configurada.

Los registros se publican en DNS, pero la prueba final ocurre sobre mensajes reales. Un verificador DNS puede confirmar que el texto existe; los encabezados muestran qué dominio se evaluó, qué firma se usó y si hubo alineación.

SPF: qué servidores pueden enviar.

SPF publica una lista de mecanismos que autorizan servidores para usar un dominio en la identidad SMTP MAIL FROM o en HELO. El receptor compara la IP que entrega el mensaje con esa política.

Ejemplo ilustrativov=spf1 include:mail.proveedor.example -all
No copies este valor. El registro correcto depende de todas las plataformas que envían para tu dominio y de las instrucciones exactas de cada proveedor.

Debe existir un solo registro SPF aplicable por dominio; las fuentes se combinan dentro de esa política.
Hay que incluir correo, CRM, facturación, formularios, soporte y cualquier otro emisor legítimo.
La evaluación limita a diez los términos que generan consultas DNS; excederlos puede producir permerror.
El reenvío puede cambiar la IP que entrega el mensaje y provocar un fallo SPF aunque el remitente original fuera legítimo.

Un resultado SPF pass confirma autorización para la identidad que SPF evaluó. No demuestra por sí solo que el dominio visible para la persona destinataria sea el mismo.

DKIM: una firma verificable del mensaje.

DKIM agrega una firma criptográfica a encabezados y cuerpo. El servidor emisor conserva la clave privada; el receptor obtiene la clave pública desde DNS y verifica que las partes firmadas no hayan cambiado de una forma incompatible con la firma.

Selector DKIMLa firma incluye un selector s= y un dominio d=. El receptor consulta una ruta como mail._domainkey.empresa.cl. El selector real debe copiarse desde el proveedor; no siempre es mail.

Un mismo dominio puede usar distintos selectores para proveedores o rotaciones de clave.
Publicar la clave no basta: el servicio emisor también debe firmar los mensajes.
Algunas modificaciones realizadas durante reenvíos o listas pueden romper la firma.
DKIM puede pasar con un dominio d= distinto del From visible; en ese caso puede no aportar alineación DMARC.

DMARC: alineación, política y reportes.

DMARC toma el dominio visible en el campo From como referencia. El mensaje pasa DMARC cuando al menos una de estas rutas tiene autenticación correcta y alineación suficiente:

SPF pasa y el dominio evaluado por SPF se alinea con el From visible.
DKIM pasa y el dominio d= de la firma se alinea con el From visible.

Política	Solicitud al receptor	Uso responsable
`p=none`	Observar y reportar sin pedir cuarentena o rechazo por DMARC.	Inventariar fuentes y corregir alineación.
`p=quarantine`	Tratar los fallos como sospechosos, normalmente enviándolos a spam.	Aplicar gradualmente después del monitoreo.
`p=reject`	Rechazar mensajes que fallen DMARC.	Usar cuando las fuentes legítimas están controladas.

La etiqueta rua puede indicar dónde recibir reportes agregados. Esos reportes ayudan a detectar servicios conocidos, remitentes olvidados y posibles intentos de suplantación; necesitan interpretación, no solo almacenamiento.

Por qué la alineación cambia el resultado.

Autenticar no siempre significa alinear. Un proveedor puede pasar SPF usando su propio dominio de retorno, mientras el From visible usa empresa.cl. Si DKIM firma con d=empresa.cl, DMARC aún puede pasar por DKIM; si ninguna ruta se alinea, DMARC falla.

Escenario	SPF	DKIM	Resultado DMARC
SPF autorizado y alineado con From.	Pasa y alinea	Puede fallar	Pasa
SPF usa dominio del proveedor; DKIM firma con el dominio de la empresa.	Pasa, no alinea	Pasa y alinea	Pasa
Ningún dominio autenticado se alinea con From.	Falla o no alinea	Falla o no alinea	Falla

DMARC admite alineación relajada o estricta. La relajada acepta ciertas relaciones entre dominio organizacional y subdominios; la estricta exige coincidencias más exactas y debe aplicarse con conocimiento de todas las fuentes.

Orden recomendado para configurarlos.

Inventaria todos los sistemas que envían usando el dominio.
Publica o actualiza un único SPF con las fuentes legítimas y revisa el límite de consultas.
Activa DKIM en cada proveedor con su selector y clave correspondientes.
Envía mensajes de prueba y revisa Authentication-Results, From, retorno y firma DKIM.
Publica DMARC en observación y configura un destino controlado para reportes.
Corrige fuentes que fallen o no alineen antes de avanzar.
Evoluciona gradualmente hacia cuarentena y rechazo cuando la evidencia sea suficiente.

La implementación gradual reduce el riesgo de bloquear facturación, CRM, formularios u otros emisores legítimos que no aparecieron en el inventario inicial.

Errores frecuentes que debes evitar.

Publicar dos registros SPF separados en vez de consolidar las fuentes.
Copiar un SPF de internet sin incluir los servicios que realmente envían.
Publicar una clave DKIM y olvidar activar la firma en el proveedor.
Consultar un selector DKIM distinto del que aparece en los mensajes o en el panel.
Confundir SPF pass con alineación y aprobación DMARC.
Aplicar p=reject antes de revisar reportes y fuentes legítimas.
Suponer que los registros garantizan bandeja principal o reparan reputación.
Olvidar revisar la autenticación cuando se agrega un nuevo CRM, formulario o plataforma.

Cómo lo aborda Connectia.

El onboarding de Connectia presenta los registros esperados para el dominio y permite verificar MX, SPF, DKIM y DMARC. Cuando el DNS se administra fuera de Connectia, el cliente copia esos valores en su proveedor y vuelve al panel para comprobar el resultado.

El monitoreo interno de entregabilidad revisa periódicamente presencia y calidad básica de autenticación, selectores conocidos, señales de firma, reportes disponibles, cola y reputación DNSBL. Estos controles ayudan a detectar problemas, pero no reemplazan la revisión de cada fuente ni controlan la bandeja del receptor.

Para un caso real, usa los valores exactos del panel y conserva el dominio, remitente, destinatario, encabezados y mensaje de error. La página de dominios y DNS explica el flujo de activación; la guía de entregabilidad ayuda a interpretar lo que ocurre después del envío.

Fuentes técnicas consultadas.

Siguiente paso

Configura con los valores reales de tu dominio.

Conecta el dominio, revisa la guía DNS de Connectia y valida cada resultado antes de endurecer DMARC.

Crear cuenta Revisar dominios y DNS

Preguntas frecuentes.

¿Necesito SPF, DKIM y DMARC al mismo tiempo?

Conviene usarlos juntos. SPF autoriza infraestructura, DKIM firma mensajes y DMARC relaciona esos resultados con el dominio visible para aplicar una política y generar reportes.

¿Puedo publicar más de un registro SPF?

No para el mismo dominio. Las fuentes autorizadas deben combinarse en un solo registro SPF. Publicar dos registros puede producir un error permanente de evaluación.

¿Qué significa DMARC p=none?

Es una política de observación. Solicita reportes y no pide al receptor poner en cuarentena o rechazar mensajes solo por DMARC. Se usa para conocer las fuentes antes de endurecer la política.

¿Un SPF pass significa que DMARC también pasa?

No necesariamente. Para aportar a DMARC, el dominio validado por SPF también debe quedar alineado con el dominio visible en From. DKIM puede ser la otra vía de alineación.

¿Qué es un selector DKIM?

Es el nombre que identifica una clave pública DKIM dentro del DNS. Permite que un dominio use y rote distintas claves, por ejemplo para proveedores diferentes.

¿Cuándo conviene cambiar DMARC a quarantine o reject?

Después de inventariar remitentes, verificar SPF y DKIM, revisar reportes y corregir fuentes legítimas. La aplicación debe ser gradual para no bloquear correo válido.

¿SPF, DKIM y DMARC garantizan llegar a la bandeja principal?

No. Autentican y protegen la identidad, pero la entrega también depende de reputación, volumen, contenido, destinatarios, rebotes, quejas y reglas del proveedor receptor.