Correo profesional con dominio propio

Usar @gmail.com para facturar no es ilegal, pero muchos clientes y proveedores perciben menos confianza. El salto a dominio propio implica elegir proveedor (Google Workspace, Microsoft 365, Zoho, Migadu, hosting con correo incluido) y configurar DNS correctamente. No es difícil si vas en orden; es frágil si mezclas registros viejos del hosting anterior con los nuevos.

Paso 1: Decide quién aloja el correo

El dominio se registra en un sitio (Cloudflare Registrar, Nominalia, DonDominio, etc.). El correo puede estar en otro. Lo habitual en pymes:

• Google Workspace — integración con Drive, buena entrega, ~7 €/usuario/mes.
• Microsoft 365 Business Basic — si ya vives en Teams y Office.
• Proveedores ligeros (Zoho Mail, Migadu, Fastmail) — menos funciones, precio bajo.
• Correo del hosting — barato o «gratis», a veces peor entrega y límites opacos.

Antes de tocar DNS, crea la cuenta en el proveedor elegido. Te dará los valores MX y registros de verificación.

Paso 2: Registros MX

Los registros MX (Mail Exchange) indican qué servidores reciben correo para tu dominio. Ejemplo simplificado para Google:

• ASP.L.GOOGLE.COM prioridad 1
• ALT1.ASP.L.GOOGLE.COM prioridad 5
• … (Google publica la lista actual en su documentación)

Errores frecuentes:

• Dejar MX apuntando al hosting viejo mientras creías que ya usabas Google — parte del correo llega a un buzón nadie mira.
• Duplicar MX de dos proveedores «por si acaso» — comportamiento impredecible.
• Olvidar el punto final en algunos paneles (DNS suele normalizarlo, pero no siempre).

Tras cambiar MX, la propagación puede tardar minutos u horas. Usa dig MX tudominio.com o herramientas online para verificar desde varias ubicaciones.

Paso 3: SPF

SPF (Sender Policy Framework) es un registro TXT que dice qué servidores pueden enviar correo en nombre de tu dominio. Sin SPF o mal configurado, aumenta el riesgo de que tus correos salientes vayan a spam o que terceros suplanten tu dominio.

Ejemplo típico para Google Workspace:

v=spf1 include:_spf.google.com ~all

Si además envías newsletters con Mailchimp o facturas con un SaaS, ese servicio te pedirá añadir su include:. Solo puede haber un registro SPF (un TXT que empiece por v=spf1); combinas includes en uno solo. Superar diez lookups DNS en SPF rompe validación — otro motivo para no acumular includes a lo loco.

Paso 4: DKIM y DMARC

DKIM firma criptográficamente los mensajes salientes. El proveedor te da un registro CNAME o TXT (selector google._domainkey, etc.) que pegas en DNS. Sin DKIM, Gmail y Outlook desconfían más.

DMARC indica qué hacer si SPF o DKIM fallan y permite recibir informes de abuso. Empieza suave:

v=DMARC1; p=none; rua=mailto:[email protected]

Cuando todo funciona, puedes endurecer a p=quarantine o p=reject. Muchas pymes nunca pasan de p=none y aun así mejoran visibilidad.

Paso 5: Migrar buzones sin perder correo

1. Exporta o sincroniza correo antiguo vía IMAP (Thunderbird, migración oficial del proveedor).
2. Baja TTL del DNS unos días antes si tu registrador lo permite (300 s), para cambios más rápidos.
3. Configura MX nuevos en horario de baja actividad.
4. Crea las mismas direcciones en el proveedor nuevo (info@, facturas@).
5. Envía prueba entrante y saliente desde y hacia Gmail, Outlook y tu móvil.
6. Mantén acceso al webmail viejo dos semanas por si queda cola.

Si usas soporte remoto, este es uno de los paquetes más pedidos: «configura mi correo bien».

Errores que veo cada mes

• Registro A del dominio raíz al hosting web mientras el correo va a Google — no choca, pero la gente confunde «web» y «correo» en el panel.
• Autenticación de dos factores solo en el admin y no en cuentas de facturación — vector de robo de dominio o buzón.
• Reenvíos infinitos entre dos buzones que se responden automáticamente.
• Usar correo del hosting gratuito con límite de 500 MB y sin backup — pérdida «por sorpresa» al migrar web.
• No configurar SPF del SaaS de facturación y extrañarse de que las facturas por correo van a spam del cliente.

Herramientas de comprobación

• Google Admin Toolbox Check MX
• mail-tester.com (envía un correo y te puntúa)
• Verificación integrada en panel de Google Workspace o M365

Una puntuación no es religión, pero si mail-tester te saca 4/10, algo falla antes de culpar al destinatario.

¿Y el correo de tu web?

Los formularios que envían desde [email protected] necesitan SPF/DKIM del servidor o servicio SMTP que uses (Resend, SendGrid, el PHP del hosting). Relacionado con desarrollo web cuando montamos landings con formulario de contacto serio.

Correo compartido vs buzones individuales

El patrón [email protected] compartido por tres personas con la misma contraseña es cómodo y peligroso: no sabes quién envió qué, no puedes revocar acceso al ex-empleado sin cambiar la clave de todos, y un phishing compromete todo. Mejor un buzón por persona y alias que redirigen (ventas@ → dos buzones) o buzón compartido con herramientas del proveedor (Google collaborative inbox) con trazabilidad.

Lista de comprobación antes de dar por bueno el correo

Recorre esta lista el día del corte y al día siguiente:

1. Envías desde el buzón nuevo a Gmail y Outlook externos — ¿llega a bandeja de entrada, no spam?
2. Respondes desde Gmail al nuevo buzón — ¿entra sin retraso?
3. SPF pasa en cabeceras (muestra «pass» en «Ver original» de Gmail).
4. DKIM firma con el selector correcto del proveedor.
5. El webmail viejo no sigue recibiendo MX residual.
6. Calendarios y contactos migrados si los usabas en el sistema anterior.

Si un solo paso falla, no des por cerrado el proyecto: los clientes que «a veces no reciben» casi siempre son un registro DNS a medias.

Autenticación y robo de dominio

Activa verificación en dos pasos en el registrador del dominio y en el panel del proveedor de correo. Los ataques de «transferencia de dominio» o cambio de MX silencioso existen; un correo de phishing al administrador basta. Registrar bloqueo de transferencia y usar gestor DNS con 2FA reduce riesgo. Si tu dominio es crítico, vale la pena revisar cada seis meses quién tiene acceso de admin.

Alias y buzones departamentales

facturacion@, info@ o hola@ pueden ser alias que entregan en un buzón real sin pagar licencia extra por cada dirección, según proveedor. Evita crear diez buzones completos «por si acaso» si solo lee una persona. Documenta en una tabla quién recibe qué alias y revisa la lista cuando alguien deja la empresa — es un vector de fuga de correo interno olvidado.

Correo en el móvil

Tras configurar MX, añade la cuenta en el iPhone o Android con el asistente del proveedor (Google, Microsoft) o IMAP manual. Comprueba que no queda la cuenta antigua del hosting «también activa» recibiendo duplicados o vaciando el buzón viejo sin querer. En empresas con varios móviles, documenta quién tiene acceso y exige bloqueo de pantalla en dispositivos con correo de facturación.

Spam saliente: tu dominio no es excusa

Si un ordenador infectado envía spam usando tu dominio, acabarás en listas negras aunque el MX sea correcto. Mantén equipos actualizados, no reenvíes credenciales por WhatsApp y revisa de vez en cuando si tu dominio aparece en herramientas de reputación. El DNS perfecto no compensa un PC comprometido en la oficina.

Resumen

Dominio propio en correo = MX correctos + SPF unificado + DKIM activo + DMARC al menos en monitorización + prueba real de envío/recepción + buzones individuales con MFA + móviles alineados. Dedica una tarde ordenada o contrata ayuda puntual; lo caro es descubrir el error cuando un cliente importante no recibe tu presupuesto. Si tras leer esto sigues con dudas en registros concretos, es trabajo típico de soporte remoto de una o dos horas, no de un proyecto infinito.