Dos direcciones, y has configurado una
Apuntar un dominio aquí exige un solo registro DNS. Ese registro — el MX — responde exactamente a una pregunta: ¿adónde va el correo dirigido a este dominio? Es todo lo que necesita un catch-all, y en cuanto se resuelve, el dominio funciona. Y en ese mismo momento solo está configurado a medias, porque un nombre de dominio se usa en dos direcciones y el registro MX no tiene nada que decir sobre la segunda.
La segunda dirección es la interesante. Nada en el protocolo de correo impide que un desconocido escriba tu dominio en la línea From: de un mensaje que envía desde su propia máquina. No necesita acceso a tu DNS, a tu registrador ni a tu buzón — la dirección de un mensaje es una afirmación, no una credencial, y siempre lo ha sido. Lo que decide si esa afirmación se cree es lo que tu dominio dice sobre quién tiene permiso para hacerla:
- El dominio que no dice nada
- Un servidor receptor no encuentra ni SPF ni política DMARC, y tiene que recurrir a sus propias heurísticas: reputación, contenido, cómo se ha comportado el dominio antes. Un dominio recién creado, sin historial y sin política, es más o menos lo ideal para falsificar, porque no hay nada que contradiga la falsificación ni nada que reprochar después.
- El dominio que dice que no
- Ese mismo servidor encuentra una política publicada que dice que ninguna máquina en ningún sitio está autorizada a enviar como este dominio, y que los fallos deben rechazarse. Deja de ser una cuestión de criterio. El mensaje se rechaza en la puerta, normalmente sin llegar siquiera a una carpeta de spam.
Esto no es una hipótesis sobre grandes marcas. Los dominios sin correo saliente se eligen precisamente porque no tienen política — un nombre que nadie protege, usado durante quince días y abandonado, vale más para quien envía correo no deseado que un nombre que se defiende.
Por qué te ahorras la parte que a todos los demás les lleva seis meses
Si has leído algo sobre DMARC antes, habrás leído que es un proyecto largo y cuidadoso. Ese consejo es correcto, y no habla de ti. Está escrito para un dominio que envía correo, y es largo por una razón: antes de poder decirle al mundo que rechace todo lo que falle, tienes que encontrar cada sistema que envía legítimamente en tu nombre y hacer que cada uno pase la verificación. En una organización normal esa lista es más larga de lo que nadie espera, y se descubre en lugar de conocerse de antemano:
- Publica una política que no hace nada.
p=nonepide a los receptores que informen pero no cambien nada, para que un remitente olvidado no quede cortado por la propia política. - Lee los informes durante semanas. El sistema de facturación, el helpdesk, la herramienta de boletines, la plataforma de contratación en la que alguien se registró en 2019 — cada uno aparece como una fuente que falla, y cada uno hay que autorizarlo o retirarlo.
- Endurece por fases. Pasa a
quarantine, espera, observa, y solo entonces areject, porque cada paso del endurecimiento puede detener en silencio correo del que alguien depende.
Cada uno de esos pasos existe para proteger a los remitentes legítimos de tu propia política. Un dominio que se ha apuntado a un buzón de solo recepción no tiene remitentes legítimos. La lista no es larga, ni difícil de descubrir, ni parcialmente desconocida — está vacía. Y una política que rechaza todo no puede romper un remitente que no existe.
También hay un argumento de segundo orden para ir directo al estado final. Un dominio que se queda en p=none publica una política que no pide nada, y un servidor receptor lo trata casi exactamente igual que un dominio sin ninguna política. El registro existe, así que parece resuelto — lo cual es peor que estar obviamente sin terminar, porque nadie vuelve para terminarlo.
Los tres registros
Los tres son registros TXT, y los tres van junto al MX que ya tienes. Los nombres están escritos como los pide la mayoría de los paneles DNS — relativos a la zona, con @ significando el propio dominio. Si el tuyo pide un nombre completamente cualificado, escribe en su lugar yourdomain.com, _dmarc.yourdomain.com y *._domainkey.yourdomain.com.
| Nombre | Tipo | Valor | Qué resuelve |
|---|---|---|---|
@ | TXT | v=spf1 -all | Ninguna máquina está autorizada a enviar correo con este dominio en el sobre. No unas cuantas: ninguna. |
_dmarc | TXT | v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s | Todo lo que llegue afirmando ser este dominio y no pueda probarlo debe rechazarse, y lo mismo vale para todos los subdominios. |
*._domainkey | TXT | v=DKIM1; p= | Toda clave DKIM por la que se pueda preguntar sobre este dominio está revocada, así que no hay forma de que una firma falsificada llegue a verificarse. |
Si tu proveedor exige que el valor vaya entre comillas, ponlas. Algunos paneles añaden las comillas por ti y acaban guardándolas dos veces, lo que produce un registro que ningún verificador puede leer — si un valor vuelve de dig con dos pares de comillas alrededor, eso es lo que ha pasado.
Los tres valores, listos para pegar. Cópialos en lugar de reescribirlos: un punto y coma que falte en el registro DMARC hace que toda la lista de etiquetas sea ilegible para el analizador, y una política ilegible se trata como si no hubiera ninguna política.
SPF — en el propio dominiov=spf1 -all
DMARC — en el nombre _dmarcv=DMARC1; p=reject; sp=reject; adkim=s; aspf=s
DKIM — en el nombre *._domainkeyv=DKIM1; p=
Qué hace en realidad cada palabra de esos registros
Cinco decisiones, y merece la pena saber cuál es cuál — sobre todo para que reconozcas, más adelante, cuál relajar si el dominio llega a enviar correo alguna vez.
-all- El final del registro SPF, y la única parte de él que importa aquí. Significa todo lo que no está listado arriba es una falsificación, y arriba no hay nada listado. La alternativa habitual,
~all, significa probablemente una falsificación, pero entrégala de todos modos y márcala — que es la respuesta correcta mientras todavía estás localizando tus propios remitentes, y la equivocada cuando tienes la certeza de que no hay ninguno. p=reject- Qué debe hacer un servidor receptor con el correo que afirma ser de este dominio y falla la verificación.
nonesignifica solo informar,quarantinesignifica tratarlo como sospechoso,rejectsignifica rechazarlo en la propia conversación SMTP. Reject es el que mantiene el mensaje completamente fuera de la vista de una persona. sp=reject- Lo mismo, aplicado a todos los subdominios — incluidos los que no existen. Sin ella, un falsificador usa
billing.yourdomain.com, que no tiene registros propios, y no hereda nada que lo detenga. Esta etiqueta toma por defecto lo que digap, así que el registro se comporta igual sin ella; se escribe explícitamente porque una política que no ves al releer el registro es una política que darás por hecho que falta. adkim=s,aspf=s- Alineación estricta. Exige que el dominio autenticado sea exactamente el dominio de la línea
From:, y no solo un pariente suyo — así un mensaje deanything.yourdomain.comno puede tomar prestado un aprobado que pertenecía al dominio padre. Relajada es el valor por defecto, y estricta es lo que debería decir un dominio que no tiene nada que autorizar. v=DKIM1; p=- Una clave pública DKIM sin ninguna clave dentro. La especificación es explícita en que una clave vacía significa revocada, así que cualquier firma que nombre cualquier selector bajo este dominio falla la verificación en lugar de ser ignorada. El comodín cubre cualquier nombre de selector que un falsificador pueda inventar, porque es él quien elige el nombre.
Y el registro que debe quedarse exactamente como está
Nada de lo anterior toca el correo entrante, y nada debería hacerlo. El registro MX es lo que convierte cada dirección del dominio en un buzón aquí, y nada de esto lo cambia:
Registro MX — sin cambios10 smtp.grabmail.io
Los tres registros nuevos y este responden preguntas distintas, así que no interactúan: SPF y DMARC los leen los servidores que deciden si aceptar el correo que afirma ser tuyo, y el MX lo leen los servidores que deciden dónde entregar el correo dirigido a ti. Un dominio con los cuatro es un dominio que recibe todo y no responde por nadie.
Comprobar tu trabajo, en tres comandos
El DNS no es un sitio para dar cosas por hechas. Cada uno de estos registros se publica para que lo lean desconocidos, lo que significa que puedes leerlo exactamente igual que ellos — sin cuenta, sin herramienta, sin ningún sitio donde pegar tu dominio:
$ dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX yourdomain.comSustituye por tu propio dominio. Lo que buscas es esto, salvo por los otros registros TXT que ya puedas tener en el nombre:
"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.Cuatro formas en que esto puede salir mal, más o menos por orden de frecuencia:
- El primer comando no responde nada en absoluto
- El registro todavía no se ha propagado, o se añadió al nombre equivocado. Los registros TXT sobre el propio dominio van en
@, no enwww— un panel que por defecto usa el último nombre que editaste suele ser el culpable. - Vuelven dos registros SPF
- Un dominio solo puede tener exactamente uno. Dos no es más estricto que uno — es un error permanente, y un servidor receptor que encuentra dos trata la comprobación SPF como rota, no como fallida. Si ya tenías un registro SPF, edita ese en lugar de añadir un segundo.
- La línea DMARC vuelve, pero nada la hace cumplir
- Lee el valor con atención: tiene que empezar por
v=DMARC1, y las etiquetas van separadas por punto y coma. Un registro al que le falta la etiqueta de versión, o uno en el que un punto y coma se convirtió en una coma, no es una política más débil — es una ilegible, que cuenta como si no hubiera ninguna política. - La respuesta del MX ha cambiado
- No debería haber cambiado. Si la línea MX ahora falta, o muestra un simple punto, o lista un host que no es
smtp.grabmail.io, para y restáuralo antes de hacer cualquier otra cosa — es el registro del que depende tu buzón.
La parte que casi todo el mundo pasa por alto: los subdominios
DMARC y SPF no dividen el espacio de nombres de la misma forma, y esa diferencia es por donde se filtra un dominio protegido con esmero. sp=reject sí cubre de verdad todos los subdominios, existan o no. SPF no funciona así en absoluto: se busca sobre el nombre exacto que aparece en el sobre, y un nombre sin registro SPF propio no tiene registro SPF — no hereda el del dominio padre.
| Lo que usa un falsificador | SPF en ese nombre | Qué lo detiene |
|---|---|---|
yourdomain.com | Encontrado: -all, así que la comprobación falla. | SPF y DMARC juntos. Este es el caso para el que se escribieron los tres registros de arriba. |
billing.yourdomain.com | Ninguno, a menos que publiques uno. SPF no devuelve un fallo, sino la ausencia de un resultado. | DMARC por sí solo, mediante sp=reject — que basta, y por eso esa etiqueta no es opcional. |
yourdomaln.com, un dominio similar | Irrelevante. No es tu dominio. | Nada que puedas publicar. Nombre distinto, dueño distinto, registros distintos. |
DMARC ya cubre la segunda fila por sí solo, así que esto es un refuerzo redundante y no una brecha — pero un registro SPF comodín cuesta una sola línea y cierra el hueco también en la capa SPF, lo cual importa para los receptores que comprueban SPF y no implementan DMARC:
SPF comodín — un registro TXT más* TXT v=spf1 -all
Un comodín DNS solo responde para los nombres que no tienen registros propios. Si mail.yourdomain.com ya tiene algún registro TXT, el comodín no se consulta para ese nombre y tendrías que publicar ahí el registro SPF explícitamente. Para un dominio que solo se usa como catch-all, esa situación es lo bastante rara como para merecer saberlo, sin merecer planificarla.
Los informes, y si merece la pena tenerlos
DMARC tiene un lado de informes: añade una etiqueta rua y los receptores participantes te envían un resumen diario de todo lo que afirmó ser tu dominio y qué pasó con ello. Es la única parte de DMARC que te dice algo que no sabías ya, y en un dominio apuntado aquí no cuesta nada recopilarlos, porque la dirección a la que van puede ser una dirección del propio dominio:
DMARC con informes — sustituye el dominiov=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com
Enviar los informes a una dirección del mismo dominio evita una parte de la especificación que suele pillar a la gente: si rua nombra una dirección de un dominio distinto, ese otro dominio tiene que publicar un registro que autorice recibir tus informes, y hasta que no lo haga la mayoría de los remitentes no enviará ninguno. Mismo dominio, no hace falta ese registro, nada que se pueda hacer mal. Merece la pena saber qué es lo que llega antes de activarlo:
- Son XML, comprimidos en gzip, como adjunto. No un resumen que te lees con el café. Los dominios pequeños reciben un puñado al día de los grandes proveedores de correo, cada uno de unos pocos kilobytes; querrás algo que los descomprima y los lea.
- Vacío es el buen resultado. Un dominio que no envía nada debería generar informes que no listen más que fallos, y una semana tranquila significa que ahora mismo nadie te está falsificando — que es información, y la única forma de obtenerla.
- Llegan como correo normal. Aquí eso significa un buzón normal: legible en el navegador y a través de la API como cualquier otra cosa, y se elimina a los 5 días junto con todo lo demás.
Si prefieres no recopilarlos en absoluto, deja la etiqueta fuera por completo. Un registro DMARC sin rua es un registro perfectamente válido y protege exactamente igual de bien; los informes son cómo te enteras de lo que pasa, no cómo se hace cumplir la política.
Lo que esto no hace
Estos registros son limitados, y tener claros sus bordes es la diferencia entre un control en el que confías correctamente y uno en el que confías mal. Cuatro cosas que no cubren:
- No filtran tu propio buzón
- SPF y DMARC en tu dominio son instrucciones para los servidores que reciben correo de ti. Los leen los sistemas de correo de otras personas, nunca el tuyo, y no tienen ningún efecto sobre lo que aparece en el catch-all. Lo que llega sigue siendo lo que el mundo entero envíe a una dirección cuya única credencial es conocerla.
- No detienen un nombre en la línea From
- Un mensaje que dice
Your Company <attacker@gmail.com>pasa todas las comprobaciones, porque el dominio que se autenticó es realmente el del atacante. DMARC protege el dominio, no el nombre para mostrar que va delante — y en un móvil, el nombre para mostrar es a menudo lo único que se ve. - No tocan un dominio similar
- Un dominio a un carácter de distancia del tuyo es el dominio de otra persona con los registros de otra persona. Nada de lo que publiques lo alcanza. Eso es un problema de registrador y de monitorización, y es realmente un problema distinto.
- No hacen privado el buzón
- Aquí una dirección sigue sin tener contraseña: quien la conozca puede leerla, que es el trato que ofrece todo el servicio. Tu propio dominio elimina el adivinar, no el leer — la versión honesta de eso está en la guía sobre dominios catch-all.
Hacerlo, de principio a fin
Todo el trabajo, en el orden que deja el dominio funcionando en cada paso:
- Confirma primero el MX.
dig +short MX yourdomain.comdebería respondersmtp.grabmail.ioy nada más. Arregla eso antes de añadir nada, porque el resto no vale de nada en un dominio que no está recibiendo. - Añade el registro SPF en
@, a menos que ya haya uno — en cuyo caso edítalo, ya que dos son un error y no un ajuste más estricto. - Añade el registro DMARC en
_dmarc, directamente con la política estricta. Aquí no hay ningún despliegue por fases que hacer ni nada que se rompa por saltárselo. - Añade el registro DKIM comodín en
*._domainkey, y el registro SPF comodín si quieres cerrar la capa de subdominios por partida doble. - Relee los cuatro con
dig, contra un resolutor público, una vez que el TTL haya tenido tiempo de caducar. - Envíate algo. Manda correo a una de tus propias direcciones del dominio desde donde sea y abre el buzón. Si llega, el lado entrante ha sobrevivido al cambio, que es la única regresión que merece la pena comprobar.
Con eso el dominio queda terminado: acepta cualquier dirección que se te ocurra inventar en él, y no responde por nadie en absoluto. Si todavía no has conectado el dominio, empieza por la guía del catch-all — es un registro y los mismos cinco minutos — y vuelve a esta página después, que es el orden que no deja nada a medias.
Preguntas
¿De verdad necesito un registro DKIM si nunca firmo nada?
No lo necesitas para que funcione tu propio correo, porque no hay ninguno. Lo publicas para que un falsificador no pueda inventar un nombre de selector, firmar un mensaje con su propia clave y que se verifique — la clave vacía es una respuesta permanente de revocada a cualquier nombre de selector que elija. Es un registro, nunca necesita mantenimiento, y cierra el único camino que dejan abierto SPF y DMARC.
¿Reducirá algo de esto el spam que llega a mi catch-all?
No, y merece la pena ser tajante con esto porque es la expectativa más habitual. Estos registros rigen el correo que afirma venir de tu dominio. El correo que llega a tu dominio no se ve afectado — cada dirección en él sigue aceptando todo, que es lo que es un catch-all. Si el problema es el correo no deseado en una dirección concreta, la solución es dejar de usar esa dirección, no cambiar estos registros.
¿Y si quiero enviar correo desde este dominio más adelante?
Entonces cambias dos cosas, en este orden: autoriza al nuevo remitente en el registro SPF antes de enviar nada, y añade su clave DKIM en el selector que te pida. El comodín *._domainkey no bloquea un selector real — un registro explícito en ese nombre exacto se encuentra primero, y el comodín solo se consulta para los nombres que no tienen ninguno. Nada de esto te deja acorralado; solo significa que el dominio está cerrado por defecto en lugar de abierto por defecto.
¿Debería empezar con p=none o p=quarantine para ir sobre seguro?
Esas fases existen para proteger a remitentes que todavía no has encontrado. Tú no tienes remitentes, así que no hay nada que las fases tengan que proteger ni nada que la política estricta pueda romper. Empezar con none en un dominio de solo recepción no reduce el riesgo — publica un registro que pide a los receptores que no hagan nada, y deja el dominio tan falsificable como estaba antes, con la desventaja añadida de parecer terminado.
¿Afecta añadir estos registros a mi registro MX o a mi buzón?
En absoluto. Son registros separados que responden preguntas separadas, y ningún servidor receptor consulta tu SPF o tu DMARC al decidir dónde entregar el correo dirigido a ti. Lo único que rompería el buzón es cambiar el propio MX — por eso el registro MX nulo que recomiendan las guías de dominios aparcados tiene su propia sección más arriba.
¿Cuánto tarda en surtir efecto?
Los registros nuevos se pueden usar en cuanto se propagan, que normalmente son minutos. Cambiar un registro que ya tenías tarda lo que tardaba su antiguo TTL, porque los resolutores que obtuvieron el valor anterior lo conservan hasta que caduca. Si estás a punto de editar un registro existente, bajar su TTL un día antes es el truco que hace rápido el cambio — y si ya lo has editado, esperar es la única opción.
¿Necesito un registro distinto para cada subdominio?
Para DMARC, no: sp=reject los cubre todos, incluidos los subdominios que nunca han existido. Para SPF, estrictamente sí — un subdominio no hereda el registro SPF de su dominio padre — pero un único registro TXT comodín en * responde por cualquier nombre que no tenga registros propios, que en un dominio catch-all son todos.
¿Puedo dirigir los informes DMARC a una dirección de Gmail en su lugar?
Puedes, pero entonces el otro dominio tiene que autorizarlo: una dirección rua fuera de tu propio dominio exige un registro en yourdomain.com._report._dmarc.gmail.com, que no puedes publicar porque ese nombre no es tuyo. Por eso el ejemplo de arriba envía los informes a una dirección de tu propio dominio, donde no hace falta autorización y el correo simplemente cae en el catch-all.
¿Cómo sé que esto realmente está funcionando?
La prueba directa es un informe: activa rua y los resúmenes nombran cada fuente que intentó enviar en tu nombre y qué hizo cada receptor al respecto. Sin informes, releer los registros con dig desde un resolutor público es la comprobación práctica — la política la hacen cumplir los servidores que la leen, así que un registro que se resuelve correctamente para desconocidos es un registro que funciona.
