10 mitos DMARC;

Cuando se trata de phishing, muchas empresas cometen el error de confiar en sus clientes o empleados para identificar y denunciar los ataques.

Pero esta estrategia es defectuosa. 97% de los usuarios de todo el mundo no pueden identificar correctamente un mensaje sofisticado de phishing.

La tecnología que bloquea mensajes maliciosos antes de que lleguen a la bandeja de entrada debe ser la primera línea de defensa contra el fraude de correo electrónico. Y el estándar DMARC (Domain-based Message Authentication Reporting and Conformance) hace precisamente eso.

Construir su registro DMARC es bastante sencillo. Pero hay muchos conceptos erróneos comunes sobre el proceso de implementación DMARC que pueden desviar la atención de sus esfuerzos para identificar y mitigar los ataques de phishing.

Desde que el equipo de Return Path’s Managed Service escucha estos conceptos erróneos de DMARC diariamente, pensaron que podría ser útil enumerar y desmentir los diez primeros aquí:

1. Los mecanismos de notificación de DMARC contienen datos suficientes para implementar una política de «rechazo» de DMARC con éxito.

Usted realmente necesita datos adicionales para dar el contexto de RUA y RUF, o termina confiando en suposiciones, lo que puede ser estresante.

2. Es una buena idea listar todos los posibles campos de encabezado en su firma DKIM porque es «más seguro».

Su objetivo con DKIM es validar criptográficamente que sólo usted podría haber enviado el mensaje en cuestión. Por lo tanto, elija sólo unos pocos campos para poner en su «h:array», ninguno de los cuales se cambiará por reenvío (lo que podría causar que su firma se quiebre).

3. Debe agregar “incluir” declaraciones (include statements) a su registro SPF en vez de ingresar IPs individuales o un rango CIDR (Classless Inter-Domain Routing).

Su registro de SPF necesita ser una máquina de velocidad significativa, esbelta—idealmente, una lista limpia de IPs. Mantenga include statement en un mínimo absoluto.

Haciendo esto añade velocidad y elimina un punto potencial de error.

4. Agregue 11ª include statement a su registro SPF.

El protocolo SPF sólo permite 10 include statements. Adicionando la 11ª include statement rompe el registro.

5. Enviar su clave privada de DKIM a alguien no es una gran cosa.

En el momento en que su clave privada está en cualquier otro lugar que no sea el MTA que lo usa, ya no es una clave privada y tiene que ser reemplazado.

6. Usted debe enviar todo el correo electrónico desde el dominio organizacional/de nivel superior.

Hay muchas razones para anotar aquí por qué el envío de correo electrónico de su dominio de nivel superior es una mala idea. Algunos se basan en gestión de vendedores y seguridad—su sistema de reservas de vacaciones es el más feliz enviando desde reservas@vacaciones.example.com. Otros en terrenos de entrega —usted nunca quiere mezclar correo de marketing y uno transaccional, por ejemplo. Vea este recurso de Google para obtener más detalles.

7. Un registro DMARC en el dominio organizacional/de nivel superior es todo lo que necesita.

Implementando DMARC en su dominio de nivel superior es un buen comienzo, pero no es suficiente para darle el control y la fidelidad de informes que necesita. Todos los dominios pertenecientes a su empresa (tanto de envío como de no envío) deben estar protegidos con una política de DMARC.

8. Debido a que usted envía la mayoría de su correo electrónico desde un cierto subdominio, los mal intencionados también lo harán.

Esta es una suposición común, y es falsa—usted necesita bloquear todo el dominio (el dominio organizacional principal y los subdominios). El objetivo de mayor valor es el dominio organizacional, no el subdominio del que usted envía más volumen.

9. Las decisiones de infraestructura anteriores se tomaron de manera racional.

No te vuelvas loco tratando de replicar el proceso de pensamiento de aquellos que construyeron tu infraestructura de correo electrónico. En vez de eso, utiliza el nuevo DMARC como una oportunidad para rediseñar y optimizar su (y la de su tercera parte) infraestructura y arquitectura.

10. Los vendedores en 2016 todos pueden firmar DKIM.

«Debe» no es lo mismo que «puede». El panorama del vendedor es muy variado. Usted necesita un experto que tenga un conocimiento detallado de cómo superar los diversos retos que enfrentará haciendo que toda su infraestructura se autentique correctamente con DKIM, en particular cuando se trata de vendedores de terceros.

 

Este artículo fue escrito por Neil Hammet en el blog del Return Path

Este post es parte de la contribución de Babel-Team para mejorar las prácticas de email marketing.

buenas practicas del email marketing DKIM email marketing entregabilidad de email Inbox Placement registro spf