Seguridad de correo electrónico práctica: implementar DMARC, DKIM y SPF con Postfix y flujo de pruebas

Si implementa DMARC, DKIM y SPF, es más que cambios en DNS: es un proyecto operativo que requiere inventario, diseño del MTA, estrategia de firmas, gestión de reportes y rollbacks seguros. Este Runbook está dirigido a administradores, ingenieros de sistemas y operadores: procedimientos pragmáticos, comandos de verificación, errores típicos y una estrategia de retroceso clara.

Implementación de DMARC, DKIM y SPF: breve aclaración de términos: SPF, DKIM, DMARC en la práctica

SPF (Sender Policy Framework) es un registro TXT en DNS que indica qué servidores pueden enviar en nombre del dominio del Envelope‑From; protege principalmente contra la suplantación directa del Return‑Path. DKIM (DomainKeys Identified Mail) firma los mensajes criptográficamente; el receptor verifica la firma frente a una clave pública en DNS. DMARC (Domain‑based Message Authentication, Reporting & Conformance) enlaza SPF y DKIM y comprueba además Alignment, es decir, si los dominios verificados coinciden con el dominio visible en el campo From:. Sin Alignment la efectividad frente al engaño visual es limitada.

Requisitos previos y preparación organizativa

Antes de cambiar registros, cree un inventario completo de todos los remitentes de correo: relays centrales Postfix, aplicaciones (p. ej. instancias Zammad), servicios en la nube (M365, Google, herramientas de marketing), monitorización, alertas de backup y proveedores externos. Aclare permisos de escritura en DNS, la política de TTL (reducir temporalmente el TTL antes de los cambios) así como posibles configuraciones de Split‑Horizon‑DNS que puedan devolver respuestas distintas interna/externalmente.

Secuencia recomendada para el despliegue

1. Activar DMARC con p=none y RUA habilitado, para hacer visibles los remitentes reales.
2. Consolidar SPF: un registro limpio por dominio, respetando el límite de búsquedas.
3. Activar DKIM en todo el entorno, idealmente firmando de forma centralizada en el relay (OpenDKIM).
4. Monitorizar y luego endurecer DMARC por etapas: quarantine (posiblemente con pct) → reject.

SPF: reglas prácticas y errores típicos

SPF es técnicamente simple, pero en entornos grandes se vuelve complejo rápidamente. Reglas importantes:

• Solo un registro TXT SPF por dominio (varios generan PermError).
• Limite las búsquedas DNS (máximo 10); evite cadenas de include profundas.
• Documente cada include y verifique remitentes de terceros (newsletters, scanners).

Ejemplo de SPF

; SPF für example.tld
example.tld. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailerprovider.net ~all"

Verificar SPF

dig +short TXT example.tld
# oder für vollständige Ausgabe
dig TXT example.tld +noall +answer

Si tiene muchos includes, considere el SPF‑flattening con precaución o cree subdominios de envío (p. ej. mailer.example.tld) con sus propios registros SPF.

DKIM con Postfix: OpenDKIM como Milter

En Postfix, DKIM se implementa típicamente mediante un milter. OpenDKIM es una herramienta extendida y estable. Decida: firma centralizada en el relay (unifica claves/rotaciones) o descentralizada por host (mejor asignación de responsabilidades).

Estrategia de claves

Recomendación: RSA 2048 como mínimo; 1024 se considera obsoleto. Use un esquema de selectores con componente temporal (p. ej. s2026q3) para la rotación. Almacene las claves privadas de forma segura (permisos de archivo, restricciones de acceso) y establezca fechas periódicas de rotación.

OpenDKIM: instalación y configuración básica

sudo apt-get update
sudo apt-get install -y opendkim opendkim-tools

; /etc/opendkim.conf (Auszug)
Syslog                  yes
SyslogSuccess           yes
Canonicalization        relaxed/simple
Mode                    sv
Socket                  local:/run/opendkim/opendkim.sock
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

sudo install -d -m 0750 -o opendkim -g opendkim /etc/opendkim/keys/example.tld
cd /etc/opendkim/keys/example.tld
sudo -u opendkim opendkim-genkey -b 2048 -s s2026q3 -d example.tld
sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.tld
sudo chmod 0640 /etc/opendkim/keys/example.tld/s2026q3.private
# DNS prüfen
dig @1.1.1.1 +short TXT s2026q3._domainkey.example.tld

Integración con Postfix

# /etc/postfix/main.cf (Ausschnitt)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock

Importante: Durante la fase de despliegue debe establecer milter_default_action=accept para que fallos del milter no bloqueen la entrega.

DMARC: activar los informes, endurecer la política más adelante

Publique DMARC como un registro TXT en _dmarc.example.tld. Empiece con p=none y un receptor rua para recopilar informes agregados y detectar problemas.

Registro inicial

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; fo=1; pct=100"

Los informes RUA son archivos XML (a menudo en ZIP) que contienen información sobre los resultados SPF/DKIM, las IPs y el volumen. Utilice un parser (p. ej. herramientas de código abierto como pydmarc) o un collector externo; preste atención al almacenamiento, la retención y la protección de datos de la información de IP incluida.

Comprender el alineamiento

DMARC exige que SPF o DKIM estén alineados con el dominio visible en el campo From:. Las causas comunes de fallos de DMARC son:

• Envelope‑From pertenece a un tercero (proveedor), From: muestra el dominio de la empresa.
• DKIM firma con una d= distinta del dominio visible en From:.

Soluciones: ajustar el Envelope‑From (p. ej. mediante relay), firmar con DKIM de modo que d= sea el dominio de From:, o enviar desde subdominios con su propio DMARC.

Flujo de pruebas: medible y controlado

Un enfoque iterativo protege frente a la inhabilitación de sistemas legítimos. Modelo de procedimiento recomendado:

1) Línea base: DMARC p=none, 48–72 horas de informes

Recoja los datos RUA, catalogue las IPs emisoras y los servicios. Marque las fuentes inciertas y priorice su resolución según volumen y criticidad.

2) Depurar SPF

Reduzca los includes, cree subdominios de envío si es necesario y pruebe después de cada cambio con resolvers públicos.

3) Activar DKIM en todos los flujos

Asegúrese de que todos los caminos productivos pasen por el salto firmante. Envíe correos de prueba desde cada aplicación y verifique los encabezados en el receptor.

4) Cuarentena con control pct

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=50"

Aumente la severidad de la política de forma gradual y supervise buzones canario (Gmail, M365) así como el backlog de soporte.

5) Rechazo

Establezca p=reject solo cuando todos los remitentes legítimos estén alineados de forma estable y pueda responder con prontitud a los tickets de soporte. Planifique SLAs claros para análisis & reversión.

Comandos prácticos de prueba y diagnóstico

Para enviar correos de prueba es útil swaks (Swiss Army Knife SMTP); con él puede comprobar si se generan firmas:

# Beispiel: Testmail via lokalen Relay
swaks --to test@example.org --from zammad@example.tld --server localhost:25 --header "Subject: DKIM Test"

# DKIM/Header prüfen (auf Empfänger oder lokalen Mailbox-Store)
grep -i "DKIM-Signature|Authentication-Results" /var/mail/testuser | sed -n '1,80p'

Comprobaciones DNS:

dig @1.1.1.1 TXT s2026q3._domainkey.example.tld
dig @8.8.8.8 TXT _dmarc.example.tld +noall +answer
# Über TCP testen, falls große TXT-Records Probleme machen
dig @1.1.1.1 TXT s2026q3._domainkey.example.tld +noall +answer +tcp

Comprobar informe RUA (descomprimir ZIP y formatear):

unzip -p report-12345.zip | xmllint --format - | sed -n '1,200p'

Reglas operativas específicas para Zammad

Las instancias Zammad suelen enviar correos críticos del sistema (notificaciones de tickets, alertas de SLA). Compruebe los siguientes puntos:

• Configure Zammad para que los correos salientes pasen por el relay central de Postfix (Admin‑UI o systemsendmail). Eso garantiza la firma DKIM central y el alineamiento DMARC.
• Compruebe From: frente a Envelope‑From: Zammad puede usar remitentes distintos por defecto; configure dominios de remitente consistentes o utilice un subdominio de mailer.
• Realice envíos de tickets de prueba y verifique completamente las cabeceras en el receptor (Received, DKIM‑Signature, Authentication‑Results).
• Automatice comprobaciones puntuales: un trabajo de monitorización que envíe correos de prueba periódicamente y verifique la firma y Authentication‑Results reduce los riesgos operativos.

Casos problemáticos y resolución de problemas

DMARC fail obwohl SPF/DKIM pass

A menudo se debe a falta de alineamiento. Compruebe si DKIM d= coincide con el dominio From o si el Return‑Path pertenece a la misma dominio organizacional.

DKIM pass bei einigen Providern, fail bei anderen

A menudo la causa es la entrega DNS: split‑horizon, truncamiento de TXT o caché. Pruebe con distintos servidores DNS públicos y por TCP para detectar problemas de fragmentación.

Fallo de Milter

sudo systemctl status opendkim --no-pager
sudo ss -xlpn | grep opendkim
journalctl -u opendkim -n 200 --no-pager
journalctl -u postfix -n 200 --no-pager

Durante la fase de despliegue los errores de Milter no deberían impedir la entrega (milter_default_action=accept); sin embargo, en la fase operativa deben ser monitorizados y solucionados.

Reenvío, listas de correo y ARC

SPF suele fallar en reenvíos simples porque el servidor de reenvío no figura en su SPF. Dos opciones prácticas:

• Usar DKIM — las firmas suelen sobrevivir mejor al reenvío.
• Soportar Authenticated Received Chain (ARC) — ARC es un mecanismo de cabeceras que documenta la autenticidad a través de listas de correo/servidores de reenvío y ayuda a los receptores a aceptar mensajes legítimos pese a resultados SPF/DKIM rotos.

ARC es especialmente útil en entornos con muchas listas de correo o reenvíos internos.

Seguridad, gestión de claves e higiene operativa

Las claves privadas DKIM son secretos operativos: asegure los ficheros, restrinja los permisos de archivo y proteja las copias de seguridad. Documente las fechas de rotación y pruebe los cambios de clave en una zona de staging. Implemente un control de cambios para modificaciones de DNS (Git + CI para archivos de zona o un despliegue DNS guiado por tickets).

Plan de reversión concreto (breve y operativo)

1. Si se producen fallos críticos de entrega, establezca DMARC rápidamente a p=none:

# Beispiel: neuer DMARC-Record
_dmarc.example.tld. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=100"

# DNS-Änderung prüfen
dig @1.1.1.1 TXT _dmarc.example.tld +noall +answer
# Postfix/OpenDKIM Status prüfen
sudo systemctl status postfix opendkim --no-pager

A continuación inicie el análisis de causas: qué remitentes fallaron, qué servicios se vieron afectados, y documente las lecciones aprendidas en su registro de cambios.

Mantenimiento y monitorización a largo plazo

Planifique revisiones periódicas: analizar los informes RUA (p. ej., semanalmente), rotación de claves DKIM semestralmente, inventario SPF trimestralmente. Automatice alertas para aumentos súbitos de volumen o de tasas de error en los informes DMARC.

Conclusión

Implementar DMARC, DKIM y SPF es un proyecto operativo: inventario, gobernanza DNS, estrategia central de firma, flujo de pruebas y rutas claras de retorno son decisivos. Comience con el reporting DMARC, depure SPF, active DKIM en el relay y endurezca DMARC por fases. La documentación, la monitorización y el mantenimiento periódico hacen que la medida sea sostenible en el tiempo — especialmente para aplicaciones como Zammad, que envían notificaciones críticas.

DMARC, DKIM & SPF: operación, monitorización y automatización

Una vez implementada la técnica básica, el éxito depende de la operación continua. Cambie la perspectiva de proyecto puntual a servicio permanente: gobernanza DNS, alta disponibilidad del milter, canalización RUA, ciclo de vida de claves y automatización de rollback son frentes operativos que debería planificar desde temprano.

Proveedor DNS y operación de cambios

• Tenga en cuenta los límites del proveedor para llamadas API y el rate‑limiting en cargas de zona; de lo contrario, los despliegues automatizados pueden fallar o generar inconsistencias en las TTL.
• Use TTL cortas antes de cambios mayores (p. ej. 300 s) y recupérelas tras alcanzar estabilidad.
• Pruebe la entrega de registros TXT a través de varios resolvers públicos y mediante TCP para detectar truncamiento.

Alta disponibilidad y gestión de claves

Opere el firmador DKIM como una componente de alta disponibilidad: desacople los hops de Postfix mediante TCP/inet‑milter o un proxy central. Las claves privadas deben residir en un Key‑Store seguro o HSM; defina un playbook documentado de Emergency‑Rotation (publicar un nuevo Selector, conmutar las firmas, y retirar la clave antigua solo tras la ventana de pruebas).

Canalización RUA e integración SIEM

Los informes RUA son datos en bruto — construya una canalización automatizada: Collector (correo electrónico o API) → Parser/Normalizer → base de datos de series temporales & SIEM. Reglas que deben alertar inmediatamente: aumento súbito de DMARC‑Fails, nuevas IP remitentes con alto volumen, o fallos recurrentes en subdominios críticos. Preste atención a la protección de datos: las IP en los informes son datos personales y requieren políticas de retención adecuadas.

Redes de seguridad operativas

• Receptores canary: un pequeño conjunto de proveedores (Gmail, M365) como sistema de alerta temprana.
• Milter‑Circuit‑Breaker: alertas automáticas ante repetidos timeouts de Milter; mientras milter_default_action=accept ayuda una fase segura de fallback.
• Infrastructure as Code: cambios de DNS mediante GitOps (Pull‑Request, Review, CI) minimizan errores humanos y permiten revertir rápidamente.

Estos componentes operativos hacen que el proyecto sea resiliente: reducen los tickets de soporte, previenen interrupciones operativas para software empresarial individual como Zammad y generan un historial de cambios claramente auditable.

Para este tema también son importantes Postfix Dkim y Spf Record. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en el día a día.