Un ejemplo de registro DMARC muestra una política DNS TXT que solicita al receptor cómo tratar el correo cuando ningún mecanismo proporciona un resultado SPF o DKIM válido y alineado con From. Una configuración incorrecta puede dejar la suplantación sin restricciones DMARC o afectar mensajes legítimos; otros filtros y requisitos de Gmail también influyen. Para configurar el sistema completo, consulta la guía de correo empresarial y cómo crear correo con tu dominio.
Publica una única política DMARC válida en _dmarc.yourdomain.com. Si aún no conoces todos los remitentes, comienza observando y evalúa cuarentena o rechazo después de validar los flujos. La guía de registros DNS necesarios de TrekMail explica la configuración básica; aquí veremos qué ejemplo de registro DMARC se adapta a cada etapa.
Qué hace un registro DMARC
Un ejemplo de registro DMARC puede indicar la versión del protocolo, la política solicitada para mensajes que fallan y un destino de informes. DMARC se apoya en SPF y DKIM, no los sustituye ni repara. Comprueba que al menos uno pase con alineación respecto al dominio visible de From.
Este registro solicita informes sin aplicar todavía restricciones DMARC:
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.comSus componentes son:
v=DMARC1identifica el registro como DMARC.p=noneno solicita cuarentena ni rechazo por DMARC; siguen siendo posibles los filtros locales.rua=mailto:dmarc@example.comsolicita informes agregados XML a los receptores participantes, sin garantizar su envío.
Esa es la base. Las demás etiquetas ajustan el comportamiento solicitado.
DMARC es una política, no una prueba de que el contenido sea seguro. SPF y DKIM autentican determinados dominios; DMARC comprueba si un resultado satisfactorio está alineado con el dominio que el usuario ve en From.
5 ejemplos de políticas DMARC
Un único ejemplo de registro DMARC no resuelve todos los casos. La política depende de la etapa de observación, las restricciones previstas, los subdominios y la necesidad de alineación estricta. Los siguientes registros son alternativas, no deben publicarse juntos.
Solo supervisión. Útil mientras investigas proveedores y reenvíos, contrastando los informes parciales con tu inventario.
v=DMARC1; p=none; rua=mailto:dmarc@example.comSolicitar cuarentena. Una opción restrictiva que puedes evaluar tras validar los remitentes legítimos.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comSolicitar el rechazo. Para configuraciones verificadas y riesgos evaluados; el receptor puede aplicar excepciones locales.
v=DMARC1; p=reject; rua=mailto:dmarc@example.comImplantación gradual. El porcentaje solicita muestreo de los mensajes que fallan, no de todo el correo, y depende del receptor.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comSubdominios y alineación estricta. La política heredada se aplica desde el dominio organizativo a subdominios sin política propia. La alineación estricta exige coincidencia exacta y puede afectar flujos autorizados.
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
| Política | Uso posible | Ventaja prevista | Riesgo principal |
|---|---|---|---|
p=none | Observación inicial | No solicita restricciones DMARC | No solicita bloquear la suplantación ni garantiza ausencia de incidencias |
p=quarantine | Flujos empresariales ya validados | Solicita tratamiento restrictivo | Puede afectar aplicaciones sin alineación; no garantiza carpeta de spam ni recuperación |
p=reject | Configuración de producción verificada | Solicita rechazar fallos DMARC | Una mala configuración puede provocar el rechazo de correo legítimo |
pct=25 | Restricciones graduales | Solicita aplicación parcial a mensajes que fallan | El muestreo no se respeta universalmente ni garantiza menor impacto |
adkim=s; aspf=s | Necesidad probada de coincidencia exacta | Exige alineación exacta de dominios | Puede hacer fallar correo autorizado de terceros |
Este ejemplo de registro DMARC es una opción de cuarentena para evaluar después de probar los flujos legítimos, no la política inicial más segura para cualquier dominio:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comYa solicita restricciones, aunque no pide rechazo directo. Su aplicación y la posibilidad de recuperar mensajes dependen del receptor.
Cómo publicar un registro DMARC en DNS
Para publicar un ejemplo de registro DMARC, crea una única política TXT en _dmarc, adapta su valor y comprueba la respuesta DNS. Los errores habituales son publicarla en la raíz en lugar de _dmarc o crear varias políticas DMARC.
Si has decidido usar cuarentena, este es el formato del ejemplo; el TTL no garantiza cuándo terminará la propagación:
Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comComprueba la publicación:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comDebe aparecer una única política DMARC válida que empiece por v=DMARC1. Varios fragmentos TXT pueden constituir un mismo registro; otros TXT no son necesariamente políticas DMARC.
Según RFC 7489, si no existe una política o aparecen varias políticas DMARC, no se aplica una política válida en esa búsqueda. Comprueba también el formato del panel: algunos esperan solo _dmarc, otros un nombre completo. Una interfaz puede añadir el dominio automáticamente.
Para el conjunto de DNS, la documentación de TrekMail sobre registros DNS necesarios aborda MX, SPF, DKIM y DMARC.
Errores habituales en los registros DMARC
Un ejemplo de registro DMARC mal adaptado puede fallar por el nombre, varias políticas, un destino de informes incorrecto o una alineación estricta no probada. También es frecuente confundir un fallo SPF por reenvío con un fallo DMARC. Investiga la configuración y los mensajes reales.
Revisa especialmente estos puntos:
- Publicar en la raíz. El nombre de consulta es
_dmarc, no@. - Crear varias políticas DMARC TXT. Mantén una única política por nombre de consulta.
- Usar
p=rejectsin validar el inventario. Un CRM o sistema de facturación olvidado puede ver rechazados sus mensajes. - Atribuir todos los fallos de reenvío a DMARC. SPF puede fallar; DKIM permite superar DMARC si sigue válido y alineado y se conserva el contenido firmado tras la canonicalización. Consulta cómo reenviar correo del dominio a Gmail y el reenvío con alias de correo. ARC puede informar excepciones locales, pero no es por sí mismo un resultado DMARC válido.
- Ignorar la alineación. Un SPF válido no basta si no está alineado y DKIM tampoco proporciona un resultado válido y alineado. Si DKIM sí lo proporciona, DMARC pasa.
- No solicitar informes. Sin
ruano se solicitan informes agregados; otras fuentes de diagnóstico siguen siendo útiles. Supervisa acceso y privacidad y la autorización DNS del destino externo cuando corresponda.
Las directrices de Google citadas describen requisitos cuya ausencia puede provocar restricciones de envío a Gmail, según el remitente y la norma aplicable. Consulta las preguntas frecuentes oficiales sobre las directrices de envío. No todos los requisitos se aplican igual a todos los volúmenes.
Elegir un registro DMARC para TrekMail
El ejemplo de registro DMARC adecuado depende de cómo envías. El SMTP gestionado de un plan de pago puede facilitar la configuración, pero necesita los DNS indicados y pruebas reales. Con SMTP propio, autoriza al proveedor en el SPF del dominio del sobre utilizado y verifica DKIM y la alineación.
Estas son opciones de coordinación:
| Configuración | Gestión separada | Gestión con TrekMail |
|---|---|---|
| Envío gestionado | Coordinar alojamiento de buzones y otro proveedor SMTP | Usar el SMTP gestionado del plan correspondiente, publicar DNS y comprobar la alineación |
| SMTP propio | Elegir registros sin verificar el servicio de salida | Separar los buzones y configurar exactamente el SPF y DKIM requeridos por el proveedor real |
| Varios dominios | Editar cada dominio sin seguimiento común | Estandarizar configuraciones adaptadas y revisar cada dominio |
La documentación de SMTP gestionado de TrekMail describe el envío incluido en los planes de pago correspondientes. Debes publicar los registros y comprobar la autenticación alineada. Con SMTP propio, SPF autoriza al proveedor externo en el dominio usado y DMARC puede depender de DKIM si SPF no pasa alineado. Respeta el límite SPF de mecanismos y modificadores que requieren DNS, también en evaluaciones anidadas.
El alojamiento del buzón y el envío pueden ser servicios distintos. Si tu aplicación envía por SES, SendGrid o Mailgun, un ejemplo de registro DMARC válido no evita el fallo si ningún mecanismo pasa alineado en ese servicio.
Para usuarios de TrekMail:
- Evalúa SMTP gestionado en un plan de pago si se adapta a tus necesidades y verifica su configuración.
- Con SMTP externo, coordina SPF, DKIM y DMARC como un mismo cambio.
- Con muchos dominios, organiza los destinos de informes y adapta las etapas a cada dominio.
La oferta descrita presenta Starter desde $3.50 al mes, una prueba gratuita de 14 días en planes de pago sujeta a condiciones y Nano sin coste ni tarjeta según la oferta vigente. Consulta precios, requisitos y prestaciones en la página de precios de TrekMail. El almacenamiento compartido y la migración IMAP dependen del plan; copiar mensajes no sustituye el cambio de MX ni migra todas las aplicaciones.
Implantación gradual de DMARC en 2026
La implantación de un ejemplo de registro DMARC en 2026 debe basarse en los remitentes reales y los riesgos. Empieza observando, valida los servicios y después evalúa restricciones. Pasar directamente al rechazo puede revelar sistemas olvidados cuando ya afecta al correo de producción.
- Publica primero una política de supervisión.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - Revisa los informes durante 7 a 14 días como observación inicial, no como garantía de preparación. Contrasta facturación, CRM, soporte y reenvíos con inventarios, registros y pruebas; los flujos trimestrales o excepcionales pueden exigir más tiempo.
- Corrige SPF, DKIM y al menos un resultado válido y alineado por remitente. Si un proveedor no permite alineación, evalúa cambiarlo o separar su envío con una configuración planificada.
- Evalúa pasar a cuarentena después de las pruebas.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - Considera el rechazo cuando los informes, las pruebas y la evaluación del riesgo lo justifiquen.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Para agencias y carteras de clientes, un proceso gradual puede facilitar la coordinación. TrekMail ofrece gestión multidominio, precios por plan, almacenamiento compartido y copia IMAP según la oferta; no sustituye la validación individual ni garantiza una migración sin incidencias.
El mejor ejemplo de registro DMARC es el que corresponde a tus remitentes y al nivel de restricciones que puedes aplicar. Investiga los informes parciales, prueba la autenticación alineada y después evalúa cuarentena o rechazo. Eso puede reducir la suplantación directa, sin garantizar el bloqueo de todo fraude ni la entrega en la bandeja de entrada.
TrekMail puede reunir buzones, orientación DNS, SMTP gestionado o propio y gestión multidominio según el plan. Consulta trekmail.net y compara límites y costes; centralizar no garantiza ahorro frente a precios por usuario ni elimina las tareas operativas.
