Resumen
00:00:33 – Conoce a Marcel Becker
00:01:10 – ¿Y cuál es la gran actualización de Yahoo y Gmail?
00:04:18 – ¿Por qué ahora?
00:08:22 – Al fin y al cabo, también somos remitentes
00:00:07
Eric Trinidad: Bienvenidos a Email’s Not Dead. Tu podcast de frikis del email para frikis del email. Me llamo Eric y conmigo, como siempre, está mi brochacho. JT. JT, ¿cómo estás, señor?
00:00:16
Jonathan Torres: Muy bien, amigo. Bien. Gracias por la presentación.
00:00:18
Eric Trinidad: Sí, tío. Gracias por venir. Ya sabes, hemos tenido una semana muy ocupada hasta ahora, saliendo de la euforia de las vacaciones y mirando hacia el futuro. Y con esto, creo que hoy tenemos a un invitado muy especial con nosotros, ¡el Director sénior de Gestión de productos de Yahoo! Marcel Becker. Marcel, ¿cómo estás hoy, señor?
00:00:33
Marcel Becker: Estoy bien. Hace un poco de frío donde estoy ahora mismo, pero por lo demás bien.
00:00:38
Eric Trinidad: Sí, claro. ¿Dónde estás? No hace falta que nos des tu dirección. Solo la región en general.
00:00:44
Marcel Becker: En el Área de la Bahía, en California.
00:00:46
Eric Trinidad: Ah, muy bien.
00:00:47
Jonathan Torres: Creo que el frío de allí es mucho frío para Texas, porque en Texas no hace mucho frío. Y cuando lo hace, hace mucho frío de verdad. Así que…
00:00:56
Eric Trinidad: Sí, ahora mismo estamos a unos agradables 60 grados y está un poco húmedo, pero estamos bien. Lo estamos llevando bien.
00:01:02
Jonathan Torres: Es lo que hay. Es lo que hay. Solo estaremos por aquí, ya sabes, hablando de email, de todas las cosas en torno al email, me encanta. Nos divertimos con ello.
00:01:10
Eric Trinidad: Sí, por supuesto. Queríamos traerte hoy. Algunos cambios que se avecinan, algunas cosas que se van a aplicar en un futuro próximo. Y bueno, es bueno tener a alguien de la fuente para darnos algo de feedback y tratar de aclarar algunas de estas cosas. Marcel, ¿te importaría darnos una pequeña previsualización de lo que va a pasar en el nuevo año?
00:01:28
Marcel Becker: Sí, totalmente. Aunque no estoy seguro de qué pasará en el nuevo año.
00:01:32
Eric Trinidad: Sí, bueno, nos informaron en octubre. Va a haber algunos nuevos requisitos que se aplicarán por ahí de febrero.
00:01:41
Jonathan Torres: Podemos resumirlo rápidamente. Van a ser tres cambios: autenticación, autenticación y autenticación.
00:01:47
Eric Trinidad: Sí.
00:01:49
Marcel Becker: Básicamente es eso. Así que creo que mi trabajo aquí ha terminado.
00:01:51
Eric Trinidad: Vale. De acuerdo. Buen trabajo a todos. Chocad esos cinco.
00:01:53
Jonathan Torres: Gracias a todos.
00:01:56
Marcel Becker: Quiero decir que no va a pasar nada en términos de cómo gestionamos y tratamos el email. Exacto. Porque todas estas cosas que anunciamos conjuntamente con Gmail son en realidad cosas de las que hemos hablado, publicado y documentado como mejores prácticas de envío o requisitos durante mucho tiempo, en algunos casos una década. Realmente las desglosamos. Estas tres cosas que son: necesitas autenticar tu email, y tienes que asegurarte de proporcionar una opción fácil para darse de baja a los usuarios. Y por supuesto, tienes que mantenerte por debajo de un cierto umbral de spam. Es decir, son cosas que queríamos que los remitentes hicieran, o que los remitentes ya deberían estar haciendo desde hace tiempo. Y si lo piensas, no son irrazonables. Para mí, tienen muchísimo sentido, son más que obvias. Realmente enfocamos esto desde la perspectiva de la experiencia del cliente, ¿verdad? Queremos asegurarnos de que nuestros usuarios tengan la mejor experiencia posible. Que reciban los emails que realmente quieren, y les ayudamos a deshacerse de los emails que no quieren, ¿verdad? Y luego observamos estos requisitos de autenticación de tu email, para entender realmente quién diablos eres, ¿no? Ayudar a los usuarios a deshacerse del email. De ahí viene lo de darse de baja. Y también asegurarnos de que la gente reciba los emails que realmente ha pedido y que no les llegue basura a la bandeja de entrada. De ahí viene el asunto del spam.
00:03:20
Eric Trinidad: Sí. Porque yo sé, por ejemplo, que odio tener que darme de baja de algo y que sea como: Vale, ya no quieres ver esto. ¿Puedes escribirnos una carta, por favor? Envíala directamente. Te responderemos en unas tres semanas. Te avisaremos si te damos de baja. Pero luego me están contactando como dos veces al día durante las siguientes tres semanas, ¿sabes?
00:03:36
Marcel Becker: Exactamente. Sí.
00:03:37
Jonathan Torres: Más o menos cubrimos el por qué, que definitivamente está en esa afirmación de intentar mejorar. Exacto. Como comunidad, creo que todos necesitamos mejorar un poco con el email. Es hacia lo que siempre nos esforzamos y lo que siempre pensamos cuando damos contexto para el podcast, en cómo mejorar como remitentes, ¿verdad? ¿Cómo puede la comunidad de envíos mejorar en lo que todos deberíamos hacer, siendo buenos participantes aquí? Y sabes, en lo que respecta a esto y a los cambios que se están haciendo, creo que la pregunta pendiente es (y puede que no tengas una respuesta para esto y nos metamos en lo teórico y las opiniones y cosas así). Pero, ¿por qué ahora? En plan, ¿hay alguna inclinación al por qué hoy? Dijiste que llevabas hablando de esto unos diez años, ¿cuál es ese disparador que dice: oye, hagámoslo ahora?
00:04:18
Marcel Becker: Sí, es un buen punto, ¿verdad? Te puedes poner muy filosófico con esto y probablemente pasarte toda una tarde en cualquier sitio dándole vueltas. Pero recuerdo estar en un escenario en algún sitio probablemente hace diez años. Hablamos con un grupo de gente también, donde decíamos «sin autenticación, no hay entrada». Exacto. Y dijimos que esto es algo por lo que deberíamos esforzarnos. Es algo en lo que deberíamos trabajar porque tiene mucho sentido poder identificar de forma positiva quién envía un email, simplemente ayuda, ¿verdad? No significa necesariamente que si autenticas tu email vaya a pasar directamente a la bandeja de entrada o podamos identificarte como un spammer. Ese no es realmente el caso, pero apunta o nos ayuda a identificar quién eres y luego asignar la reputación a tu identidad. Y si envías cosas buenas y la gente quiere tu email, entonces es una señal muy positiva; y puedes identificarlo si envías basura y la gente no lo quiere. También nos ayuda a identificar eso, ¿no? Simplemente nos facilita la tarea de ayudar a nuestros usuarios a obtener la mejor experiencia, ayudar a combatir el spam y también, francamente, liberar algunos recursos. Y a medida que avanzábamos a lo largo de la última década, de cierta forma el problema empeoró, porque el volumen de emails sigue aumentando. La cantidad de emails con los que la gente tiene que lidiar sigue aumentando. ¿Verdad? Todos lo sabemos por experiencia propia. Simplemente hay mucho ruido y puede que lo hayamos comprado o puede que yo lo quisiera, o puede que no. Y luego hay personas malintencionadas tratando de aprovecharse de la reputación supuestamente buena de alguien, o lo que sea, y de la buena reputación de cierta plataforma de envío donde sale mucho spam de grandes proveedores en la nube. Y en un momento dado, nosotros, por parte del proveedor de servicios de email, simplemente dijimos: vale, ya es suficiente. Tenemos que hacer algo que nos ayude a ayudar a nuestros usuarios a obtener una mejor experiencia de usuario. Y de alguna forma también necesitamos ayudarnos a nosotros mismos, necesitamos que los remitentes nos ayuden, ayudarles a llegar a la bandeja de entrada si son buenos remitentes, pero también a dejar fuera la basura en algún momento. Y creemos que la tecnología estaba ahí y ha estado ahí durante algún tiempo. Y también creemos que, basándonos en las conversaciones que mantuvimos dentro de la industria o con grupos de trabajo del sector como M3aawg y otros, la comunidad de envíos debería estar preparada para respaldar estos cambios desde una perspectiva puramente tecnológica. Así que no vimos ninguna razón por la que alguien no pudiera hacer estas cosas que han estado por ahí como mejores prácticas. Pero la adopción seguía siendo muy, muy pequeña porque esa es la parte que podemos debatir, ¿verdad? Los incentivos, porque ¿por qué pasa eso? Pero dijimos: vale, pongamos un límite y digamos que si quieres enviar un email de marketing, si quieres llegar a la bandeja de entrada del usuario, aquí tienes las cosas que hicimos más allá de los requisitos técnicos básicos que la gente ya tiene que cumplir.
00:07:07
Jonathan Torres: Es increíble. Creo que cubre tantas cosas que, incluso desde nuestra perspectiva, desde el lado del envío y la gente que conocemos y con la que nos hemos comunicado, sé que les he dicho a los remitentes cosas como: oye, haced esta parte de la autenticación. Es una de esas cosas que sé que son útiles y que ayudan a la comunidad en general. Creo que, con cada incentivo que se ha ido lanzando, pensarías: oye, va a haber adopción, está saliendo BIMI, va a haber adopción. Ya sabes, haciéndolo más fácil, haciéndolo mucho más sencillo de adoptar para la gente. Y aún así no ha tenido adopción. Y una de las cosas que quiero señalar de lo que dijiste, porque realmente es una de las cosas que resuenan conmigo y, siempre que hablo con alguien que hace envíos a cualquier nivel, siempre digo que la responsabilidad del ISP es con su base de usuarios. Así que, si no estás respetando lo que haces, lo que envías para respetar a su base de usuarios, ellos tienen que hacer lo necesario para respetar a su propia base de usuarios, para ayudar a su base de usuarios y para asegurarse de que su base de usuarios esté protegida. Y tenemos que ser buenos ciudadanos con la forma en que se envían las cosas y asegurarnos de que hacemos lo correcto con lo que enviamos para poder jugar en ese entorno. Es decir, sin duda es algo que, ya sabes, es un privilegio. No es un derecho y requiere hacer lo correcto para poder hacerlo. Así que quería mencionar eso porque realmente resuena conmigo y me siento validado. Me siento escuchado, ya sabes. Y es como. Es una de esas cosas donde tienes una responsabilidad.
00:08:22
Marcel Becker: Para añadir a eso. Me gusta decir que no es solo nuestra base de usuarios, ¿verdad? Es nuestra base de usuarios mutua como marca. En lugar de llegar a todos nuestros usuarios. También son sus usuarios y deberían tener, ya sabes, su mayor interés o la mejor experiencia del usuario en mente también, ¿verdad? Al fin y al cabo estamos juntos en el mismo barco, y si podemos trabajar juntos para crear esa gran experiencia y nosotros también somos consumidores; como siempre, hacemos esto internamente. Es decir, pregunto a la gente cuando se les ocurre una idea o una sugerencia: ¿Tú lo usarías? Y si no, ¿por qué?, ¿verdad? Así que ponte en la piel del usuario o, ya sabes, simplemente sé un usuario. Y todos nosotros también somos consumidores. ¿Te encantaría hacer clic en eso? ¿Te encantaría recibir estos emails realmente? ¿Y si no, por qué no?
00:09:07
Jonathan Torres: Sí, es una gran perspectiva.
00:09:09
Eric Trinidad: Sí. Parece que ese es un tema recurrente temprano en esta temporada: simplemente hay que ser humanos, ¿verdad? O sea, si te parece bien y lo harías, entonces ya sabes. Sí. Pero si te parece raro, no lo hagas. Lo cual aplica a la vida en general. En general, me parece.
00:09:24
Jonathan Torres: Ponerse, ya sabes, en el lugar del destinatario. Exacto. En la piel del usuario creo que es, sin duda, una gran parte de eso. Cuando se trata de eso, de la parte del envío. Sabes, mientras la gente se alista y se prepara. Sé que ha habido muchas preguntas. Estoy seguro, si es que no estás ya cansado de hablar de esto. Me pregunto lo cansado que vas a estar para febrero de hablar sobre este tema, porque sé que todo el mundo tiene un montón de preguntas y parece que son las mismas preguntas una y otra vez, y que sé que volveremos a hacer aquí. Pero, ya sabes, cuando se trata de la preparación del usuario, sé que ya estamos hablando de diferentes cosas. Hablamos de la parte de la autenticación, pero ¿cuáles son las cosas clave que la gente puede empezar a hacer ahora, hoy mismo, para prepararse para este cambio?
00:09:58
Marcel Becker: La mayoría de estas cosas deberían ser cosas que la gente ya llevara haciendo mucho tiempo, como autenticar tu email, incluir ahí un enlace para darse de baja o supervisar tus tasas de spam. Creo que lo que deberías hacer ahora son todas estas cosas de manera efectiva; si no entiendes o no sabes cómo autenticar adecuadamente tu email, qué es realmente DMARC o cómo funciona, busca a un experto. Hay muchos recursos por ahí y la mayoría de las preguntas que recibimos son sobre la autenticación. ¿Qué tengo que firmar? ¿Cómo funciona DKIM? ¿Qué significa que un dominio tenga que alinearse? ¿Verdad? Son el tipo de cosas, ya sabes, que me encantaría responder. Y bueno, hay otros expertos ahí fuera, empresas que están encantadas de cobrarte por ello, o incluso gente que comparte consejos gratis. Exacto. Y también hay recursos gratuitos disponibles, y los ha habido durante décadas en estos casos. Así que sal, infórmate y entiende realmente qué significa la autenticación. Lo mismo pasa con lo de darse de baja; esta tecnología no es nueva, lleva ahí bastante tiempo y está documentada. Lee sobre ello para ver qué significa realmente. ¿Qué significa darse de baja con un clic? ¿Qué dice realmente el RFC 8058? ¿Cómo funciona? Todas estas cosas.
00:11:09
Jonathan Torres: Gracias por mencionarlo. En su mayor parte, creo que muchos de nosotros aquí hemos hecho carrera cobrando a la gente por esos consejos, ya sabes, y pagando a esos expertos. Ya sabes, e incluso desde mi punto de vista, he escrito artículos internos sobre cómo funcionan algunas de estas cosas, lo que significan, como en el caso de SPF y DKIM, y cómo encajar todo eso y asegurarse de que, ya sabes, el DMARC termine estando alineado. Y bueno, lo he hecho internamente y estoy dispuesto a compartir esos conocimientos. Y sé que he ayudado a contribuir a las publicaciones del blog que tenemos en nuestro sitio web. Podemos echar un vistazo a esos recursos gratuitos y decir, vale, ¿cómo hago esto? Es una de las cosas que tengo que considerar y cómo la implemento correctamente, pero creo que definitivamente es una de esas cosas donde hablar con un experto ayuda bastante, y no sé si hay alguien más por ahí escuchando este podcast, pero sé que leer los artículos y las directrices sobre los RFC no es lo más divertido del mundo. Yo soy uno de esos locos que va a mirarlo y a asimilarlo porque me gusta saber y entender, ya sabes, desde un nivel y una perspectiva técnica, lo que tengo que hacer. Pero si tienes la capacidad y las ganas de hacerlo, entonces eso va a ser lo más útil, cien por cien. Pero siempre hay expertos por ahí dispuestos a ayudar a digerir lo que eso significa y lo que se necesita para implementarlo en cualquier nivel. Y dependiendo de con quién estés enviando. Sé que aquí hablamos de las cosas desde la perspectiva de Mailgun.
00:12:26
Marcel Becker: Eso también es clave, ¿no? No espero que el experto en marketing se lea un RFC y entienda todos los matices. Exacto. No espero necesariamente que el profesional del marketing entienda qué significa firmar los encabezados de baja de la lista, con la firma DKIM y todas estas cosas. Exacto. Lo que me encantaría es que empresas como vosotros u otros proveedores de herramientas dieran un paso adelante y dijeran: oye, podemos resolver esto en el código, porque creo que tiene solución. Podemos hacer esto tan sencillo que literalmente solo tengas que hacer clic en un botón para enviar tus cosas como lo haces normalmente. Y nosotros nos encargamos del trabajo duro en segundo plano. No tienes que preocuparte de nada de eso. Y veo que eso pasa con un montón de empresas por ahí. También entiendo que hay muchos casos extremos y situaciones en las que decían: «Uy, tenemos que ver cómo funciona esto, ¿cómo lo solucionaríamos?» Y me alegra mucho participar en estas conversaciones, que es uno de los motivos, por si te preguntas ¿por qué en febrero? o ¿por qué ahora? Exacto. Uno de los motivos por los que no di una fecha desde mi punto de vista fue precisamente porque no quería decir: oye, para febrero tenéis que hacer X, Y y Z, y esperamos que todo el mundo cumpla con ello. Quiero entablar conversaciones y entender cuáles son los casos extremos. ¿Hay algún caso que no estemos viendo? ¿Hay casos de uso en los que necesitemos colaborar con la comunidad de envíos para encontrar una solución que ayude a estos buenos remitentes a hacer llegar los emails a nuestros clientes correctamente? Porque esa es la experiencia que queremos preservar. Al fin y al cabo, queremos ser humanos y asegurarnos de no perturbarla innecesariamente. Pero, al mismo tiempo, queremos marcar un límite. Esto no tiene un final abierto. Es en plan: vale, tengamos esta conversación durante diez años más y puede que entonces pase algo o puede que no. ¿Verdad? Ahora queremos presionar un poco más a la industria.
00:14:13
Eric Trinidad: Sin duda se requiere mucho respeto mutuo por parte de todos los implicados, ¿verdad? Como en toda buena relación, va a requerir trabajo y una comunicación abierta. Pero es genial que no estéis simplemente pulsando el interruptor y haciendo «clack», como si todo fuera a detenerse de golpe. Sino intentando comprender por lo que pasan los remitentes y escuchando lo que dice la comunidad sobre algunos de estos problemas.
00:14:31
Marcel Becker: Y por supuesto, algunas de estas cosas son más fáciles de exigir e implementar, ¿no? Y más fáciles de entender por parte de los que realizan los envíos, ¿verdad? Como la autenticación, ya que Gmail ya ha empezado a aplicar algunas de estas cosas. Y estoy seguro de que tanto vosotros como otros remitentes ya lo habéis visto. ¿Verdad? Porque eso es binario. O lo autenticas o no lo haces. Algunas de las otras cosas son un poco más difíciles de aplicar sin causar daños colaterales. Puede ser el enlace para darse de baja o las tasas de spam y cosas por el estilo.
00:14:59
Jonathan Torres: Esa es una de las cosas que agradecemos por nuestra parte. Solo por destacar esa parte, ¿no? Ya sabes, que vengas aquí y hables con nosotros y que la gente tenga la oportunidad de escuchar esto, ya sabes, de parte de la comunidad de envíos, para todos los remitentes de ahí fuera que de verdad intentan hacer las cosas bien y que sepan que, bueno, en primer lugar, se informan de que va a haber cambios y cosas sucediendo. Creo que está muy bien seguir viendo en la comunidad del email cómo contamos con esta participación de todas las partes, y que podemos ayudar desde nuestra perspectiva; es decir, ser capaces de ayudar y, con suerte, prestar un servicio haciendo este podcast y asegurándonos de que, ya sabes, corra la voz y la gente sepa y entienda lo que pasa para que se pongan manos a la obra y empiecen a prepararse para estas cosas. Una de esas cosas para las que creo que deberíamos estar preparados y para las que todo el mundo suele estarlo. Solo es cuestión de asegurarse de que todos los remitentes tienen la oportunidad de escucharlo y de estar totalmente preparados. Por eso sé que estamos intentando poner nuestro granito de arena, sin duda. ¿Tienes alguna idea sobre en qué medida esto va a influir en cuanto a si eliminamos algunos envíos de una plataforma o cosas que sabemos que van a fallar? Porque sé que una de las cosas importantes que la gente ya debería saber y que deberían llevar haciendo es el tema del spoofing o suplantación; quiero decir, ya deberían haber dejado de hacerlo. Ya pedimos a la gente que dejara de hacerlo. Y sé que está el spoofing o suplantación por ignorancia donde simplemente no saben que no deberían hacerlo, y siguen suplantando a dominios como Gmail y Yahoo, enviando simplemente desde su dirección de email personal. Pero están realizando envíos de mensajes masivos a clientes que no deberían hacer en absoluto, porque proceden de una plataforma diferente. Pero luego también están los que, ya sabes, están compartiendo espacio y haciendo cosas parecidas en las que, bueno, están haciendo spoofing o suplantación sin querer, pero en el fondo lo hacen. ¿Tienes alguna idea de la magnitud del impacto que tendrá eso?
00:16:31
Marcel Becker: Ya sabes, aprovecharse o utilizar dominios de consumidores para el envío masivo de email en realidad no es un gran problema para nosotros, porque ya tenemos una política de rechazo de DMARC desde 2014. Sí que es un problema enorme para Gmail, y no quiero hablar demasiado por ellos. Me alegra de que por fin lo estén usando porque su plataforma es una de las principales emisoras de spam o emails no deseados que utilizan el dominio de los consumidores de Gmail. Pero quiero concentrarme un poco más en que la política entrante sea como la de los remitentes que aprovechan el DMARC en estos canales; y existe un motivo en concreto por el que, sí, en el caso del DMARC nos encantaría que todos protegieran a su marca de la suplantación, pero también para ayudar a los usuarios a asegurarse realmente de que si reciben un email de una marca en concreto, pueden tener una seguridad razonable de que procede de esa marca, y para eso está diseñado DMARC. Pero también te das cuenta de que esto es un poco más difícil de aplicar en la práctica, y ese es uno de los motivos por los que empezamos con la simple exigencia de autenticación; que SPF y DKIM dieran el primer paso, publicar una política de «none» y poder supervisar los informes, porque ese es el primer paso para entender tus propias mejores prácticas de envío y saber quién está enviando emails en tu nombre. Y también el primer paso para arreglar lo que pueda estar roto.
00:17:44
Jonathan Torres: Es un buen punto. Sé que esto se vuelve un poco más técnico, ya sabes, por intentar entender la política de DMARC y lo que significa la aplicación de la política, y luego los informes que devuelve. Pero sé que previsualizamos un poco este episodio en nuestro episodio anterior, y para previsualizar un poco más en el futuro, seguro que contaremos con expertos que vendrán a hablar un poco más sobre este tema. Y sabes, queremos asegurarnos de que esas cosas se escuchan porque hay algunas empresas fantásticas que hacen un gran trabajo explicando lo que significa eso y ayudando a la gente a implementarlo y a procesar estas cosas; porque es muy importante saber y entender lo que ocurre con tu email y quién lo envía en tu nombre. Yo creo que me gustaría saber si alguien en algún lugar del mundo estuviera intentando hacerse pasar por mí. Así que, sin duda, creo que es una de las cosas más importantes. Y en lo que se refiere a la parte de DMARC y SPF, sé que la mayoría de los remitentes ya lo tienen cubierto. La mayoría de los ESP (Proveedores de Servicios de Email) ya lo hacen, al menos. Exacto. ¿Están realizando sus envíos con eso ya implementado? Incluso muchos proveedores más pequeños están empezando a implementarlo y a asegurarse de que lo tienen publicado. Y después, la siguiente parte, ya sabes, la que habla de darse de baja. También quiero profundizar un poco en eso. Entender lo que significa y lo que se supervisa exactamente, porque sé que hay algunas cosas que podemos hacer y otras no, algunas que están automatizadas y otras que superan el punto de automatización y que llevan algo más de trabajo. Así que te agradecería que te explayaras un poco sobre este tema.
00:18:55
Marcel Becker: Sí, por supuesto. Y para aclarar bien lo que decían los requisitos porque es otra de las preguntas que nos hacen. ¿Qué significa darse de baja con un clic? Si ya tengo un enlace en el cuerpo de mi correo, ¿es esto darse de baja con un clic? O si introduzco los encabezados de la lista ahí, ¿qué pasa con los bots y todo eso? Así que cuando hablamos de obtener listas, damos la opción de darse de baja con un clic. Nos referimos, más concretamente, a poner los encabezados de baja de la lista en el encabezado de un email. Eso es lo que se especifica en el RFC 80.
00:19:28
Jonathan Torres: 58.
00:19:31
Marcel Becker: 8058. Muchas gracias. Necesito . Lo he repetido tantas veces en estos últimos días.
00:19:38
Jonathan Torres: Ahora se convierte en una serie de números.
00:19:41
Marcel Becker: Sí. Y lo que significa esto, en realidad, es si estás enviando un email a un proveedor de email o a una aplicación de email que entiende el RFC 8058. Que verás dentro de la interfaz de usuario de la aplicación de email, verás una pequeña opción para darse de baja antes que esto, ¿verdad? Pero esto es lo que está haciendo Microsoft, y lo que está haciendo Google. Eso es lo que nosotros estamos haciendo. Eso es lo que Apple está haciendo, ¿verdad? Probablemente todos lo hayáis visto en alguna parte y es de mucha ayuda plantarle un botón en la cara al usuario, si quieres; de este modo le decimos: mira, si realmente quieres deshacerte de esto, aquí tienes una forma fácil y muy cómoda de hacerlo sin tener que marcarlo como spam, porque esa sería en realidad la alternativa para un usuario. Y lo hemos visto infinidad de veces. Un usuario no se queda de brazos cruzados diciendo: «Oye, ya no quiero recibir este email». A ver dónde puedo encontrar este enlace para darse de baja en el cuerpo del correo. Dejadme hacer clic en esto y luego saltar todos los obstáculos y aros y hacer todo lo necesario en esa página web. No, nadie hace eso. Es demasiado difícil. Quiero deshacerme de este email. Solo le doy al botón de spam y por eso queremos hacerlo fácil. Pero, al mismo tiempo, tampoco queremos penalizar innecesariamente a los remitentes. Si se trata de un email legítimo y alguien se ha suscrito (con suerte) pero quiere deshacerse de él, no queremos que lo marque como spam, lo que a fin de cuentas puede perjudicar a la reputación del remitente. Exacto. Queremos que se den de baja y hemos visto que implementar esto para darse de baja en la interfaz de usuario, o incluso avisando a los destinatarios cuando marcan como spam. Tenemos una página donde decimos: «Oye, ¿prefieres darte de baja en su lugar, si el remitente cumple los requisitos?» Hemos visto cómo los modos de spam caían y se reducían entre un 30 % y un 40 %. Así que creo que es una situación donde todos ganan. Una mejor experiencia de usuario también fue mejor para los remitentes. Es por eso que tanto nosotros como Gmail lo hemos adoptado a partir de ahora. Al mismo tiempo, la otra parte de ese requisito es respetar las bajas al cabo de dos días; porque a pesar de que algunos remitentes tienen esta pequeña función en el encabezado, no lo respetan. ¿Verdad? Así que un usuario hace clic en esto. Confían en que lo estamos haciendo de la manera correcta, pero luego se acercan a nosotros y se quejan: «Oye, resulta que hice clic en darme de baja para esta marca en particular, pero no paro de recibir emails suyos». Exacto. No es una gran experiencia.
00:21:54
Eric Trinidad: No, qué va.
00:21:55
Marcel Becker: No. Estamos violando la confianza del usuario; las marcas están violando la confianza del usuario en este caso, ¿verdad? No está nada bien. Y es por eso que básicamente dijimos: a ver. Sí, desde la perspectiva de CAN-SPAM, puedes esperar diez días. ¿Acaso es razonable? Porque probablemente no es lo que esperaría un usuario. Exacto. Así que lo de darse de baja de inmediato. Sí, tal vez sea razonable. Así que, no sé, digamos que dos días probablemente es razonable, ¿verdad? Y eso también es algo que el usuario esperaría razonablemente.
00:22:23
Jonathan Torres: Ya que la tecnología ha mejorado. Hay tantos espacios en los que, tan pronto como pulsan ese botón, está todo automatizado. Se les borra inmediatamente de esa lista. Y creo que definitivamente, ya sabes, está justificado. Y sí, la CAN-SPAM no ha cambiado en bastante tiempo en lo que respecta a esa parte. Así que, es decir, definitivamente, estoy seguro, justificaba una revisión como mínimo, ya sabes, en dos días creo que es definitivamente razonable. Quiero decir, yo desde luego no le veo ningún problema a eso. Sin duda es algo bueno que tener.
00:22:47
Eric Trinidad: Has mencionado un buen punto respecto a las propias tasas de spam. Si están por encima del 0,3 %, es un poco más alto de lo que exigimos por nuestra parte. ¿Es esto sobre (sé que hemos hablado de esto en el pasado, pero por reiterar algunos de estos puntos para otros usuarios que no os han escuchado antes), es sobre un intervalo de tiempo concreto o cómo se ve desde tu perspectiva?
00:23:05
Marcel Becker: Déjame hablar del número primero. También recibes muchas preguntas como: «¿Por qué hay un 0,3 %?» y «Dios mío, Dios mío, ¿voy a poder cumplirlo?» Elegimos el 0,3 % porque hay otras empresas y programas ahí fuera. Ese ya es el requisito para ellos. Exacto. Así que creo que simplemente es alinearse con eso, y también internamente; podría ser un umbral en el que si tu tráfico sostiene una tasa de spam, ya sabes, superior al 0,3 %, probablemente ya estés en apuros de todos modos. Exacto. Porque por lo general, nosotros solemos mirar números mucho, mucho más pequeños. Pero es un número que resuena en la industria y por eso lo elegimos, y lo acabamos de hacer público. Y tampoco es algo nuevo, ¿verdad? Si la gente dice, o nos pregunta en plan: vale, es una nueva política, ¿por qué hacéis esto? No, no es nuevo. Nosotros siempre hemos prestado atención a las tasas de spam en general, ¿verdad? Si tu tasa de spam ya es tan alta, lo más probable es que estés viendo retrasos desde el otro lado. Exacto. Seguro que ya estás viendo rebotes o un filtrado de spam desde el lado de Gmail. Eso ya está ocurriendo. Lo único que hicimos fue poner un número para que puedas monitorizarlo un poco mejor. La otra pregunta, ¿qué plazo estáis analizando? A veces lo digo un poco en broma, pero sigue siendo verdad. Es más de un día, menos de un año. Si llegas a un pico por el motivo que sea, ¿vale? Y has cometido un error por parte del remitente, o alguien decide marcar todo tu email como spam y llegas, no sé, al 1 % de tasa de spam o lo que sea, no lo tendremos en cuenta en tu contra. Revisaremos una cantidad de tiempo razonable, ya sabes, semanas o meses para ver cuál es el volumen. Si rondas constantemente ese umbral, seguramente estás haciendo algo mal, y ya sabes que estás haciendo algo mal. ¿Verdad? Así que deberías empezar a hacer algo bien. Si por lo general tienes buenas tasas y de repente hay un dato atípico, no pasará nada.
00:24:57
Eric Trinidad: No te van a derribar. Genial, es bueno oírlo.
00:25:03
Jonathan Torres: Sé que cuando se trata de nosotros, y claro, conozco nuestra plataforma y tenemos ciertos umbrales de quejas por spam y tasas de quejas por las que llegamos a, ya sabes, desactivar completamente a alguien. Pero cuando se trata del consejo que le damos a la gente, es que estén muy por debajo de eso. Y una de las cosas que me gusta decirle a la gente en el pasado es, oye, si no ves quejas por spam, eso probablemente no sea algo bueno. En plan, siempre va a haber una cierta cantidad de gente que, ya sabes, esas personas que van a estar muy descontentas. Le van a dar a ese botón. Pero la única manera en que pueden pulsar ese botón es si el mensaje ya está llegando a la bandeja de entrada. Y la razón por la que me vino esto a la cabeza es porque sé que de ahí viene el cálculo, ¿verdad? O sea, no tenemos necesariamente visibilidad de todo lo que entra en la bandeja de entrada, pero podemos sacar conclusiones usando ese tipo de métodos. Pero sé que en lo que respecta a la queja por spam que estás monitorizando desde el lado de Yahoo! van a ser los mensajes que ya están en la bandeja de entrada porque es desde ahí desde donde la gente se quejará. Y luego lo comparas con cuántos le están dando clic a continuación al botón de spam.
00:25:55
Marcel Becker: Ya sabes, para aclarar esto: cuando hablamos de tasa de spam, es el número de emails que acaban en spam frente al número de emails entregados en la bandeja de entrada. Y sí, bien podría ser que la mayoría de los emails ya vayan a la carpeta de spam. Tu tasa de spam puede ser muy baja, pero en ese momento probablemente ya estés viendo retrasos por nuestra parte, ¿verdad? Puede que ya veas un bloqueo u otros problemas. Y para llegar ahí tienes que pasar por, ya sabes, un mundo de sufrimiento antes, ¿no? No es que esto ocurra de repente, hay señales en las que puedes fijarte. Damos señales que te dirán que probablemente estás haciendo algo mal. Además, dependiendo de la plataforma en la que estés, realmente compartimos los datos de llegada a la bandeja de entrada. Así, puedes ver qué emails van a la bandeja de entrada, qué emails van al spam y cuál es mi tasa de spam real. Exacto. No deducida. Así que, en algunos casos, sí que mostramos esos datos. De ahora en adelante, también buscaremos cómo mejorar los datos o la información en nuestra plataforma postmaster. Para que puedas monitorizarlo todo un poco mejor.
00:27:03
Eric Trinidad: Eso es increíble.
00:27:03
Jonathan Torres: ¿El portal del remitente?
00:27:04
Marcel Becker: Nosotros lo llamamos Sender Hub.
00:27:05
Jonathan Torres: Sender Hub. Casi acierto. Lo presintí.
00:27:09
Marcel Becker: El lado de postmaster, como lo quieras llamar. Cualquiera de estas URL también funciona. Postmaster.yahoo.com, postmaster.yahooinc.com, senders.yahooinc.com. Lo que sea, todo funciona.
00:27:20
Jonathan Torres: Genial, a medida que la información crece. Y sé que los remitentes siempre tienen curiosidad por ello. Ya sabes, cuanta más información puedas obtener de cualquier fuente, mejor. Por eso siempre sugerimos hacerlo, ya sabes, como un simple consejo gratuito que damos. En lo que respecta a los mensajes de error. Sé que ya nos damos cuenta de los fallos y que va a haber todo un conjunto nuevo de códigos de error a los que prestar atención y que van a ser informativos sobre qué pasa exactamente y por qué pueden retrasarse o bloquearse los mensajes.
00:27:45
Marcel Becker: Sí, así será. Así que para algunas de las cosas nuevas, cuando hablamos de aplicar el enlace para darse de baja, tendremos nuevos códigos de error que te indicarán específicamente que, por ejemplo, está sufriendo un rebote o lo están bloqueando o lo que sea porque falta el enlace para darse de baja. Exacto. O está sufriendo un rebote porque no estás autenticando bien el email; aunque seguramente esto ya lo estés viendo con Gmail. En otras áreas, como tus tasas de spam. Como he dicho, esto no es nada nuevo, simplemente lo hemos publicado. Pero esto ya lo hacemos a día de hoy. Así que si estás recibiendo un TSS04, creo que ese es el famoso código de error. Es muy probable que se deba a que estás cerca de una tasa de spam desfavorable. De forma parecida, algunos de los requisitos del DNS y del RFC. Ya estamos rechazando tu email si no cumple con algunos de los requisitos del RFC, y te decimos el porqué.
00:28:40
Jonathan Torres: Otro tema en el que sé que la gente se ha fijado mucho es el del umbral de los 500 mensajes por día.
00:28:49
Marcel Becker: 5000.
00:28:49
Jonathan Torres: Eso. Muchas gracias. Muchas gracias. Sé que ya te he oído decir esto y lo voy a soltar. Para asegurarme de que te había oído bien, porque a veces mis oídos no funcionan muy bien. En realidad esos 5000 mensajes al día son, ya sabes, como una cifra publicada o algo que podemos usar como guía. Pero si estás haciendo envíos masivos a un montón de destinatarios y mandando mensajes similares, eso va a ser un envío masivo, y en ese momento se te considerará un remitente masivo, ¿es correcto?
00:29:15
Marcel Becker: Correcto. Y había una razón por la que en realidad no puse un número ahí fuera. Gmail sí lo hizo. Y creo que podría estar arrepintiéndose. Pero creo que estábamos alineados con Gmail y nosotros. Así que no, no hay un número fijo. No son 5000 o 6000, 4000. ¿Verdad? Por muchas razones. Una de ellas es que no es como que si estás enviando 4999, entonces no tienes que cumplir ninguno de estos requisitos. ¿Verdad? No. Si estás enviando muchos de los mismos emails a mucha gente, eres un remitente masivo y punto, y tendrás que cumplir con estos requisitos. Sí, básicamente es eso. Y estamos hablando de miles, ¿verdad? La gente debería saber si son remitentes masivos. Es decir, si eres un pequeño comercio familiar y tal vez envías unos cientos de emails, o solo es para coordinar cosas, o incluso si se trata de listas de correo pequeñas, no, no eres un remitente masivo. Además, si —porque también nos hacen estas preguntas— eres una empresa y tienes gente que manda emails individuales desde el mismo dominio a un montón de personas. Exacto. Eso no es envío masivo de email, ¿verdad? Se trata de mensajes de persona a persona, solo que se envían muchos. No se trata de un envío masivo de email. Exacto. Se trata de enviar el mismo mensaje a mucha gente. Es como si hubieras imprimido un folleto y lo estuvieras repartiendo. Tanto si repartes 1000 o 10.000, sigues distribuyendo un folleto y sigue siendo algo de marketing.
00:30:40
Eric Trinidad: Por si a la gente se le pasaba por la cabeza engañar al sistema.
00:30:44
Jonathan Torres: No lo hagáis.
00:30:45
Eric Trinidad: Ni se os ocurra intentarlo.
00:30:46
Marcel Becker: Sí, porque de hecho eso es algo que ya ocurre, ¿no? El snowshoeing y todas estas cosas que ya ocurren, en las que la gente piensa: oye, se debería enviar el mismo mensaje desde unas 5000 direcciones IP diferentes. Nadie se dará cuenta. No, os encontraremos. Sigues siendo un remitente masivo.
00:31:03
Eric Trinidad: Sí. Sí.
00:31:04
Jonathan Torres: Es graciosa la forma en que esa lógica se extiende. Se creen que han sido más listos que el sistema. Pero la verdad es que no.
00:31:11
Eric Trinidad: Bueno, Marcel, sé que se nos acaba el tiempo. Quería agradecerte de nuevo que hayas venido y hablado con nosotros hoy. Si la gente quiere obtener más información, sé que tenemos un Sender Hub, pero ¿hay alguna otra documentación por ahí que deban revisar?
00:31:24
Marcel Becker: Sí, les diría que estén atentos a este espacio, a nuestro blog. Creo que es blog.postmaster.yahooinc.com. Si no, id a senders.yahooinc.com. Pronto actualizaremos la página de mejores prácticas con los requisitos reales, durante las próximas semanas. Como ya he dicho, queríamos esperar un poco más para ver las opiniones. En la publicación del blog fui impreciso a propósito, pero daremos más detalles ahí. De lo contrario, ya podéis ir al Sender Hub; ahí están todas las mejores prácticas; casi todos los requisitos que tenemos y que vamos a aplicar ya están documentados allí, y hay enlaces sobre cosas como qué significa DKIM. ¿Cómo funciona DMARC? ¿Qué es SPF? Exacto. ¿Y cómo funciona el RFC 8058? Todo eso ya está documentado. No tenéis que esperar a que actualicemos esto. Además, ya sabéis que en la página de Gmail pasa lo mismo. Ahí tienen una página muy, muy buena con enlaces a más información; podéis ir ahí mismo y leerla.
00:32:27
Jonathan Torres: Sí, no esperéis.
00:32:29
Eric Trinidad: Exacto. Actuad ahora.
00:32:33
Eric Trinidad: Bueno, en cuanto lo confirmemos, Thomas lo pondrá aquí en las notas del programa. Será capaz de distribuir esa información a nivel nacional. Thomas, si la gente quiere averiguar dónde se encuentra esta documentación, ¿adónde pueden acudir?
00:32:46
Thomas Knierien: Sí. Señoras y señores, también podéis poneros en contacto con nosotros y buscar el podcast en mailgun.com/resources/podcasts. Nos aseguraremos de incluir estos recursos y enlaces de los que ha estado hablando Marcel hoy en la descripción del programa. Para que podáis seguirnos y estar al día con todo esto que se viene en el futuro. Y dicho esto, a continuación tendremos a Chad White hablando sobre su nuevo libro y sobre la parte del email marketing de esta actualización y de cómo va a afectar a los expertos en email marketing y todo eso. Y a continuación, estarán con nosotros nuestros amigos de DMARCIAN para hablar del aspecto de DMARC de toda esta actualización. Así que quedaos por aquí y aseguraos de seguir escuchándonos.
00:33:19
Eric Trinidad: Qué bien. De nuevo, Marcel, muchas gracias por tu tiempo. Te lo agradecemos. Y con suerte nos veremos pronto por la Bahía.
00:33:24
Marcel Becker: Gracias. Tengo muchas ganas de que eso pase y de tener una conversación más filosófica.
00:33:29
Eric Trinidad: Sí.
00:33:30
Jonathan Torres: Me encanta.
00:33:32
Eric Trinidad: Gracias a todos.
