Cumplimiento Microsoft 2025 (Outlook / Hotmail / Office 365) ============================================================= A partir de 2024 y con refuerzo progresivo durante 2025, Microsoft ha endurecido los requisitos de autenticación y reputación para remitentes de volumen medio y alto que envían hacia: - outlook.com - hotmail.com - live.com - msn.com - dominios corporativos en Microsoft 365 Los dominios que no cumplan con estos requisitos pueden experimentar: - Errores 550 5.7.515 Access denied - Mensajes "Unauthenticated email from " - Rechazos por DMARC fail - Bloqueos temporales o permanentes por reputación Requisitos mínimos exigidos por Microsoft ------------------------------------------ Para garantizar entregabilidad estable, el dominio remitente debe: 1. Tener SPF válido y alineado. 2. Tener DKIM activo y válido. 3. Tener política DMARC publicada. 4. No enviar desde IPs no declaradas. 5. Mantener baja tasa de rebotes y quejas. 6. Tener rDNS válido y consistente en las IPs de envío. 7. Utilizar TLS en la conexión SMTP. Modelo Mtmail y alineación relajada ------------------------------------ El sistema Mtmail (DMDS) utiliza: - Return-Path fijo (ej: dmds@nl.domain.com) - From dinámico (ej: cliente@domain.com) Debido a esta arquitectura, la alineación estricta (`aspf=s; adkim=s`) puede provocar fallas de autenticación en Microsoft si el subdominio del Return-Path no coincide exactamente con el dominio visible en el encabezado From. Por este motivo, se utiliza: - ``aspf=r`` - ``adkim=r`` La alineación relajada permite coincidencia a nivel de dominio organizacional (domain.com), lo cual es plenamente compatible con los requisitos actuales de Microsoft. Registro DMARC recomendado --------------------------- .. code-block:: bash _dmarc.domain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@rebotes.planisys.net; fo=1; aspf=r; adkim=r; pct=100; rf=afrf; ri=86400; sp=reject" Consideraciones críticas para Microsoft ---------------------------------------- - No enviar campañas masivas inmediatamente después de reactivar grandes volúmenes de contactos. - Implementar warm-up progresivo si se revalidan listas. - No mezclar IPs transaccionales con IPs de marketing. - Monitorizar reportes DMARC y SNDS (Smart Network Data Services). - Mantener tasas de rebote por debajo del 5%. - Mantener tasas de queja (complaint rate) por debajo del 0.3%. Buenas prácticas adicionales recomendadas ------------------------------------------ - Implementar BIMI una vez estabilizada la autenticación. - Publicar política DMARC en modo ``p=quarantine`` antes de pasar a ``p=reject`` si el dominio es nuevo. - Segmentar envíos por tipo de audiencia. - Evitar cambios frecuentes en selector DKIM sin necesidad. Advertencia operativa --------------------- Microsoft aplica filtros de reputación dinámicos basados en comportamiento histórico. Un dominio correctamente configurado técnicamente puede igualmente sufrir bloqueos si: - Se reactiva un volumen grande de contactos inválidos. - Se generan rebotes hard persistentes. - Se envía contenido percibido como phishing o engañoso. Por ello, la autenticación correcta (SPF, DKIM, DMARC) es condición necesaria pero no suficiente para garantizar entregabilidad. La combinación de: - Infraestructura autenticada - Gestión responsable de base de datos - Monitorización continua es indispensable para mantener reputación estable en el ecosistema Microsoft 2025. Evaluación de alineación SPF y DKIM en Microsoft ================================================ Microsoft no evalúa únicamente si SPF o DKIM “pasan”, sino si están **alineados correctamente con el dominio visible en el encabezado From**. El proceso simplificado que aplica Microsoft es el siguiente: 1. Verifica SPF contra el dominio del Return-Path (envelope sender). 2. Verifica DKIM contra el dominio que firma el mensaje. 3. Evalúa alineación DMARC comparando esos dominios con el dominio del encabezado From. 4. Aplica reputación histórica del dominio y de la IP. 5. Determina aceptación, cuarentena o rechazo. Alineación SPF -------------- SPF pasa si la IP está autorizada por el dominio del Return-Path. Sin embargo, para que DMARC considere SPF válido, el dominio del Return-Path debe estar alineado con el dominio del encabezado From. Ejemplo Mtmail: - Return-Path: dmds@nl.domain.com - From: cliente@domain.com Con: - ``aspf=r`` → alineación válida (mismo dominio organizacional) - ``aspf=s`` → falla (nl.domain.com ≠ domain.com exacto) Alineación DKIM --------------- DKIM pasa si: - La firma es válida. - El dominio firmante (d=) coincide con el dominio autorizado. Para que DMARC valide DKIM: - ``adkim=r`` → permite subdominios - ``adkim=s`` → requiere coincidencia exacta En Mtmail, si DKIM firma con: d=domain.com la alineación será válida incluso si el Return-Path usa nl.domain.com. Qué ocurre si falla la alineación ---------------------------------- Si SPF o DKIM pasan pero no están alineados, DMARC falla. Cuando DMARC falla y la política es: - ``p=none`` → Microsoft puede aplicar filtros internos - ``p=quarantine`` → mayor probabilidad de spam - ``p=reject`` → política clara del dominio (mejor reputación) Microsoft tiende a penalizar más dominios con DMARC en modo ``none`` cuando envían alto volumen. Casos reales de error 550 5.7.515 ================================= El error típico observado es: 550 5.7.515 Access denied, sending domain [domain.com] does not pass DMARC verification and has a DMARC policy of reject. O también: 550 5.7.515 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Este error aparece cuando: - DMARC falla. - El dominio tiene política ``p=reject``. - Microsoft detecta inconsistencia en alineación. - La reputación histórica es débil o reciente. En algunos casos también aparece cuando: - SPF no incluye correctamente la infraestructura de envío. - DKIM no está publicado. - DKIM firma con dominio incorrecto. - Se envía desde IP no autorizada. Por qué p=reject es prácticamente obligatorio en alto volumen ============================================================== Desde 2024, Microsoft y Google han endurecido requisitos para remitentes que superan ciertos umbrales de envío diario. Dominios con: - DMARC en ``p=none`` - Sin política publicada - O con configuración inconsistente son considerados de mayor riesgo. Ventajas de usar ``p=reject``: 1. Demuestra compromiso activo contra spoofing. 2. Mejora la puntuación de autenticación. 3. Reduce probabilidad de bloqueo preventivo. 4. Facilita recuperación tras incidentes. 5. Mejora consistencia en filtros automáticos. Microsoft interpreta ``p=reject`` como señal de madurez operativa del dominio. Importante: Un dominio técnicamente correcto pero con ``p=none`` puede experimentar mayor filtrado que un dominio con ``p=reject`` correctamente configurado. Recomendación para Mtmail ========================= Para dominios de envío recurrente o de alto volumen: - SPF correctamente configurado. - DKIM activo y validado. - DMARC con: .. code-block:: bash v=DMARC1; p=reject; aspf=r; adkim=r; pct=100; rua=mailto:dmarc@rebotes.planisys.net La combinación de: - Alineación relajada - Política estricta de rechazo - Infraestructura autorizada es actualmente el equilibrio más estable para el ecosistema Microsoft 2025. Cumplimiento Gmail 2025 ======================= Desde febrero de 2024, Google aplica requisitos obligatorios para remitentes que envían más de 5.000 mensajes diarios hacia dominios Gmail o Google Workspace. Dominios afectados: - gmail.com - googlemail.com - dominios corporativos en Google Workspace Requisitos obligatorios ----------------------- Para remitentes de volumen medio o alto, Google exige: 1. SPF válido. 2. DKIM válido. 3. DMARC publicado (mínimo p=none). 4. Alineación SPF o DKIM con el dominio del From. 5. TLS obligatorio. 6. Tasa de spam reportada inferior a 0.3%. 7. Cancelación de suscripción visible y funcional (List-Unsubscribe). Evaluación de autenticación en Gmail ------------------------------------ Gmail evalúa: - SPF (IP autorizada). - DKIM (firma válida). - Alineación DMARC. - Reputación del dominio. - Reputación de la IP. - Historial de quejas de spam. En el modelo Mtmail: - Return-Path: dmds@nl.domain.com - From: cliente@domain.com Con: - ``aspf=r`` - ``adkim=r`` La alineación organizacional es válida y compatible con los requisitos de Google. Errores frecuentes en Gmail ---------------------------- Cuando la autenticación falla o la reputación es baja, pueden observarse: - Bloqueos temporales 421 4.7.0 - Rechazos 550 5.7.26 Unauthenticated email - Clasificación directa en Spam - Limitaciones de volumen Gmail es especialmente sensible a: - Picos repentinos de envío. - Listas antiguas reactivadas. - Alto porcentaje de rebotes hard. - Falta de enlace de desuscripción funcional. Recomendación para Gmail ------------------------ Para dominios gestionados con Mtmail: - Publicar DMARC con ``p=reject``. - Mantener alineación relajada. - Monitorizar Google Postmaster Tools. - Implementar List-Unsubscribe header. Ejemplo recomendado: .. code-block:: bash v=DMARC1; p=reject; aspf=r; adkim=r; pct=100; rua=mailto:dmarc@rebotes.planisys.net Cumplimiento Yahoo 2025 ======================= Yahoo adopta políticas muy similares a Google, y desde 2024 exige autenticación estricta para remitentes de alto volumen. Dominios afectados: - yahoo.com - ymail.com - rocketmail.com - dominios corporativos gestionados por Yahoo Requisitos obligatorios ----------------------- 1. SPF válido. 2. DKIM válido. 3. DMARC publicado. 4. Baja tasa de quejas. 5. Infraestructura consistente. 6. Cancelación de suscripción accesible. Yahoo históricamente ha sido más agresivo en filtrado de reputación. Evaluación en Yahoo ------------------- Yahoo evalúa: - Alineación DMARC. - Reputación dominio. - Reputación IP. - Historial de engagement. - Consistencia en volumen. Dominios sin DMARC o con ``p=none`` tienen mayor probabilidad de: - Ser enviados a Spam. - Recibir limitaciones de volumen. - Ser bloqueados temporalmente. Errores típicos en Yahoo ------------------------ Ejemplos observados: 554 Message not allowed - DMARC policy reject 421 4.7.0 Temporarily deferred Yahoo penaliza especialmente: - Listas compradas. - Rebotes reiterados. - Cambios frecuentes de IP. - Firmas DKIM inconsistentes. Recomendación para Yahoo ------------------------ En el contexto Mtmail: - Mantener ``aspf=r`` y ``adkim=r``. - Usar ``p=reject``. - No alternar IPs sin warm-up. - Controlar tasas de rebote por debajo del 5%. Ejemplo recomendado: .. code-block:: bash v=DMARC1; p=reject; aspf=r; adkim=r; pct=100; rua=mailto:dmarc@rebotes.planisys.net Conclusión General (Microsoft, Gmail, Yahoo) ============================================ Los tres grandes operadores coinciden en: - SPF obligatorio. - DKIM obligatorio. - DMARC obligatorio. - Alineación correcta. - Reputación estable. - Baja tasa de quejas. Para el modelo Mtmail (Return-Path fijo + From dinámico), la configuración más estable en 2025 es: - SPF correctamente publicado. - DKIM activo. - DMARC con: .. code-block:: bash p=reject; aspf=r; adkim=r La autenticación correcta es condición necesaria, pero la gestión responsable de base de datos y reputación es igualmente crítica.