Configurar DomainKeys

He intentado mejorar la seguridad de mis correos electrónicos (y evitar que se marquen como spam) agregando los registros SPF y DKIM. Así que los creé a ambos y probé los resultados con check-auth@port25.com. Este es el resultado:

==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

Entonces, todo pasó excepto DomainKeys . El informe detallado es:

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result: neutral (message not signed)
ID(s) verified: header.From=myemail@mydomain.com
DNS record(s):

Luego intenté agregar el registro TXT _domainkey.mydomain.comcon contenido t=y; o=~y lo verifiqué nuevamente, pero el resultado fue el mismo (el DNS se ha propagado, ya que verifiqué el registro DNS de mxtoolbox y lo obtuve).

¿Qué debo hacer para arreglar esto?

La respuesta correcta a "qué debo hacer para solucionar esto" es eliminar el registro de DomainKeys. La confusión surge de pensar que DomainKeys y DomainKeys Identified Mail (DKIM) son lo mismo. No lo son DomainKeys era una tecnología específica de Yahoo que ha estado oficialmente muerta desde 2007. Como dijo Chris S., DKIM (DomainKeys Identified Mail) es el sucesor de DomainKeys. A partir de 2007.

Hace unos años ejecuté un DomainKeys y un validador DKIM en el correo entrante. Vi algunos correos electrónicos con firmas de DomainKeys, pero me sorprendería si ese fuera el caso. Ya no hay ninguna razón para implementar DomainKeys ya que ninguno de los software de firma de DomainKeys todavía es compatible.

Esto es todo de lo que debe preocuparse:

Verificación DKIM: pasar

Y tu estas bien.

Además, Chris S. está equivocado acerca de la identificación del remitente. No es, ni ha sido nunca, propuesto como sucesor de SPF. La Id. Del remitente es un estándar propuesto por Microsoft que ya no existe en SPF. El SPF y la ID del remitente no hacen lo mismo. La identificación del remitente fue el intento de Microsoft de agregar comprobaciones de validación de encabezado sobre SPF (que valida el remitente del sobre). El resto de la comunidad de correo electrónico lo rechazó en parte porque Microsoft hizo valer los derechos de patente y no los renunció hasta después de que naciera la Identificación del remitente. Fuera de hotmail.com y de los servidores de Exchange locales, la adopción de ID de remitente podría describirse con precisión como un error de redondeo.

Microsoft ha dejado de validar la ID del remitente en hotmail, dejando solo los servidores locales de Exchange como los últimos vestigios de la ID del remitente en Internet. Han anunciado los próximos cambios en Exchange que dejarán de romper las firmas DKIM a medida que los mensajes pasen por los servidores de Exchange. Aunque DMARC simplemente evita la suplantación de identidad, Microsoft se ha subido oficialmente al carro DMARC que abarca tanto DKIM como SPF.

Para que DKIM funcione, debe firmar cada correo saliente con su clave privada dkim (en el servidor de correo). La clave pública debe agregarse a su registro dkim dns, para que otras personas puedan verificar sus correos firmados.

para la firma dkim uso:

http://www.opendkim.org/

spf es fácil de implementar: dkim requiere un poco más de esfuerzo