Configuraciones recomendadas para servicios de correo electrónico

SPF, DMARC y direcciones de conformidad

Para cumplir con las principales especificaciones de servicios de correo electrónico, se deben seguir dichas normativas; se recomienda que todo servicio de correo electrónico presente las siguientes configuraciones:

• Una clave TXT en el DNS para SPF, que permitirá el envío de mensajes desde determinados servidores, a continuación líneas de ejemplo:

"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.protection.outlook.com -all"

• Una configuración DKIM, utilizada por el servidor de correo que autenticará los mensajes que serán enviados, la cual puede variar entre una clave TXT o CNAME según la estrategia del servicio de correo electrónico
• Una configuración DMARC, que declarará la regla adoptada para los registros SPF y DKIM; se recomienda el siguiente valor, cambiando la dirección de correo electrónico que recibirá los reportes de los resultados DKIM:

"v=DMARC1; p=reject; sp=reject; fo=1; adkim=r; aspf=r; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; rf=afrf; ri=86400;"

• Si los correos electrónicos indicados para recibir los reportes de DMARC no pertenecen al mismo dominio de la regla, se requiere una clave del tipo TXT en el subdominio *._report._dmarc o (el dominio del correo en lugar del comodín *, por ejemplo: example.com._report._dmarc):

"v=DMARC1;"

• Grupos de correo o listas de distribución con los siguientes IDs:

abuse (contacto sobre abuso del servicio de correo electrónico)
admin (contacto del administrador - no documentada en RFC)
administrator (contacto del administrador - no documentada en RFC)
hostmaster (contacto sobre problemas de la zona de dominio)
noc (contacto sobre problemas de la infraestructura de red)
postmaster (contacto sobre problemas de la infraestructura de correo electrónico)
security (contacto sobre problemas de seguridad)
webmaster (contacto sobre sitios web)

Estrategia de redireccionamiento de Google Workspace:

Se recomienda redirigir todas las demás bandejas administrativas a un grupo con el nombre security@ utilizando el recurso de enrutamiento presente en Apps > Google Workspace > Settings for Gmail > Routing (enlace), dado que reservan algunas direcciones de correo como abuse@, impidiendo que sean agregadas como alias. Google permite que direcciones y grupos externos sean miembros de grupos locales; si es necesario, se puede agregar el contacto externo directamente al grupo.

Para redireccionamientos de bandejas individuales a destinatarios externos, pero si el redireccionamiento está bloqueado, es necesario crear una nueva OU con el permiso de redireccionamiento concedido para realizar redireccionamientos externos de ese usuario. Verifique las configuraciones de Automatic forwarding aquí.

Estrategia de redireccionamiento de Microsoft 365:

Se recomienda redirigir todas las demás bandejas administrativas a un grupo con el nombre security@ mediante alias en el propio grupo. Microsoft permite que direcciones y grupos externos sean miembros de grupos locales siempre que se agreguen como contacto; si es necesario, agregue el contacto externo en la plataforma en Users > Contacts (enlace) y añada este contacto como miembro del grupo.

Para redireccionamientos de bandejas individuales a destinatarios externos, el bloqueo se realiza por defecto; puede configurar mediante PowerShell una política para permitir que la cuenta local especificada pueda redirigir mensajes a destinatarios externos, usando las siguientes líneas:

Connect-ExchangeOnline
Get-HostedOutboundSpamFilterPolicy
New-HostedOutboundSpamFilterPolicy -Name "Allow Specific Forwarding" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "Allow Specific Forwarding Rule" -HostedOutboundSpamFilterPolicy "Allow Specific Forwarding" -From "localaccount@domain.example"

Las reglas de reenvío también pueden revisarse aquí, sin embargo, se recomienda crearlas por PowerShell para evitar fallos en la creación.

Estrategia para Locaweb:

El proveedor es inconsistente en el envío de mensajes desde grupos; se recomienda crear un buzón con el nombre security@, agregar alias (apodos) con las demás alternativas y añadir una regla mediante el webmail para redirigir mensajes al contacto deseado, que puede ser interno o externo.

Buzones de correo para servicios:

Se recomienda el uso de registros diferentes o de buzones con subaddressing al utilizarlos en registros de contacto como CAA, DMARC, security.txt, SOA, por ejemplo:

caa@ o security+caa@ para registro tipo CAA
dmarc@ o security+dmarc@ para registro TXT de host "_dmarc"
security.txt@ o security+security.txt@ para registro de contacto del security.txt
soa@ o security+soa@ para registro tipo SOA

Información adicional:

Se recomiendan también servicios de monitoreo y reputación de dominios, como Postmaster Tools, ofrecido por la plataforma Gmail de Google.

Los dominios sin servicio de correo deben utilizar MX con hostname inválido 0 . y SPF sin aprobaciones "v=spf1 -all", además de las reglas de DMARC correspondientes para evitar ataques de spoofing utilizando esos dominios.