Por qué una cartera de clientes no pasa a reject de un solo golpe
Un dominio único se gestiona a ojo. Una cartera no: cada cliente tiene herramientas que la agencia no siempre conoce por completo. El detonante suele ser externo. Desde el 1 de febrero de 2024, Gmail pide SPF, DKIM y DMARC a los remitentes de más de 5 000 mensajes al día, Yahoo fija una exigencia parecida y Outlook.com aplica reglas comparables a los grandes volúmenes. Tanto en Gmail como en Yahoo el mínimo es un DMARC publicado con p=none: esas exigencias no le piden pasar a reject. Lo que empuja a hacerlo es la suplantación: un cliente cuyo nombre sirve para enviar facturas falsas, o cuyas facturas reales acaban en spam.
El riesgo es simétrico. Un reject puesto demasiado pronto rechaza correo legítimo, y es a usted a quien llamará el cliente. La norma DMARCbis (RFC 9989, publicada en mayo de 2026, que sustituye a RFC 7489) recomienda una progresión: p=none al menos un mes y después p=quarantine durante un tiempo similar, comparando los resultados. Las tres políticas se definen en nuestra guía sobre DMARC p=quarantine, y lo que cambia con la nueva norma está en DMARCbis. Aquí tratamos el trabajo propio de una cartera: inventario, calendario, comunicación.
Publicar p=none con una dirección de informes, cliente por cliente
Para cada dominio, la primera escritura es un registro TXT en _dmarc.your-domain.com: v=DMARC1; p=none; rua=mailto:[email protected]. El p=none no cambia nada en la entrega; pide a los receptores que le envíen informes agregados, un archivo XML comprimido por receptor y por día. Si centraliza los informes de todos sus clientes en una dirección de la agencia, por ejemplo [email protected], el dominio de esa dirección difiere del del cliente, y el receptor debe comprobar su consentimiento. La norma de informes (RFC 9990) prevé para ello un registro TXT en client-example.com._report._dmarc.agency-example.com, que contenga al menos v=DMARC1. Sin él, el receptor ignora la dirección y usted no recibe nada. Un registro genérico *._report._dmarc.agency-example.com autoriza todos los dominios de una vez.
Centralizar da una vista de conjunto, pero mezcla a los clientes en el mismo buzón. Una dirección por cliente, o una clasificación por el dominio del campo header_from, evita leer los informes de un cliente buscando los de otro.
Leer una línea de informe: los campos que cuentan
- source_ip — la dirección que entregó el mensaje; una búsqueda inversa o la cabecera
Receivedde un mensaje de prueba revela el proveedor. - count — el número de mensajes de la línea; jerarquiza el trabajo, se tratan primero los grandes volúmenes.
- disposition — lo que aplicó el receptor:
none,quarantineoreject. Con p=none todo valenone; la columna se vuelve útil en las fases siguientes. - dkim y spf — el resultado evaluado para DMARC, es decir, con alineación. Un DKIM válido pero no alineado aparece como
fail. - header_from — el dominio visible en el campo From, el que DMARC protege.
- envelope_from — el dominio del sobre (Return-Path) sobre el que se alinea SPF; un dominio de proveedor aquí explica un fallo de SPF.
- Líneas sin propietario — una IP desconocida con un
countalto es una herramienta olvidada del cliente o una suplantación: se pregunta al cliente antes de concluir.
Alineación: por qué una herramienta que pasa SPF y DKIM falla igualmente
DMARC exige que SPF o DKIM esté alineado con el dominio del campo From. SPF se alinea con el dominio del sobre (Return-Path), no con el From; DKIM se alinea con el dominio d= de la firma. Un servicio de boletines que envía con su propio Return-Path y firma con su propio d= pasa SPF y DKIM en su lado, y falla DMARC en su cliente, porque ninguno de los dos dominios es el del From. Por defecto la alineación es relaxed (aspf y adkim valen r): basta un subdominio del mismo dominio organizativo. En modo strict (s), el dominio debe ser idéntico. Mantenga relaxed salvo necesidad concreta.
La solución es casi siempre la misma: hacer que la herramienta firme con el dominio del cliente, publicando los registros CNAME de DKIM que da el proveedor. Basta una alineación, así que el Return-Path propio del proveedor es inofensivo si DKIM está alineado. Al añadir un include: de SPF, cuente: RFC 7208 limita la evaluación a 10 consultas DNS, y por encima el resultado es un error permanente (permerror).
Matriz de remitentes de terceros que alinear
Desplace la tabla
| Remitente | Lo que aporta el proveedor | Lo que publicar en el cliente |
|---|---|---|
| Boletín, envío masivo | Clave DKIM y dominio de envío | CNAME de DKIM; se recomienda un subdominio de envío dedicado |
| CRM, automatización de marketing | Firma DKIM a nombre del cliente | CNAME de DKIM; `include:` de SPF solo si el proveedor lo exige |
| Facturación, pago en línea | Envío desde sus servidores | CNAME de DKIM del proveedor; si no, envío desde un subdominio de envío dedicado |
| Helpdesk, tickets | Dirección de envío por validar | CNAME de DKIM y validación del dominio de envío |
| Correo principal | Registros SPF y DKIM documentados | `include:` de SPF y clave DKIM del proveedor de correo |
| Sitio web (formularios, tienda) | Envío por el servidor del sitio o un relé | SMTP autenticado con el dominio del cliente |
El calendario tipo de un dominio, fase por fase
Semana 0: publicar p=none
Registre el dominio y publique
v=DMARC1; p=none; rua=mailto:[email protected]. Compruebe condig +short TXT _dmarc.your-domain.com. Los primeros informes llegan en 24 a 48 horas.Semanas 1 a 4: observar y revisar cada semana
La norma recomienda al menos un mes de p=none. Cada semana, agrupe las líneas por proveedor y rellene la tabla de seguimiento: remitente, volumen, alineado o no, legítimo o no.
Corregir cada remitente legítimo no alineado
Publique los CNAME de DKIM del proveedor, envíe un mensaje de prueba a un buzón de Gmail y compruebe
dmarc=passen la cabecera. Una herramienta abandonada no se corrige: se anota como por rechazar.Semanas 5 a 8: poner quarantine
Sustituya el registro por
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected], durante un periodo comparable al de la fase anterior. Los fallos van a spam en lugar de ser rechazados: la columnadispositionde los informes muestra lo que se perdería.No contar con pct como red de seguridad
RFC 9989 eliminó la etiqueta
pct, considerada poco fiable fuera de los valores 0 y 100, y añadiót=ypara pedir que no se aplique la política. La compatibilidad de Gmail, Yahoo y Microsoft contno está documentada hasta la fecha: no construya una fase sobre ella.Semanas 9 a 12: pasar a reject
Si quarantine no reveló ningún remitente legítimo fallando, publique
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]. Avise al cliente la víspera y vigile los informes a diario durante una semana.Mantener la revisión tras el reject
Cada herramienta nueva que adopta el cliente se convierte en un remitente por alinear. Inclúyalo en el contrato de acompañamiento: toda herramienta de envío nueva se declara antes de ponerse en servicio y se añade a la tabla de seguimiento.
Subdominios: sp, np y subdominio de envío dedicado
Un subdominio sin registro propio hereda la política del dominio organizativo. La etiqueta sp fija la política de los subdominios existentes, np la de los inexistentes; a falta de np se recurre a sp y después a p (RFC 9989, definición de las etiquetas). En un registro publicado en un subdominio, sp se ignora. np es reciente: un receptor que no la conoce la ignora y aplica sp.
El uso típico son los subdominios falsos. Un estafador que escribe desde invoice.client-example.com, un subdominio que no existe, queda detenido por np=reject sin riesgo para el correo real, ya que nada legítimo sale de él. Para las herramientas de terceros, prefiera un subdominio de envío dedicado, por ejemplo news.your-domain.com: la herramienta queda alineada en relaxed, sus claves y su SPF no saturan el dominio principal, y puede endurecer este sin esperar a ese flujo. Un registro _dmarc propio en el subdominio permite incluso un calendario distinto.
Los flujos que se rompen: listas de correo, reenvíos, alias
Algunos mensajes legítimos fallan DMARC por construcción, porque un intermediario los retransmite conservando el From original. Una lista que añade un pie invalida la firma DKIM; una redirección invalida SPF, porque la IP que entrega el mensaje ya no es la que el dominio autoriza. La norma lo dice sin rodeos (RFC 9989, sección de interoperabilidad): p=reject puede ser incompatible con estos flujos indirectos, y los dominios cuyos usuarios escriben en listas no deberían publicarlo. ARC (RFC 8617) se cita como intento de solución, pero ningún método se ha extendido ampliamente. La norma pide además a los receptores que no rechacen solo por un p=reject y, sin otro análisis, traten el mensaje como con quarantine: el reject no siempre se aplica al pie de la letra, lo que no es motivo para ignorarlo.
Estos casos se detectan antes de cambiar. Busque en los informes líneas cuya IP pertenezca a un relé de lista o a un servicio de reenvío, con spf y dkim fallando y un count bajo pero regular. Pregunte después al cliente: alias de antiguos alumnos, una asociación, una dirección que redirige a un buzón personal. Para un dominio cuyas direcciones se usan para escribir en listas públicas, quédese en quarantine: es una decisión defendible, que se anota en la tabla de seguimiento.
Demostrar el resultado antes de avisar al cliente
Envíe un mensaje de prueba desde cada herramienta a un buzón de Gmail, abra «Mostrar original» y busque la línea Authentication-Results: debe contener dmarc=pass header.from=your-domain.com. Tras el paso a reject, un rechazo SMTP lleva un código 5.7.x y un texto propio del receptor. Guarde la captura del mensaje de rechazo y la línea correspondiente del informe rua: muestran al cliente que la herramienta defectuosa estaba identificada y señalada, no descubierta después.
El mensaje que enviar al cliente antes de cada fase
El cliente no tiene que entender DMARC, pero debe saber qué cambia, cuándo y qué se espera de él. Bastan cuatro frases.
Asunto: protección de su dominio contra la suplantación de correo
Hola, estamos reforzando la protección de su dominio your-domain.com contra la suplantación de sus direcciones. A partir del [fecha], los mensajes que se presenten como procedentes de su dominio sin estar autenticados se enviarán a spam y, desde el [fecha siguiente], serán rechazados. Para no perder ningún envío legítimo, ¿puede indicarnos antes del [fecha] todas las herramientas que envían correo en su nombre (boletín, facturación, CRM, soporte, sitio web)? Queda un riesgo para las listas de correo y las redirecciones de direcciones: díganos si usa alguna.
Conserve la respuesta en el expediente del cliente: fija quién declaró qué herramientas y en qué fecha.
Tabla de seguimiento de la cartera
Desplace la tabla
| Dominio | Política actual y próxima fase | Remitentes validados y estado del cliente |
|---|---|---|
| client-a-example.com | p=none, quarantine en S+4 | Correo y boletín validados; facturación por confirmar |
| client-b-example.com | p=quarantine, reject en S+8 | Cuatro remitentes alineados; ningún fallo legítimo en los informes |
| client-c-example.com | p=reject, revisión semanal | CRM añadido por el cliente, DKIM por publicar |
| client-d-example.com | p=quarantine, sin reject previsto | Direcciones usadas en listas; decisión anotada |
| client-e-example.com | p=none, ninguna fase prevista | Cliente sin respuesta; recordatorio por programar |
Solución de problemas: cinco fallos frecuentes en una cartera
En una cartera vuelven los mismos cinco incidentes. Aquí están con su causa y el gesto que los resuelve.
Síntomas y remedios
- No llega ningún informe — la dirección
ruaestá en un dominio distinto del del cliente y falta el registro de autorización_report._dmarc: publíquelo, o el receptor ignora la dirección. - Una herramienta pasa SPF y DKIM pero falla DMARC — su Return-Path y su
d=son los del proveedor: publique los CNAME de DKIM a nombre del cliente para alinear DKIM. - SPF en permerror — más de 10 consultas DNS (RFC 7208): elimine los
include:de herramientas abandonadas o pase la herramienta a un subdominio de envío dedicado. - Una herramienta nueva es rechazada tras el reject — el cliente la adoptó sin avisar: vuelva a quarantine mientras alinea la herramienta, en lugar de relajar la alineación.
- El cliente no responde — permanezca en p=none o quarantine, anote el recordatorio y su fecha en la tabla de seguimiento; un reject sin inventario compromete su responsabilidad.
La documentación oficial
RFC 9989, DMARCbis (etiquetas, subdominios, interoperabilidad): https://www.rfc-editor.org/rfc/rfc9989.html
RFC 9990, informes agregados de DMARC (destinos externos): https://www.rfc-editor.org/rfc/rfc9990.html
RFC 7208, SPF (límite de 10 consultas DNS): https://www.rfc-editor.org/rfc/rfc7208.html
RFC 8617, ARC: https://www.rfc-editor.org/rfc/rfc8617.html
Requisitos de Gmail para remitentes masivos: https://support.google.com/a/answer/81126
Buenas prácticas de Yahoo para remitentes: https://senders.yahooinc.com/best-practices/
Requisitos de Outlook para grandes volúmenes: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
