DMARC. Paso a paso.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) es el requisito previo innegociable para BIMI. Un dominio con p=none nunca mostrará un logo en Gmail o Apple Mail, independientemente de lo bien configurado que esté el archivo SVG. Esta guía cubre el proceso completo desde la implementación inicial hasta la aplicación total.

Requisitos previos

Antes de crear un registro DMARC, confirma que ya tienes configurado lo siguiente:

1. Registro SPF — Un registro TXT en tu dominio raíz que especifica qué servidores de correo están autorizados a enviar en tu nombre. Ejemplo: v=spf1 include:_spf.google.com -all
2. Registro DKIM — Una clave pública publicada en DNS que los servidores receptores utilizan para verificar las firmas de tus correos. Tu proveedor de correo la genera.
3. Acceso a DNS — Acceso de escritura a la zona DNS de tu dominio (Cloudflare, Route 53, GoDaddy o el panel de control de tu registrador).

DMARC requiere que al menos SPF o DKIM estén correctamente configurados y alineados con el dominio del campo From: para funcionar.

Paso 1: Crear un registro de monitorización (p=none)

Comienza con una política de solo monitorización. Esta registra los fallos de autenticación sin afectar la entrega del correo.

_dmarc.tudominio.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Referencia de etiquetas:

| Etiqueta | Obligatoria | Descripción | |---|---|---| | v=DMARC1 | Sí | Versión del protocolo. Debe ir primero. | | p=none | Sí | Política: solo monitorización, sin acción. | | rua=mailto: | Recomendada | Dirección de correo para informes agregados. | | pct=100 | Opcional | Porcentaje de correo sujeto a la política (por defecto: 100). |

Publica este registro y espera de 48 a 72 horas para la propagación de DNS.

Paso 2: Leer los informes agregados

Los informes agregados (RUA) llegan como archivos XML adjuntos, normalmente una vez al día por cada fuente de envío. Muestran:

• Qué direcciones IP enviaron correo utilizando tu dominio
• Si SPF y DKIM pasaron o fallaron
• Cuántos mensajes se enviaron desde cada fuente

Qué buscar: Cualquier servicio de envío legítimo (tu ESP, CRM, sistema de tickets, plataforma de marketing) que esté fallando en la alineación de SPF o DKIM debe corregirse antes de pasar a la aplicación. Avanzar a p=reject con fallos de alineación sin resolver provocará el bloqueo de correo legítimo.

Fuentes comunes que requieren configuración separada de DKIM/SPF: Mailchimp, Salesforce, HubSpot, Zendesk, SendGrid, Google Workspace, Microsoft 365.

Paso 3: Avanzar a p=quarantine

Una vez que todas las fuentes de envío legítimas pasen la autenticación, actualiza la política para poner en cuarentena los mensajes que fallen:

_dmarc.tudominio.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

Comienza con pct=25 para aplicar la política de cuarentena solo al 25% de los mensajes que fallen. Monitoriza durante una o dos semanas. Si no se está poniendo en cuarentena correo legítimo, aumenta a pct=100.

Paso 4: Avanzar a p=reject

Aplicación total. Los mensajes no autenticados se rechazan directamente y nunca se entregan.

_dmarc.tudominio.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Este es el requisito mínimo para BIMI. Gmail y Apple Mail no procesarán tu registro BIMI a menos que tu dominio tenga p=quarantine o p=reject con pct=100. Una política de p=none es invisible para BIMI — el logo nunca aparecerá, independientemente de lo correctamente configurado que esté el resto.

Por qué p=none bloquea BIMI

La especificación BIMI exige que los proveedores de correo verifiquen que el dominio remitente tiene una política DMARC aplicada antes de mostrar el logo. La razón: un logo es una señal de confianza. Mostrar un logo para un dominio que no ha aplicado controles anti-suplantación permitiría a los atacantes mostrar logos verificados en correos de phishing. p=none no proporciona ninguna aplicación, por lo que los proveedores rechazan procesar el registro BIMI.

Alineación: El detalle que la mayoría de guías omiten

DMARC solo pasa cuando el dominio autenticado se alinea con el dominio del encabezado From:. Hay dos modos de alineación:

• Relajada (por defecto): El dominio organizacional debe coincidir. mail.ejemplo.com se alinea con ejemplo.com.
• Estricta: El dominio exacto debe coincidir. mail.ejemplo.com no se alinea con ejemplo.com.

Para BIMI, utiliza alineación relajada (adkim=r; aspf=r) a menos que tengas una razón específica para usar estricta. La alineación estricta causa fallos con subdominios y servicios de envío de terceros.

Referencia completa del registro

_dmarc.tudominio.com  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; pct=100"

| Etiqueta | Valor | Significado | |---|---|---| | p=reject | Reject | Bloquear correo no autenticado | | sp=reject | Reject | Aplicar la misma política a subdominios | | adkim=s | Strict | La alineación DKIM debe ser exacta | | aspf=s | Strict | La alineación SPF debe ser exacta | | rua= | Email | Destino de informes agregados | | pct=100 | 100% | Aplicar a todo el correo |

Próximos pasos

Una vez que tu dominio alcance p=reject:

1. Genera tu SVG para BIMI — Utiliza makeBIMI™ para producir un archivo de logo compatible con W3C SVG Tiny P/S. Gratuito, sin necesidad de crear cuenta.
2. Ejecuta una auditoría DMARC — La herramienta makeBIMI Domain Audit verifica el estado de tus registros DMARC, SPF y BIMI en tiempo real.
3. Obtén un certificado — Para mostrar el logo en Gmail, se requiere un VMC o CMC. veriBIMI℠ gestiona todo el proceso de certificación, incluyendo la gestión de aplicación DMARC, preparación del SVG y solicitud ante la CA.