Correo profesional con tu dominio: SPF, DKIM y DMARC sin ser técnico

Configura los registros DNS imprescindibles para que tus correos no acaben en spam y tu dominio no sea suplantado.

01 El problema: tu correo legítimo parece spam

Muchas pequeñas empresas usan el correo con su propio dominio y, sin embargo, sus mensajes acaban en spam o no se entregan. Esto no suele ser culpa del hosting, sino de la falta de registros de autenticación que demuestren que el correo es realmente tuyo.

Sin SPF, DKIM y DMARC, cualquiera puede enviar correos haciéndose pasar por tu dominio, y los proveedores como Gmail u Outlook desconfiarán de tus mensajes. El resultado: clientes que no reciben presupuestos, facturas que se pierden y una reputación dañada.

La buena noticia es que arreglarlo lleva alrededor de una hora si tienes acceso al DNS de tu dominio, y no necesitas ser administrador de sistemas. Te explico cada registro, por qué importa y los pasos exactos.

02 Antes de tocar nada: requisitos y accesos

Necesitas tres cosas: el dominio (por ejemplo, tudominio.com), acceso al panel de gestión DNS (normalmente en tu registrador de dominios o en el hosting) y saber qué servicio de correo usas (correo del hosting, Google Workspace, Microsoft 365, Zoho, etc.).

Si no sabes dónde se gestiona el DNS, mira los nameservers del dominio con una consulta whois o en el panel de tu registrador. Si usas Cloudflare, el DNS está allí; si usas el hosting, estará en cPanel o similar.

No toques los registros MX a menos que vayas a cambiar de proveedor de correo. Los MX controlan a dónde llega el correo entrante; si los cambias mal, dejarás de recibir mensajes. En esta guía solo añadiremos o modificaremos registros TXT.

03 Paso 1: Publica el registro SPF

El SPF (Sender Policy Framework) indica a los servidores que reciben tu correo qué direcciones IP están autorizadas a enviar en nombre de tu dominio. Sin él, muchos correos fallan la autenticación.

El valor exacto depende de tu proveedor. Los más habituales son:

Si usas Google Workspace: v=spf1 include:_spf.google.com ~all

Si usas Microsoft 365: v=spf1 include:spf.protection.outlook.com -all

Si usas el correo de tu hosting, consulta su documentación; suele ser algo como v=spf1 mx a ip4:IP.DEL.SERVIDOR -all

Crea un registro TXT con el nombre @ (o déjalo en blanco según tu panel) y el valor correspondiente. Si ya existe un TXT para SPF, edítalo en lugar de añadir otro; tener varios SPF invalida la configuración.

Espera unos minutos y comprueba con una herramienta como MXToolbox SPF Checker.

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com -all

04 Paso 2: Activa DKIM y publica el registro

DKIM (DomainKeys Identified Mail) añade una firma digital a cada correo saliente, ligada a una clave criptográfica. El servidor receptor comprueba que el correo se firmó con la clave privada y valida contra la clave pública publicada en DNS.

Debes generar una clave DKIM en el panel de administración de tu proveedor de correo. En Google Workspace: Apps > Gmail > Autenticar correo. En Microsoft 365: Seguridad > Protección contra amenazas > DKIM. En cPanel: apartado Entregabilidad de correo o Autenticación.

El proveedor te mostrará un registro DNS, normalmente con el nombre google._domainkey (Google) o selector1._domainkey (Microsoft). Crea un registro TXT con ese nombre exacto y el valor largo que te den.

No alteres la clave, los saltos de línea ni los espacios. Es una cadena larga; cópiala tal cual. Si cometes un error, DKIM fallará y tus correos irán firmados pero sin poder verificarse.

Después de publicarlo, espera el TTL (hasta 1 hora) y comprueba con un validador de DKIM.

google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

05 Paso 3: Configura DMARC en modo monitorización

DMARC (Domain-based Message Authentication, Reporting and Conformance) indica a los servidores receptores qué hacer si un correo no supera SPF o DKIM. También te da informes sobre quién envía correo con tu dominio.

Empieza con una política permisiva: p=none. Así los correos que fallen se entregan igualmente, pero recibes informes. Es imprescindible antes de endurecer a quarantine o reject.

El registro se crea con el nombre _dmarc y el valor es un TXT como este: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100; sp=none; adkim=s; aspf=s

Sustituye dmarc@tudominio.com por una dirección que vigiles. Empezarás a recibir informes XML de los principales proveedores; son poco legibles pero útiles. Puedes usar servicios como DMARC Analyzer si lo prefieres.

No pongas p=quarantine ni p=reject hasta haber monitorizado al menos un par de semanas y asegurado que todos los remitentes legítimos están autenticados. De lo contrario, tus propios correos podrían ser rechazados.

_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100; sp=none; adkim=s; aspf=s"

06 Qué no debes tocar y cuándo llamar a un técnico

No toques los registros MX ni los registros NS (nameservers) a menos que estés migrando el correo o el DNS completo. Un cambio incorrecto en MX puede dejar tu correo sin recibir mensajes durante horas.

No borres registros TXT existentes sin saber qué hacen. Algunos TXT de verificación de dominio (Google Site Verification, etc.) no tienen que ver con el correo, pero eliminarlos puede romper otras integraciones.

No publiques DMARC con p=quarantine o reject si acabas de configurar SPF y DKIM y no has verificado que todo el correo legítimo (boletines, facturación, formularios web) pasa la autenticación.

Llama a un técnico si: no tienes acceso al panel DNS y el proveedor no te lo facilita; has hecho cambios y el correo ha dejado de funcionar; usas múltiples servicios de envío (CRM, tienda online, etc.) y no sabes cómo incluirlos en SPF; o si los informes DMARC muestran fuentes legítimas que fallan y no encuentras la causa.

Si algo se rompe, revierte el último cambio. La mayoría de paneles DNS permiten deshacer o volver a poner el valor anterior.

07 ¿Merece la pena hacerlo tú o pagar a alguien?

Si tu dominio está en un registrador típico (Namecheap, GoDaddy, Ionos, etc.) y usas un único proveedor de correo, puedes hacerlo tú en 30-60 minutos siguiendo esta guía. No necesitas conocimientos técnicos avanzados.

Si usas varios servicios que envían correo (tu web, tu CRM, tu tienda online, tu servicio de facturación), la configuración SPF se complica porque debes incluir todos los remitentes autorizados. En ese caso, un técnico puede dejarlo bien a la primera.

Si tu dominio está en Cloudflare y usas reglas de correo electrónico o proxy, ten cuidado: Cloudflare a veces añade registros automáticos que pueden interferir. Ahí conviene revisar la documentación.

El coste de no hacer nada es alto: correos que no llegan, clientes que piensan que no respondes, y posible suplantación de tu dominio para enviar phishing. Es una hora bien invertida.

Preguntas frecuentes

¿Puedo usar el correo de mi hosting en lugar de Google Workspace o Microsoft 365?

Sí, pero ten en cuenta que muchos hostings compartidos tienen IPs con mala reputación, lo que puede hacer que tus correos acaben en spam aunque configures SPF, DKIM y DMARC. Para un negocio que depende del correo, un proveedor dedicado como Google Workspace o Microsoft 365 suele dar mejor entregabilidad. El hosting vale para un uso muy básico.

¿Cuánto tarda en propagarse un registro DNS?

Normalmente entre unos minutos y 48 horas, dependiendo del TTL que tengas configurado. Si bajas el TTL antes de hacer cambios, la propagación será más rápida. Puedes comprobar si el registro ya está activo con herramientas como dig o MXToolbox.

¿Qué pasa si configuro DMARC con p=reject y algo falla?

Los correos que no superen SPF o DKIM serán rechazados por los servidores receptores, lo que puede incluir correos legítimos tuyos si no has configurado bien todos los remitentes. Por eso se recomienda empezar con p=none y revisar los informes durante al menos dos semanas antes de endurecer la política.