Un dominio de correo electrónico es la parte que aparece después de @ en una dirección, como ejemplo.com, y la identidad DNS que un remitente usa para enviar y recibir correo. En entregabilidad, el dominio permite a los proveedores comprobar quién autoriza un mensaje mediante SPF, DKIM y DMARC, y asociar su reputación con el tráfico enviado.

Qué significa dominio en el envío de email

En su sentido más simple, un dominio es un nombre legible por personas que DNS traduce en registros técnicos. En una dirección como ana@tienda-ejemplo.com, tienda-ejemplo.com es el dominio. Puede usarse para publicar un sitio web, recibir correo, alojar servicios y declarar reglas que ayudan a otros servidores a verificar el email.

En email no basta con ser titular de un dominio o con ponerlo en el campo visible From:. Para que un mensaje se considere legítimo, el remitente debe demostrar que tiene autorización para utilizar esa identidad. Esa prueba se publica, normalmente, como registros DNS bajo el dominio o bajo un subdominio.

Un dominio interviene en varios lugares de un mensaje:

Dominio del destinatario: la parte posterior a @ de quien recibe, por ejemplo gmail.com. Sus servidores deciden si aceptan, filtran o rechazan el mensaje.
Dominio visible del remitente: el que ve la persona destinataria en From:, como noticias@marca.com.
Dominio de sobre o Return-Path: el dominio usado durante la conversación SMTP para gestionar rebotes. Suele ser distinto del dominio visible.
Dominio de firma DKIM: el valor que aparece en la etiqueta d= de la firma DKIM y que identifica qué dominio firmó el contenido.
Dominio de enlaces y seguimiento: un subdominio como click.marca.com puede utilizarse para enlaces medidos, aunque no sustituye la autenticación del email.

Estos dominios pueden coincidir o no. La cuestión decisiva no es que todos sean idénticos, sino que estén configurados de forma intencional y que la autenticación se alinee con el dominio visible cuando corresponde.

Dominio, dirección de email y servidor: diferencias importantes

Es común confundir una dirección, un dominio y el servidor que entrega el mensaje. Separarlos ayuda a diagnosticar problemas de entrega con más precisión.

Una dirección de email identifica un buzón o identidad concreta: soporte@marca.com. El dominio es la porción compartida por las direcciones de la organización: marca.com. Un servidor SMTP, por su parte, es la infraestructura que transmite el mensaje a través de Internet. Un mismo dominio puede usar diferentes servidores para correo transaccional, campañas de marketing, soporte y correo corporativo.

Por ejemplo, una empresa puede enviar confirmaciones de pedido desde pedidos@marca.com, newsletters desde boletin@news.marca.com y correos de soporte desde ayuda@marca.com. También puede contratar un proveedor externo para la entrega, sin ceder la identidad del dominio. El proveedor aporta la infraestructura SMTP o API; la empresa conserva y autentica su dominio.

El campo From no es una prueba por sí solo

El campo From: es lo que ve la persona destinataria, pero por sí solo no prueba que el mensaje provenga de quien dice ser. Sin controles de autenticación, un atacante puede intentar colocar facturacion@marca.com en el campo visible aunque no controle marca.com.

SPF, DKIM y DMARC existen, entre otras razones, para limitar esa suplantación. Cada protocolo cubre una parte distinta del problema: SPF autoriza infraestructura, DKIM firma el mensaje y DMARC aplica una política basada en la alineación de esas comprobaciones con el dominio de From:.

El dominio no es una lista de contactos

El dominio tampoco equivale a una audiencia. Tener una buena reputación de dominio no convierte automáticamente una lista antigua, comprada o sin consentimiento en una lista segura. Los proveedores de buzones consideran señales del envío: quejas de spam, interacciones, rebotes, volumen, coherencia de identidad y autenticación, entre otras.

Por eso, una marca puede tener DNS impecable y, aun así, sufrir problemas de inbox placement si manda campañas irrelevantes a destinatarios que no las esperan. Del mismo modo, un mensaje transaccional esperado puede rendir bien aunque se envíe desde un subdominio nuevo, si se configura y escala con prudencia.

Por qué el dominio de correo electrónico importa para la entregabilidad

La entregabilidad es la capacidad de llegar al buzón previsto, no solo de que un servidor acepte un mensaje. El dominio es una de las identidades centrales que los proveedores de correo usan para atribuir el tráfico y tomar decisiones de filtrado.

Cuando una campaña sale de un dominio autenticado, con una identidad coherente y una audiencia que ha dado permiso, el proveedor receptor dispone de más señales para evaluar el mensaje. Cuando la identidad es ambigua, cambia constantemente o falla la autenticación, aumenta la incertidumbre. Esa incertidumbre puede traducirse en spam, limitación de volumen, aplazamientos SMTP o rechazos.

Los requisitos de remitentes de Google y Yahoo han reforzado esta idea, especialmente para quienes envían grandes volúmenes. Ambos proveedores exigen autenticación; Google, además, explica que los remitentes masivos deben configurar DMARC y mantener muy baja la tasa de spam comunicada por sus usuarios. Aunque una organización no alcance los umbrales de gran volumen, aplicar esas prácticas reduce riesgos operativos y de fraude.

Confianza de marca y reconocimiento del remitente

La autenticación no es únicamente un requisito técnico. Si el destinatario reconoce recibos@marca.com, entiende por qué recibe el mensaje y puede darse de baja fácilmente de comunicaciones promocionales, es menos probable que marque el correo como spam o denuncie una suplantación.

Utilizar un dominio propio también evita que la identidad de marca quede ligada a un dominio genérico de un tercero. Esto es especialmente importante para correos de restablecimiento de contraseña, facturas, alertas de seguridad, recibos y confirmaciones de compra: son mensajes que el usuario necesita distinguir de un intento de phishing.

Reputación atribuida a una identidad

No existe una puntuación pública, universal y única de “reputación de dominio”. Cada proveedor receptor utiliza sus propios modelos, señales y umbrales. Sin embargo, el dominio autenticado permite atribuir el comportamiento de envío a una identidad relativamente estable.

Esa atribución tiene una consecuencia práctica: los cambios de lista, frecuencia, contenido o infraestructura no ocurren en el vacío. Si un dominio comienza a enviar a contactos inactivos y recibe muchas quejas, el efecto puede perjudicar futuros mensajes legítimos desde la misma identidad. Por el contrario, un historial de tráfico esperado, autenticado y bien gestionado ayuda a construir confianza con el tiempo.

DNS: la base técnica del dominio de envío

DNS es el sistema que publica la información técnica de un dominio. Antes de enviar con un dominio, hay que poder modificar la zona DNS correspondiente o trabajar con la persona que la administra. Los cambios se realizan en el registrador, el proveedor DNS o la plataforma de infraestructura que gestione la zona.

Los registros de autenticación suelen ser de tipo TXT, aunque algunos proveedores entregan valores mediante CNAME para facilitar la administración de claves. No se deben adivinar ni reutilizar registros de otro servicio: el proveedor de envío debe proporcionar los valores exactos para su configuración.

Estos son ejemplos de sintaxis ilustrativa, no valores que deban copiarse sin adaptarlos:

example.com. IN TXT "v=spf1 ip4:198.51.100.25 -all"

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=CLAVE_PUBLICA_LARGA"

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

El primer registro muestra SPF, el segundo una clave pública DKIM y el tercero una política DMARC. Las direcciones y claves del ejemplo son deliberadamente ficticias. En producción, una clave DKIM tiene una parte pública larga y el proveedor conserva la clave privada para firmar.

Registros MX y recepción de correo

Los registros MX indican qué servidores reciben correo para un dominio. Son fundamentales si se desea recibir mensajes en direcciones como soporte@marca.com, pero no son el mecanismo principal que autoriza el envío de campañas o mensajes transaccionales.

Una empresa puede enviar correctamente desde un dominio incluso si usa una infraestructura diferente para recibir correo, siempre que la configuración de envío y autenticación sea válida. Aun así, conviene que las direcciones visibles usadas como remitente o respuesta existan, se supervisen o redirijan a un equipo responsable. Mandar desde no-reply@ puede ser apropiado para ciertos avisos estrictamente operativos, pero no debería impedir que una persona responda cuando una respuesta sea razonable.

Propagación y validación

Los cambios DNS pueden tardar en ser visibles debido al TTL y a la caché de resolvers. No conviene interpretar una comprobación fallida inmediatamente después de publicar un registro como una incidencia permanente. Hay que confirmar que el valor está en el nombre de host correcto, que no hay comillas o duplicados indebidos y que la consulta pública devuelve el registro esperado.

También es importante evitar múltiples registros SPF independientes en el mismo dominio. SPF está diseñado para evaluarse como un único registro de política; si existen varios registros TXT que empiezan por v=spf1, el resultado puede ser un error de permerror. Si se usan varios servicios autorizados, sus mecanismos deben combinarse en una única política SPF válida, respetando sus límites de evaluación.

SPF, DKIM y DMARC: cómo autentican un dominio

SPF, DKIM y DMARC suelen mencionarse juntos, pero no son intercambiables. Entender su función evita configuraciones que parecen correctas pero no protegen el dominio visible.

SPF autoriza el dominio del sobre

Sender Policy Framework, o SPF, publica qué servidores o mecanismos están autorizados a enviar en nombre de un dominio usado en el comando SMTP MAIL FROM o Return-Path. El receptor consulta DNS y compara la IP que entrega el mensaje con la política publicada.

Un resultado SPF “pass” indica que la infraestructura está autorizada para ese dominio de sobre. No demuestra necesariamente que el dominio de SPF coincida con el que ve el usuario en From:. Por eso SPF por sí solo no protege de forma completa la identidad visible de marca.

SPF también tiene límites técnicos. La especificación establece un máximo de diez consultas que generan búsquedas DNS durante la evaluación. Cadenas extensas de include: pueden superar ese límite y producir errores. Cada vez que se añade una plataforma de envío, conviene revisar la política completa en lugar de acumular inclusiones sin control.

DKIM firma el contenido y declara d=

DomainKeys Identified Mail, o DKIM, añade una firma criptográfica al encabezado del mensaje. El servidor emisor firma ciertos encabezados y el cuerpo del email con una clave privada. El receptor obtiene la clave pública desde DNS, normalmente en una ubicación formada por selector, _domainkey y dominio.

En un encabezado DKIM, d=marca.com identifica el dominio firmante y s=selector1 identifica el selector. El receptor busca entonces selector1._domainkey.marca.com. Si la firma se valida, sabe que el contenido firmado no fue alterado después de la firma y que quien firmó controlaba la clave privada asociada a la clave pública publicada.

DKIM es especialmente útil porque puede seguir validando después de reenvíos o cambios de infraestructura que afectarían a SPF. No obstante, una modificación posterior de partes firmadas —por ejemplo, ciertos cambios de pie de página realizados por intermediarios— puede romper la firma. Por ello, hay que validar mensajes reales tras activar cualquier capa que modifique el contenido.

DMARC conecta autenticación e identidad visible

DMARC usa resultados SPF y DKIM y comprueba si al menos uno está alineado con el dominio que aparece en From:. La alineación significa, en modo relajado, que los dominios comparten el mismo dominio organizativo; en modo estricto, que deben coincidir exactamente.

Si From: es avisos@marca.com y DKIM firma con d=marca.com, normalmente hay alineación relajada. Si SPF pasa para bounce.proveedor-ejemplo.net pero el From: es marca.com, SPF puede pasar sin estar alineado. Si DKIM está alineado y pasa, DMARC puede pasar pese a que SPF no esté alineado.

DMARC permite publicar políticas como p=none, p=quarantine o p=reject. p=none sirve para obtener informes y observar el tráfico sin solicitar una acción de bloqueo basada en DMARC. quarantine pide tratar con cautela los mensajes que fallen, mientras que reject solicita rechazarlos. La adopción debe ser gradual: pasar directamente a reject sin inventario de todos los flujos de envío puede bloquear mensajes legítimos de herramientas olvidadas.

Dominios raíz y subdominios para transaccional y marketing

Un subdominio es una rama del dominio principal, como mail.marca.com, news.marca.com o notify.marca.com. Las empresas lo utilizan para separar clases de tráfico y hacer más clara la operación de correo.

Una arquitectura frecuente consiste en enviar marketing desde news.marca.com y mensajes transaccionales desde notify.marca.com o desde el dominio principal. Las confirmaciones de pedido, restablecimientos de contraseña y alertas de cuenta suelen tener expectativas e interacción distintas de una newsletter semanal. Separarlas puede facilitar el análisis y limitar el impacto de una incidencia de campañas sobre el tráfico crítico.

No hay un subdominio mágico que garantice una mejor entrega. Un subdominio nuevo no hereda automáticamente toda la confianza operativa del dominio principal, y tampoco es una vía legítima para escapar de malas prácticas. Debe tener autenticación, volumen introducido de forma sensata, listas con permiso y contenido consistente con la identidad de marca.

Alineación relajada frente a estricta

Con DMARC en alineación relajada, news.marca.com y marca.com pueden considerarse relacionados para la comprobación organizativa. Con adkim=s o aspf=s, el modo estricto exige coincidencia exacta. El modo estricto puede aportar controles más cerrados, pero aumenta el riesgo de que un flujo válido deje de alinear tras un cambio de proveedor o configuración.

La decisión debe responder a la arquitectura real. Antes de endurecer la alineación, documente qué dominio usa el From:, qué dominio aparece en el Return-Path y cuál firma DKIM cada sistema: plataforma de marketing, aplicación, CRM, herramienta de soporte, facturación y servicio de atención al cliente.

Dominios de seguimiento y enlaces

Los enlaces de una campaña pueden pasar por un dominio de seguimiento para medir clics. Un subdominio con marca, como click.marca.com, puede reducir la sorpresa del usuario frente a un dominio desconocido. Sin embargo, no debe usarse para ocultar destinos engañosos ni reemplaza la configuración SPF, DKIM o DMARC.

Revise que los enlaces usen HTTPS, que el dominio de destino sea coherente con el mensaje y que las redirecciones no generen advertencias del navegador. La confianza del destinatario depende de toda la experiencia, no solamente de los encabezados técnicos.

Cómo se evalúa la salud de un dominio de email

Un dominio no tiene una única métrica oficial de salud. En cambio, se evalúa mediante un conjunto de evidencias técnicas y de comportamiento. La métrica visible dependerá de cada plataforma, pero un equipo de email puede construir un cuadro de mando práctico.

Las señales útiles incluyen:

Porcentaje de mensajes con SPF aprobado y alineado.
Porcentaje de mensajes con DKIM aprobado y alineado.
Porcentaje de mensajes que pasan DMARC.
Rebotes duros, rebotes temporales y aplazamientos SMTP por dominio de destinatario.
Quejas de spam, bajas, aperturas y clics cuando esas métricas estén disponibles y se recopilen conforme a la normativa aplicable.
Volumen diario, cambios bruscos de volumen y distribución entre proveedores de buzón.
Informes DMARC agregados, que muestran fuentes que están usando o intentando usar el dominio.

Ejemplo numérico de una medición operativa

Aunque “salud de dominio” no sea una tasa estandarizada, una empresa puede calcular su tasa interna de alineación DMARC para detectar problemas. Suponga que durante un día se envían 120.000 mensajes y que los registros de eventos muestran que 117.600 pasan DMARC con SPF o DKIM alineado.

La fórmula sería:

Tasa de alineación DMARC = mensajes que pasan DMARC / mensajes enviados × 100
                         = 117.600 / 120.000 × 100
                         = 98 %

Ese 98 % no es una calificación universal de entregabilidad ni garantiza inbox placement. Sí señala que 2.400 mensajes no están pasando la comprobación esperada y merece la pena segmentarlos por aplicación, proveedor, dominio From: y motivo de fallo. Quizá un servicio secundario firma con un dominio no alineado; quizá una aplicación antigua usa un Return-Path no autorizado; quizá un cambio DNS no se publicó correctamente.

Informes y fuentes de diagnóstico

Los informes agregados DMARC enviados a la dirección rua pueden revelar IP, dominios y resultados de autenticación observados por receptores participantes. Son especialmente valiosos antes de aplicar una política restrictiva, porque ayudan a descubrir plataformas legítimas que no estaban en el inventario.

Los registros de eventos del proveedor de envío complementan esos informes. Un rechazo SMTP con una respuesta del receptor, una caída de DKIM o un aumento de quejas tienen causas y responsables distintos. Para una verificación previa de datos de contacto, una herramienta de verificación de direcciones puede ayudar a detectar direcciones con problemas antes de incorporarlas a un flujo, pero no sustituye el consentimiento ni la gestión de rebotes posterior.

Problemas habituales de dominio y sus causas

Los problemas de dominio rara vez se deben a una sola causa. Con frecuencia aparecen tras migrar de proveedor, lanzar una nueva aplicación, añadir una plataforma SaaS o cambiar registros DNS sin revisar todos los flujos existentes.

SPF ausente, duplicado o demasiado complejo

Un SPF inexistente impide que los receptores confirmen la autorización mediante ese protocolo. Un SPF duplicado puede producir un error de evaluación. Y un SPF lleno de include: de proveedores antiguos puede exceder el límite de consultas DNS o mantener autorizada infraestructura que ya no debería enviar.

La solución es crear un inventario de emisores autorizados, retirar servicios retirados y consolidar la política en un solo registro SPF. Antes de cambiar -all, confirme con el proveedor de entrega qué dominio usa para el sobre y qué mecanismo DNS requiere. No cambie una política en producción sin enviar pruebas a varios proveedores de buzones.

DKIM roto, selector incorrecto o rotación incompleta

DKIM puede fallar si la clave pública no está publicada, si el selector no coincide, si se han partido indebidamente cadenas TXT largas o si el sistema emisor no está firmando con el dominio previsto. También puede fallar tras una rotación de clave mal coordinada: el emisor comienza a usar un selector nuevo antes de que DNS esté disponible para los receptores.

Mantenga documentados los selectores activos y quién los utiliza. Publique la nueva clave, compruebe que se resuelve públicamente, active la firma con el selector nuevo y solo retire la clave antigua cuando ya no existan mensajes en tránsito que la necesiten. Las claves y el método exacto de rotación dependen del proveedor; siga su configuración oficial.

DMARC sin alineación con From

Un mensaje puede mostrar SPF pass y DKIM pass en una herramienta de prueba, pero fallar DMARC porque ninguno de los dos dominios se alinea con el From: visible. Este caso es frecuente cuando se usa un dominio compartido de un proveedor en el Return-Path o en la firma DKIM.

La corrección consiste en configurar un dominio de firma DKIM propio y, cuando sea posible, un dominio de sobre alineado, además de revisar la política DMARC. Para integrar estos elementos en una aplicación, consulte las guías de configuración y referencia de la API de email del proveedor elegido y aplique exactamente los registros que entregue para su cuenta y dominio.

Suplantación y fuentes no autorizadas

Los informes DMARC pueden mostrar envíos desde IP o servicios que la organización no reconoce. Algunos serán intentos de spoofing; otros serán herramientas legítimas adquiridas por un equipo sin coordinación con TI o marketing.

No autorice una fuente solo porque aparezca en un informe. Verifique quién la opera, qué mensajes envía, a qué destinatarios, bajo qué dominio y con qué controles de consentimiento. Si no es legítima, no la añada a SPF y evite modificar la política DMARC para acomodarla. Si sí es legítima, autentíquela y alinéela antes de considerarla parte de la infraestructura aprobada.

Cómo configurar y mejorar un dominio de envío

La mejora sostenible no consiste en buscar un “truco” de DNS. Requiere una combinación de control técnico, higiene de datos y disciplina de campañas. Un proceso ordenado reduce el riesgo de interrumpir flujos críticos mientras se endurece la protección.

1. Cree un inventario de todos los emisores

Liste cada sistema que envía con su marca: aplicación web, plataforma de campañas, CRM, facturación, soporte, monitorización, formularios, recursos humanos y proveedores externos. Para cada uno, anote el dominio del From:, el Return-Path, el dominio DKIM, el volumen aproximado y la persona responsable.

Este inventario suele descubrir emisiones invisibles para el equipo principal. Una automatización pequeña puede parecer irrelevante hasta que una política DMARC restrictiva bloquea miles de recordatorios, invitaciones o respuestas de soporte.

2. Autentique cada flujo y pruebe mensajes reales

Publique SPF, DKIM y DMARC usando los valores proporcionados por cada plataforma. Envíe pruebas a buzones de diferentes proveedores y examine encabezados completos, no solo el aspecto visual del mensaje. Busque explícitamente resultados spf=pass, dkim=pass y dmarc=pass, además de confirmar qué dominio está alineado.

Pruebe también versiones HTML y texto plano, adjuntos si los usa, respuestas, reenvíos y mensajes generados por cada entorno de aplicación. Un mensaje de prueba enviado manualmente desde un panel puede tener una configuración diferente de la que utiliza un trabajo automatizado en producción.

3. Empiece DMARC en observación y analice

Una política p=none permite recopilar información sin pedir a los receptores que cuarentenen o rechacen por DMARC. Durante este periodo, clasifique cada fuente detectada: legítima y alineada, legítima pero no alineada, retirada o no autorizada.

El tiempo de observación no debe ser una pausa indefinida. Establezca un responsable y un criterio de salida: por ejemplo, haber identificado todos los emisores recurrentes y corregido los fallos de alineación de los flujos importantes. Después, avance con cuidado hacia una política más protectora según el riesgo y la capacidad de supervisión de la organización.

4. Proteja las listas y la experiencia del suscriptor

La autenticación no compensará una lista obtenida sin permiso. Use formularios claros, describa qué tipo de correo recibirá la persona, gestione las bajas con rapidez y elimine o suprima direcciones que generan rebotes duros. Para segmentos inactivos, reduzca el riesgo con campañas de reactivación y deje de insistir cuando no haya señales de interés.

Los mensajes promocionales deben incluir un mecanismo de baja fácil de encontrar. Los correos transaccionales no deben convertirse subrepticiamente en campañas promocionales: mezclar propósitos puede aumentar quejas y perjudicar la confianza de la identidad que se usa para avisos esenciales.

5. Controle el volumen y los cambios

Un dominio nuevo o un subdominio que no ha enviado antes necesita generar una historia de tráfico gradual. Evite pasar de cero a una campaña masiva sin segmentación ni observación. Priorice destinatarios activos y comprometidos, vigile respuestas SMTP, quejas y bajas, y aumente el volumen solo cuando las señales sean saludables.

También hay que vigilar cambios repentinos en un dominio ya establecido. Una migración de proveedor, una campaña estacional, un error que duplica envíos o un cambio en la plantilla puede alterar la reacción de los destinatarios. El dominio funciona como una identidad persistente, por lo que las decisiones operativas acumuladas importan.

Recomendaciones para campañas y correo transaccional

Las campañas y los mensajes transaccionales comparten infraestructura de email, pero tienen objetivos distintos. Diseñar sus dominios y flujos con esa diferencia en mente ayuda a conservar la relevancia para el destinatario.

Para marketing, use un remitente reconocible, una frecuencia explicada durante el registro y una vía clara de baja. Segmente por interacción, idioma, producto o preferencias cuando resulte pertinente. La métrica más importante no es maximizar el número de mensajes enviados, sino mantener una relación esperada con la audiencia.

Para transaccional, priorice la puntualidad, la claridad y la seguridad. Un recibo debe identificar el pedido; un restablecimiento de contraseña debe explicar la acción y tener una vigencia coherente; una alerta de acceso debe dar información útil sin imitar prácticas de phishing. Mantenga estable el dominio del remitente para que los usuarios aprendan a reconocer comunicaciones auténticas.

Lista de comprobación antes de lanzar

Antes de activar un dominio para producción, revise lo siguiente:

El dominio y las direcciones From: representan claramente a la marca.
SPF está publicado una sola vez y autoriza únicamente emisores actuales.
DKIM firma los mensajes de cada flujo y la clave pública se resuelve en DNS.
DMARC está publicado y al menos SPF o DKIM se alinea con From:.
Hay una dirección o proceso válido para respuestas cuando el caso de uso lo requiere.
Las bajas de marketing funcionan y se reflejan en los sistemas de origen.
Los rebotes, quejas y respuestas SMTP se registran y revisan.
Los equipos saben qué cambios DNS requieren revisión de entregabilidad.

Conclusión

El dominio de correo electrónico es mucho más que el texto situado después de @. Es la identidad sobre la que se apoyan la autenticación, la protección contra suplantación, el reconocimiento de marca y buena parte de la evaluación de entrega que realizan los proveedores de buzones.

La base es clara: controle DNS, autentique con SPF y DKIM, publique DMARC, asegure la alineación con el From: y mantenga prácticas de envío que los destinatarios esperen. A partir de ahí, los informes y datos de campaña permiten corregir fuentes no autorizadas, proteger los flujos críticos y construir una operación de email más resistente.

FAQ

¿Qué es el dominio de una dirección de correo electrónico?

Es la parte situada después de @. En ventas@empresa.com, el dominio es empresa.com. En el envío de email, también es una identidad DNS que puede publicar reglas de autenticación y recibir correo.

¿Necesito un dominio propio para enviar campañas?

Es muy recomendable. Un dominio propio permite alinear la identidad visible de marca con SPF, DKIM y DMARC, controlar la reputación asociada al envío y reducir la dependencia de dominios compartidos de terceros.

¿SPF, DKIM y DMARC son obligatorios?

Los requisitos varían según el proveedor receptor y el volumen, pero SPF y DKIM son prácticas fundamentales, y DMARC es clave para proteger la identidad del dominio y cumplir las expectativas modernas de grandes proveedores de buzón. Configurarlos es una base sólida incluso con volúmenes modestos.

¿Puedo usar un subdominio para newsletters?

Sí. Un subdominio como news.empresa.com puede separar newsletters de mensajes transaccionales. Debe configurarse con autenticación correcta, una estrategia de volumen responsable y una identidad que los destinatarios reconozcan.

¿Un dominio nuevo tiene mala reputación?

Un dominio nuevo no tiene el historial de envío de uno consolidado. No es necesariamente malo, pero exige más cuidado: autentíquelo antes de usarlo, empiece con destinatarios que esperan sus mensajes y aumente el volumen de forma progresiva mientras observa rebotes, quejas y resultados de autenticación.

Dominio de correo electrónico: qué es y cómo protegerlo