Última actualización: julio de 2026

En resumen: La etiqueta opcional sp= en un registro DMARC establece una política independiente específicamente para los subdominios. Permite a los administradores blindar los subdominios de forma estricta o gestionarlos con mayor flexibilidad que el dominio principal.

Por defecto, Domain-based Message Authentication, Reporting, and Conformance (DMARC) aplica la herencia de políticas en toda tu jerarquía DNS. Cuando publicas un registro DMARC en _dmarc.example.com, el modo de política declarado en la etiqueta p= se aplica no solo a example.com, sino que es heredado automáticamente por cada subdominio, como mail.example.com o portal.example.com.

Sin embargo, las grandes arquitecturas organizativas o los despliegues por fases requieren con frecuencia que los subdominios sigan reglas distintas a las del dominio principal. Para proporcionar este control granular, el protocolo especifica la etiqueta sp= (Subdomain Policy).

Cómo funciona la etiqueta sp= bajo el RFC 7489

La etiqueta sp= acepta exactamente los mismos valores de política (none, quarantine, reject) que la etiqueta principal p=. Su característica distintiva es su estricto ámbito de aplicación: se aplica únicamente a los subdominios, anulando la política declarada en p=.

Según el RFC 7489, el protocolo define: sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains.

Un registro DMARC que utiliza una política de subdominio diferenciada se ve así:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

En este despliegue, los correos no autenticados que afirman provenir del dominio raíz (example.com) se rechazan de inmediato (p=reject), mientras que los mensajes no autenticados que afirman provenir de cualquier subdominio se envían a cuarentena (sp=quarantine).

Casos de uso estratégicos para la etiqueta sp=

Desplegar una etiqueta sp= es especialmente valioso en dos escenarios operativos habituales:

1. Blindar subdominios mientras se monitoriza el dominio principal

Las organizaciones suelen necesitar varios meses para auditar y autorizar todos los flujos de correo complejos en su dominio principal (example.com). Mientras el dominio raíz permanece en modo de monitorización (p=none), los atacantes podrían explotar fácilmente subdominios no protegidos (support.example.com o billing.example.com) para lanzar campañas de suplantación y phishing.

Al configurar p=none; sp=reject, blindas de inmediato todos tus subdominios sin envío de correo contra el spoofing exacto, mientras sigues recopilando de forma segura informes XML sobre tu dominio principal.

2. Ofrecer un margen de seguridad al integrar nuevos subdominios

Si tu dominio principal ya aplica p=reject, pero tu equipo de marketing lanza una nueva plataforma de correo de terceros en un subdominio dedicado (news.example.com), una política reject inmediata podría bloquear correos legítimos si la alineación DNS aún está incompleta. Configurar sp=quarantine crea un margen de seguridad temporal para tus subdominios hasta que todos los nuevos servicios superen la alineación.

Verificar tu configuración

Para comprobar si tu política principal y la de tus subdominios se heredan correctamente en tu árbol DNS, analiza tu dominio con el escáner gratuito MXAudit.

Para obtener más información sobre cómo estructurar políticas de autenticación y configurar proveedores concretos, explora la guía central de DMARC y tutoriales como configurar DMARC en IONOS.

Más información