El libro mayor técnico, no el carrete de anuncios
Este es el registro de qué cambió en la plataforma de envío, la API y la pila de autenticación — escrito para el ingeniero que necesita saber si un cambio toca su integración antes de que le sorprenda en producción. Formato Keep a Changelog, fechado en ISO, con los cambios disruptivos y los parches de seguridad siempre en su propia línea. Sin "nos complace anunciar". Solo qué se movió, cuándo, y si te afecta.
Qué cambió, cuándo, y si te afecta
Este es el registro de cambios de la plataforma de envío, la API, la pila de autenticación y las herramientas operativas. Existe para un lector concreto: el ingeniero o responsable de operaciones que necesita saber si un cambio toca su integración antes de que le sorprenda en producción. Lo mantenemos en el formato Keep a Changelog, fechado en ISO 8601, con cada entrada clasificada en la categoría que te dice cuánta atención merece: un parche de seguridad y un retoque de texto se ven distintos aquí porque son distintos. Los cambios disruptivos (breaking changes) y los parches de seguridad siempre llevan su propia línea, nunca plegados en una nota genérica de "mejoras", porque enterrar un cambio disruptivo es como se pierde la confianza de un cliente en un solo despliegue.
Una nota sobre lo que esto no es. No son notas de versión de marketing: aquí no hay ningún "nos complace anunciar", y las descripciones de funciones orientadas al beneficio viven en otro sitio. Esto es el libro mayor técnico. Si un cambio no tiene efecto en cómo integras o en qué puedes confiar, en general no aparece; si cambia un comportamiento del que podrías depender, sí aparece, incluso cuando el cambio es pequeño. Las fechas son la fecha de despliegue en UTC. Donde un cambio implica trabajo de migración, la entrada lo dice con claridad.
2026
2026-04-22 · Seguridad
Impuesto MTA-STS en modo enforce en todos los dominios de envío compartidos, con endpoints de informe TLS-RPT publicados. Las conexiones que no pueden negociar TLS hacia un receptor compatible ahora fallan de forma cerrada en lugar de caer a texto plano. No requiere acción del cliente; los clientes gestionados en dominios propios fueron migrados individualmente en las dos semanas previas, con aviso.
2026-03-30 · Añadido
El aprovisionamiento de registros DANE/TLSA está ahora disponible para clientes cuyos socios receptores ejecutan DNSSEC, ofrecido junto a MTA-STS y no como reemplazo. Relevante sobre todo para remitentes con redes de corresponsales alemanas, neerlandesas y otras con fuerte presencia de DNSSEC. Opcional por dominio desde el panel o por petición al equipo operador.
2026-02-18 · Cambiado
La tubería de ingesta de informes DMARC agregados se reescribió para procesar informes en un ciclo de cuatro horas en lugar de diario. Las anomalías de colocación y autenticación afloran ahora al equipo de operaciones el mismo día hábil en la mayoría de casos. No cambió ninguna superficie de la API; el único efecto visible son alertas de anomalías más rápidas para clientes gestionados.
2026-01-12 · Corregido
Resuelto un caso límite en el aplanamiento SPF donde un dominio corresponsal que publicaba más de diez includes anidados podía, de forma intermitente, empujar un registro aplanado más allá del límite de 255 caracteres del segmento TXT. El aplanador ahora segmenta correctamente y avisa cuando un registro origen es patológicamente grande. Afectó a un número reducido de clientes con SPF upstream inusualmente complejo.
2025
2025-11-03 · Añadido
Soporte BIMI con validación de Certificado de Marca Verificada, incluido un validador autoservicio que comprueba las cuatro puertas (registro DNS, enforcement DMARC, conformidad SVG Tiny P/S y cadena de certificado) antes de que te comprometas. Disponible para cualquier cliente en DMARC p=quarantine o más estricto.
2025-09-15 · Cambiado
Versión mínima de TLS por defecto para la entrega saliente elevada a 1.2, con 1.3 negociado siempre que el receptor lo soporte. Los receptores que aún ofrecen solo TLS 1.0/1.1 —un caso cada vez más raro y relevante para la seguridad— requieren ahora una excepción explícita por dominio en lugar de una degradación silenciosa. Un puñado de corresponsales legacy se señaló a los clientes afectados antes del cambio.
2025-07-21 · Obsoleto
El formato de payload de webhook v1 legacy queda obsoleto en favor de v2, que lleva campos estructurados de resultado de autenticación y un esquema de eventos estable. v1 sigue funcionando al menos hasta el 2026-12-31; el aviso de obsolescencia existe para que las integraciones migren a su propio ritmo y no bajo presión. La migración es un ejercicio de mapeo de campos, documentado en la referencia de la API.
2025-05-08 · Añadido
Aislamiento por stream en Managed PowerMTA, que permite que el tráfico transaccional y el masivo corran en MTAs virtuales separados con reputación, colas y throttling independientes bajo una sola cuenta. Fue la capacidad más solicitada por clientes de alto volumen y permite que un envío de marketing deje de envenenar la reputación de un stream de restablecimiento de contraseña.
2025-02-26 · Seguridad
Rotadas y reemitidas las claves de firma DKIM a 2048 bits en todos los dominios gestionados que aún estaban en 1024 bits, conservando los selectores antiguos durante un solapamiento de 30 días para que el correo en tránsito validara contra cualquiera de los dos. Higiene rutinaria más que respuesta a ningún incidente, pero registrado aquí porque la rotación de claves es el tipo de cambio sobre el que un auditor preguntará.
2024
2024-10-09 · Cambiado
Migrado el panel de cliente a un backend reconstruido con carga sub-segundo en las vistas de entregabilidad que antes tardaban varios segundos con alto volumen de logs. Sin cambio en el modelo de datos; las URLs marcadas y los tokens de API siguieron funcionando sin cambios.
2024-06-17 · Añadido
Selección de región para clientes de nivel Custom, añadiendo una opción de centro de datos alemán junto al predeterminado sueco, ambos dentro de la UE. La residencia solo-UE sigue siendo el predeterminado de todos los planes; este cambio hizo seleccionable la ubicación concreta sin introducir ningún enrutamiento fuera de la UE.
2024-03-04 · Corregido
Corregido un fallo de clasificación de rebotes donde ciertos soft bounces de un gran proveedor de buzones se categorizaban como hard bounces, causando la supresión prematura de direcciones recuperables. Se revisaron las entradas de supresión de la ventana previa y se restauraron las direcciones suprimidas incorrectamente para los clientes afectados.
Anterior
La plataforma opera de forma continua desde 2003. Las entradas de arriba cubren el periodo desde que empezamos a publicar un changelog público estructurado; la historia más profunda —el paso a IP-dedicada-por-defecto, las herramientas PowerMTA originales, dos décadas de endurecimiento incremental— precede a este formato y vive en los registros operativos en lugar de aquí. Si necesitas entender un cambio anterior a este registro por una razón de cumplimiento o auditoría, el equipo operador puede recuperar el historial relevante.
Cómo seguir los cambios que te importan
Los cambios disruptivos y las entradas de seguridad son las que vale la pena seguir. Los consumidores de API registrados reciben aviso de cualquier cambio disruptivo bastante antes de la fecha efectiva, y las entradas de categoría seguridad se comunican directamente en lugar de dejarlas para que las descubras aquí. Para el detalle orientado al desarrollador detrás de cualquier entrada —esquemas de endpoint, formas de payload, pasos de migración— consulta la referencia de la API, y para cualquier cosa ambigua, pregunta al equipo operador directamente.
Cómo versionamos, y por qué se ve así
Versionamos este registro por fecha en lugar de por un número de versión semántica, y es una elección deliberada por la audiencia. Una versión semántica como 4.7.2 comunica magnitud a un desarrollador que consume una librería, pero para la infraestructura de correo la pregunta significativa es casi siempre "qué cambió y cuándo", no "en qué release numerada estoy". Las fechas responden eso directamente: puedes desplazarte a un mes y ver todo lo que se movió. Donde un cambio sí lleva una implicación disruptiva en la API, la etiqueta de categoría y el texto de la entrada llevan esa señal explícitamente, lo cual es más fiable que pedirle al lector que descifre un incremento de versión. La API en sí se versiona por separado a nivel de endpoint, así que una integración fijada a una versión dada de la API sigue funcionando sin importar lo que aparezca aquí.