En un registro B2B, admita direcciones genéricas salvo que el producto exija una dirección de correo individual para cada usuario. Una dirección como support@example.com puede ser el contacto que el cliente quiere usar. Si el inicio de sesión o la recuperación de la cuenta dependen del acceso a ese buzón, pida confirmación antes de habilitar esas funciones.
Si exige una dirección individual para iniciar sesión, explique el requisito. Ofrezca un campo separado para los contactos compartidos de facturación o del servicio. Una dirección puede ser técnicamente utilizable aunque no cumpla las reglas de su aplicación.
Qué indica el nombre de la dirección
Una dirección genérica lleva el nombre de una función, como soporte o ventas. La sección 3 de RFC 2142 describe nombres de buzones empresariales como INFO, SALES y SUPPORT. El nombre no demuestra que la organización haya creado ese buzón.
La organización puede dirigir los mensajes a una persona, a un buzón compartido o a un sistema de incidencias. La clasificación de la dirección no revela cuál de esos casos se aplica. El glosario de direcciones genéricas explica el concepto y los límites de la señal.
Emvero compara la parte anterior a @ con su lista de nombres de función. Si hay una coincidencia, establece checks.role_account en true y añade el código de motivo ROLE_ACCOUNT. Solo para esta comparación, ignora la diferencia entre mayúsculas y minúsculas y elimina la etiqueta añadida con el signo más: support+trial@example.com puede coincidir con el nombre base support. La dirección enviada no cambia. Conserve la dirección original para la confirmación y los mensajes posteriores. La guía sobre direcciones con el signo más explica por qué eliminar la etiqueta puede cambiar el destino.
Esta señal no indica cuántas personas leen el buzón. Su ausencia tampoco demuestra que lo lea una sola persona. Ninguno de esos resultados permite establecer la identidad de alguien, su consentimiento para recibir una campaña o un abuso de la prueba gratuita.
Elija la regla según la función del campo
Un campo de correo puede recoger una dirección para iniciar sesión, enviar facturas o contactar con soporte. Decida qué direcciones admite según el uso del campo. Las siguientes reglas son recomendaciones para su aplicación; Emvero no las aplica automáticamente.
| Uso de la dirección | Regla sugerida para una dirección genérica | Qué queda por comprobar |
|---|---|---|
| Contacto para facturas o avisos del servicio | Admitir la dirección que el cliente eligió para esa función. | Si el cliente eligió ese contacto y la dirección puede recibir mensajes. Confirmar el acceso al buzón cuando el proceso dependa de él. |
| Inicio de sesión en una cuenta donde se permite usar un buzón compartido | Permitir el registro. Pedir confirmación antes de habilitar el inicio de sesión o la recuperación de la cuenta por correo. | Si alguien puede recibir el mensaje y completar la confirmación. |
| Inicio de sesión en una cuenta destinada a una persona concreta | Pedir una dirección de correo del trabajo de uso individual y explicar el requisito. Guardar el contacto compartido por separado. | La identidad y la autorización mediante los controles previstos en la aplicación. El nombre de la dirección no las demuestra. |
| Prueba gratuita donde se quieren detectar registros repetidos | No rechazar solo porque la dirección tenga un nombre de función. | Historial de la cuenta y otras pruebas de abuso pertinentes. Una dirección genérica no demuestra abuso y otra dirección no demuestra que sea otra persona. |
Por ejemplo, un cliente puede querer alex@example.com para acceder a la cuenta y billing@example.com para las facturas. Guarde cada contacto junto con su finalidad. Una restricción del campo de acceso no debería eliminar el contacto de facturación del registro del cliente.
Aunque exija una dirección individual, mantenga los controles de identidad y autorización. Una dirección que parece contener el nombre de una persona no aporta una prueba de identidad más sólida que support@.
Lea ROLE_ACCOUNT junto con el resultado de verificación
Según las reglas actuales de Emvero, la señal de dirección genérica por sí sola no cambia status ni action. El siguiente ejemplo muestra un resultado final con esta señal. Se ha creado para ilustrar el caso y omite otros campos; no es la respuesta a una petición real:
{
"status": "deliverable",
"action": "allow",
"checks": {
"smtp": "accepted",
"role_account": true
},
"reason_codes": ["SMTP_RCPT_ACCEPTED", "ROLE_ACCOUNT"]
}
allow significa que la verificación no ha encontrado un motivo técnico para rechazar la dirección. La aplicación puede exigir además una confirmación o una dirección individual según sus reglas de acceso. Conserve el resultado recibido y registre la decisión de la aplicación por separado. No cambie deliverable por undeliverable para representar una restricción de su producto.
Otros hallazgos pueden cambiar el resultado general. La comprobación de un buzón con una dirección genérica también puede quedar sin resolver, y la dirección puede pertenecer a un dominio catch-all. Lea status, action, checks y reason_codes juntos, como explica la guía para interpretar un resultado de verificación. En particular, risky no implica una única acción fija.
Separe la confirmación de las reglas de admisión
Una confirmación completada indica que alguien accedió al mensaje y realizó el paso solicitado en ese momento. No demuestra acceso exclusivo al buzón ni identifica a un empleado concreto. Al verificar una dirección, Emvero no envía un mensaje de confirmación. Su aplicación debe enviarlo y comprobar que se ha completado la confirmación. La comparación entre verificación y confirmación explica qué permite establecer cada paso.
En el servidor, mantenga separados el resultado de verificación, la decisión sobre la admisión y el estado de confirmación. La confirmación debe corresponder exactamente a la dirección a la que se envió el mensaje. Si la persona cambia esa dirección, pida que confirme la nueva.
Si una verificación finalizada devuelve unknown, no se han obtenido pruebas suficientes para llegar a una conclusión sobre la dirección. Cuando necesite comprobar el acceso al buzón, permita continuar el registro, pero exija confirmación antes de habilitar el acceso a la cuenta por correo. allow_with_email_confirmation recomienda este proceso; la aplicación sigue siendo responsable de la confirmación. Un resultado inconcluso no significa que la dirección no sea válida.
pending indica que la comprobación no ha terminado. Vuelva a consultar el resultado tras el intervalo indicado en la respuesta de la API. Fije cuánto tiempo esperará la aplicación y qué hará si el resultado no está listo al vencer ese plazo. Un error HTTP indica un problema con la petición o el servicio. Ni un error ni pending permiten concluir que la dirección sea undeliverable. La guía de validación del formulario de registro cubre el proceso general en el servidor y las alternativas cuando no se puede esperar más.
Explique cómo resolver una restricción
Si para registrarse se necesita una dirección individual, explique el requisito en el formulario. Por ejemplo:
Para iniciar sesión en esta cuenta necesita una dirección de correo del trabajo de uso individual. Puede añadir una dirección compartida de facturación o soporte después del registro.
Use este texto solo si el producto ofrece ese campo de contacto separado. En caso contrario, describa el modo de corregir la dirección que sí ofrece. Conserve el valor introducido para que la persona pueda editarlo.
Evite un mensaje como «Esta dirección de correo no es válida» cuando la única causa sea la regla para direcciones genéricas. Un cliente que usa ese buzón a diario recibiría una explicación incorrecta. Compruebe las reglas de admisión en el servidor además de mostrar los avisos del navegador. Las credenciales de la API deben permanecer en el servidor.
Compruebe la política antes de activarla
Pruebe las decisiones de la aplicación con direcciones ficticias y resultados de verificación preparados de antemano. Los casos de la tabla suponen que la aplicación ya ha recibido el resultado indicado. No hace falta comprobar ningún buzón real para estos ejemplos.
| Caso | Comportamiento esperado de la aplicación |
|---|---|
Señal de dirección genérica con deliverable y allow; se permiten contactos compartidos |
Continuar el registro. Exigir confirmación del buzón si el acceso a la cuenta depende de él. |
| El mismo resultado, pero el inicio de sesión exige una dirección individual | Explicar la regla de admisión y pedir otra dirección para iniciar sesión. Conservar la original como contacto separado solo si el cliente lo elige. |
Señal de dirección genérica con unknown |
Conservar el resultado inconcluso. Exigir confirmación cuando se necesite comprobar el acceso al buzón. |
Comprobación sin terminar con pending |
Mantener la verificación como incompleta. Consultar de nuevo mientras no haya vencido el plazo de espera; después, aplicar la regla prevista para continuar. |
| Sin señal de dirección genérica | Aplicar las reglas normales de acceso y confirmación; no deducir identidad personal. |
Después de activar la regla, observe en qué punto las personas abandonan el registro o corrigen la dirección y si completan la confirmación. Compruebe también si los clientes pueden seguir usando sus contactos de facturación. Use esas observaciones para decidir si la restricción ayuda a cumplir el requisito de acceso que la justificaba.
Una vez definida la regla, compruebe las direcciones introducidas desde el servidor con la API de verificación de correo. Aplique las reglas de registro y confirme el acceso al buzón por separado.