fTLD DMARC: Buenas prácticas de seguridad del correo electrónico para instituciones financieras
por
Última actualización:
6 Tiempo de lectura: 6 min
Puntos clave
- DMARC fTLD refuerza la autenticación estricta combinando SPF, DKIM y alineación DMARC para validar remitentes legítimos.
- A olítica p=rechazar es obligatoria para todos los dominios .BANK y .INSURANCE, bloqueando el uso no autorizado del correo electrónico.
- DMARC mejora la entregabilidad mejorando la reputación del dominio y garantizando comunicaciones fiables.
- El cumplimiento apoya normativa de ciberseguridad financiera y reduce la exposición a pérdidas financieras relacionadas con el fraude.
- La supervisión continua de los informes y la alineación con los proveedores garantizan la protección y el cumplimiento continuos en todas las fuentes de correo electrónico.
Cada día, las organizaciones envían y reciben innumerables mensajes de correo electrónico, pero no todos son seguros. Para los bancos y los proveedores de seguros, mantener estos mensajes seguros es fundamental para proteger tanto a sus clientes como su reputación. Reconociendo esta necesidad, en 2023, fTLD introdujo DMARC para Dominios de Sufijo Público (PSD) para los Dominios de Nivel Superior (TLD) .BANK y .INSURANCE, que proporcionan una capa automática, a nivel de registro, de protección del correo electrónico.
¿Qué es PSD DMARC?
Public Suffix Domains DMARC (PSD DMARC) es una medida de seguridad que aplica reglas básicas de autenticación de correo electrónico en todos los dominios registrados bajo los TLDs .BANK y .INSURANCE. A diferencia del DMARC tradicional, que los propietarios de dominios deben implantar individualmente, el PSD DMARC funciona a nivel de registro, lo que garantiza una protección coherente en todos los dominios.
Este desarrollo tiene su origen en las normas establecidas por el Grupo de Trabajo de Ingeniería de Internet (IETF) y se documenta formalmente en RFC 9091. fTLD obtuvo la aprobación de la Corporación de Asignación de Nombres y Números de Internet (ICANN), lo que permitió la aplicación de esta salvaguardia automática.
¿Qué es un fTLD?
Registro fTLD es la autoridad de dominio para .BANCO y .SEGURO. Se trata de las extensiones de dominio más fiables y las únicas exclusivas para bancos, aseguradoras y productores. fTLD Registry pretende dotar a estos dominios de un sólido escudo contra los ciberataques y el fraude.
Lista de comprobación del cumplimiento de los dominios fTLD (.BANK / .INSURANCE)
Esta lista de comprobación ayuda a los registrantes a cumplir los requisitos de autenticación y cifrado (TLS) del correo electrónico para dominios fTLD tal y como se especifica en los documentos oficiales de fTLD.
1. Requisitos de autenticación del correo electrónico
Registros DNS obligatorios
Publicar un registro registro DMARC válido para el dominio (obligatorio tanto si el dominio envía correo electrónico como si no). Publicar al menos uno de los siguientes:
- SPF (Marco de directivas del remitente)
- DKIM (DomainKeys Identified Mail)
Requisitos de la política DMARC
| Uso del dominio | Política DMARC requerida | Notas |
|---|---|---|
| Dominio no utilizado para enviar correo electrónico | p=rechazar | Evita que se acepten correos falsos o no válidos |
| Dominio utilizado para enviar correo electrónico | p=rechazar (obligatorio para las operaciones en curso) | Puede comenzar con p=ninguno o p=cuarentena durante la aplicación, pero debe cambiar a p=rechazar lo antes posible, y no más tarde de 90 días. |
Configuración DMARC recomendada
Aunque no es un requisito, fTLD recomienda una alineación estricta para SPF y DKIM utilizando las etiquetas: adkim=s y aspf=s. Para dominios organizativos que publican DMARC, establezca una etiqueta sp: adecuada para definir la política de subdominios.
Ventajas de la configuración:
- La autenticación del correo electrónico evita los mensajes falsos o fraudulentos que afirman proceder de su dominio.
- Aumenta la confianza y la entregabilidad del correo electrónico
2. Requisitos de cifrado/seguridad de la capa de transporte (TLS)
Certificado digital
- Obtenga un certificado TLS válido para su dominio y todos los subdominios.
- Asegúrese de que no se utilizan componentes de cifrado prohibidos (véase la lista más abajo).
Aplicación de HTTPS
- Forzar todo el tráfico del dominio y subdominio a HTTPS (encriptado).
- Cualquier URL HTTP debe redirigirse automáticamente a HTTPS.
- La redirección debe originarse en la versión HTTPS del dominio fTLD.
- El dominio debe ser sólo HTTPS (sin acceso no cifrado).
| Tipo de conexión | Requisito | Notas |
|---|---|---|
| Conexiones web | Mantener TLS v1.2 o superior | Aunque las versiones inferiores pueden utilizarse temporalmente para contenidos educativos sobre higiene y actualizaciones del navegador, no lo recomendamos. |
| Correo electrónico de servidor a servidor | Ofrecer TLS v1.1 o superior con la máxima prioridad | Las versiones inferiores (TLS/SSL o sin cifrado) sólo se permiten cuando se comunica con dominios no TLD que no admiten cifrado. |
| Otros servicios | Utilice TLS v1.1 o superior | No es necesario desactivar TLS v1.0 en esta fase. |
| RFC 5746 (Extensión de indicación de renegociación de seguridad de la capa de transporte) | Debe aplicarse | Evita una forma específica de ataque man-in-the-middle en el que un atacante establece una conexión TLS con el servidor de destino, inserta contenido malicioso y luego lo fusiona con una nueva conexión TLS iniciada por un cliente. |
Componentes del conjunto de cifrado prohibidos
Las directrices desaconsejan utilizar o incluir cualquiera de los siguientes elementos en sus configuraciones o certificados TLS:
Anon, CBC, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA1, RC4, EXPORT, EXPORT1024, SRP
Ventajas de la configuración
- Garantiza una comunicación segura y cifrada a través de la web y el correo electrónico.
- Evita la manipulación, interceptación o escucha de datos
Resumen rápido sobre el cumplimiento
- Publicar y aplicar DMARC (p=reject), además de SPF/DKIM
- Implantar TLS v1.1+ en todos los servicios
- Redirigir todos los HTTP a HTTPS
- Utilice sólo suites de cifrado aprobadas
- Haga cumplir políticas DMARC en los 90 días siguientes a la instalación del correo electrónico
Por qué DMARC es fundamental para los fTLD
DMARC es fundamental para los dominios financieros debido a las siguientes ventajas que proporciona:
Evita el uso fraudulento de dominios
A p=rechazar es una instrucción directa a los servidores de correo de todo el mundo para que bloqueen cualquier correo electrónico que falle la autenticación. Esta acción impide eficazmente que los delincuentes suplanten directamente un dominio financiero en ataques de phishing.
Aumenta la entregabilidad del correo electrónico
Una configuración DMARC adecuada mejora la reputación del remitente y favorece la entrega fiable y sin problemas de comunicaciones oficiales.
Apoya el cumplimiento de la normativa
El sector financiero está lleno de leyes y reglamentos. DMARC sirve como un importante control técnico que ayuda a las organizaciones a satisfacer los requisitos de ciberseguridad.
Reduce la exposición a pérdidas financieras
La prevención de los ataques basados en el correo electrónico ayuda a una institución a evitar los graves costes asociados a las violaciones de datos, como multas reglamentarias, gastos de reparación y daños a la reputación.
Mejores prácticas de implantación de DMARC
La implementación de la autenticación del correo electrónico exige un enfoque metódico.
1. No se apresure a p=rechazar
La configuración final debe ser una política de rechazo (p=rechazar). Sin embargo, esta acción debe realizarse con precaución, tras un periodo de supervisión de sus dominios en p=none y p=quarantine. Incluso las directrices de los fTLD ofrecen un periodo de gracia de 90 días antes de la aplicación.
2. Confirme la alineación SPF y DKIM
Tanto SPF como DKIM requieren una configuración precisa para cada fuente de correo electrónico autorizada. Los dominios utilizados en estos mecanismos de autenticación deben coincidir con el dominio "De:" que ve un cliente.
3. Utilizar herramientas de análisis de informes DMARC
DMARC genera informes agregados (RUA) y forenses (RUF) que contienen datos vitales sobre el tráfico de correo electrónico de su dominio, pero no son intuitivos ni legibles por humanos. Un analizador de informes analizador de informes DMARC analiza esta información para ayudarte a descifrarla y comprenderla mejor.
4. Alinear las políticas de correo electrónico internas y de los proveedores
Todos los servicios de terceros que transmitan correo electrónico en nombre de su institución deben ajustarse a sus necesidades de autenticación. La comunicación con estos proveedores al respecto es fundamental.
Retos comunes
Las organizaciones pueden enfrentarse a algunos obstáculos técnicos durante el proceso de adopción de DMARC.
El descubrimiento de terceros remitentes
Un inventario exhaustivo de todos los servicios externos que envían correo electrónico puede ser una tarea compleja para grandes organizaciones y empresas con diversas pilas tecnológicas.
Retrasos de propagación del DNS
DMARC, SPF y DKIM se configuran a través de DNS. Las actualizaciones de estos registros requieren tiempo para propagarse por Internet, un factor que puede introducir retrasos en el calendario de implantación.
Gestión de datos de informes DMARC
Los datos XML en bruto de los informes DMARC son densos y voluminosos. Su análisis sin una plataforma especializada es excepcionalmente difícil e ineficaz.
Herramientas y proveedores recomendados
El volumen y la complejidad de los datos DMARC hacen que la gestión manual sea una estrategia poco práctica. Las plataformas especializadas son necesarias para una supervisión eficaz. Entre las características clave que se deben buscar en un proveedor se incluyen:
Visualización inteligente de informes
La plataforma debe traducir los datos XML en bruto en cuadros de mando claros y procesables que muestren tendencias y amenazas.
Identificación del remitente
El servicio debe clasificar automáticamente las fuentes de correo electrónico y ofrecer una orientación clara sobre los pasos de autenticación necesarios para cada remitente legítimo.
Alertas proactivas de amenazas
También es una gran ventaja que la plataforma ofrezca notificaciones en tiempo real sobre fallos de autenticación o nuevos intentos de suplantación para permitir una respuesta de seguridad rápida.
En PowerDMARC, nuestra plataforma ofrece un conjunto completo de servicios gestionados de autenticación de correo electrónico. Nuestro analizador DMARC transforma los complejos informes XML en gráficos legibles para el ser humano para una clara visibilidad de las amenazas. En PowerSPF optimiza dinámicamente los registros SPF complejos para evitar errores de validación y garantizar que todos los remitentes legítimos están autorizados.
Además, simplificamos la implantación de estándares avanzados como Hosted BIMI para mostrar su logotipo en los correos electrónicos y MTA-STS para cifrar el correo electrónico en tránsito.
Reflexiones finales
En última instancia, la adopción de DMARC es un requisito operativo básico para cualquier institución en el dominio .BANCO y .SEGURO TLD. Es una tecnología indispensable para la defensa de la marca de la institución, la protección de sus clientes y el cumplimiento de las obligaciones reglamentarias.
El camino hacia la plena conformidad comienza con una política de sólo supervisión para obtener una visibilidad completa del panorama del correo electrónico. A partir de ahí, una organización puede autenticar metódicamente a sus remitentes legítimos y avanzar hacia una política final de rechazo. La asociación con un experto en servicios DMARC puede reducir el riesgo de esta transición y garantizar una seguridad sostenida.
¿Listo para asegurar su dominio financiero? Explore nuestra solución DMARC Compliance y comience hoy mismo su viaje hacia el cumplimiento total.
Preguntas frecuentes
¿En qué cambian los requisitos DMARC de fTLD las cosas para el correo electrónico de mi dominio?
Cómo te afecte depende de tu configuración actual:
- Si ya dispone de un registro DMARC: Sus políticas e informes de correo electrónico existentes no cambiarán. PSD DMARC actúa simplemente como una potente copia de seguridad.
- Si NO tiene un registro DMARC: Se trata de una enorme mejora de la seguridad. La política DMARC de PSD da a los proveedores de correo electrónico instrucciones claras sobre qué hacer con los correos fraudulentos. Esta protección se aplica a todos tus dominios registrados, incluido tu sitio web principal, los dominios aparcados y cualquiera que poseas con fines defensivos.
¿Cambia DMARC fTLD los datos que se recogen de mi correo electrónico?
Si ya tiene su propia política DMARC, sus datos de informes no cambian. El principal cambio es que ahora los fTLD pueden recibir informes agregados de alto nivel para dominios que no se publican activamente (como registros defensivos) o para intentos de suplantación de dominios que no existen. Estos datos les ayudan a supervisar la salud de todo el sistema.
¿Cómo utiliza fTLD estos datos?
El objetivo es proteger a la comunidad .BANK y .INSURANCE. fTLD utiliza estos datos agregados para detectar amenazas emergentes, identificar actividades maliciosas, hacer cumplir las normas de seguridad y mejorar la estabilidad y seguridad generales de estos TLD.
¿Dónde puedo encontrar más información?
- La norma técnica: Puedes leer la especificación oficial del IETF, RFC 9091.
- Más información sobre PSD DMARC: Visite esta documentación oficial sobre PSD DMARC para obtener recursos adicionales.
Normas específicas de los fTLD: Puede consultar los requisitos de seguridad DMARC directamente en los sitios web de los registros .BANK y .INSURANCE BANK y .INSURANCE.
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.
Últimos mensajes de Yunes Tarada (ver todos)
- DMARCbis explicado: qué va a cambiar y cómo prepararse - 16 de abril de 2026
- El formato del número de serie de SOA no es válido: causas y cómo solucionarlo - 13 de abril de 2026
- Cómo enviar correos electrónicos seguros en Gmail: guía paso a paso - 7 de abril de 2026
