Temas de esta sección:
los ajustes mínimos necesarios
Toma el control total de la reputación de tus correos electrónicos
controla lo que ocurre con tus correos electrónicos
comprueba automáticamente el correcto funcionamiento de los servicios cada diez minutos
Temas de esta sección:
Introducción al Marco de Políticas del Remitente
Comprueba la configuración SPF de tu correo electrónico enviando un mensaje de correo electrónico
Introducción a DomainKeys Identified Mail
Comprueba la configuración DKIM de tu correo electrónico enviando un mensaje de correo electrónico
SPF es la abreviatura de Sender Policy Framework, un estándar de autenticación de correo electrónico,
que te permite indicar cuáles son los servidores SMTP autorizados para enviar correos electrónicos en nombre de tu dominio.
Te permite verificar la dirección del remitente y su relación con el servidor que envió el mensaje.
Si los correos electrónicos se envían con tu dominio de remitente, el destinatario puede comprobar si han sido enviados desde un servidor SMTP que tú reconoces.
Se recomienda configurarlo, ya que algunos destinatarios podrían rechazar tus mensajes si no se ha configurado el SPF.
Hay dos enfoques diferentes:
La configuración «suave» provocará menos rechazos, o ninguno, por parte de los destinatarios.
La configuración «rigurosa» provocará que algunos mensajes sean rechazados si el servidor no ha sido declarado o, en algunos casos, cuando el correo electrónico haya sido redirigido o enviado a través de una lista de distribución.
La configuración «rígida» ofrece al servidor de correo de destino más libertad para decidir si acepta o no el mensaje; este es el enfoque que recomendamos.
Para configurar SPF es necesario saber exactamente qué servidores utilizas para enviar mensajes de correo electrónico.
Con RealSender, el registro TXT de tu dominio (ejemplo.com) debe contener la cadena
a:ejemplo.realsender.com y tener este aspecto:
example.com TXT «v=spf1 a:example.realsender.com ~all» Con HighSender, el registro TXT de tu dominio (ejemplo.com) debe contener la cadena
include:spf.realsender.com y tener este aspecto:
example.com TXT «v=spf1 include:spf.realsender.com ~all» Estas herramientas te ayudarán a validar la configuración:
www.kitterman.com/spf/validate.html *
recupera los registros SPF del nombre de dominio especificado y determina si el registro es válido
comprobación de SPF en línea
valida la configuración SPF de tu correo electrónico enviando un mensaje de correo electrónico
* = enlace a una página web externa; se abrirá en una nueva pestaña
Aunque todo esté configurado correctamente, la verificación del mensaje puede fallar
si el correo electrónico se ha redirigido (reenviado) o se ha enviado a través de una lista de correo.
In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.
spf@tester.realsender.comhttps://tester.realsender.com/spfLa comprobación SPF en línea de RealSender añadirá un prefijo al asunto si el mensaje no se ha autenticado correctamente:
!! spf-fail !! El servidor SMTP no figura entre los autorizados
y el correo electrónico debe rechazarse o descartarse
!! spf-softfail !! El servidor SMTP no figura entre los autorizados
pero este caso debe tratarse como un «softfail»
!! spf-neutral !! el registro SPF especifica explícitamente que no se puede determinar nada sobre su validez
!! spf-none !! el dominio del remitente no contiene información para autenticar el correo electrónico A veces, la información registrada a nivel de dominio no es correcta o no se entiende bien.
!! spf-permerror !! Se ha producido un error permanente (por ejemplo, un registro SPF mal formateado)
!! spf-temperror !! Se ha producido un error temporalLa comprobación SPF se realiza con la dirección de correo electrónico «Mail-From», que está oculta en los encabezados del correo electrónico.
Solo es visible la dirección de correo electrónico «De». Si sus dominios raíz son diferentes, aparece esta advertencia:
!! spf-diff !! Los dominios raíz de «Mail-From» y «From» son diferentesSi el mensaje supera tanto la comprobación SPF como la comprobación de alineación SPF para DMARC (alineación flexible), obtendrás:
|OK| spf-pass Tu correo electrónico supera la comprobación SPF y la comprobación de alineación SPFSi solo uno de ellos, SPF o DKIM, supera la comprobación de alineación de DMARC (alineación flexible),
el mensaje sigue considerándose «OK» (de confianza) y se añade el símbolo ~ (tilde) al principio:
|~OK| spf-pass Tu correo electrónico supera la comprobación SPF (pero no la de alineación) + comprobación de alineación DKIM
DKIM es el acrónimo de DomainKeys Identified Mail, un estándar de autenticación de correo electrónico,
diseñado para garantizar que el correo electrónico (incluidos los archivos adjuntos) no ha sido modificado desde que se añadió la «firma».
Para ello, añade una firma digital, vinculada a un nombre de dominio, a cada mensaje de correo electrónico saliente.
Se utilizan dos claves: una «pública» y otra «privada»:
Al enviar un mensaje, el servidor SMTP genera una «firma hash cifrada» basada en el contenido del mensaje de correo electrónico y en la clave privada.
El sistema receptor puede verificar la firma que figura en el encabezado del correo electrónico, comparándola con el contenido del mensaje y la clave «pública» del remitente.
Las firmas DKIM no son visibles de inmediato para los usuarios finales, sino que son añadidas y verificadas por la infraestructura de correo electrónico.
Los servidores SMTP de RealSender firman todos los mensajes de correo electrónico salientes con la firma DKIM.
RealSender firma inicialmente todos los mensajes salientes con su propio dominio vinculado al servidor SMTP,
sin que sea necesaria ninguna configuración por parte del usuario o del administrador.
Para obtener la«alineación de dominio DKIM para DMARC»,
el mensaje debe estar firmado con el mismo dominio del remitente.
Con RealSender, debes añadir dos registros CNAME
en la configuración de DNS de tu dominio (example.com), tal y como se muestra a continuación:
key1._domainkey.example.com CNAME key1._domainkey.yourcompany.realsender.com
key2._domainkey.example.com CNAME key2._domainkey.yourcompany.realsender.comEsta herramienta te ayudará a validar la configuración:
toolbox.googleapps.com *
* = enlace a una página web externa; se abrirá en una nueva pestaña
Un mensaje sellado con DKIM no se puede modificar, pero cualquiera puede leerlo.
Un mensaje firmado que no supera la verificación suele ser rechazado.
Si no se han producido cambios durante el trayecto desde el remitente hasta el destinatario, esto no debería ocurrir.
Hemos detectado algunos casos aislados, todos relacionados con la longitud de las líneas (que debe ser de un máximo de 990 caracteres).
Algunas aplicaciones envían el contenido en una sola línea o transmiten una línea muy larga dentro del código HTML.
En estas ocasiones, la firma DKIM se corrompe, lo que provoca que el resultado de la comprobación sea «dkim=fail».
dkim@tester.realsender.comhttps://tester.realsender.com/dkimLa comprobación DKIM en línea de RealSender añadirá un prefijo al asunto si el mensaje no se ha firmado correctamente:
!! dkim-none !! No se han encontrado encabezados DKIM-Signature (ni válidos ni no válidos)
!! dkim-fail !! Se ha encontrado un encabezado DKIM-Signature válido, pero la firma
no contiene un valor correcto para el mensaje A veces no es posible realizar la comprobación:
!! dkim-invalid !! Hay un problema en la propia firma o en el registro de la clave pública.
Es decir, no se ha podido procesar la firma
!! dkim-temperror !! Se ha detectado algún error que probablemente sea de carácter transitorio,
como una imposibilidad temporal de recuperar una clave públicaCuando el mensaje se haya firmado utilizando un dominio diferente, se añadirá una alerta «diff» al asunto.
Esta advertencia NO se mostrará si el remitente supera la comprobación SPF y la alineación SPF para DMARC:
!! dkim-diff !! El mensaje NO ha sido firmado por el dominio del remitenteSi el mensaje supera tanto la comprobación DKIM como la comprobación de alineación DKIM para DMARC (alineación flexible), obtendrás:
|OK| dkim-pass Tu correo electrónico supera la comprobación DKIM y la comprobación de alineación DKIMSi solo uno de los dos, DKIM o SPF, supera la comprobación de alineación de DMARC (alineación flexible),
el mensaje sigue considerándose «OK» (de confianza) y se añade el símbolo ~ (tilde) al principio:
|~OK| dkim-pass Tu correo electrónico supera la comprobación DKIM (no la alineación) + comprobación de alineación SPFTemas de esta sección:
Los dominios SPF que no estén alineados pueden provocar que falle la comprobación DMARC
Los dominios DKIM que no estén alineados pueden provocar que falle la comprobación DMARC
Autenticación, notificación y conformidad de mensajes basados en dominio
Recopilación de mensajes de RUA y generación de informes DMARC diarios en línea
DMARC es un estándar de autenticación de correo electrónico, desarrollado para combatir el correo fraudulento que suplantaba dominios.
Para la alineación de dominios, requiere que:
cuando un remitente autentica su correo electrónico mediante SPF o DKIM,
al menos uno de los dominios debe coincidir con el dominio «De» del mensajePara cumplir con el SPF (Sender Policy Framework), hay que tener en cuenta dos dominios:
DMARC admite dos tipos de alineación SPF: alineación flexible y alineación estricta.
Si no se especifica la alineación estricta, se asume por defecto la alineación flexible.
Con la alineación flexible, solo el dominio raíz de la dirección «Mail-From» debe coincidir con el dominio raíz de la dirección «From».
La alineación flexible permite utilizar cualquier subdominio y seguir cumpliendo el requisito de alineación de dominios.
ejemplo:
Si tu dominio «Mail-From» es mail.abc.com y tu dominio «From» es abc.com,
tu correo electrónico superará la comprobación de alineación SPF (los dominios raíz «abc.com» coinciden).
Si tu dominio «Mail-From» es abc.mail.com y tu dominio «From» es abc.com,
tu correo electrónico NO superará la comprobación de alineación SPF (los dominios raíz «mail.com» y «abc.com» no coinciden)
En el caso de la coincidencia exacta, el dominio de la dirección «Mail-From» debe coincidir exactamente con el dominio de la dirección «From».
ejemplo:
Si tu dominio «Mail-From» es mail.abc.com y tu dominio «From» es mail.abc.com,
tu correo electrónico superará la comprobación de coincidencia SPF (los dominios «mail.abc.com» coinciden).
Si tu dominio «Mail-From» es «mail.abc.com» y tu dominio «From» es «abc.com»,
tu correo electrónico NO superará la comprobación de alineación SPF (los dominios «mail.abc.com» y «abc.com» no coinciden).
DMARC es un estándar de autenticación del correo electrónico, desarrollado para combatir el correo fraudulento que suplantaba dominios.
En cuanto a la alineación de dominios, exige que:
cuando un remitente autentica su correo electrónico mediante SPF o DKIM,
al menos uno de los dominios debe coincidir con el dominio «De» del mensajePara que sea válido según DKIM (DomainKeys Identified Mail),
el dominio de firma DKIM (DKIM-Signature: d=…) debe coincidir con el dominio del remitente.
DMARC admite dos tipos de alineación DKIM: alineación flexible y alineación estricta.
Si no se especifica la alineación estricta, se asume por defecto la alineación flexible.
Con la alineación flexible, solo la raíz del dominio de firma DKIM debe coincidir con el dominio del campo «De» del remitente.
La alineación flexible permite utilizar cualquier subdominio y seguir cumpliendo el requisito de alineación de dominios.
ejemplo:
Si tu dominio de firma DKIM es mail.abc.com y tu dominio «De» es abc.com,
tu correo electrónico superará la comprobación de coincidencia DKIM (los dominios raíz «abc.com» coinciden).
Si tu firma DKIM es abc.mail.com y tu dominio «De» es abc.com,
tu correo electrónico NO superará la comprobación de alineación DKIM (los dominios raíz «mail.com» y «abc.com» no coinciden).
Para que la alineación sea estricta, el dominio de la firma DKIM debe coincidir exactamente con el dominio de la dirección «De» del remitente.
ejemplo:
Si tu dominio de firma DKIM es mail.abc.com y tu dominio «De» es mail.abc.com,
tu correo electrónico superará la comprobación de coincidencia DKIM (los dominios «mail.abc.com» coinciden).
Si tu dominio de firma DKIM es mail.abc.com y tu dominio «De» es abc.com,
tu correo electrónico NO superará la comprobación de coincidencia de DKIM (los dominios «mail.abc.com» y «abc.com» no coinciden).
DMARC son las siglas de: Autenticación, Notificación y Conformidad de Mensajes Basadas en Dominios.
Se trata de un estándar de autenticación de correo electrónico, desarrollado para combatir el correo electrónico que suplantaba dominios.
Remitentes:
Receptores:
En el caso de algunos proveedores de correo electrónico, esto influye de manera significativa en la capacidad de entrega; véase:
Cómo funciona DMARC con Gmail y Office 365 en 2020 *
«Office 365 suele responder bien a la autenticación SPF y DKIM.
La única forma de obtener resultados consistentes y llegar a la bandeja de entrada es combinarlos con DMARC»
* = enlace a una página web externa; se abrirá en una nueva pestaña
DMARC utiliza SPF (Sender Policy Framework) y DKIM (Domain Keys Identified Mail)
para gestionar los casos en los que un correo electrónico no supera las pruebas de autenticación.
SPF exige que se especifiquen los servidores que se utilizan para enviar mensajes de correo electrónico.
Consulte cómo configurar SPF para obtener más información y configurarlo correctamente.
Los servidores SMTP de RealSender firman todos los mensajes de correo electrónico salientes con la firma DKIM.
Es necesario realizar una configuración si deseas firmar con el mismo dominio del remitente.
Consulta cómo configurar DKIM para obtener más información.
RealSender te ofrece un buzón que recopila los informes DMARC generados por los destinatarios.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"A partir del día siguiente, empezarás a recibir los informes DMARC RUA en línea.
Es posible que te des cuenta de que te has olvidado de autenticar una campaña de correo electrónico enviada por un tercero.
Si ocurre algo así, solo tienes que autentificarla y comprobar que el siguiente envío supere las pruebas DMARC.
Cuando los informes sean correctos durante unas semanas, indica a los proveedores de correo electrónico que rechacen o bloqueen esos correos electrónicos falsificados o de phishing.
El registro TXT _dmarc de tu dominio debe modificarse para que quede así:
«v=DMARC1; p=reject; rua=mailto:dmarc.example@rsbox.com»Si su organización utiliza DMARC, deberá consultar detenidamente
antes de implementar cualquier nuevo método de envío de correo electrónico.
Dmarc aplica políticas estrictas sobre cómo se comprueban SPF y DKIM
Esto puede provocar que los proveedores de correo electrónico rechacen mensajes que, de otro modo, superarían esas comprobaciones
.
Aunque todo esté configurado correctamente, es posible que la verificación falle:
RealSender recopila y analiza los informes DMARC RUA(*) por ti.
* = Significado de «rua»:
URI de informe para datos agregados. En RealSender, la «rua» es la dirección de correo electrónico facilitada a los clientes,
,
a la que se envían informes agregados por parte de los dominios
que han recibido correos que afirman proceder de tu dominio.
Los informes se generan todos los días a las 13:00 (CET) y recogen los datos de los últimos siete días.
Este es un informe en línea de DMARC; página de ejemplo:
Temas de esta sección:
informes detallados por mes, días, horas, servidores y correo electrónico del remitente
registros de correos electrónicos, notificaciones de estado de entrega (DSN), notificaciones de entrega correcta
Revisa los mensajes de correo electrónico que se han enviado para entender qué está pasando
RealSender ofrece informes detallados sobre la actividad de cada servidor SMTP y de los correos electrónicos salientes.
Los datos se actualizan automáticamente cada cinco minutos.
Si lo solicita, podemos enviarle un resumen semanal por correo electrónico.
Nota: estos errores se deben a intentos no autorizados de enviar correos electrónicos a través del servidor
RealSender te permite acceder a través del navegador a los datos de los correos electrónicos procesados:
Los datos mostrados se pueden guardar localmente directamente desde el navegador, o registrarse automáticamente a intervalos regulares (por ejemplo, una vez al día), para mantener un historial.
31 de mayo 06:26:22 rs336 v4V4QL1K030027:from=sender@yourcompany.com
31 de mayo 06:26:25 rs336 v4V4QL1K030027:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Enviado (Mensaje aceptado para su entrega)
31 de mayo 08:58:04 rs336 v4V6w3jN001390:from=sender@yourcompany.com
31 de mayo 08:58:05 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Aplazado: 421 recipient@yourcustomer.com Servicio no disponible: demasiado ocupado
31 de mayo 09:02:03 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Aplazado: 421 recipient@yourcustomer.com Servicio no disponible: demasiado ocupado
31 de mayo 09:12:42 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Enviado (Mensaje aceptado para su entrega)
31 de mayo 10:00:22 rs336 v4V80L9Z004176:from=sender@yourcompany.com
31 de mayo 10:00:24 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Aplazado: 451 4.7.1 recipient@yourcustomer.com: Dirección del destinatario rechazada: Lista gris activa, inténtelo más tarde
31 de mayo 10:02:03 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: Dirección del destinatario rechazada: Lista gris activa, por favor, inténtelo más tarde
31 de mayo 10:12:04 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Enviado (Mensaje aceptado para su entrega)
31 de mayo 16:17:14 rs336 v4VEHCk6017038:from=sender@yourcompany.com
31 de mayo 16:17:15 rs336 v4VEHCk6017038:to=recipient@yourcustomer.com, dsn=5.1.1, stat=Usuario desconocido
31 de mayo 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: Usuario desconocido
25 de mayo 12:43:37 rs336 v4PAhZw1019212:from=sender@yourcompany.com
25 de mayo 12:43:38 rs336 v4PAhZw1019212:to=recipient@yourcustomer.com, dsn=5.0.0, stat=Servicio no disponible
25 de mayo 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: Servicio no disponible
25 de mayo 09:17:41 rs336 v4P7Hc6P011481:from=sender@yourcompany.com
25 de mayo 09:17:42 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 buzón lleno
[…] el sistema vuelve a intentar el envío cada diez minutos* […]
25 de mayo 13:25:47 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 buzón lleno
25 de mayo 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: notificación del remitente: No se puede enviar el mensaje durante 4 horas*
* = véase la nota al final del siguiente párrafo
Los correos devueltos (por ejemplo, por usuario desconocido) se envían a la dirección de correo electrónico del remitente o a la dirección de ruta de retorno (si se ha especificado).
En caso de que se produzca un retraso en la entrega de los mensajes, recibirás un aviso al cabo de 30 minutos*, como este:
Asunto:
Advertencia: no se ha podido enviar el mensaje durante los últimos 30 minutos
Cuerpo:
**********************************************
** ESTE ES SOLO UN MENSAJE DE ADVERTENCIA **
** NO ES NECESARIO QUE VUELVAS A ENVIAR TU MENSAJE **
**********************************************
[...] El sistema volverá a intentarlo automáticamente durante cuatro horas*. Si no recibe más notificaciones, significa que el mensaje se ha entregado correctamente. Puede consultar los detalles en los registros (véanse los ejemplos mencionados anteriormente).
Tras cuatro horas* de intentos fallidos, se enviará un mensaje de error definitivo a la dirección de correo electrónico del remitente o a la dirección de retorno (si se ha especificado), de la siguiente manera:
Subject:
Returned mail: see transcript for details
Body:
The original message was received at ...
----- The following addresses had permanent fatal errors -----
<recipient@yourcustomer.com>
----- Transcript of session follows -----
Deferred: Connection timed out with yourcustomer.com.
Message could not be delivered for 4 hours
Message will be deleted from queue
[...] * = al enviar correos masivos:
las notificaciones de estado de entrega retrasada están desactivadas,
el intervalo entre los intentos de entrega se ha ampliado (de diez a treinta minutos),
el tiempo máximo de permanencia en la cola es mayor (de cuatro a veinticuatro horas)
Si lo solicita, también podemos activar la «notificación de entrega» para los correos entregados correctamente. De este modo, por cada mensaje entregado, el remitente recibirá el acuse de recibo del servidor de destino, como el que se muestra a continuación. Esta opción resulta útil para quienes necesitan un acuse de recibo por cada correo enviado.
Subject:
Return receipt
Body:
The original message was received at ...
----- The following addresses had successful delivery notifications -----
<recipient@yourcustomer.com> (successfully delivered to mailbox)
----- Transcript of session follows -----
<recipient@yourcustomer.com>... Successfully delivered
[...]En casos excepcionales (menos del 1 % de los correos enviados), no se envía el acuse de recibo al remitente. Esto ocurre si el destinatario ha activado una opción especial de «privacidad / sin acuses de recibo» en su servidor de correo. Por lo general, no se recomienda esta configuración, ya que también bloquea el envío de las notificaciones estándar de no entrega.
A veces, para entender lo que está pasando, es necesario revisar los mensajes de correo electrónico que se han enviado.
Si así se solicita, RealSender puede activar la copia automática de todos los correos electrónicos salientes en un buzón específico.
El buzón está configurado para poder recibir grandes cantidades de correos electrónicos en poco tiempo sin ningún problema.
Los mensajes de correo electrónico se eliminan automáticamente al cabo de 7 días.
Atención: si los mensajes se envían desde cuentas de correo electrónico personales (aunque sean cuentas de la empresa),
debes informar al remitente de que las comunicaciones que envía pueden ser leídas con el fin de realizar comprobaciones técnicas.
Para comprobar el correcto funcionamiento del servicio,
hemos activado un entorno de control automático.
Una aplicación externa se conecta a cada servidor SMTP cada diez minutos
y envía un mensaje real. El envío correcto del correo electrónico nos permite garantizar
la disponibilidad y el correcto funcionamiento del sistema.
El resultado se publica en la «página de estado» de tu servidor RealSender,
y se puede consultar libremente en la dirección web: rsXXX-realsender.com/status
Los datos se muestran en tiempo real, como se puede ver en el ejemplo que aparece a continuación.
La información mostrada corresponde a las últimas veinticuatro horas.
11/09/2024 06:25:26 UTC
rsXXX: comprobación de disponibilidad cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 06:16:18 UTC
rsXXX: comprobación de disponibilidad cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 06:05:56 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:55:41 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:45:57 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:35:58 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:25:27 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:16:30 UTC
rsXXX- COMPROBACIÓN DE DISPONIBILIDAD cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 05:05:57 UTC
rsXXX: comprobación de tiempo de actividad cada diez minutos (se ha enviado un correo electrónico correctamente) - OK
11/09/2024 04:55:36 UTC
rsXXX: comprobación de tiempo de actividad cada diez minutos (se ha enviado un correo electrónico correctamente) - OK