Verificar SPF DKIM DMARC gratis con una API sin registro
En pocas palabras: Mailers.email ofrece una API gratuita (POST a /v1/scan) y un servidor MCP para chequear SPF, DKIM y DMARC de cualquier dominio sin registro ni API key. Permite 60 consultas por hora por IP, con resultados cacheados 24 horas, ideal para agentes de IA o chequeos rápidos pre-envío.
SPF, DKIM y DMARC son los tres registros DNS que determinan si un servidor de correo confía en los mensajes que salen de tu dominio. SPF autoriza servidores de envío, DKIM firma el contenido con criptografía y DMARC define qué hacer cuando SPF o DKIM fallan, además de a dónde mandar los reportes. Verificarlos por separado importa porque un dominio puede tener los tres “bien” en teoría y seguir mandando mails a spam.
En este artículo:
- En 30 segundos
- ¿Qué diferencia hay entre SPF, DKIM y DMARC?
- ¿Por qué un dominio puede tener SPF y DKIM bien pero fallar DMARC?
- ¿Cómo verificar los tres registros desde la terminal con una API gratuita?
- ¿Qué otros datos revisa el escáner web además de SPF, DKIM y DMARC?
- ¿Cuáles son los límites de uso de la API gratuita?
- ¿Qué checklist seguir antes de enviar campañas de email?
- ¿Cómo usar esta verificación desde un agente de IA?
- Errores comunes al configurar SPF, DKIM y DMARC
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- La API de mailers.email hace POST a /v1/scan con solo el dominio, sin API key.
- Límite: 60 requests por hora por IP, con caché de 24 horas para el mismo dominio.
- El escáner web en mailers.email/scan suma MX, DNS reverso y 32+ listas negras, algo que la API no incluye.
- Un dominio puede tener SPF y DKIM correctos y fallar DMARC si el From visible no está alineado.
- Existe un servidor MCP (mcp.mailers.email/mcp) con la herramienta scan_domain para agentes de IA.
¿Qué diferencia hay entre SPF, DKIM y DMARC?
SPF, DKIM y DMARC cumplen tres funciones distintas y complementarias dentro de la autenticación de email. SPF es una lista en el DNS que dice qué servidores pueden enviar correo en nombre de tu dominio. DKIM agrega una firma criptográfica al mensaje para que el receptor verifique que no fue alterado en el camino. DMARC, en cambio, no autentica nada por sí mismo: le dice al servidor receptor qué hacer cuando SPF o DKIM fallan, y a qué dirección mandar los reportes de esos fallos. Cubrimos ese tema en detalle en configurar estos registros correctamente desde el inicio.
Ninguno de los tres reemplaza a los otros dos. Podés tener SPF configurado y no tener DKIM, o tener DKIM sin DMARC, y en cualquiera de esos casos el dominio queda con huecos de seguridad. El tema es que la mayoría de la gente configura SPF (porque es lo primero que aparece en cualquier tutorial) y se olvida de los otros dos.
¿Por qué un dominio puede tener SPF y DKIM bien pero fallar DMARC?

Un dominio falla DMARC aunque SPF y DKIM estén correctos cuando no hay alineación entre el dominio autenticado y el dominio que aparece en el From visible del mensaje. DMARC no solo revisa si SPF o DKIM pasaron: revisa si el dominio que autenticaron coincide con el que ve el destinatario en su bandeja de entrada.
Ponele que tu plataforma de envíos autentica correctamente mail.tuempresa.com con SPF y DKIM, pero el From que le llega al usuario dice [email protected]. Si esos dos dominios no están alineados según la política DMARC configurada, el chequeo falla igual, por más que SPF y DKIM hayan pasado sin problema. Por eso la nota técnica de dev.to insiste en revisar los tres registros por separado en vez de asumir que “si dos están bien, el tercero también”.
¿Cómo verificar los tres registros desde la terminal con una API gratuita?
Para verificar SPF DKIM DMARC desde la terminal sin sitio web ni cuenta, mailers.email expone un endpoint público que devuelve el detalle de cada chequeo en un solo request. No hace falta mandar un mail de prueba ni esperar a que algo rebote. Tema relacionado: verificar que los side effects funcionen realmente.
El comando es este:
curl -s https://api.mailers.email/v1/scan -H 'content-type: application/json' -d '{"domain":"example.com"}'
La respuesta no es un simple “pass” o “fail” general: devuelve el resultado de cada chequeo por separado, así que podés ver exactamente cuál de los tres registros está roto. Eso es más útil que un semáforo verde/rojo, porque te dice dónde mirar en vez de solo avisarte que algo anda mal.
¿Qué otros datos revisa el escáner web además de SPF, DKIM y DMARC?
El escáner web en mailers.email/scan revisa MX, DNS reverso (rDNS/PTR) y presencia en más de 32 listas negras (DNSBLs), chequeos que la API pública no incluye. Es la herramienta a usar cuando SPF y DKIM parecen correctos pero el correo igual no llega.
Hay un detalle que me parece bien resuelto: cuando una lista negra bloquea las consultas de resolvers públicos, el scanner marca ese ítem como “Unknown” en vez de darlo por limpio. “Unknown” no es “Clean”, y la herramienta no inventa un resultado positivo solo para completar el reporte. El puntaje final es sobre 100 y pondera más fuerte DMARC y blacklists, después SPF, DKIM, MX, antigüedad del dominio y rDNS. Ya lo cubrimos antes en revisar la validez de tus certificados también.
¿Cuáles son los límites de uso de la API gratuita?
La API gratuita de mailers.email permite 60 requests por hora por IP, cachea el resultado del mismo dominio durante 24 horas y no pide API key ni registro. Si superás el límite, la API responde con HTTP 429; si usás el servidor MCP, el error llega como JSON-RPC.
- Sin API key: ni la API REST ni el MCP piden autenticación, son anónimos y se limitan por IP.
- Caché de 24 horas: aplica solo a la API, no a las llamadas vía MCP, que siempre corren un scan nuevo.
- Sin blacklist en la API: ese chequeo queda reservado para el scanner web.
Con esos números, la API sirve para un health check rápido, un smoke test en CI o una herramienta dentro de un agente de IA. No está pensada para validar listas masivas de contactos: para eso necesitás otra cosa, con otro volumen y otro modelo de costos.
¿Qué checklist seguir antes de enviar campañas de email?
Antes de lanzar una campaña o un flujo transaccional conviene revisar cinco puntos concretos, según el checklist de la guía de dev.to:
- SPF bajo el límite de lookups DNS: que incluya todos los servicios que realmente envían en tu nombre, sin pasarse del límite técnico.
- DKIM con el selector correcto: configurado con el selector que tu proveedor realmente usa para firmar, no uno viejo que quedó de otra migración.
- DMARC con dirección de reporte: el registro tiene que existir y apuntar a un correo que alguien revise.
- From alineado: el dominio visible coincide con el dominio autenticado.
- Reputación separada: el correo transaccional y el de marketing no comparten una reputación de envío dañada.
Subís el registro SPF, lo probás, funciona bárbaro en el scanner, lo das por terminado y a los dos meses cambiás de proveedor de email marketing sin tocar el DNS, entonces el SPF viejo deja afuera al servidor nuevo y empezás a perder entregas sin entender por qué. Pasa más seguido de lo que parece. En los reportes que te envía tu proveedor de email profundizamos sobre esto.
¿Cómo usar esta verificación desde un agente de IA?
Un agente de IA puede verificar SPF DKIM DMARC de un dominio en tiempo real conectándose al servidor MCP de mailers.email en mcp.mailers.email/mcp, que expone una única herramienta llamada scan_domain. Con eso, el agente chequea el estado real del dominio antes de sugerir algo, en vez de basarse en un checklist estático que puede estar desactualizado.
¿Tiene sentido meter esto en un pipeline de CI o en un agente que audita infraestructura? Sí, porque el chequeo corre en segundos y no necesita credenciales. Si administrás varios dominios y DNS propios, conviene automatizar este chequeo en vez de revisarlo a mano cada vez.
Errores comunes al configurar SPF, DKIM y DMARC
- Dar por buena una herramienta de terceros sin revisar la alineación: muchos servicios de envío configuran SPF y DKIM automático pero dejan el From sin alinear con DMARC.
- No actualizar SPF al cambiar de proveedor: al migrar de plataforma de mail, el registro SPF viejo queda con el servidor anterior y el nuevo queda afuera.
- Dejar DMARC en modo “none” para siempre: ese modo solo reporta, no bloquea nada; sirve para empezar, no para quedarse ahí indefinidamente.
- Confundir “SPF configurado” con “SPF correcto”: tener el registro no alcanza si supera el límite de lookups DNS o no incluye todos los servicios que mandan mail.
Preguntas Frecuentes
¿Cómo verifico si mi dominio tiene SPF, DKIM y DMARC configurados correctamente?
Podés correr curl -s https://api.mailers.email/v1/scan -H 'content-type: application/json' -d '{"domain":"tudominio.com"}' desde la terminal, o entrar a mailers.email/scan para un reporte visual. Ambas opciones muestran el resultado de cada registro por separado, no un pass/fail único.
¿Qué herramienta gratuita permite escanear SPF, DKIM y DMARC sin registrarme?
Mailers.email ofrece tanto una API REST como un scanner web que no requieren cuenta, login ni API key. Ambos son anónimos y se limitan por IP a 60 consultas por hora.
¿Por qué un dominio con SPF y DKIM correctos puede fallar en DMARC?
Porque DMARC exige que el dominio autenticado por SPF o DKIM coincida con el dominio visible en el From del mensaje. Si SPF autentica un subdominio distinto al que ve el destinatario, DMARC falla aunque SPF y DKIM hayan pasado sus propios chequeos.
¿Cómo integro una verificación de email authentication en un agente de IA o en CI?
Para un agente de IA, conectalo al servidor MCP en mcp.mailers.email/mcp y usá la herramienta scan_domain. Para CI, el mismo endpoint POST /v1/scan de la API REST funciona como smoke test previo a un deploy o a un cambio de DNS.
¿Cuántas consultas gratis permite la API de mailers.email por hora?
La API gratuita permite 60 requests por hora por dirección IP, y cachea el resultado del mismo dominio durante 24 horas. Si superás ese límite, la respuesta es un HTTP 429.
Conclusión
Verificar SPF DKIM DMARC ya no requiere mandar un mail de prueba y esperar a ver dónde cae. Con un curl a la API de mailers.email, o con el scanner web que suma MX, rDNS y listas negras, podés chequear el estado real de un dominio en segundos, sin cuenta ni API key. Lo que cambia con esto no es la existencia del chequeo (siempre se pudo hacer a mano revisando el DNS), sino la velocidad para meterlo en un checklist de release, en un pipeline de CI o en un agente que audita dominios antes de dar una recomendación. Si administrás varios dominios, sumá este scan a tu rutina después de cada cambio de proveedor de email y no esperes a que un cliente te avise que la factura le llegó a spam.






