Última actualización: julio de 2026
En resumen: Al terminar esta guía tu dominio publicará un registro DMARC que indica a los servidores receptores qué hacer con el correo no autenticado — y te muestra mediante informes quién envía en tu nombre.
Requisitos previos
- Un servidor Mailcow en marcha
- SPF y DKIM deben configurarse primero — la documentación de Mailcow llama expresamente a DMARC “el último paso”, tras SPF y DKIM
- Acceso a la gestión de DNS de tu dominio
¿Qué es DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) combina SPF y DKIM en una política aplicable. Es un registro TXT bajo el subdominio _dmarc. En él defines qué debe hacer un destinatario con el correo que falla la comprobación (la política p), y dónde te envía los informes (la dirección rua).
Al autoalojar, DMARC cierra el círculo: SPF autoriza tu servidor, DKIM firma el mensaje, y DMARC convierte ambos en una regla que los servidores receptores aplican.
El punto de partida en Mailcow
Mailcow por sí mismo no define el registro DMARC — tu zona DNS está en tu proveedor de DNS. Pero la documentación de Mailcow documenta exactamente lo que va ahí, y señala un Asistente DMARC para crearlo. Su registro de ejemplo ya está en modo aplicación:
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.org"
Para un autoalojador con una configuración limpia, p=reject es el objetivo correcto — pero llega ahí por la rampa, no de inmediato.
La vía segura: none → quarantine → reject
p=none— observar, no bloquear nada. Empiezas aquí y recopilas informes:
v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de
p=quarantine— el correo sospechoso acaba en spam, opcionalmente escalonado conpct:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de
p=reject— aplicación, opcionalmente con alineación estricta y una política de subdominios:
v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; sp=reject; adkim=s; aspf=s
Solo avanza cuando los informes muestren que todas tus fuentes de envío legítimas pasan SPF/DKIM.
Guía paso a paso
1. Define la dirección de informe
La dirección rua recibe los informes agregados. Para el análisis, vale la pena un monitor DMARC como MARCo — hace legibles los informes XML diarios y te muestra qué fuentes aún no se autentican limpiamente.
2. Crea el registro TXT _dmarc en el proveedor de DNS
Crea un registro TXT en el host _dmarc. Dónde exactamente depende del proveedor de DNS — consulta nuestras guías para IONOS, Strato, Netcup o Hetzner DNS (en Hetzner el valor TXT debe ir entre comillas).
3. Lee los informes y endurece la política
Empieza con p=none, avanza vía quarantine a reject una vez que los informes estén limpios.
4. Espera hasta que el cambio esté activo
Los cambios de DNS tardan unas horas según el caché.
Las etiquetas más importantes
| Etiqueta | Significado |
|---|---|
v=DMARC1 | versión, debe ir al principio |
p= | política: none (observar), quarantine (spam), reject (rechazar) |
rua= | dirección para informes de estado agregados |
ruf= | dirección para informes forenses de fallo |
sp= | política separada para subdominios |
adkim= / aspf= | alineación (r relaxed, s strict) para DKIM y SPF respectivamente |
Verifica el resultado
Comprueba tu configuración con el escáner MXAudit gratuito — te muestra la política DMARC, SPF y DKIM de un vistazo.
Errores habituales
Copiar el ejemplo p=reject de Mailcow al pie de la letra. El ejemplo de la documentación está en modo aplicación. Si lo adoptas antes de que tus fuentes se autentiquen limpiamente, bloqueas tu propio correo. Primero p=none, lee los informes, luego endurece.
No definir rua. Sin una dirección de informe nunca ves qué fuentes fallan.
DMARC sin SPF/DKIM. DMARC comprueba los resultados de SPF y DKIM. Primero SPF y DKIM, luego DMARC.
Nombre de host incorrecto. El registro va en _dmarc — no en @ ni en el dominio a secas.
Más información
- Documentación de Mailcow: Configuración de DNS (consultado el 10 de julio de 2026)
- RFC 7489 — DMARC
