¿Necesito SPF, DKIM y DMARC, o solo uno?

Los tres. Desde febrero de 2024 Google y Yahoo exigen a todo remitente en volumen tener SPF, DKIM y un registro DMARC. Además funcionan como cadena — el DMARC solo hace enforcement cuando SPF o DKIM pasa y alinea con tu From.

¿Qué cuenta como "envío en volumen"?

Google y Yahoo trazan la línea cerca de 5.000 mensajes por día a sus usuarios. Pero cumplir los requisitos es barato y es buena higiene, así que vale publicar los tres incluso por debajo de ese número.

¿Alcanza con DMARC en p=none para cumplir?

Sí para el requisito — Gmail y Yahoo aceptan p=none. Pero p=none solo monitorea; no frena la falsificación. Cuando tus reportes agregados muestren que el correo legítimo pasa, sube a p=quarantine y luego a p=reject.

¿Por qué mi SPF pasa pero el DMARC falla?

El DMARC necesita alineamiento, no solo un pase. Si un SaaS envía por ti con su propio dominio de return-path, el SPF autentica ese dominio — no tu From — así que el DMARC ve un desalineamiento y falla. Se arregla con un return-path alineado o con DKIM.

¿Cómo encuentro mi selector DKIM?

Está en el encabezado DKIM-Signature de un mensaje que enviaste, en la etiqueta s=. Comunes son google, selector1/selector2 (Microsoft), s1, k1 y dkim. Escríbelo arriba si la detección automática vuelve vacía.

¿Qué es el límite de 10 consultas del SPF?

El RFC 7208 limita la evaluación del SPF a 10 consultas DNS. Cada include: cuesta una. Si te pasas, el SPF devuelve permerror, que muchos receptores tratan como falla — así que sumar remitentes puede romper la autenticación sin avisar.

¿Pasar los tres garantiza llegar a la bandeja de entrada?

No — pasas la valla de autenticación, que es un prerrequisito, no una garantía. La reputación de la IP de envío, el contenido, la higiene de la lista y el engagement igual deciden bandeja o spam. Pero no ganas eso sin la autenticación en verde.

Verificar Autenticación de Correo

La autenticación de correo es el conjunto de registros DNS — SPF, DKIM y DMARC — que le permite al servidor que recibe confirmar que un mensaje realmente vino de tu dominio y decidir qué hacer cuando no fue así. Desde febrero de 2024, Google y Yahoo exigen los tres a quien envía correo en volumen. Este verificador lee los tres a la vez y te dice exactamente cuáles están en su lugar y cuáles faltan.

Cómo usarlo

1
Ingresa el dominio de envío
Usa el dominio de tu From — la parte después del @. Si envías como [email protected], verifica acme.com.
2
Agrega un selector DKIM si lo conoces
El DKIM vive en selector._domainkey.tudominio. La verificación detecta selectores comunes sola, pero si vuelve vacía y conoces el tuyo (google, s1, k1, dkim…), escríbelo.
3
Lee SPF, DKIM y DMARC
Verde: el registro está publicado y es coherente. La línea de veredicto arriba te dice si pasas la valla de Gmail/Yahoo, y cada falla enlaza a la herramienta que la corrige.

Cómo funciona

Por qué los tres, y por qué se volvió urgente

Por años SPF, DKIM y DMARC fueron "buena práctica" — recomendados, casi nunca exigidos. Eso cambió en febrero de 2024. Google y Yahoo ahora exigen a quien envía en volumen (a grandes rasgos, quien manda 5.000+ mensajes por día a direcciones Gmail o Yahoo) publicar SPF, firmar con DKIM y tener un registro DMARC, además de mantener las quejas de spam bajo 0,3% y ofrecer baja en un clic. Si no cumples, el correo se limita o se rechaza de plano.

El efecto práctico es que un dominio que enviaba bien en 2023 puede pegar contra la pared en 2024 sin ningún cambio de tu lado — los receptores movieron la valla. Revisar los tres juntos importa porque son una cadena: el DMARC solo hace su trabajo cuando SPF o DKIM pasa Y alinea con tu dominio From, así que un SPF verde sin DMARC igual te deja falsificable y fuera de las reglas.

SPF: quién puede enviar

El SPF es un solo registro TXT que empieza con v=spf1 y lista los servidores autorizados a enviar por tu dominio — tu propio servidor de correo y cada SaaS que envía en tu nombre (una mesa de ayuda, una plataforma de newsletter, tu CRM). El receptor compara la IP del servidor que conecta contra esa lista.

La trampa que rompe el SPF en silencio es el límite de consultas: el RFC 7208 §4.6.4 permite un máximo de 10 consultas DNS al evaluar el registro. Cada include: (y la mayoría de proveedores te da uno) cuenta. Suma suficientes servicios y la evaluación devuelve permerror, que muchos receptores tratan como falla — así que sumar una herramienta nueva puede romper la autenticación de todo sin avisar.

DKIM: la firma criptográfica

El DKIM prueba que el cuerpo del mensaje no fue alterado y que realmente vino de un servidor con tu clave privada. Tu plataforma firma cada mensaje que sale; el receptor busca la clave pública en un registro TXT en selector._domainkey.tudominio y verifica la firma. El selector es solo una etiqueta que te deja tener varias claves a la vez (una por proveedor, o vieja y nueva durante una rotación).

El largo de la clave importa: 1024 bits es el piso viejo y 2048 bits es la recomendación actual. Si el DKIM vuelve como ausente aquí, casi siempre es que el selector no se publicó o el registro quedó cortado — los proveedores DNS a veces parten mal los valores TXT largos, y una clave pública rota falla en la verificación igual que si no hubiera clave.

DMARC: la política que amarra todo

El DMARC es el registro que convierte a SPF y DKIM en una decisión real. Le dice al receptor qué hacer cuando un mensaje falla en la autenticación — p=none (solo reportar), p=quarantine (mandar a spam) o p=reject (rechazar) — y a dónde enviar los reportes agregados en la dirección rua=. Gmail y Yahoo aceptan p=none para cumplir el requisito, pero p=none no protege a nadie: el correo falsificado igual llega.

Lo que casi todos olvidan es el alineamiento. Un mensaje puede pasar el SPF y aún así fallar el DMARC si el dominio que el SPF autenticó no coincide con el dominio del From — común cuando un SaaS envía por ti usando su propio return-path. El DMARC exige que SPF o DKIM pase Y alinee con el From visible. Por eso "el SPF pasa pero el DMARC falla" es un resultado tan frecuente y confuso.

Cómo leer los resultados

Resultado	Qué significa	Qué hacer
SPF — verde	Hay un registro v=spf1 publicado y queda bajo 10 consultas.	Nada que hacer — revisa de nuevo al agregar un remitente.
SPF — ámbar (más de 10 consultas)	La evaluación pasa el límite del RFC y puede dar permerror.	Aplana o quita los include: que no uses.
DKIM — rojo (sin clave)	No hay clave pública en el selector revisado.	Publica el registro DKIM de tu proveedor, o escribe el selector correcto.
DMARC — ámbar (p=none)	Publicado pero sin enforcement; la falsificación igual funciona.	Sube a p=quarantine cuando los reportes estén limpios.
DMARC — rojo (falta)	Sin DMARC — no cumples el requisito de Gmail/Yahoo.	Publica al menos v=DMARC1; p=none; rua=mailto:tu@dominio.