La decisión de crear un registro DMARC suele llegar después de una incidencia: mensajes suplantados, avisos de Gmail, cambios DNS solicitados por un proveedor o informes con resultados SPF y DKIM dispares. Si todavía estás configurando el sistema, empieza por nuestra guía de correo empresarial para coordinar el dominio, los buzones y el DNS desde el principio.
Una configuración incorrecta no siempre produce un fallo inmediato. El registro puede existir sin que los receptores lo utilicen como esperas: nombre incorrecto, política inválida, informes que no llegan o autenticación sin alineación. La suplantación puede continuar y el correo legítimo seguir llegando a spam; publicar DMARC no garantiza la entrega.
Esta guía explica cómo crear un registro DMARC, qué etiquetas revisar, qué publicar en _dmarc.yourdomain.com y cómo evaluar el paso de la supervisión a las restricciones.
Qué publicas al crear un registro DMARC
Publica un TXT en _dmarc.yourdomain.com que empiece por v=DMARC1 e incluya una política válida: p=none, p=quarantine o p=reject. DMARC solicita un tratamiento al receptor cuando ningún mecanismo proporciona un resultado válido y alineado con From. Basta con que SPF o DKIM pase con alineación para superar DMARC.
Este es un ejemplo mínimo válido:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;Publica una política sin restricciones DMARC, pero no solicita informes agregados porque falta su destino. Los receptores pueden seguir aplicando filtros locales.
Como alternativa inicial con informes puedes usar:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100Si las pruebas justifican aplicar restricciones, sustituye la política anterior, no añadas otra:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100RFC 7489 exige que v sea la primera etiqueta y que p esté presente. Sin ellas en el formato válido, los receptores no pueden aplicar la política como tal. Consulta los detalles en RFC 7489.
Dónde crear el registro DMARC en DNS
El registro no se publica en la raíz, sino en _dmarc. Para example.com, el nombre completo de consulta es _dmarc.example.com. Si lo publicas con otro nombre, no estará disponible en esa consulta DMARC.
Un error habitual es usar @ o introducir _dmarc.example.com en un panel que espera solo _dmarc y añade el dominio automáticamente. Comprueba si tu proveedor pide un nombre relativo o completo.
Después de publicarlo, consulta el DNS desde fuera del panel:
dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.comDebe existir una única política DMARC válida que empiece por v=DMARC1, no varias. Las cadenas TXT fragmentadas pueden formar un mismo registro; tampoco hay que confundir otros TXT con políticas DMARC.
En TrekMail, puedes añadir el dominio, copiar los valores indicados y utilizar las comprobaciones DNS disponibles, contrastándolas con consultas externas. Consulta cómo añadir un dominio, los registros DNS necesarios y la comprobación del estado DNS. El panel no demuestra por sí solo la autenticación de todos los flujos.
Etiquetas para crear un registro DMARC
Muchas etiquetas son opcionales. Empieza por v, p y, si quieres solicitar informes, rua. Ajusta la alineación cuando exista una necesidad concreta, después de verificar la configuración básica.
| Etiqueta | Obligatoria | Función | Consejo práctico |
|---|---|---|---|
v | Sí | Identificador de versión | Debe ser DMARC1 y aparecer primero |
p | Sí | Política para mensajes que fallan DMARC | Empieza con none y evalúa después quarantine y reject según las pruebas |
rua | No | Destino de informes agregados | Configura un destino supervisado; los informes dependen de los receptores participantes y pueden requerir autorización externa |
ruf | No | Destino de informes de fallos | Opcional, con soporte limitado y posibles datos sensibles; revisa privacidad y acceso |
adkim | No | Modo de alineación DKIM | r es el valor predeterminado; cambiarlo exige revisar los remitentes |
aspf | No | Modo de alineación SPF | Empieza con r; usa s solo si necesitas alineación estricta y has probado sus efectos |
pct | No | Porcentaje solicitado de aplicación a mensajes que fallan | 100 no garantiza cobertura universal; el muestreo depende del receptor y no impone restricciones con una política de supervisión |
sp | No | Política heredada por subdominios | Se aplica desde el dominio organizativo cuando el subdominio no tiene su propio registro; si falta, se hereda la política principal |
Un registro válido con p=none pero sin rua no solicita informes agregados. Eso no elimina los registros y otras herramientas de diagnóstico que puedas tener, pero limita la observación mediante informes DMARC.
Cómo elegir la política DMARC
Si no has validado todos los remitentes, suele ser útil empezar con p=none. Evalúa p=quarantine después de investigar los informes y corregir los servicios. Considera p=reject tras contrastar las fuentes desconocidas con el inventario, los registros y las pruebas de flujos críticos poco frecuentes.
| Política | Tratamiento solicitado | Cuándo evaluarla | Riesgo principal |
|---|---|---|---|
p=none | Sin restricciones por DMARC; siguen existiendo filtros locales | Observación inicial | No solicita bloquear los mensajes suplantados |
p=quarantine | Tratamiento restrictivo, según la política local del receptor | Tras validar remitentes y flujos | El correo legítimo mal configurado puede sufrir restricciones sin recuperación garantizada |
p=reject | Rechazo solicitado, sujeto a excepciones locales | Configuración validada y riesgo evaluado | Los mensajes legítimos que fallan pueden ser rechazados |
Las directrices de Google citadas requieren SPF y DKIM para los remitentes masivos y que al menos uno pase alineado con el dominio de From para DMARC. No conviertas posibles cambios futuros en requisitos actuales; verifica las condiciones y su ámbito en las preguntas frecuentes sobre las directrices de envío de Google.
DMARC no es solo una casilla de configuración. Si tu CRM usa tu dominio en From, pero firma y envía con dominios del proveedor no alineados, DMARC puede fallar aunque el proveedor diga que la autenticación está activada.
Paso a paso: crear un registro DMARC
Organiza una implantación gradual: inventario, política de supervisión y restricciones después de las verificaciones. La ausencia de sorpresas en los informes no basta para demostrar que todos los remitentes funcionan.
- Enumera los servicios que envían con tu dominio, incluidos Google Workspace, Microsoft 365, soporte, CRM, formularios, facturación y boletines.
- Verifica SPF y DKIM en cada servicio y al menos un mecanismo válido y alineado. DMARC no los sustituye ni repara. Publica un SPF válido por dominio real del sobre y respeta su límite de mecanismos y modificadores que requieren DNS, también en evaluaciones anidadas.
- Crea un buzón como
dmarc@yourdomain.como usa un servicio de informes, con supervisión, acceso adecuado y autorización DNS en el destino externo cuando corresponda. - Publica inicialmente una política
p=none. - Investiga los informes agregados disponibles y contrástalos con los remitentes conocidos y sus registros.
- Corrige los dominios autenticados y su alineación con From; no basta con modificar la política DMARC.
- Evalúa
p=quarantinedespués de probar los flujos. - Evalúa
p=rejectcuando las pruebas, incluidos los procesos poco frecuentes, justifiquen el cambio.
Este ejemplo de supervisión para un dominio empresarial en 2026 debe adaptarse a tu destino de informes:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100Si utilizas reenvíos, consulta cómo reenviar el correo del dominio a Gmail. El reenvío puede hacer fallar SPF. DKIM puede mantener DMARC si sigue válido y alineado y se conservan los datos firmados tras la canonicalización. ARC puede informar excepciones locales del receptor, pero no constituye un resultado de autenticación DMARC válido por sí mismo.
Errores habituales al crear un registro DMARC
Muchos problemas nacen de la configuración: nombre incorrecto, varias políticas DMARC, destinos de informes inválidos o la expectativa de que DMARC arregle SPF y DKIM. Publica una política válida y compruébala desde fuera.
Estos errores se repiten con frecuencia:
1. Publicar en la raíz en vez de _dmarc.
Un registro en @ no aparece en la consulta DMARC del dominio.
2. Publicar varias políticas DMARC en TXT.
RFC 7489 indica que varias políticas DMARC impiden continuar el procesamiento. Mantén una única política por nombre de consulta; varios fragmentos de un TXT no son varias políticas.
3. Activar p=reject desde el principio.
Un servicio olvidado puede provocar el rechazo de restablecimientos de contraseña, facturas o respuestas de soporte legítimas.
4. Apuntar rua a un buzón inexistente.
Puedes perder informes que sí se enviaron. La ausencia de informes tampoco demuestra que los receptores los hayan generado.
5. Esperar que DMARC repare los reenvíos.
DMARC necesita SPF o DKIM válido y alineado. Si SPF falla al reenviar, DKIM debe seguir siendo válido y alineado para aportar ese resultado.
Ejemplo: la web envía confirmaciones por un proveedor SMTP, soporte por otro y marketing por un tercero. Publicas
p=rejectsin revisar los tres. Un flujo pasa y dos fallan; sus destinatarios pueden rechazar mensajes que tus clientes necesitan. La política no corrigió los servicios pendientes.
Si configuras el dominio desde cero, nuestra guía para crear correo con tu dominio explica el contexto de DNS y buzones junto con SPF, DKIM y DMARC.
Gestión dispersa o centralizada de DMARC en varios dominios
Las hojas de cálculo, los accesos a cada registrador y los TXT de incidencias antiguas complican la coordinación. Una interfaz central y comprobaciones DNS pueden ayudar a identificar diferencias, pero cada dominio y servicio de envío necesita una configuración verificada.
| Gestión dispersa | Gestión con TrekMail |
|---|---|
| Revisar cada registrador para identificar los valores DNS vigentes | Usar la interfaz multidominio disponible en el plan |
| Comparar TXT manualmente y dar por terminada la propagación | Consultar DNS y contrastar discrepancias, sin garantizar propagación completa |
| Coordinar SPF, DKIM y DMARC en herramientas separadas | Usar el flujo DNS disponible y verificar mensajes de cada servicio real |
| Pagar por usuario incluso con pocos buzones por dominio | Evaluar la oferta multidominio desde $3.50 al mes, según límites y condiciones actuales |
Según el plan, TrekMail ofrece varios dominios, almacenamiento compartido, buzones IMAP, herramientas de migración, catch-all, reenvío y SMTP gestionado o propio. La copia IMAP no sustituye el cambio de MX ni migra todas las aplicaciones. La oferta descrita de Nano permite hasta 10 dominios sin coste con SMTP propio; los planes de pago parten de $3.50 al mes bajo sus condiciones. Consulta las prestaciones y precios actuales en la página de precios de TrekMail.
Centralizar puede facilitar las comprobaciones y reducir la coordinación entre cinco proveedores y veinte pestañas. No demuestra automáticamente el estado de todos los flujos ni garantiza menos incidencias o ahorro.
Comprobaciones finales antes de aplicar restricciones DMARC
Antes de aplicar restricciones, verifica SPF y DKIM de los remitentes autorizados, al menos un resultado válido y alineado por flujo, el destino de informes y una única política DMARC válida en _dmarc. DMARC no sustituye una autenticación correcta.
Repasa esta lista:
- Una única política DMARC en TXT.
- Nombre
_dmarc, relativo o completo según el proveedor DNS. - Valor que empieza por
v=DMARC1; p=.... ruaapunta a un buzón o servicio válido, supervisado y autorizado cuando corresponda.- Un SPF válido por dominio del sobre, con autorizaciones consolidadas y el límite aplicable a mecanismos o modificadores que requieren DNS, incluidas evaluaciones anidadas.
- DKIM configurado y verificado en las plataformas compatibles, con alineación en al menos un mecanismo por flujo.
- Las consultas externas muestran la política esperada.
- Empieza con
nonesi todavía necesitas validar remitentes y flujos poco frecuentes.
TrekMail puede centralizar dominios personalizados, buzones IMAP, comprobaciones DNS, elección de SMTP y herramientas de migración según el plan. Eso no elimina el seguimiento continuo ni garantiza la entrega. Consulta trekmail.net y evalúa las prestaciones junto con tus necesidades operativas.
