Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

Política DMARC

La política DMARC - la etiqueta p= - indica a los receptores qué hacer con el correo que falla DMARC: p=none (solo monitorizar), p=quarantine (enviar al spam) o p=reject (bloquear de plano). La protección completa contra la suplantación requiere p=reject.

Esta guía forma parte de nuestra guía completa sobre DMARC. Relacionado: el registro DMARC y cómo configurar DMARC.

Tu política DMARC — la etiqueta p= de tu registro DMARC — indica a los servidores de correo receptores qué hacer con los mensajes que fallan la autenticación DMARC. Hay tres opciones: p=none (solo monitorizar, no tomar ninguna acción), p=quarantine (enviar el correo que falla al spam) y p=reject (bloquear de plano el correo que falla). Solo p=reject te da protección completa contra la suplantación de tu dominio.

Todo el que tiene un registro DMARC tiene una política, pero la mayoría de los dominios se quedan en p=none, que no hace nada para detener la suplantación. El objetivo es progresar de forma segura hasta p=reject. Esta guía explica cada política, por qué la alineación decide silenciosamente si los mensajes pasan o fallan, y cómo llegar a la aplicación sin bloquear tu propio correo legítimo.

Las tres políticas: none, quarantine, reject

La etiqueta p= es la parte más importante de tu registro DMARC. Indica a los receptores qué acción tomar cuando un mensaje dice ser de tu dominio pero falla DMARC.

PolíticaQué hacen los receptoresCuándo usarla
p=noneNo tomar ninguna acción — entregar con normalidad, pero enviarte informes agregadosEl punto de partida. Úsala solo mientras recopilas datos y confirmas que cada remitente legítimo pasa.
p=quarantineEnrutar el correo que falla a la carpeta de spam/correo no deseadoLa fase intermedia. Úsala cuando los informes estén limpios, para aplicar de forma suave antes de comprometerte con un bloqueo duro.
p=rejectRechazar el correo que falla en el servidor — nunca llega al buzónLa meta final. Úsala cuando tengas la certeza de que todo el correo legítimo se autentica y se alinea. Protección completa contra la suplantación.

p=none es un modo de monitorización, no una protección. Un dominio atascado en p=none aún puede ser suplantado libremente: los atacantes pueden enviar correo en tu nombre y llega a los buzones. La protección real contra la suplantación empieza en p=quarantine y se completa en p=reject.

La alineación determina el pase o el fallo

Un “pase” de DMARC es más estricto que un pase de SPF o DKIM por sí solo. Para que DMARC pase, un mensaje necesita que al menos uno de SPF o DKIM tanto autentique como se alinee con el dominio From: visible que los destinatarios realmente ven.

  • Alineación SPF — el dominio del sobre SMTP (Return-Path) debe coincidir con el dominio From: visible, y SPF debe pasar.
  • Alineación DKIM — el dominio de la firma DKIM (d=) debe coincidir con el dominio From: visible, y la firma debe verificarse.

Aquí es donde SPF rompe silenciosamente DMARC. Un registro SPF está limitado a 10 consultas DNS. Cuando tu registro supera ese límite — fácil de hacer una vez que añades varios proveedores mediante declaraciones include: anidadas — SPF devuelve un PermError y deja de evaluar. Eso mata silenciosamente la alineación SPF. Si la alineación DKIM tampoco está en su sitio, el correo por lo demás legítimo falla DMARC y se pone en cuarentena o se rechaza en el momento en que pasas a la aplicación.

Por eso por qué la alineación SPF importa tanto antes de endurecer tu política. Comprueba que tu registro está por debajo del límite de consultas y no devuelve PermError. AutoSPF mantiene SPF válido aplanando tu registro automáticamente, de modo que se mantiene por debajo de 10 consultas incluso a medida que añades remitentes, protegiendo la alineación de DMARC mientras avanzas hacia reject.

También puedes controlar cuán estricta es la alineación con las etiquetas aspf (SPF) y adkim (DKIM). r (relajada, la opción por defecto) permite que los subdominios se alineen; s (estricta) requiere una coincidencia exacta. La mayoría de los dominios deberían dejarlas en relajada. Consulta el registro DMARC para ver la referencia completa de etiquetas.

Cómo pasar de none a reject de forma segura

Saltar directamente a p=reject arriesga bloquear correo real. Usa en su lugar un despliegue por fases:

  1. Empieza en p=none. Publica un registro DMARC con p=none y una dirección de informes (rua=). Esto no cambia nada en la entrega, pero comienza a recopilar informes agregados.
  2. Lee tus informes. Durante dos a cuatro semanas, revisa los informes para ver cada origen que envía en nombre de tu dominio: tu propia plataforma de marketing, CRM, mesa de ayuda, herramienta de facturación y cualquier remitente en la sombra.
  3. Corrige los remitentes legítimos que fallan. Para cada remitente real que falla, añádelo a SPF o configura la firma DKIM para que se autentique y se alinee. Mantén SPF por debajo del límite de 10 consultas mientras lo haces.
  4. Pasa a p=quarantine con pct. Fija p=quarantine; pct=25 para aplicar primero a una cuarta parte del correo que falla, luego eleva pct hacia 100 a medida que los informes se mantienen limpios. Esto limita el radio de impacto si se te escapó un remitente.
  5. Pasa a p=reject. Una vez que la cuarentena está en pct=100 y los informes muestran solo los fallos esperados (es decir, suplantación real), cambia a p=reject para protección completa.

Para la sintaxis del registro y la publicación paso a paso, consulta cómo configurar DMARC.

La etiqueta sp (política de subdominios)

La etiqueta sp= establece una política separada para los subdominios de tu dominio. Si la omites, los subdominios heredan el valor p= principal. Esto importa porque los atacantes a menudo suplantan subdominios (como mail.yourdomain.com) que quizá no uses activamente. Un patrón seguro y común es publicar sp=reject incluso mientras tu política de nivel superior aún está en fase de ramp-up, para que los subdominios no usados queden bloqueados desde el principio. Si usas subdominios para envíos legítimos, trátalos de la misma manera: monitoriza, alinea y luego aplica.

Preguntas frecuentes

¿Qué es una política DMARC?

Una política DMARC es la etiqueta p= del registro DNS DMARC de tu dominio. Indica a los servidores de correo receptores cómo tratar los mensajes que dicen provenir de tu dominio pero fallan la autenticación DMARC. Los tres valores son p=none (solo monitorizar), p=quarantine (enviar al spam) y p=reject (bloquear). Es la instrucción central que convierte a DMARC en una protección real.

¿Cuál es la diferencia entre p=none, p=quarantine y p=reject?

p=none no toma ninguna acción sobre el correo que falla — solo te envía informes, así que tu dominio aún puede ser suplantado. p=quarantine enruta los mensajes que fallan a la carpeta de spam, una fase de aplicación suave. p=reject rechaza el correo que falla en el servidor para que nunca llegue al buzón. Solo p=quarantine y p=reject detienen realmente la suplantación; p=reject es la meta de protección completa.

¿Es seguro usar p=reject?

Sí, una vez que te has preparado para ello. p=reject es seguro tras un despliegue por fases en el que cada remitente legítimo se autentica y se alinea, y tus informes agregados muestran solo los fallos esperados. El riesgo viene de saltar a reject demasiado pronto y bloquear correo real. Corrige los remitentes que fallan en p=none, avanza gradualmente por p=quarantine con pct, y luego comprométete con reject.

¿Por qué mi política DMARC no está activada?

Normalmente porque está fijada en p=none, que es solo monitorización y no aplica nada, de modo que tu dominio sigue siendo suplantable. También puede parecer desactivada si SPF supera el límite de 10 consultas y devuelve PermError, rompiendo silenciosamente la alineación de modo que el correo legítimo falla DMARC. Comprueba tu registro con un comprobador de SPF, corrige la alineación y luego progresa de none a reject.

Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)