Correo propio que no cae en spam: SPF, DKIM, DMARC y buzones explicados de verdad

Publicado el 2026-08-25 por frfrand

Guía honesta sobre SPF, DKIM y DMARC: qué hace cada uno, por qué sin los tres tu correo termina en spam, y cómo montar un dominio de correo con buzones y verificación DNS conversando con una IA. Cubre crear_dominio_correo, verificar_dns_dominio_correo, crear_cuenta_correo, editar_cuota_cuenta_correo y ver_stats_dominio_correo.

Montar un servidor de correo propio es fácil. Lograr que ese correo llegue a la bandeja de entrada y no a spam es lo difícil, y es donde casi todo el mundo se estrella.

El motivo es que el correo electrónico se diseñó sin ninguna noción de autenticación: originalmente, cualquiera podía decir que era cualquiera. Todo lo que existe hoy — SPF, DKIM, DMARC — son parches construidos encima para tapar ese agujero. Entenderlos no es opcional: si te falta uno, Gmail y Outlook van a desconfiar de tus mensajes.

Esta guía explica qué hace cada uno, en qué orden montarlos, y cómo administrar dominios y buzones con el MCP de ArduMaker.

Como en el resto del área de cloud, las herramientas trabajan con ids: company_id para lo que es de la empresa, domain_id para el dominio de correo y account_id para el buzón. Se listan primero y se opera sobre el id, nunca sobre el nombre.

Herramientas cubiertas: crear_dominio_correo, listar_dominios_correo, ver_dominio_correo, verificar_dns_dominio_correo, eliminar_dominio_correo, ver_stats_dominio_correo, crear_cuenta_correo, listar_cuentas_correo, ver_cuenta_correo, editar_cuota_cuenta_correo, listar_cuentas_bot_correo, crear_carpeta_correo y listar_carpetas_correo.

Los cuatro registros que deciden si tu correo llega

MX — quién recibe. Le dice al mundo a qué servidor entregar los mensajes dirigidos a tu dominio. Sin MX no recibís nada. Tiene prioridad numérica y gana el número más bajo; si tenés un MX viejo con prioridad menor, tu correo sigue yendo al servidor anterior aunque hayas agregado el nuevo.

SPF — quién puede enviar en tu nombre. Es un registro TXT que lista los servidores autorizados a enviar correo con tu dominio como remitente. Si un mensaje llega desde una IP que no está en la lista, el receptor sabe que algo huele mal.

La trampa clásica de SPF: solo puede haber un registro SPF por dominio. Si tenés dos, muchos receptores los tratan como error y anulan la protección. Cuando sumás un servicio nuevo de envío — un CRM, una plataforma de newsletters — no agregás otro SPF: modificás el existente para incluirlo. La otra trampa es el límite de diez búsquedas DNS: encadenar demasiados include: rompe el registro en silencio.

DKIM — la firma criptográfica. Tu servidor firma cada mensaje saliente con una clave privada, y publica la clave pública en el DNS. El receptor verifica la firma y confirma dos cosas: que el mensaje salió de quien dice, y que nadie lo modificó en el camino. A diferencia de SPF, DKIM sobrevive a los reenvíos, y por eso pesa más.

DMARC — qué hacer cuando algo falla. SPF y DKIM detectan problemas pero no dicen qué hacer con ellos. DMARC es esa política: rechazar, mandar a cuarentena, o solo observar. Además pide informes, que es la parte que casi nadie aprovecha y la más útil: te enteras de quién está intentando enviar correo falsificando tu dominio.

El consejo práctico: empezá DMARC en modo observación (p=none). Mirás los informes unas semanas, confirmás que tus envíos legítimos pasan, y recién ahí endurecés la política. Poner p=reject el primer día es la forma más rápida de descubrir que aquella aplicación vieja que manda facturas ya no le llega a nadie.

Montar el dominio de correo, paso a paso

crear_dominio_correo da de alta el dominio en el servidor de correo. Este es el punto de partida, y lo que devuelve es tan importante como lo que hace: los registros DNS que tenés que publicar —MX, SPF, DKIM y DMARC—, incluida la clave pública DKIM que se genera para tu dominio.

Y hay una regla que ordena todo lo que viene después: el dominio no acepta correo ni permite crear buzones hasta que la verificación de DNS dé positiva. No es una recomendación, es un bloqueo. crear_cuenta_correo falla mientras el dominio no esté verificado.

verificar_dns_dominio_correo vuelve a comprobar en vivo el MX, el SPF, el DKIM y el DMARC, y actualiza el estado de verificación. Es la herramienta que más vas a usar mientras configurás, y la respuesta correcta a la pregunta "¿ya está todo bien?". En vez de abrir tres validadores online distintos, preguntás una vez.

Consejo de orden: publicá primero el MX y el SPF, verificá, después el DKIM, verificá de nuevo, y dejá el DMARC para el final. Si publicás todo junto y algo falla, no sabés cuál de los cuatro es.

listar_dominios_correo muestra los dominios activos con su estado de verificación y su plan. Uso típico: revisión rápida para detectar el dominio que quedó a medio configurar hace meses y que nadie notó porque "el correo más o menos anda".

ver_dominio_correo trae el detalle completo, incluidos el estado de verificación y los registros DNS que espera. Uso típico: pasarle a un cliente exactamente lo que tiene que cargar en su registrador, sin transcribir nada a mano.

ver_stats_dominio_correo consulta el uso real contra el servidor de correo: cantidad de buzones, consumo de cuota. Uso típico: anticiparse a un buzón que está por llenarse, que es la causa silenciosa de correos rebotados.

eliminar_dominio_correo merece un párrafo aparte, porque es la herramienta más destructiva de toda esta guía.

No "da de baja el dominio": cascadea. Borra el dominio y con él todos los buzones activos —la cuenta en el servidor de correo y el registro local—, y en la práctica no se recupera. No es un borrado blando como el de los dominios DNS de la guía anterior; acá no hay vuelta atrás.

Por eso pide confirmado explícito. Sin ese parámetro falla con un 409 que te dice cuántos buzones se verían afectados — y esa cifra es exactamente el dato que tenés que leer antes de confirmar. Si el número no es el que esperabas, no confirmes: mirá primero qué hay ahí adentro con listar_cuentas_correo.

Buzones, cuotas y carpetas

crear_cuenta_correo crea un buzón sobre un dominio ya verificado (si no lo está, falla) y que no haya llegado a su límite de casillas. Uso típico: alta de un empleado, o las direcciones funcionales que todo proyecto necesita — hola@, soporte@, facturacion@.

Sobre la contraseña, con precisión, porque acá es fácil equivocarse. La contraseña que ponés al crear el buzón se guarda cifrada, y no es un descuido: es lo que permite que después funcionen las herramientas de mensajes —listar_mensajes_correo, ver_mensaje_correo, enviar_correo—, que necesitan autenticarse contra el buzón para leer y mandar.

Lo que sí es cierto es que nunca se devuelve: ver_cuenta_correo te da todo el detalle de la cuenta salvo eso. Y va una corrección importante sobre lo que a veces se asume: tampoco existe una herramienta MCP para cambiarla. No hay forma de verla ni de rotarla desde el agente. Si hace falta cambiarla, es por el panel o el webmail. Anotala en tu gestor de contraseñas en el momento de crearla, porque desde el MCP no la vas a volver a ver ni a poder reemplazar.

listar_cuentas_correo enumera los buzones activos del dominio. Uso típico: la auditoría que todos posponen, donde aparecen las tres cuentas de gente que ya no trabaja ahí.

editar_cuota_cuenta_correo cambia el plan del buzón y con él su espacio. Con un límite explícito: es solo hacia arriba. Mover una cuenta a un plan más chico se rechaza; si de verdad hace falta bajarla, hay que borrar la cuenta y crearla de nuevo. Uso típico: el buzón de administración que acumula adjuntos pesados y está al 95%. Un buzón lleno deja de recibir, y los remitentes reciben un rebote: es un problema que conviene resolver antes, no después.

listar_cuentas_bot_correo es de solo lectura y muestra las cuentas automatizadas del dominio, solo como contexto. La administración de esas cuentas —crearlas, regenerar su token, borrarlas— está deliberadamente fuera del MCP: las usan otros procesos automáticos, y un agente tocándolas podría romper algo en silencio del otro lado. Uso típico: entender qué direcciones envían notificaciones del sistema antes de tocar reglas de filtrado.

crear_carpeta_correo y listar_carpetas_correo trabajan sobre la estructura IMAP del buzón; las carpetas nuevas cuelgan de INBOX salvo que indiques otro padre. Ojo con una asimetría: no hay herramienta para renombrar ni borrar una carpeta. Se crean por acá, se corrigen por el webmail. Uso típico: preparar carpetas por cliente o por año antes de montar filtros que archiven automáticamente, que es el tema de la siguiente guía de esta serie.

Una advertencia de seguridad que en correo importa más que en ningún lado

Vale la pena decirlo aquí y no en la guía de seguridad, porque es en el correo donde se materializa: un buzón es la única superficie de tu infraestructura donde un desconocido puede poner texto delante de tu agente sin tener cuenta en ArduMaker. Alcanza con conocer una de tus direcciones.

El servidor MCP trata ese contenido como corresponde: lo que devuelven listar_mensajes_correo y ver_mensaje_correo llega envuelto y marcado como no confiable, con la instrucción de tratarlo como datos y nunca como instrucciones — incluso si el mensaje dice venir de ArduMaker, de un administrador o de ti.

Pero la otra mitad de la defensa la eliges tú, al autorizar el agente. El propio servidor publica tres combinaciones de alcance a evitar:

• Leer correo + ejecutar comandos en un VPS. Un correo bien escrito pasa a ser un intento de ejecución remota que no le cuesta nada a quien lo manda. Ninguna de las dos mitades es peligrosa sola.
• Leer correo + enviar correo del mismo dominio. Un mensaje entrante puede convencer al agente de responderle a un tercero desde tu dominio: phishing a tus propios clientes, firmado con tu DKIM.
• Leer correo + consultar bases de datos. Texto ajeno más SQL arbitrario es un camino de exfiltración.

La regla práctica: separa agentes. Uno que atiende el correo, sin acceso a servidores ni bases. Otro que opera servidores, sin buzones. Y para triage y resúmenes, alcanza con autorizar la sesión en solo lectura.

TÚ: Los mails que mandamos desde el dominio nuevo caen en spam en Gmail.

IA: listar_dominios_correo(company_id = 3) -> estudio.com -> domain_id 8, dns_verified: false

verificar_dns_dominio_correo(company_id = 3, domain_id = 8) -> MX OK SPF ADVERTENCIA: se detectaron 2 registros SPF DKIM NO ENCONTRADO DMARC NO ENCONTRADO

"Ahí están las dos causas.

Primero, hay dos registros SPF publicados. Un dominio solo puede tener uno: cuando hay dos, muchos receptores lo consideran inválido y descartan la protección entera. Hay que fusionarlos en un único registro que incluya ambos servicios.

Segundo, no hay DKIM publicado. Sin firma, Gmail no puede verificar que los mensajes salieron de tu servidor, y eso pesa mucho en su decisión.

El DMARC tampoco está, pero ese lo dejaría para el final: primero que SPF y DKIM funcionen bien.

Y una consecuencia práctica: mientras la verificación no dé positiva, el dominio no me deja crear buzones nuevos."

TÚ: Dale, dame los registros que tengo que poner.

IA: ver_dominio_correo(company_id = 3, domain_id = 8) -> devuelve los registros esperados, incluido el DKIM público generado para el dominio

"Publicá estos dos y avisame para volver a verificar: [SPF unificado] y [TXT del DKIM].

Cuando ambos den OK durante unos días, sumamos el DMARC en modo observación y miramos los informes antes de endurecerlo."

Preguntas frecuentes

¿Por qué mis correos caen en spam? Las causas más comunes, en orden: falta DKIM, hay más de un registro SPF, no hay DMARC, o el dominio es muy nuevo y todavía no tiene reputación. Verificá los cuatro registros antes de buscar explicaciones más exóticas.

¿Puedo tener dos registros SPF? No. El estándar admite uno solo por dominio; con dos, el resultado suele ser un fallo de evaluación. Si sumás un proveedor de envío, fusionalo dentro del SPF existente.

¿Qué es DKIM y por qué importa más que SPF? Es una firma criptográfica del mensaje. Importa más porque sobrevive a los reenvíos: SPF se rompe cuando un mensaje se reenvía, DKIM no.

¿Conviene poner DMARC en p=reject desde el principio? No. Empezá observando, revisá los informes, confirmá que todos tus orígenes legítimos pasan, y endurecé después. Al revés se rompen cosas silenciosamente.

Un dominio nuevo, ¿arranca con buena reputación? No arranca con ninguna. Aunque tengas los cuatro registros perfectos, el volumen alto desde el primer día genera desconfianza. Subí el volumen de forma gradual.

¿No puedo crear buzones todavía? Si el dominio no pasó la verificación de DNS, no. Es un bloqueo, no un aviso: corré verificar_dns_dominio_correo hasta que dé positiva.

¿La IA puede ver las contraseñas de los buzones? No. ver_cuenta_correo devuelve todo el detalle de la cuenta menos la contraseña. Se guarda cifrada para que las herramientas de mensajes puedan autenticarse, pero no hay ninguna herramienta que la muestre.

¿Y puede cambiarlas? Tampoco. No existe una herramienta MCP para rotar la contraseña de un buzón. Guárdala cuando crees la cuenta; si se pierde, se cambia por el panel o el webmail.

¿Puedo bajar un buzón a un plan más chico? No: editar_cuota_cuenta_correo es solo hacia arriba. Bajar implica borrar la cuenta y crearla de nuevo.

¿Qué pasa exactamente si elimino un dominio de correo? Se borran también todos sus buzones, y no se recupera. Por eso pide confirmación explícita y te dice antes cuántas casillas se verían afectadas. Lee ese número antes de confirmar.

Mi agente lee correo. ¿Hay algún riesgo? Sí, y conviene tenerlo presente: el correo es la vía por la que un desconocido puede poner texto delante de tu agente. El contenido llega marcado como no confiable, pero la mejor defensa es de alcance: no le des al mismo agente acceso a leer correo y a ejecutar comandos, enviar correo o consultar bases. Para triage, solo lectura alcanza.

¿Cómo conecto el MCP? Agregando https://mcp.ardumaker.com/mcp en un cliente compatible y autorizándolo con tu cuenta.

Parte de la serie de guías sobre las herramientas del MCP de ArduMaker.