Cómo configurar correctamente SPF, DKIM y DMARC en Plesk

En esta guía, le mostraré paso a paso cómo SPF DKIM y DMARC en Plesk para que sus correos electrónicos sean autenticados de forma fiable. Recibirá procedimientos claros para entradas DNS, switches de Plesk y métodos de prueba con los que podrá aumentar la entregabilidad y bloquear remitentes abusivos.

Puntos centrales

• SPF determina qué sistemas están autorizados a enviar correos para su dominio.
• DKIM firma los mensajes salientes y los protege contra manipulaciones.
• DMARC vincula SPF/DKIM con directrices e informes.
• Plesk proporciona asistentes y plantillas DNS para un inicio rápido.
• Monitoreo de los informes DMARC afina su política en funcionamiento.

Compruebe los requisitos previos en Plesk

Antes de realizar cualquier configuración, compruebo el servidor de correo utilizado en Plesk y gestión de DNS. En Linux suelo trabajar con Postfix, en Windows con SmarterMail, ya que estos servicios ofrecen funciones SPF, DKIM y DMARC. También compruebo si el dominio tiene sus zonas DNS en el DNS de Plesk o con un proveedor externo, porque así puedo gestionar las entradas fuera de Plesk debe añadirse. Para un funcionamiento sin problemas, mantengo limpios el nombre de host, el DNS inverso y los certificados TLS válidos, ya que los servidores de entrega comprueban estos puntos. Un punto de partida limpio ahorra mucho tiempo después y refuerza la Reputación.

Configuración de SPF en Plesk - paso a paso

Para empezar, abro "Herramientas y configuración" → "Configuración DNS" y busco un registro TXT que empiece por v=spf1 comienza. Si falta, me lo pongo, por ejemplo: v=spf1 a mx include:yourmailprovider.de -allpara que los sistemas autorizados puedan enviar y todos los demás queden bloqueados. Si el dominio utiliza remitentes adicionales como Microsoft 365, Google Workspace o servicios de boletines, añado el correspondiente incluir-de su documentación. Después de guardar, dejo pasar hasta 48 horas para que el cambio surta efecto globalmente y pruebo el registro con un verificador SPF mediante un correo electrónico de prueba a un buzón seleccionado. Puede encontrar una clasificación compacta de la interacción de los mecanismos en la página guía compactaque explica los escenarios más importantes.

Activar DKIM en Plesk - así es como se procede

Para DKIM Voy a "Herramientas y configuración" → "Configuración del servidor de correo" y activo la opción de firmar los correos electrónicos salientes. A continuación, abro "Sitios web y dominios" a nivel de dominio → Dominio → "Correo" → "Configuración" y compruebo si la firma está activada para cada dominio. Si gestiono los DNS de forma externa, exporto los datos de Plesk claves públicas DKIM generadas e introdúzcalas como registros TXT con el proveedor de DNS (tenga en cuenta el nombre del selector). Después de un máximo de 24-48 horas, los destinatarios deberían validar las firmas DKIM, lo que confirmo enviando un correo de prueba a un buzón de comprobación DKIM o una comprobación de cabecera. Una firma válida refuerza la Entregabilidad notable.

Definir la política DMARC y utilizar informes

Ahora pongo DMARC como registro TXT en _dmarc.sudominio.tld con el valor v=DMARC1; p=cuarentena; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Las etiquetas p, rua y llame a política de control e información, mientras que adkim/aspf definir la alineación estricta (strict). En la práctica, suelo empezar con p=ningunoevaluar los informes durante dos a cuatro semanas y luego elaborar cuarentena o rechazar en. Los informes muestran qué sistemas envían correos en su nombre y dónde fallan SPF o DKIM, lo que permite realizar correcciones directas. Una secuencia de pasos más detallada describe los Implantación de DMARC con ejemplos concretos.

Propagación de DNS, pruebas y mejores prácticas

Cada cambio de DNS lleva su tiempo, así que yo preveo hasta 48 horas para los cambios globales de DNS. Propagación on. En esta fase, envío correos de prueba a buzones externos y compruebo los resultados de autenticación en la cabecera para spf=pass, dkim=pass y dmarc=pass. Si un correo recibe un softfail o NeutroCompruebo los mecanismos SPF, los selectores DKIM y la alineación del envelope-from (ruta de retorno) con From:. Cuando utilizo redireccionamientos, controlo los resultados de DMARC, ya que SPF suele fallar en este caso; DKIM suele compensarlo. Evito ~all permanentemente y para configuraciones productivas confíe sistemáticamente en -todo.

Etiquetas y valores DMARC - tabla compacta

Utilizo el siguiente resumen para DMARC de forma rápida y fiable y evitar interpretaciones erróneas. Mantengo la coherencia de los valores entre los dominios principales y los subdominios y documento los cambios de forma rastreable. Para los dominios productivos, establezco una alineación estricta y activo siempre los informes agregados. Informes forenses (llame a) Planifico respetando la normativa de protección de datos. Establecer directrices claras estabiliza el Reputación del dominio.

Día	Significado	Valores posibles	Recomendación
p	Política para el dominio principal	ninguno, cuarentena, rechazar	Empezar con ninguno, luego aumentar hasta rechazar
sp	Política de subdominios	ninguno, cuarentena, rechazar	sp=rechazar para configuraciones productivas
rua	Informes agregados	mailto:adresse	Utilice su propia dirección de notificación
llame a	Informes forenses	mailto:adresse	Activar sólo si es necesario
adkim	Alineación DKIM	r (relajado), s (estricto)	adkim=s para asignación clara
aspf	Alineación SPF	r (relajado), s (estricto)	aspf=s para reducir las falsas alarmas
pct	Porcentaje de aplicación	0-100	Apriete paso a paso con pct

Integrar remitentes externos: Microsoft 365, Google, servicios de boletín de noticias

Si un dominio utiliza rutas de envío adicionales, añado el SPF incluye para Microsoft 365, Google Workspace, Mailgun, SendGrid o herramientas de boletín exactamente como se documenta. Para cada servicio, compruebo si está activa una clave DKIM independiente y si el dominio de origen está realmente firmado. Evito duplicados o demasiados incluir-cascadas, ya que SPF está limitado a diez búsquedas DNS. Si el presupuesto para búsquedas no es suficiente, consolido remitentes o muevo flujos individuales a subdominios con su propia política DMARC. Así es como mantengo el SPF aligerado y aseguro el Firmas de.

Comprobaciones exhaustivas y selección de servidores

Para los correos entrantes activo en Plesk comprobación de SPF, DKIM y DMARC para que el servidor filtre el spam en una fase temprana. En Linux, estas comprobaciones están disponibles por defecto, mientras que en Windows se implementan con SmarterMail. Me aseguro de que el servidor de correo se actualiza correctamente para que las rutinas de firma y los analizadores sintácticos permanezcan al día. Si hay problemas de falsos positivos, ajusto los umbrales de puntuación, pero nunca el Política de su propio dominio. Así mantengo alta la protección y garantizo la entrega de remitentes legítimos.

Errores comunes y soluciones rápidas

Encuentros "SPF permerror", suele haber un error de sintaxis o se ha superado el límite de búsqueda. Si DKIM falla, compruebo el selector, el registro de clave pública y la terminación del valor TXT con comillas correctas. Si falla DMARC fallaPrimero compruebo la alineación: From-Domain, Return-Path y DKIM-d= deben coincidir perfectamente. Si SPF se rompe con las redirecciones, confío en DKIM y mantener estable el estado de la firma. Utilizo esta secuencia para resolver la mayoría de los problemas de entrega sin una larga búsqueda.

Plantillas DNS y automatización en Plesk

Si administro muchos dominios, configuro la opción Plantilla DNS en Plesk y almacenar allí registros estándar para SPF, DKIM y DMARC. Los nuevos dominios reciben inmediatamente valores predeterminados sólidos que sólo tengo que ajustar. También implemento cambios planificados como DMARC más estricto en todo el dominio utilizando plantillas y scripts. Para las rotaciones de las claves DKIM, trabajo con dos selectores para poder realizar cambios graduales. Esto mantiene la coherencia de la operación en docenas de dominios y mantenible.

Evaluar los informes DMARC y reforzar la política

Tras la puesta en marcha, analizo diariamente los informes agregados e identifico Fuentesque envían en nombre del dominio sin autorización. Bloqueo las IP inesperadas y limpio las herramientas obsoletas antes de endurecer la política. El cambio de p=ninguno en cuarentena y más tarde rechazar Llevo a cabo con pct por etapas para poder medir los efectos de forma controlada. Si aparecen remitentes legítimos en el informe fallido, corrijo los SPF incluidos o activo mi propia clave DKIM. Esta rutina refuerza el Reputación visible y reduce la suplantación de identidad.

Entender correctamente la alineación

De modo que DMARC Garantizo sistemáticamente una alineación correcta. Con SPF es el dominio en el sobre desde (ruta de retorno) o la identidad HELO/EHLO, que debe coincidir con el dominio visible desde (estricto: idéntico, relajado: mismo dominio de organización). Con DKIM Compruebo el d=-atributo de la firma: Debe apuntar al mismo dominio (estricto) o al mismo dominio organizativo (relajado). En la práctica, me aseguro de que:

• la ruta de rebote utilizada (ruta de retorno) utiliza un dominio que coincide con el dominio de origen o se externaliza deliberadamente a un subdominio con su propia política DMARC,
• todos los proveedores terceros el dominio From firmar (DKIM), no sólo su propio dominio de envío,
• la firma DKIM permanece intacta durante el reenvío para compensar las interrupciones SPF.

Si no hay alineación, los receptores DMARC informan de un error a pesar de un SPF/DKIM válido. dmarc=fallo. Por eso compruebo los campos de las cabeceras de los correos electrónicos Resultados de la autenticación, Ruta de retorno y los parámetros DKIM. Esto me permite reconocer rápidamente si SPF o DKIM están proporcionando la alineación y dónde necesito hacer mejoras.

Gestión de claves y parámetros DNS

Para una mayor solidez DKIM-He utilizado claves de 2048 bits. En Plesk Puedo configurar la longitud de la clave por dominio; las claves más antiguas de 1024 bits me salen enseguida. Si es necesario, divido los registros DKIM TXT largos en varios segmentos de coma invertida para que el servidor DNS los entregue correctamente. También defino TTL-valores: En fases de rollout voy a 300-900 segundos, productivamente uso 1-4 horas. Esto me permite reaccionar con flexibilidad a los cambios sin sobrecargar las cachés.

El Rotación Lo hago sin fallos con dos selectores:

1. Cree un nuevo selector en Plesk y publique la clave pública como TXT en el DNS.
2. Cambie el remitente al nuevo selector y observe la supervisión (mostrar cabeceras) s=nuevo selector).
3. Una vez convertidos todos los flujos, elimine el antiguo selector en el DNS y desactívelo en Plesk.

En la medida de lo posible, recurro a proveedores externos, delegado Registros DKIM (por ejemplo, CNAME al selector de proveedor). Esto me permite mantener el control en mi zona y rotar las claves sin arriesgarme a interrupciones operativas.

Casos particulares: Reenvío, listas de correo y pasarelas

En entornos reales, veo regularmente redireccionamientos, listas de correo o pasarelas de seguridad que reescriben los correos electrónicos. Aquí presto especial atención a los efectos:

• ReenvíoSPF a menudo se rompe porque la IP de reenvío no está en el SPF del dominio del remitente. En este caso me baso en DKIMque proporciona la protección del contenido. Si la firma no se modifica, DMARC existe a través de la alineación DKIM.
• Listas de correoMuchas listas cambian de asunto o pie de página y, por tanto, rompen la firma DKIM. En estos casos, planifico una alineación relajada y compruebo si la lista utiliza SRS/ARC o sus propias firmas. Si es posible, utilizo un subdominio con su propia política DMARC para las listas.
• Pasarelas de seguridadLas pasarelas que vuelven a firmar los mensajes o reescriben el envelope-from deben estar correctamente alineadas con el dominio del remitente. Yo documento su función y las anclo en el SPF (ip4/ip6) o mediante include para que se mantenga la alineación.

Conocer los correos con spf=fallo a través de un reenvío, esto no es automáticamente crítico siempre y cuando dkim=pass está presente y la alineación DKIM es correcta. Evalúo la totalidad de los resultados de autenticación en lugar de señales individuales aisladas.

IPs compartidas, HELO/EHLO y rDNS

Si varios dominios comparten la misma IP saliente, confío en la limpieza rDNS y nombres HELO/EHLO coherentes. El puntero inverso apunta a un FQDN (p. ej. mail.hosting-ejemplo.tld), cuyo registro A apunta a la misma IP. El MTA informa exactamente con este nombre. Me aseguro de que el Certificado SMTP TLS coincide con el nombre HELO (SNI si se sirven varios nombres). Para cada dominio remitente, también me aseguro de que SPF/DKIM/DMARC estén completa y correctamente alineados - la IP compartida por sí sola no afecta a DMARC mientras la autenticación sea efectiva.

Para remitentes dedicados (por ejemplo, correo transaccional frente a marketing), me gusta separarlos mediante subdominios y, opcionalmente, sus propias IP. Esto ayuda a Gestión de la reputaciónsimplifica la evaluación de los informes DMARC y minimiza las interferencias mutuas.

Seguimiento e implantación en la práctica

Para garantizar un funcionamiento sin problemas, combino Análisis DMARC con pasos claros para su puesta en marcha:

• Línea de base2-4 semanas p=ningunorecopilar todos los informes agregados (rua), identificar las fuentes de error.
• LimpiezaElimine los remitentes no autorizados, limpie los SPF includes, active DKIM en todos los sistemas legítimos.
• AderezoCon pct gradualmente a cuarentenamás adelante rechazar aumento, medir los efectos en porcentaje.
• AlertaDefina valores umbral (nuevas IP, tasa de fallos por proveedor, nuevos desde dominios) y configure notificaciones.
• DocumentaciónMantenga los selectores, TTL, tiempos de ejecución de claves, presupuesto SPF y responsabilidades bajo control de versiones.

Compruebo el Presupuesto de búsqueda SPF (máx. 10 mecanismos con consultas DNS) y consolidar incluye. Mecanismos críticos como ptr o +todos Generalmente no los utilizo; ip4/ip6, a, mx y dirigido incluir siguen siendo los medios elegidos. Así es como mantengo la configuración estable y auditable.

Comprobación rápida de cada dominio

Al final de cada instalación, ejecuto un Consulte a través de: Registro SPF disponible, presupuesto de búsqueda inferior a diez, mecanismos correctamente ordenados, -todo Activo. Firma DKIM válida, selector documentado, longitud de clave suficiente, rotación prevista. DMARC con registro TXT válido, alineación estricta, buzones de notificación accesibles y archivados. Mostrar correos de prueba spf=pass, dkim=pass y dmarc=pass en la cabecera. Utilizo esta secuencia para mantener las configuraciones reproducibles y Error bajo.

Resumen práctico para un éxito rápido

Empiezo cada proyecto con un NormasMantener SPF ajustado, activar DKIM para cada remitente y desplegar DMARC con informes. A esto le siguen de dos a cuatro semanas de supervisión para cerrar los puntos ciegos y endurecer las directrices. Integro servicios externos de forma controlada, documento las inclusiones y mantengo el presupuesto de búsqueda bajo control. Utilizo plantillas DNS para varios dominios y planifico rotaciones de claves DKIM para mantener las firmas actualizadas. Resumo ideas prácticas útiles y consejos para solucionar problemas en mi Plesk consejos 2025 juntos para poder mantener una Entregabilidad alcanzar.