Los 7 registros DNS que todo remitente autohospedado necesita

El email es inusual: un setup completo de remitente tiene siete registros DNS distintos repartidos entre tres o cuatro tipos de registro. Pierda uno y el cable igual mueve mensajes, pero los proveedores de buzones lo degradarán silenciosamente a la carpeta de spam. Publique los siete y cruza el umbral del "todo lo que Google pide" descrito en /guide/email-deliverability.

El orden importa: SPF y DKIM deberían aterrizar antes de que DMARC empiece a exigir alineación, de lo contrario el correo legítimo termina en cuarentena. La regla estándar entre vendors también es "espere a que el DNS propague" — permita al menos 30 minutos entre publicar un registro y pedirle al proveedor de buzones que reverifique.

Los registros MX (RFC 1035 §3.3.9) le indican al mundo dónde entregar el correo entrante de su dominio. Aunque su dominio de envío sea "solo saliente" (no lee respuestas en él), igual se requiere un registro MX — muchos proveedores de buzones bajan la reputación de los dominios sin MX, partiendo del supuesto de que los remitentes legítimos aceptan respuestas. Basta un único registro apuntando a cualquier servidor de correo alcanzable, aunque ese servidor solo entregue a un buzón postmaster.

SPF (RFC 7208) es un único registro TXT que lista qué IPs están autorizadas a enviar por el dominio. La regla dura: el total de lookups DNS recursivos debe quedarse bajo 10 (RFC 7208 §4.6.4). Cada include: consume uno; los includes anidados cuentan de forma acumulada. Los mecanismos ip4: / ip6: cuestan cero lookups, así que colapse includes viejos en rangos IP explícitos si la cuenta empieza a trepar.

Termine con -all (hard-fail) una vez que haya verificado que todas las fuentes legítimas de envío están cubiertas. Si todavía no está seguro, arranque con ~all (soft-fail) y endurezca a -all tras dos semanas de reportes DMARC limpios.

DKIM (RFC 6376) publica la mitad pública de un keypair de firma como registro TXT en {selector}._domainkey.{domain}. El "selector" es un identificador que usted elige — específico del vendor o arbitrario. Para SES, AWS le entrega tres CNAMEs que resuelven a registros TXT gestionados por AWS (de modo que AWS pueda rotar las claves sin que usted toque el DNS):

Para Postal o Postfix+OpenDKIM autohospedado, usted genera el keypair localmente, configura al MTA para firmar y publica la mitad pública como TXT:

Sea cual sea el camino, verifique con dig TXT {selector}._domainkey.{domain} antes de dar DKIM por terminado.

DMARC (RFC 7489) va en _dmarc.{domain}. Saltarse la rampa p=none es el error más común — saltar directo a p=reject contra un dominio cuyos flujos de correo todavía no entiende del todo va a rebotar silenciosamente correo legítimo (forwarders, mailing lists, remitentes de CRM de terceros).

Lea los reportes agregados XML diarios que aterrizan en su buzón rua entre etapas. Herramientas como el DMARC analyzer de Postmark o Parsedmarc autohospedado los visualizan; el XML crudo es denso pero legible.

Por defecto, las URLs de open-pixel y click-tracking de AcelleMail vienen del dominio primario de su instalación. A los proveedores de buzones les gusta ver dominios raíz consistentes entre el From, los clics de enlace y la URL de baja — todos sobre el mismo dominio registrado. En cuanto a branding, los enlaces apuntando a tracker.suempresa.com también transmiten más confianza que los enlaces apuntando a links.acellemail.com.

Una vez que el CNAME resuelve, AcelleMail reescribe todas las URLs de click-tracking de los mensajes salientes para usarlo. El dominio del enlace de baja sigue la misma regla (y el mismo CNAME).

MTA-STS (RFC 8461) les dice a los demás remitentes "exija siempre TLS al entregar a mi MX". Sin él, un atacante en el camino puede degradar un handshake TLS-capaz a texto plano. Con él, el servidor remitente se niega a entregar si no se puede establecer TLS. La implementación es un único registro TXT apuntando a un archivo de policy alojado:

Corra la policy en mode: testing durante la primera semana, después flipee a mode: enforce. Muchos bulk senders se saltan MTA-STS — desplegarlo es una señal de confianza gratuita.

BIMI (Brand Indicators for Message Identification) es el más joven de los siete y el único que todavía no es RFC finalizado, pero está soportado en producción por Gmail, Yahoo, Apple Mail, Fastmail y otros clientes. El trato: publicar un registro TXT que apunta a un logo SVG y (opcionalmente) a un Verified Mark Certificate (VMC), y los clientes que lo soportan muestran el logo junto a sus mensajes en el listado de la bandeja.

Precondiciones: una policy DMARC de al menos p=quarantine (BIMI no se honra bajo p=none), y el SVG debe ser SVG Tiny Portable / Secure (SVG-PS). La aceptación varía: Gmail exige un VMC pago ($1.500/año vía DigiCert / Entrust) para mostrar en el listado completo de la bandeja; Yahoo y Apple aceptan BIMI sin VMC. Se reportan habitualmente subas de open rate del 5-20% en case studies publicados.

Después de publicar, envíese un mensaje de prueba y revise las cabeceras. Gmail web: abra el mensaje, haga clic en el menú de tres puntos, "Mostrar original". Busque:

Tres veredictos pass es la barra. Cualquier cosa menos — fail, softfail, neutral — significa que un registro está mal, o que el DNS todavía no propagó, o que el cuerpo del correo se está modificando en tránsito (raro). Crucífiquelo contra la spec canónica de la cabecera Authentication-Results (RFC 8601) si un veredicto es ambiguo.