example.com no tiene registro MX, por lo que su servidor SMTP en el dominio de envío debe devolver el mensaje si está configurado como la mayoría de los servidores SMTP.
EDITAR: para mayor claridad para aquellos que encuentren esta respuesta en el futuro, aquí hay una explicación de lo que es un registro MX: (de http://en.wikipedia.org/wiki/Mx_record recuperado el 21 de noviembre de 2011)
Un registro de intercambiador de correo (registro MX) es un tipo de registro de recursos en el Sistema de nombres de dominio que especifica un servidor de correo responsable de aceptar mensajes de correo electrónico en nombre del dominio del destinatario y un valor de preferencia utilizado para priorizar la entrega de correo si hay varios servidores de correo disponibles. . El conjunto de registros MX de un nombre de dominio especifica cómo se debe enrutar el correo electrónico con el Protocolo simple de transferencia de correo.
Entonces, básicamente, example.com, example.net y example.org no tienen un servidor designado para manejar el correo entrante y, por lo tanto, cualquier correo que se les envíe debe ser devuelto al remitente como "no entregable" (puede variar según la configuración del servidor SMTP , pero volver al remitente como "no se puede entregar" es un comportamiento muy común para esta situación).
EDITAR 2: Alguien mencionó el comportamiento definido de RFC 5321 de recurrir al uso del registro A en el caso de que falte un registro MX. Busqué en este RFC ( http://tools.ietf.org/html/rfc5321 ) y no encontré tal cosa, pero es posible que algunos MTA (Mail Transfer Agent, como exim, postfix, sendmail y Microsoft Exchange Server, entre otros) pueden intentar enviar correo a través de SMTP a la dirección definida en el registro A. Para la posteridad, esto es lo que sucede cuando intenta establecer una conexión SMTP con la dirección de registro A definida para example.com (192.0.43.10 en el momento de la escritura):
$ telnet 192.0.43.10 25
Trying 192.0.43.10...
telnet: Unable to connect to remote host: Connection timed out
EDITAR 3: ver las respuestas a continuación para obtener aclaraciones sobre los RFC relevantes y el comportamiento alternativo.