AWS Route 53 es un lugar rápido y fiable para publicar los tres registros DNS que
autentican tu correo —SPF, DKIM y DMARC—, pero su consola tiene un par de
convenciones que despistan: los nombres de registro totalmente cualificados y el
entrecomillado doble obligatorio de cada valor TXT. Los registros en sí son
idénticos a los que publicarías en cualquier proveedor de DNS; lo único que
cambia es el editor. Esta guía te muestra exactamente dónde, en la consola de
Route 53, añades cada registro, qué escribir en el campo de nombre de registro
para el dominio raíz frente a _dmarc frente a tu selector DKIM, y el detalle
del entrecomillado que rompe en silencio las claves DKIM largas si se te pasa.
La respuesta rápida#
Los tres registros son registros TXT normales dentro de tu zona alojada de Route 53. Lo que cambia de un proveedor a otro es únicamente la convención de nomenclatura y el formato de entrada:
- SPF — un registro TXT en la raíz de tu dominio. En Route 53 dejas el campo de nombre de registro en blanco, y el registro se aplica al ápice de la zona.
- DKIM — un registro TXT en
<selector>._domainkey.tudominio.com. Escribes solo la parte<selector>._domainkeyen el campo de nombre de registro; tanto el selector como el largo valor de la clave provienen de tu proveedor de correo. - DMARC — un registro TXT en
_dmarc.tudominio.com. Escribes_dmarcen el campo de nombre de registro y Route 53 añade la zona por ti.
Los valores son específicos de cada proveedor, así que no los escribas a mano. Genera tu línea SPF con el generador de registros SPF, tu línea de política con el generador de registros DMARC, y copia tu clave DKIM directamente del panel de tu plataforma de correo. Para los conceptos que hay detrás de cada registro, la explicación de SPF, DKIM y DMARC cubre qué hacen y por qué importan.
Cómo se corresponden SPF, DKIM y DMARC con los registros de Route 53#
Route 53 organiza el DNS en torno a una zona alojada: una zona por dominio. Dentro de una zona, cada registro tiene un nombre totalmente cualificado relativo al ápice de la zona, y la consola lo deja explícito: junto a la casilla "Nombre del registro" muestra el sufijo de tu dominio, y lo que escribas se antepone a él. Ese único detalle explica la ubicación de los tres registros.
| Registro | Escríbelo en "Nombre del registro" | Nombre resultante |
|---|---|---|
| SPF | (déjalo en blanco) | example.com |
| DKIM | s1._domainkey | s1._domainkey.example.com |
| DMARC | _dmarc | _dmarc.example.com |
Dónde añadir registros en la consola de Route 53#
El recorrido es el mismo para los tres registros. Abre la consola de Route 53, elige Zonas alojadas en la navegación de la izquierda y haz clic en la zona del dominio desde el que envías correo. Haz clic en Crear registro y, si la consola ofrece un conmutador entre "Creación rápida" y "Asistente", la creación rápida es la vía más sencilla para una única entrada TXT.
En el formulario de creación de registro configuras tres cosas: el Nombre del
registro (el prefijo, según la tabla anterior), el Tipo de registro (TXT
para los tres) y el Valor. Deja la política de enrutamiento en la opción
predeterminada "Enrutamiento simple": son registros meramente informativos, no
enrutamiento de tráfico. El TTL puede quedarse en el valor predeterminado (300 o
3600 segundos está bien); un TTL más corto solo significa que los cambios se
propagan más rápido mientras haces pruebas.
Publicar tu registro SPF en el dominio raíz#
SPF autoriza qué servidores pueden enviar correo usando tu dominio. Crea un registro TXT, deja el nombre del registro en blanco para que caiga en el dominio raíz, y pega tu valor SPF. Un valor típico tiene este aspecto:
"v=spf1 include:amazonses.com include:_spf.google.com ~all"
Fíjate en las comillas dobles que lo envuelven: Route 53 espera que los valores
TXT vayan entrecomillados, y la consola suele añadirlas si se te olvidan, pero es
más limpio incluirlas tú mismo. El ~all del final es un fallo suave (soft-fail);
-all es un fallo duro (hard-fail) que indica a los receptores que rechacen de
plano a los remitentes no autorizados.
Dos reglas importan más que ninguna otra cosa aquí. Primero, publica
exactamente un registro SPF. Si un segundo registro TXT en la raíz también
empieza por v=spf1, el SPF queda inválido y todas las comprobaciones fallan; así
que si ya envías a través de otro servicio, fusiona todos los mecanismos
include: en una sola línea en lugar de añadir un registro nuevo. Segundo,
mantente dentro de diez búsquedas DNS; cada include: cuenta, y pasarte
provoca un error SPF permanente. El
generador de registros SPF construye una única
línea válida a partir de los proveedores que realmente usas y te avisa del límite
de búsquedas.
Añadir tu registro DKIM en el selector#
DKIM publica la mitad pública de una clave de firma para que los receptores
puedan verificar que tus mensajes no han sido falsificados ni alterados. Tu
proveedor de correo te da dos cosas: un selector (una etiqueta corta como
s1, google o una cadena aleatoria) y el largo valor de la clave pública.
Publicas esa clave como un registro TXT en <selector>._domainkey.
Crea un registro TXT, escribe el selector más ._domainkey en el campo de
nombre de registro —por ejemplo s1._domainkey— y pega el valor que te dio tu
proveedor. El valor tiene este aspecto:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
No inventes ni edites este valor: cópialo tal cual desde los ajustes de autenticación de tu plataforma de correo, porque la clave pública debe coincidir exactamente con la clave privada que hace la firma. Algunos proveedores (Amazon SES entre ellos) emiten tres registros DKIM basados en CNAME en lugar de un único registro TXT; en ese caso crea tres registros CNAME con los nombres y destinos que te faciliten, siguiendo la misma regla de "escribe el prefijo, Route 53 añade la zona". Sea cual sea la forma que use tu proveedor, los valores vienen de él, nunca de ti.
Publicar tu registro DMARC en _dmarc#
DMARC vincula SPF y DKIM a la dirección "From" visible, indica a los receptores
qué hacer con el correo que falla y te envía informes. Crea un registro TXT,
escribe _dmarc en el campo de nombre de registro y pega una política inicial:
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Empieza en p=none. Ese es el modo de monitorización: no cambia nada sobre
cómo se gestiona tu correo, pero activa los informes agregados diarios que hacen
posible un despliegue seguro. Solo después de que los informes confirmen que cada
flujo legítimo se autentica de forma alineada deberías endurecerlo a
p=quarantine y luego a p=reject. Publicar p=reject el primer día es la vía
más rápida para mandar tu propio correo a spam. El
generador de registros DMARC construye una
política sintácticamente correcta, y la
guía completa paso a paso para desplegar DMARC cubre
en detalle la secuencia de monitorizar-y-luego-aplicar; una vez que empiecen a
llegar los informes,
leer los informes agregados de DMARC explica
cómo actuar sobre ellos.
El detalle del entrecomillado que rompe las claves DKIM largas#
Este es el detalle específico de Route 53 en el que merece la pena detenerse, porque falla en silencio. Una sola cadena TXT de DNS está limitada a 255 caracteres. Los valores cortos —tu línea SPF, tu política DMARC— caben holgadamente dentro de una única cadena entrecomillada. Pero una clave pública DKIM de 2048 bits mide más de 255 caracteres, así que no puede vivir en una sola cadena.
La respuesta de Route 53 es dividir el valor en varias cadenas entrecomilladas, cada una de 255 caracteres o menos, colocadas juntas en el mismo valor de registro. Los resolvers de DNS concatenan las cadenas de vuelta en una sola clave. En la casilla de Valor de la consola, eso se ve como dos cadenas entrecomilladas adyacentes:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"
El truco: las dos cadenas se concatenan en una única clave continua sin ningún espacio entre ellas, así que no añadas caracteres en el punto de división y mantén ambas cadenas en un único valor de registro TXT en lugar de dejar que se conviertan en dos registros separados. Si tu comprobación DKIM falla justo después de la configuración y la clave parece completa, una división incorrecta es el culpable habitual. Pega la clave entera, deja que la consola o tu herramienta gestionen el troceado donde puedan, y verifica el resultado en vez de fiarte de él.
Gestionar los registros como código#
Route 53 es una opción favorita para los equipos que gestionan la infraestructura
como código, y no tienes por qué usar la consola en absoluto. La CLI de AWS
publica registros con aws route53 change-resource-record-sets, pasando un lote
de cambios en JSON que especifica el nombre, el tipo TXT, el TTL y el valor. En
Terraform, cada registro es un recurso aws_route53_record:
resource "aws_route53_record" "dmarc" {
zone_id = aws_route53_zone.primary.zone_id
name = "_dmarc.example.com"
type = "TXT"
ttl = 3600
records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}
Las mismas reglas se trasladan aquí: un registro SPF en el ápice, el valor DKIM
directamente de tu proveedor, DMARC empezando en p=none. El límite de 255
caracteres por cadena también se aplica aquí: una clave DKIM larga sigue teniendo
que trocearse en varias cadenas dentro del valor del registro, así que aplica el
registro y verifica el resultado publicado.
Verifica antes de aplicar#
Los cambios de DNS en Route 53 suelen propagarse en un minuto o dos, aunque tu
TTL y las cachés intermedias pueden alargarlo. Una vez que los registros están en
vivo, confirma que los tres resuelven y se analizan correctamente con el
comprobador de SPF, DKIM y DMARC: detecta un
registro SPF ausente o duplicado, una clave DKIM que se dividió o pegó mal, y una
política DMARC con un error de sintaxis, que son las tres cosas con más
probabilidad de salir mal en Route 53. Solo después de que el comprobador esté en
verde deberías empezar a subir la política DMARC desde none hacia reject.
Conseguir que los tres estén publicados y pasen es lo que satisface los requisitos de remitente de Google y Yahoo para remitentes masivos. Pero recuerda el límite: la autenticación demuestra quién eres, no que seas un buen remitente. Un mensaje perfectamente autenticado a una lista llena de direcciones muertas sigue aterrizando en spam. La guía de entregabilidad de correo cubre el trabajo de reputación e higiene de listas que convierte una identidad de confianza en colocación en la bandeja de entrada.
Preguntas frecuentes#
¿Qué pongo en el campo de nombre de registro de Route 53 para el registro SPF raíz?#
Déjalo en blanco. Route 53 aplica un registro con nombre vacío al ápice de la
zona —el propio dominio raíz—, que es exactamente donde debe ir el registro TXT
de SPF. Establece el tipo en TXT y pega tu único valor v=spf1 .... No escribas
@ ni el nombre de tu dominio en el campo; un nombre de registro vacío es la
forma en que Route 53 expresa la raíz.
¿Por qué falla mi registro DKIM en Route 53 cuando la clave parece correcta?#
Casi siempre por el límite de 255 caracteres por cadena. Una clave DKIM de 2048 bits es demasiado larga para una sola cadena TXT, así que Route 53 exige dividirla en varias cadenas entrecomilladas que los resolvers concatenan. Si la división añade un espacio de más, pierde un carácter o las piezas acaban como dos registros separados en vez de un solo valor, la clave no validará. Vuelve a pegar la clave completa, mantenla como un único valor de registro y confírmalo con un comprobador de DKIM.
¿Escribo _dmarc o el _dmarc.example.com completo en el nombre del registro?#
Escribe solo _dmarc. Route 53 muestra el sufijo de tu dominio junto al campo y
lo añade automáticamente, de modo que _dmarc se convierte en _dmarc.example.com.
Escribir el nombre completo produciría un _dmarc.example.com.example.com
duplicado, que ningún receptor consultará jamás. La misma regla de anteposición
se aplica a tu selector DKIM.
¿Puedo gestionar SPF, DKIM y DMARC en Route 53 con Terraform o la CLI?#
Sí. Cada registro es un recurso aws_route53_record en Terraform o un lote de
cambios para aws route53 change-resource-record-sets en la CLI. Los nombres,
tipos y valores de los registros son idénticos a los que introducirías en la
consola, y se aplica la misma división de 255 caracteres para las claves DKIM
largas. Genera primero los valores, luego confírmalos en el código y verifica el
resultado publicado.
Route 53 hace que los tres registros sean sencillos una vez que conoces sus convenciones de nomenclatura y entrecomillado, pero la autenticación es solo el billete de entrada a la bandeja de entrada. Construye tus registros con las herramientas gratuitas y luego limpia la lista que hay detrás de ellos con el comprobador de correo gratuito: detecta dominios muertos, erratas y trampas de spam antes de que reboten, porque una identidad de confianza solo gana colocación cuando la lista para la que firma está limpia.
