Uma aplicação de envio e uma caixa de entrada podem usar domínios diferentes. Os registros que direcionam respostas não precisam estar em cada subdomínio usado para envio.
Como um servidor de envio usa registros MX?
O servidor de envio consulta o domínio do destinatário para encontrar os servidores que aceitam seus e-mails recebidos.
Para person@example.org, ele consulta os registros MX de example.org. Cada registro indica um servidor de destino cujo hostname resolve para um endereço IP.
A RFC 5321 define esse processo de consulta para SMTP.
O servidor de envio reporta um erro quando o domínio do destinatário não existe. Após uma falha temporária de consulta, ele enfileira a mensagem para uma tentativa posterior.
O que acontece quando um domínio não tem registro MX?
Se não existem registros MX, SMTP trata o próprio domínio como destino e tenta seus registros de endereço.
Esse MX implícito tem preferência zero. Não há uma lista MX explícita para superá-lo, então a entrega segue para o endereço do próprio domínio quando utilizável.
Esse fallback se aplica a uma lista MX vazia. Ele não resgata um domínio cujos registros MX publicados são inutilizáveis.
Um null MX é uma instrução diferente: a RFC 7505 define um registro explícito declarando que o domínio não aceita e-mails. Um registro ausente permite fallback. Um null MX recusa a entrega.
O que significam os números de preferência MX?
Valores de preferência mais baixos identificam os destinos que o remetente deve tentar primeiro.
Com os valores 10, 20 e 30, o destino com 10 é o preferido. Os outros oferecem alternativas caso a entrega não possa prosseguir ali. Atribuir o mesmo valor a todos os destinos permite distribuição entre opções de preferência igual.
Segundo a RFC 5321, servidores de envio devem aleatorizar destinos com preferência igual, a menos que haja um motivo claro para favorecer um. Preferências iguais não garantem uma divisão exata do tráfego.
Aponte seu registro MX para um hostname cujo endereço você publica, para que remetentes possam se conectar. Use um registro A para o endereço IPv4 ou um registro AAAA para IPv6. Não use um alias CNAME como destino. O alias impede o DNS de incluir o endereço junto à resposta MX. Isso adiciona consultas extras, como a RFC 2181 explica.
Clientes SMTP devem suportar a tentativa de destinos alternativos. A especificação recomenda tentar pelo menos dois endereços quando disponíveis. Uma falha no primeiro não precisa encerrar as tentativas de entrega.
Você precisa de um registro MX para enviar?
SMTP não exige um registro MX explícito no seu domínio apenas para originar uma mensagem.
A consulta de entrega usa o domínio do destinatário. Seu domínio de envio ainda precisa de DNS válido e autenticação adequada aos requisitos do receptor. Um receptor pode aplicar suas próprias verificações ao domínio do remetente.
Um registro MX ausente, portanto, não significa que um domínio de remetente inacessível seja aceitável para todo receptor.
Para onde vão as falhas de entrega?
As falhas de entrega vão para o remetente do envelope, o endereço fornecido para avisos de falha durante a entrega SMTP.
Para onde vão as respostas?
As respostas normalmente usam o Reply-To quando presente, caso contrário o endereço From visível.
Um subdomínio de envio não precisa hospedar todas as caixas de e-mail da empresa. Por exemplo, news.example.com pode enviar enquanto as respostas vão para um endereço funcional em example.com. Torne essa escolha de roteamento explícita nos endereços da mensagem.
Para onde vão os relatórios operacionais?
Endereços operacionais como postmaster@ e abuse@ oferecem a outros operadores uma forma de reportar problemas de entrega ou abuso.
Segundo a RFC 5321, um servidor SMTP que retransmite ou entrega e-mails deve aceitar postmaster@ para seus domínios servidos. Isso fornece um contato para problemas do serviço de e-mail.
A RFC 2142 exige que organizações mantenham caixas de e-mail por função onde a função correspondente existir. Por exemplo, um provedor de serviços de Internet deve manter abuse@ em seu domínio organizacional. Isso direciona reclamações para a equipe responsável.
Como você recebe e-mails com Bird?
Você habilita o recebimento para um domínio e publica os registros MX que Bird retorna.
O campo inbound.enabled do API aceita true para habilitar o recebimento ou false para desabilitá-lo. Publicar os registros sozinhos não habilita a funcionalidade.
Após a verificação, e-mails endereçados a esse domínio se tornam mensagens de entrada. Use um subdomínio dedicado para recebimento, porque substituir os registros MX do domínio principal da empresa muda para onde os e-mails existentes chegam.
O registro de return-path do Bird trata avisos de falha de entrega separadamente desses registros MX de entrada. O guia de recebimento explica a configuração de domínio. O guia de bounce-domain explica o tratamento de falhas.
Em resumo
Registros MX direcionam e-mails recebidos.
O servidor de envio consulta o domínio do destinatário para encontrar um destino.
Registros MX ausentes podem recorrer a registros de endereço.
Quando não existem registros MX, o servidor de envio pode usar os registros de endereço do domínio.
Valores de preferência mais baixos são tentados primeiro.
Destinos com preferência igual são aleatorizados quando não há motivo para favorecer um.
Envio e recebimento exigem decisões separadas.
E-mails de saída ainda precisam de tratamento adequado para falhas de entrega, respostas e endereços de contato operacional.