La función PHP mail() permite entregar un mensaje al sistema de correo configurado en el servidor. Sin embargo, que la función devuelva true solo significa que el mensaje fue aceptado para su procesamiento: no confirma que haya llegado al servidor destinatario ni a la bandeja de entrada.
Para aplicaciones modernas suele ser preferible utilizar una biblioteca mantenida y SMTP autenticado. Este método brinda mayor control sobre autenticación, cifrado, errores, formato y registro del envío.
Cómo funciona PHP mail()
La aplicación construye el mensaje y lo entrega al mecanismo configurado en PHP y en el sistema operativo. En un servidor Linux normalmente interviene un agente de transferencia de correo local. Ese servicio analiza el mensaje, intenta enviarlo al destino y genera un registro o rebote cuando corresponde.
Por este motivo existen varias etapas diferentes:
- El código PHP acepta o rechaza la llamada.
- El servidor local recibe y procesa el mensaje.
- El servidor remoto lo acepta, rechaza o aplaza.
- El proveedor destinatario decide si lo ubica en bandeja, spam o cuarentena.
Un valor verdadero en la primera etapa no garantiza el resultado de las siguientes.
Cuándo puede utilizarse mail()
Puede resultar suficiente para un mensaje ocasional generado por una aplicación correctamente programada y alojada en un servidor con correo local configurado. Aun así, el código debe crear cabeceras válidas, utilizar un remitente autorizado y registrar los errores.
No es la opción apropiada para campañas, boletines o grandes cantidades de mensajes en un bucle. Cada envío requiere procesamiento individual y puede activar límites del servidor. Para ese uso corresponde una plataforma de email marketing o un servicio transaccional preparado para volumen.
Por qué conviene SMTP autenticado
SMTP autenticado permite indicar explícitamente el servidor, el usuario, la contraseña, el puerto y el tipo de cifrado. Una biblioteca de correo también administra correctamente MIME, caracteres especiales, mensajes HTML, adjuntos y respuestas del servidor.
Los datos habituales son:
- Nombre del servidor SMTP proporcionado por el hosting.
- Dirección de correo completa como usuario, cuando corresponda.
- Contraseña de esa casilla o una credencial específica para la aplicación.
- Puerto 465 con TLS implícito o 587 con STARTTLS, según indique el proveedor.
- Autenticación SMTP habilitada.
No mezcles puerto y método de cifrado por prueba y error. Utilizá exactamente la combinación publicada por el proveedor y verificá el certificado del servidor.
Utilizar una biblioteca mantenida
En lugar de construir manualmente cabeceras complejas, usá el componente de correo incluido por el CMS o una biblioteca mantenida que admita SMTP. Esto reduce errores de formato y facilita conocer el motivo de un fallo de conexión o autenticación.
Actualizá la biblioteca junto con el resto de la aplicación. No copies archivos aislados de versiones antiguas ni desactives la validación TLS para ocultar un problema de certificado.
Remitente, destinatario y Reply-To
El campo From debería utilizar una dirección real y autorizada del dominio desde el cual se envía. Si un visitante completa un formulario, su dirección puede colocarse en Reply-To después de validarla, pero no debería reemplazar el remitente del propio dominio.
Esta separación mejora la coherencia del mensaje y evita falsificar dominios ajenos. También reduce rechazos por políticas SPF o DMARC. La dirección visible, el dominio autenticado y el servidor de envío deben formar una combinación legítima.
SPF, DKIM y DMARC
SMTP autenticado no reemplaza la autenticación DNS. SPF autoriza servidores, DKIM firma el mensaje y DMARC define una política basada en la alineación de los dominios. Revisá la guía para configurar SPF, DKIM y DMARC en cPanel.
Estos registros mejoran la identidad técnica, pero tampoco garantizan por sí solos la bandeja de entrada. La reputación, el contenido, el volumen, las quejas y la calidad de la lista también influyen.
Formato, codificación y contenido
Un mensaje debe tener cabeceras y estructura MIME válidas. Para asuntos o nombres con acentos, utilizá codificación adecuada. Si enviás HTML, agregá una alternativa en texto plano y evitá depender de imágenes remotas para comunicar información esencial.
- Definí UTF-8 de forma consistente.
- No agregues cabeceras copiando texto sin validar.
- Incluí un asunto claro y un cuerpo identificable.
- Evitá enlaces engañosos, acortadores innecesarios y adjuntos ejecutables.
- No solicites contraseñas ni datos sensibles por correo.
Cómo guardar las credenciales SMTP
No publiques la contraseña dentro de archivos descargables, repositorios ni código visible desde la web. Guardala en el mecanismo de configuración segura ofrecido por la aplicación, fuera del control de versiones y con permisos restringidos.
Utilizá una cuenta destinada a la aplicación cuando sea posible. Si sospechás que la clave fue expuesta, cambiala y revisá los registros de envíos inmediatamente.
Qué revisar si el mensaje no llega
- Confirmá que la aplicación informó un envío exitoso o registró un error.
- Verificá servidor, puerto, cifrado, usuario y contraseña.
- Comprobá que el remitente pertenezca al dominio autorizado.
- Revisá SPF, DKIM y DMARC.
- Buscá el intento en Track Delivery de cPanel.
- Leé el mensaje SMTP o el rebote completo, no solamente su título.
- Probá con otro destinatario para determinar si el problema afecta a un proveedor concreto.
Si el servidor interrumpe los envíos por demasiados destinatarios fallidos, consultá Max defers and failures per hour. No conviene aumentar el límite sin corregir primero direcciones inválidas, formularios abusados o aplicaciones comprometidas.
Errores frecuentes de configuración
- Usar como From la dirección escrita por el visitante.
- Confundir la contraseña de cPanel con la de la casilla.
- Seleccionar TLS para un puerto que espera otro método.
- Desactivar la validación del certificado.
- Enviar en un bucle sin cola, límites ni reintentos.
- Interpretar
truedemail()como confirmación de entrega. - Ocultar errores sin conservar un registro técnico.
Proteger el origen del mensaje
Si el correo nace en un formulario público, el envío debe estar acompañado por validación del servidor, límites de frecuencia y protección contra bots. Consultá cómo proteger un formulario contra spam y abuso y los riesgos de seguridad al construir mensajes con datos externos.
Lista de comprobación
- La aplicación usa una biblioteca actualizada.
- SMTP está autenticado y cifrado.
- El remitente es una cuenta autorizada del dominio.
- La dirección del visitante solo se usa como Reply-To validado.
- SPF, DKIM y DMARC están correctos.
- Los errores y rebotes se registran.
- El volumen respeta los límites y el propósito del servicio.
