O SMTP e o ESMTP (os protocolos subjacentes) que lidam com a entrega de mensagens têm RFCs extensos (o RFC822 original e a atualização mais moderna RFC2822 e um protocolo de rastreamento de padrões da Internet no RFC5322).
Como os servidores de email lidam com erros durante a entrega varia de servidor de email para servidor de email. Além da complicação, muitos deles são configuráveis e fáceis de alterar o comportamento padrão descrito nos RFCs.
A regra geral, dadas as advertências acima, é:
Escolha o registro MX de maior preferência, ou um aleatório, se existirem vários registros da mesma preferência (algumas vezes, o comportamento aleatório é, em vez disso, um algoritmo round-robin). Se o host escolhido for "inacessível" (sem rota para hospedar, conexão recusada ou similar), tente o próximo registro MX de mesma preferência ou menor. Como msw mencionou, estes são alguns que contra-intuitivo - a maior preferência é 0 e os registros de um número maior são considerados menos preferenciais.
Isso é repetido até que uma conexão seja estabelecida OU todos os hosts não respondam. Nesse caso, o email é enfileirado novamente para uma tentativa posterior de reenvio. A maioria dos servidores de email tentará isso por um determinado período de tempo (geralmente algo como 1 a 2 dias), antes de desistir e retornar o email em uma notificação de falha na entrega (NDR).
Se a conexão for bem-sucedida, as várias etapas do protocolo RFC determinam o comportamento geral de conectar MTAs. Do banner inicial enviado pelo servidor de correio remoto a cada um dos vários comandos emitidos para ele (de EHLO / HELO , até MAIL FROM , RCPT TO e DATA declarações), a regra geral é é:
erro transiente de 4xx, tente novamente mais tarde
Com este código, o email é re-enfileirado pelo servidor de correio local e a entrega tentada mais tarde (configurado nas configurações desse servidor de correio local)
5xx erro fatal, e-mail não entregue
Com esse código, o email é considerado não entregue e o servidor de email de envio local gerará um NDR (Non-delivery Report).
Em termos de sua pergunta "Se esse servidor não tiver o endereço de email solicitado", no RCPT TO stage, a maioria dos servidores responderia com um código 5xx e seu servidor de email local geraria um NDR.
Nem todos os servidores de e-mail são criados iguais
Existem algumas ressalvas para isso. MS Exchange por mais tempo, aceitaria TODOS os emails, independentemente de destinatários incorretos, domínios não rotuáveis e assim por diante, e geraria uma notificação de falha na entrega após o fato. Determinados ISPs devido a problemas com spam e fenômeno conhecidos como Dispersão de volta , nem sequer gera notificações de falha na entrega e seu email "falha silenciosamente" (você nunca recebe nenhuma notificação de falha na entrega).
Você também deve levar em consideração que o MTA (Mail Transport Agent ou servidor de email) nem sempre é o ponto final de entrega e MDAs (agentes de entrega de mensagens - como procmail) e MUAs (Mail User Agents) ou "clientes de e-mail", como o thunderbird / outlook, etc., podem ser configurados para "retornar" esses e-mails com suas próprias respostas semelhantes a NDR. Existem também mecanismos como .forward files que podem fazer com que o MTA redirecione o email para outro endereço após a aceitação do email. Certos servidores de email (eu sei que este é o caso do Exim), tentarão expandir o .forward no ponto do estágio RCPT TO da conversa SMTP e se isso se expandir para uma resposta de endereço não rotuável com a série 5xx dos códigos de erro mencionados acima.
Para uma explicação muito mais precisa e aprofundada, leia as RFCs mencionadas acima e a documentação do MTA que você está usando (lembrando que o modo como ele está configurado pode desempenhar um papel em seu comportamento).