Tutoriales y consejos de correo electrónico

por

1

Cómo configuramos el área de DNS TXT para SPF, DKIM y DMARC y cómo evitamos que Gmail rechace los mensajes de correo electrónico de negocios. – Entrega de correo fallido

Cómo configuramos el área de DNS TXT para SPF, DKIM y DMARC y cómo evitamos que Gmail rechace los mensajes de correo electrónico de negocios. – Entrega de correo fallido

1
Tutoriales y consejos de correo electrónico

Administradores de correo electrónico privado severo para empresas A menudo se enfrentan a muchos problemas y desafíos. De las olas de CORREO BASURA que deben ser bloqueados por filtros específicos, seguridad de la correspondencia en el servidor de correo electrónico local y en los servidores remotos, Configurando y monitoreo de servicios SMTP, ESTALLIDO, IMAP, además de muchos y muchos otros detalles de Configuración SPF, DKIM y DMARC Cumplir con las buenas prácticas para el envío de mensajes de correo electrónico seguros.

muchos problemas de enviando mensajes de correo electrónico o consignatario hacia/desde sus proveedores, aparecen debido a una configuración incorrecta del área DNS, ¿qué pasa con el servicio de correo electrónico?

Para que los correos electrónicos se envíen desde un nombre de dominio, debe ser alojado en un servidor de correo correctamente configurado y el nombre de dominio debe tener zonas DNS para FPS, MX, DMARC Y DKIM configurado correctamente en el administrador Texto DNS del dominio.

En el artículo de hoy nos centraremos en un problema bastante común. servidores de correo electrónico privados para empresas. Imposibilidad de enviar mensajes de correo electrónico a cuentas de Gmail, Yahoo! o iCloud.

Los mensajes enviados a @Gmail.com se rechazan automáticamente. “Error en la entrega del correo: devolver el mensaje al remitente”

Am intalnit recent o problema pe un domeniu de e-mail al unei companii, de pe care se expediaza regulat mesaje e-mail catre alte companii si catre persoane fizice, unele dintre acestea avand adrese @gmail.com. Toate mesajele expediate catre conturile de Gmail reveneau imediat la expeditor. “Error en la entrega del correo: devolver el mensaje al remitente”.

Mesajul de eroare returnat in serverul de e-mail pe Exim arata in felul urmator:

1nSeUV-0005zz-De ** [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

In acest scenariu nu este ceva foarte grav, cum ar fi includerea numelui de domeniu expeditor sau IP expeditor intr-o lista de SPAM globala sau o eroare majora de configuratie a serviciilor de e-mail pe sevrer (Exim).
Chiar daca multi cand vad acest mesaj se duc cu gandul imediat la SPAM sau o la eroare de configurare SMTP, problema este generata de zona Texto DNS del campo. La mayoría de las veces DKIM no está configurado en la zona DNS o no está introducido correctamente en el administrador DNS del dominio. Este problema lo encuentran a menudo quienes lo usan. Marco de la nube como Administrador de DNS y olvídate de pasar Texto DNS: correo._domainkey (DKIM), DMARC y FPS.

Tal y como nos indica en el mensaje de rechazo de Gmail, la autenticidad y autenticación del dominio del remitente ha fallado. “This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks.”. Esto significa que el dominio no tiene DNS TXT configurado para garantizar la credibilidad del servidor de correo electrónico del destinatario. Gmail, en nuestro escenario.

Cuando agregamos un dominio web con un servicio de correo electrónico activo en cPanel o VestaCP, automáticamente se crean los archivos de la zona DNS del dominio respectivo. La zona DNS que también contiene la configuración del servicio de correo electrónico: MX, FPS, DKIM, DMARC.
En la situación en la que elegimos el dominio para que esté en el administrador Llamada de nube DNS, la zona DNS de la cuenta de alojamiento del dominio, se debe copiar a CloudFlare para que el dominio de correo electrónico funcione correctamente. Ese fue el problema en el escenario anterior. En un administrador de DNS de terceros, no hay ninguna entrada DKIM, aunque sí existe en el administrador de DNS del servidor local.

¿Qué es DKIM y por qué se rechazan los correos electrónicos si no tenemos esta característica en un dominio de correo electrónico?

Correo identificado con claves de dominio (DKIM) es una solución estándar para la autenticación de un dominio de correo electrónico, que agrega una firma digital a cada mensaje enviado. Los servidores de destino pueden comprobar a través de DKIM si el mensaje proviene del dominio legal del remitente y no de otro dominio que utiliza la identidad del remitente como máscara. Por supuesto, si tienes el dominio abcdqwerty.com Sin DKIM, los mensajes de correo electrónico se pueden enviar desde otros servidores utilizando su nombre de dominio. Es si quieres un robo de identidad, que en términos técnicos se llama suplantación de correo electrónico.
Una técnica común cuando los mensajes de correo electrónico se envían por phishing y correo basura.

También a través de DKIM se puede asegurar que, el contenido del mensaje no fue modificado después de que fue enviado por el remitente.

Avand DKIM setat corect pe severul gazda al sistemului de e-mail si in zona DNS, se elimina mult si posibilitatea ca mesajele dvs. sa ajunga in SPAM la destinatar sau sa nu ajunga deloc.

Un exemplu de DKIM este:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Desigur, valoarea DKIM obtinuta prin algoritmul de cripatre RSA este unica pentru fiecare nume de domeniu si poate fi regenerata de pe serverul gazda al serviciului de e-mail.

Avand DKIM instalat si setat corect in Texto DNS manager, este foarte posibil sa rezolve problema mesajelor returnate catre conturile de Gmail. Cel putin pentru eroarea “Entrega de correo fallido”:

SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked.

A modo de breve resumen, DKIM añade una firma digital a cada mensaje enviado, que permite a los servidores de destino verificar la autenticidad del remitente. Si el mensaje vino de su empresa y la dirección no fue utilizada por un tercero para utilizar su identidad.

Gmail (Google) puede rechazar automáticamente todos los mensajes que provienen de dominios que no cuentan con dicha firma digital DKIM.

¿Qué es SPF y por qué es importante para enviar mensajes de correo electrónico de forma segura?

Además de DKIM, y FPS tiene como objetivo prevenir phishing de mensajes y suplantación de correo electrónico. De esta forma los mensajes enviados ya no serán marcados como spam.

Marco de políticas del remitente (SPF)Es un método estándar para autenticar el dominio desde el que se envían los mensajes. Las entradas SPF están configuradas en administrador DNS TXT de su dominio y en esta entrada se especificará el nombre de dominio, IP o dominios que tienen derecho a enviar mensajes de correo electrónico utilizando su nombre de dominio o el de su organización.

Un dominio sin SPF puede permitir a los spammers enviar mensajes de correo electrónico desde otros servidores, usando su nombre de dominio como máscara. De esta manera pueden propagarse información falsa o Se pueden solicitar datos sensibles. en nombre de su organización

Por supuesto, aún se pueden enviar mensajes en su nombre desde otros servidores, pero se marcarán como spam o se rechazarán si ese servidor o nombre de dominio no está especificado en la entrada SPF TXT de su dominio.

Un valor SPF en el administrador de DNS se ve así:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Dónde “ip4” representa el IPv4 de su servidor de correo.

¿Cómo configuro SPF para múltiples dominios?

Si queremos autorizar a otros dominios a enviar mensajes de correo electrónico en nombre de nuestro dominio, los especificaremos con el valor “include” en SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Esto significa que se pueden enviar mensajes de correo electrónico desde nuestro nombre de dominio de correo electrónico y desde ejemplo1.com y ejemplo2.com.
Es un registro muy útil si tenemos, por ejemplo, uno Revista en línea en la dirección “ejemplo1.com“, pero queremos que los mensajes de la tienda online a los clientes vayan desde la dirección de dominio de la empresa, siendo este “ejemplo.com“. En Texto SPF para “ejemplo.com”, ya que debemos especificar junto con la IP y “incluir: ejemplo1.com”. Para que se puedan enviar mensajes en nombre de la organización.

¿Cómo configurar SPF para IPv4 e IPv6?

Tenemos un servidor de correo con ambos. IPv4 así como con IPv6, es muy importante que ambas IP estén especificadas en el SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

A continuación, después “IP” se puede utilizar la directiva “include” para agregar dominios autorizados para envío.

Qué quiere decir esto “~all“, “-all” y “+all” ¿Ale SPF?

Como dije anteriormente, los ISP aún pueden recibir mensajes de correo electrónico en nombre de su organización incluso si se envían desde un dominio o IP que no está especificado en la política SPF. Etiqueta “todo” indica a los servidores de destino cómo tratar estos mensajes de otros dominios que no están autorizados y envían mensajes en nombre suyo o de su organización.

~all : Si el mensaje se recibe desde un dominio que no figura en SPF TXT, los mensajes se aceptarán en el servidor de destino, pero se marcarán como spam o sospechosos. Estarán sujetos a las buenas prácticas de filtros antispam del proveedor receptor.

-all : Es la etiqueta más estricta agregada a una entrada SPF. Si el dominio no aparece en la lista, el mensaje se marcará como no autorizado y será rechazado por el proveedor. Ni siquiera se entregará al spam.

+all : Esta etiqueta, que se utiliza muy poco y no se recomienda en absoluto, permite a otras personas enviar mensajes de correo electrónico en su nombre o en el de su organización. La mayoría de proveedores rechazan automáticamente todos los mensajes de correo electrónico provenientes de dominios con SPF TXT “+all“. Precisamente porque la autenticidad del remitente no puede verificarse, sólo después de una verificación por “encabezado de correo electrónico”.

Resumen: ¿Qué es el marco de políticas del remitente (SPF)?

Autoriza, a través de la zona DNS TXT/SPF, IPs y nombres de dominio que pueden enviar mensajes de correo electrónico desde su dominio o el de su empresa. También aplica las consecuencias que se aplican a los mensajes que se envían desde dominios no autorizados.

¿Qué es DMARC y por qué es importante para el servidor de correo electrónico?

DMARC (Informes y conformidad de autenticación de mensajes basados ​​en dominio) está estrechamente relacionado con los estándares de políticas FPS y DKIM.
DMARC es un sistema de validación diseñado para proteger su nombre de dominio de correo electrónico o el de su empresa, de prácticas como la suplantación de correo electrónico y estafas de phishing.

Utilizando los estándares de control SPF (Sender Policy Framework) y DKIM (Domain Keys Identified Mail), DMARC agrega una característica muy importante. informes.

Cuando el propietario de un dominio publica DMARC en la zona DNS TXT, obtendrá información sobre quién envía mensajes de correo electrónico en su nombre o en nombre de la empresa propietaria del dominio protegido con SPF y DKIM. Al mismo tiempo, los proveedores destinatarios de los mensajes sabrán si el propietario del dominio de envío supervisa estas políticas de mejores prácticas y cómo.

Un registro DMARC en DNS TXT puede tener la forma:

V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;

In DMARC se pot pot pune mai multe conditii de raportare a incidentelor cat si adresele de e-mail pe care sa ajunga analizele si rapoartele. Este indicat sa folositi adrese de e-mail dedicate pentru DMARC deoarece volumul de mesaje primite poate fi semnificativ.

Etichetele DMARC pot fi setate in functie de politica impusa de dvs. sau de organizatie:

vversiunea protocolului DMARC existent.
paplica aceasta politica atunci cand nu se poate verificarea DMARC pentru mesajele e-mail. Poate avea valorea:none“, “quarantine” o “reject. Se utilizeazanonepentru a obtine rapoarte despre fluxul mesajelor si starea acesora.
ruaEste o lista de URL-uri pe care ISP-urile pot trimite feedback in format XML. Daca adaugam aici adresa de e-mail, link-ul va fi de forma:rua=mailto:[email protected]” .
ruf – Lista de URL a las que los ISP pueden enviar informes de incidentes cibernéticos y delitos cometidos en nombre de su organización. La dirección será de la forma: “ruf=mailto:[email protected]“.
rf – Formato de denuncia de delitos cibernéticos. se le puede dar forma “afrf” o “iodef“.
pct – Le indica al proveedor de Internet/ISP que aplique la política DMARC solo a un cierto porcentaje de mensajes fallidos. Por ejemplo, podemos tener: “pct=50%” o políticas “quarantine” y “reject“. Nunca será aceptado “none“.
adkim – Especificar “Modo de alineación” para firmas digitales DKIM. Esto significa que se comprueba la coincidencia de la firma digital de una entrada DKIM con el dominio. adkim puede tener los valores: r (Relaxed) o s (Strict).
aspf – De la misma manera que en el caso adkim se especifica “Modo de alineación” para SPF y admite los mismos valores. r (Relaxed) o s (Strict).
sp – Esta política se aplica para permitir que los subdominios derivados del dominio de la organización utilicen el valor DMARC del dominio. Esto evita el uso de políticas separadas para cada dominio individual. Es básicamente un “comodín” para todos los subcampos.
ri – Este valor establece el intervalo en el que se recibirán los informes XML para DMARC. La mayoría de las veces, es preferible realizar informes diariamente.
fo – Opciones de denuncia de fraude. “Opciones forenses“. Pueden tener los valores “0” para informar incidentes cuando fallan la verificación SPF y DKIM, o el valor “1” para el escenario en el que SPF o DKIM no existe o no pasa la verificación.

Entonces, para estar seguro de que sus mensajes de correo electrónico o los de su empresa llegan a los destinatarios en la Bandeja de entrada, es necesario tener en cuenta estos tres estándares de “mejores prácticas para enviar mensajes de correo electrónico“. DKIM, FPS y DMARC. Estos tres estándares pertenecen a DNS TXT y pueden administrarse desde el administrador de DNS del dominio.

Cómo configuramos el área de DNS TXT para SPF, DKIM y DMARC y cómo evitamos que Gmail rechace los mensajes de correo electrónico de negocios. – Entrega de correo fallido

También te puede interesar...

un pensamiento sobre “Cómo configuramos el área de DNS TXT para SPF, DKIM y DMARC y cómo evitamos que Gmail rechace los mensajes de correo electrónico de negocios. – Entrega de correo fallido

  1. Pingback: Configuración de dominios de correo electrónico personalizados en iCloud Mail

Deja un comentario

Su dirección de correo electrónico no será publicada. Los campos requeridos están marcados *