← Volver al blog

Antes de poner DMARC en p=reject: la lista de remitentes externos

  • Gmail
  • Consola de administración
Antes de poner DMARC en p=reject: la lista de remitentes externos

Por qué p=reject falla en silencio con los remitentes que olvidaste

Imagina un despacho contable de 12 personas que termina lo que parece un despliegue de DMARC impecable. El correo de Workspace alinea, el boletín alinea, dos semanas de reportes se ven limpias y alguien pone la política en p=reject un viernes por la tarde. El lunes llama un cliente a preguntar dónde quedó su factura.

Nadie en el despacho vio un rebote. Un mensaje rechazado se rechaza en el servidor que lo recibe, y el aviso vuelve al remitente del sobre, que aquí es la plataforma de facturación, no una persona del despacho. El correo dejó de llegar en silencio, y la primera señal fue un cliente que pagó tarde.

Así falla la aplicación de la política. No rompe los remitentes que probaste. Rompe los que nadie anotó: la herramienta de facturación, el escáner del pasillo, los recordatorios del sistema de reservas, los avisos de envío de la tienda, la mesa de ayuda que responde como soporte@. Todos ponen tu dominio en el De y firman con el de otro, y mientras la política no tuvo dientes, los receptores los dejaron pasar.

Entonces el trabajo real antes de p=reject no es de DNS. Es un inventario. Esta es la lista que revisamos en el dominio de un cliente, en el orden en que la revisamos.

Arma el inventario de remitentes con los reportes agregados

Adivinar te da la lista de los remitentes que ya conocías. Los reportes agregados te dan la de verdad, incluida la herramienta que un área contrató el año pasado sin avisarle a nadie.

Deja la política en p=none con una dirección rua al menos dos semanas, y un mes completo si el negocio tiene ciclo mensual de facturación o planilla. Un remitente que dispara una vez al mes no aparece en una ventana de dos semanas, y ese suele ser justo el que duele.

Después lee los reportes y anota, para cada origen: de qué proveedor es la IP, si SPF pasó y alineó, si DKIM pasó y alineó, y cuántos mensajes fueron. La alineación es la columna que decide todo. El RFC 9989, publicado en mayo de 2026 como el reemplazo en vía de estándar del RFC 7489, mantiene la misma regla en el centro: SPF o DKIM tiene que pasar y coincidir con el dominio del De que se ve. Un proveedor cuyo SPF pasa con su propio dominio no aporta nada.

Y si leer XML crudo no es como quieres pasar la tarde, mejor pega un reporte.

Clasifica cada línea en tres grupos. Tuyo y alineado, que no necesita nada. Tuyo y sin alinear, que es el trabajo. Y lo que no es tuyo, un reenviador o alguien suplantándote, y ninguno debería detener el despliegue.

Qué configurar, categoría por categoría

Casi todo remitente sin alinear se arregla con uno de tres movimientos: que el proveedor firme DKIM con tu dominio, mover ese correo a un subdominio que le delegas, o hacer relay por tu propia plataforma de correo. Cuál aplica depende sobre todo de la categoría.

Plataformas de marketing y boletines

Son las más fáciles, porque toda plataforma seria soporta DKIM propio. Publica los registros CNAME que te da el proveedor, espera a que resuelvan y recién entonces activa la firma.

Hay un detalle que confunde a mucha gente. Varias plataformas, entre ellas Mailchimp y HubSpot, no te dejan mover el return path a tu dominio, así que SPF sigue marcando pase con el dominio de ellos y falla de alineación, para siempre. No pasa nada: solo un identificador tiene que alinear, y DKIM es el que tú controlas. No pegues el include: del proveedor en tu SPF pensando que arreglas esa columna, porque no puede alinear y te gasta una de tus diez consultas. Lo detallamos en por qué Mailchimp, HubSpot y Klaviyo fallan la alineación DMARC.

CRM y herramientas de ventas

Salesforce marca el patrón. Su documentación te hace crear una llave DKIM en Setup, eligiendo tamaño de llave RSA, con 2048 bits como recomendación, y un selector que identifica la llave. Lo que importa para DMARC es firmar con el dominio de tu De y no con el que trae el proveedor por defecto. Salesforce también documenta una opción de relay que enruta el correo saliente por tu propio servidor, Workspace o Microsoft 365 incluidos, que de paso resuelve la alineación de SPF porque el mensaje sí sale de tu plataforma.

Las herramientas que envían desde el buzón de cada persona con una conexión autorizada por lo general ya alinean, porque el mensaje de verdad sale de Workspace o de Exchange Online. Verifícalo en lugar de suponerlo.

Facturación, contabilidad y el resto del back office

Esta es la categoría que se rompe callada y la que cuesta dinero cuando se rompe. Facturas, estados de cuenta, avisos de planilla y recibos salen mensualmente, así que quedan sub representados en una ventana corta de reportes, y quien los recibe es un cliente que no va a llamar para avisar que la factura nunca llegó.

Se dan tres desenlaces comunes. La herramienta soporta DKIM propio, que es la respuesta limpia. Te deja poner tus credenciales SMTP, así que la apuntas a tu plataforma de correo y hereda tu autenticación. O no ofrece ninguna y envía como tú sin forma de firmar, y ahí lo honesto es cambiar la dirección del De: a un subdominio que le delegas a ese proveedor, o al dominio del proveedor con el nombre de tu empresa como display y un responder a que regresa contigo.

Tiendas, sistemas de reservas y sus apps de correo

Shopify representa bien a la categoría. Su centro de ayuda te hace agregar registros CNAME en tu proveedor de DNS para autenticar el dominio de envío, y pone dos condiciones sobre el propio registro DMARC: el dominio debe tener un solo registro TXT de DMARC, y no debe estar en alineación estricta, adkim=s o aspf=s. Si la verificación no pasa, Shopify reescribe el remitente visible a una dirección de su propio dominio, justo lo que querías evitar. Esos cambios de DNS pueden tardar hasta 48 horas.

Mesa de ayuda y buzones compartidos

Las mesas de ayuda responden como soporte@ u hola@ desde su propia infraestructura, así que necesitan el mismo tratamiento de DKIM que una plataforma de marketing. Lo que importa es la secuencia: agrega la dirección externa, publica los registros DKIM del proveedor, confirma que resuelven y solo entonces activa la firma en su consola. Al revés, el proveedor firma con una llave que no resuelve y el correo que antes pasaba empieza a fallar.

La impresora de la oficina y el sistema del negocio

La multifuncional del pasillo escanea a correo. También el panel de alarma, el software de respaldo, el punto de venta y aquel script que alguien escribió en 2021. Ninguno aparece en una lista de proveedores, todos usan tu dominio, y varios solo envían cuando algo anda mal, el peor momento para que el mensaje sea rechazado.

Para los que están en Google Workspace, Google documenta el envío desde una impresora, un escáner o una app mediante el servicio de relay SMTP, que pasa el mensaje por Google para que salga con tu firma DKIM en lugar de salir sin nada. Los dispositivos se autentican con credenciales o por dirección IP, la opción práctica para una impresora. Tu registro SPF necesita autorizar a Google, cosa que casi seguro ya hace:

ejemplo.com.  TXT  "v=spf1 include:_spf.google.com ~all"

En Microsoft 365 la trampa está un paso antes. La documentación de Microsoft es explícita en que la firma DKIM hay que configurarla para tu dominio propio, de modo que el dominio que firma alinee con el del De. Un tenant que nunca lo hizo firma con su dominio .onmicrosoft.com, y entonces el correo de Exchange Online pasa SPF, pasa DKIM y aun así falla DMARC. Si tus reportes muestran rangos de Microsoft fallando alineación mientras todo se ve configurado, casi siempre es por eso.

Cuando no hay forma de autenticar un dispositivo, dale su propio subdominio y deja limpio el dominio principal. Un escáner que envía como escaneos@avisos.ejemplo.com es un problema contenido. El mismo escáner como escaneos@ejemplo.com es razón para no aplicar la política.

Dos límites que muerden durante el inventario

Cada proveedor que agregas te tienta a pegar otro include: en SPF, y el registro tiene techo. El RFC 7208, sección 4.6.4, limita una evaluación de SPF a diez mecanismos que consultan DNS, y pasarse produce un PermError, que reprueba SPF para todos los mensajes sin importar de dónde vengan. Así que la regla de trabajo mientras recorres el inventario: DKIM es como alineas a un tercero, SPF es para los pocos sistemas que de verdad hacen relay de tu correo, y un include sale del registro la misma semana que sale el proveedor. Si ya estás sobre el límite, volver a bajar de diez consultas va antes que cualquier cambio de política.

Una semana en quarantine y después reject

Cuando cada línea esté alineada o movida a propósito fuera del dominio, aprieta en dos pasos y no en uno.

La perilla de porcentaje que quizá recuerdas de guías viejas ya no está. El RFC 9989 quitó la etiqueta pct y puso en su lugar una bandera simple de prueba, t=y, que reporta sin aplicar. Los registros que traen pct siguen siendo válidos, pero un porcentaje escalonado ya no es base para un despliegue. Escalona con el valor de la política.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.com; adkim=r; aspf=r"

Quarantine convierte una falla dura en una suave. Lo que se te haya pasado cae en la carpeta de spam en lugar de desaparecer, y quien lo recibe todavía puede encontrarlo y avisarte. Revisa los reportes a diario esos días, y si el negocio tiene corrida de facturación, agenda la semana para que caiga adentro.

Después pasa a aplicar:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com; adkim=r; aspf=r"

Deja la dirección rua en el registro de forma permanente. El inventario es una foto, y alguien va a comprar una herramienta nueva en marzo. Si los subdominios entran en tu plan, la etiqueta sp decide qué les pasa, y eso tiene sus propias trampas.

Vale la pena saberlo antes de poner fecha: un dominio que envía más de 5,000 mensajes al día a Gmail ya tiene que publicar una política DMARC, mantener su tasa de quejas de spam por debajo del 0.3 por ciento y soportar la baja en un clic en el correo masivo, que Google aplica desde febrero de 2024. Llegar a p=reject va más allá de eso, y el inventario es lo que lo hace seguro y no valiente.

Cómo ayuda Guanacos Tech

Hacemos esto como un trabajo acotado para empresas pequeñas y medianas de Norteamérica y Latinoamérica, en inglés y en español: un mes de reportes agregados, el inventario de remitentes, la alineación arreglada proveedor por proveedor, una semana de quarantine y después los reportes vigilados durante las primeras semanas de aplicación, para que un remitente olvidado sea una llamada y no una factura perdida. La sorpresa casi nunca es alguien suplantando. Casi siempre es una herramienta que compró un área y nadie más conocía.

Empieza por tu cuenta si quieres: el analizador DMARC y el diagnóstico de correo son gratis y no piden cuenta. Y si prefieres delegarlo, nuestra página de consultoría de entregabilidad de correo explica cómo corre el trabajo, y con una llamada de 30 minutos leemos tu registro y te nombramos los remitentes que están entre tú y p=reject. Documentación de proveedores citada aquí consultada el 24 de septiembre de 2026.

Fuentes

Siguiente paso

¿Prefieres que lo hagamos nosotros?

Treinta minutos por Google Meet, sin costo. Miramos tu dominio o tu proyecto contigo, te decimos qué está mal y qué haríamos primero. Si lo puedes resolver solo, te lo decimos.

Reservar una llamada de 30 minutos o lee sobre nuestro servicio de entregabilidad de correo

Preguntas frecuentes

¿Cuánto tiempo hay que quedarse en p=none antes de pasar a p=reject?

Dos semanas es el mínimo y un mes completo es mejor cuando el negocio factura o paga planilla de forma mensual. Los remitentes que disparan una vez al mes no aparecen en una ventana de dos semanas, y suelen ser justo los que se rompen cuando empieza la aplicación.

Un proveedor no puede firmar DKIM con mi dominio. ¿Qué opciones tengo?

Tres, en orden de preferencia. Apunta la herramienta a tu propia plataforma de correo con credenciales SMTP para que herede tu autenticación. Mueve ese correo a un subdominio que le delegues al proveedor. O cambia la dirección del De al dominio del proveedor con el nombre de tu empresa como display y un responder a que regresa contigo.

¿SPF tiene que alinear si DKIM ya alinea?

No. DMARC pasa cuando SPF o DKIM pasa y alinea con el dominio del De visible. Varias plataformas de marketing nunca dejan que SPF alinee porque el return path se queda en su dominio, y esos mensajes pasan DMARC solo con DKIM.