email da retirada na NF-e: contato do expedidor e limites da tag

retirada/email informa o endereço de e-mail do expedidor no local de retirada. O campo é opcional, com uma ocorrência no máximo e conteúdo de 1 a 60 caracteres quando informado. Ele não significa que o destinatário da nota foi alterado, que uma mensagem foi enviada ou que esse contato recebeu autorização de acesso ao XML. MOC 7.0, F14, p. 16.

Qual contato pertence à retirada

O e-mail deve vir do contato confirmado do expedidor/local de saída física. Um cadastro pode ter contatos de cliente, transportadora, equipe de expedição e responsável técnico; cada um pode cumprir uma função diferente. Copiar o e-mail do comprador para a retirada por falta de um contato próprio pode identificar o participante errado.

Um cenário ilustrativo é o local de saída ter uma caixa de contato de expedição e o cliente ter outra caixa para receber sua nota. retirada/email descreve o primeiro contexto; dest/email, o segundo. Se ambos correspondem à mesma caixa no caso real, isso deve ser consequência do cadastro confirmado, e não de uma regra que os considera sinônimos.

Esse campo é informação complementar dentro de retirada, grupo destinado ao endereço diferente do remetente. Não crie uma retirada artificial apenas para gravar um e-mail. Na NFC-e e na NF-e com DANFE Simplificado Tipo 2 (tpImp=6), F01-10/669 da NT 2026.002 v1.10a, p. 11 restringe a presença do grupo inteiro. O cronograma da linha que inclui essa regra prevê teste 01/07/2026 e produção 03/08/2026; o diagnóstico real precisa conferir modelo, ambiente e autorizador.

Comprimento permitido não comprova e-mail utilizável

O TLocal/email do pacote anterior 010c v1.30 usa TString, com mínimo 1 e máximo 60 caracteres. Não é adequado herdar o mínimo 6 do e-mail de infRespTec ou uma validação de outro formulário: são campos em contextos diferentes.

Um caractere isolado pode satisfazer o mínimo lexical dessa tag e continuar sem representar um e-mail utilizável. O schema não prova que a caixa exista, pertença ao expedidor, receba mensagens ou tenha consentido em alguma comunicação. Confirme o dado na origem, inclusive eventuais espaços copiados junto do endereço. O tipo preserva espaços e tem regras de texto próprias; uma string com espaços no começo ou no fim pode falhar na estrutura anterior.

Se não há contato informado, a tag opcional é omitida na geração. Isso é diferente de emitir <email/>, que não satisfaz mínimo 1, ou de inserir um endereço de exemplo para completar cadastro. Não trunque silenciosamente um e-mail com mais de 60 caracteres: perder parte do domínio pode direcionar a mensagem para uma caixa diferente ou inutilizar o contato.

Não use a tag como lista de destinatários separados por ponto e vírgula. A ocorrência é de um campo de endereço de e-mail, não de uma relação de contatos. Se um sistema precisa encaminhar mensagens para várias pessoas, esse fluxo precisa de contrato e configuração próprios; a tag isolada não demonstra esse comportamento.

Exemplo de leitura e XPath

Fragmento sintético e parcial, usado apenas para localizar o contato. O domínio reservado example.invalid deixa claro que não há uma caixa real nem intenção de envio. Os elementos obrigatórios de retirada foram omitidos; não é XML para transmissão:

<retirada xmlns="http://www.portalfiscal.inf.br/nfe">
  <!-- Identificação e endereço foram omitidos. -->
  <email>expedicao@example.invalid</email>
</retirada>

No arquivo processado, o XPath é /nfeProc/NFe/infNFe/retirada/email. O campo vem depois de fone e antes de IE quando esses opcionais estiverem presentes. Use o namespace da NF-e na consulta. Procurar qualquer tag email no arquivo pode recuperar contato do destinatário, do local de entrega ou do responsável técnico.

O exemplo demonstra uma string no intervalo permitido e um contato com papel de expedição. A identificação sintética não comprova existência de caixa, cadastro fiscal, autorização ou funcionalidade de envio de um produto.

Informar e-mail não é enviar a NF-e ou autorizar download

Uma tag no XML registra um dado. Para existir envio de mensagem, o sistema precisa executar um serviço de comunicação com destinatário, conteúdo, status e histórico próprios. A presença de retirada/email não prova que esse fluxo foi executado; não se pode diagnosticar “não recebeu a nota” apenas olhando essa tag.

Também não se confunde com autXML, grupo destinado à autorização de acesso ao XML. Endereço de e-mail não substitui a identificação prevista nessa autorização. O expedidor nomeado em retirada não passa a ser o destinatário fiscal em dest por causa de um contato igual.

Se a dúvida é sobre recebimento de mensagem, compare o contato registrado no XML com o destinatário do histórico de envio do sistema usado. Confirme se há tentativa registrada, qual caixa recebeu o envio e qual foi o resultado. Isso é investigação de comunicação, diferente de falha de schema ou autorização fiscal.

Como encontrar a causa de contato errado ou falha de estrutura

Compare o contato do local selecionado com a prévia XML. Se a origem está correta, mas a tag traz o e-mail do cliente, investigue o mapeamento de participantes. Se a origem contém espaço, lista de caixas ou texto truncado, confirme o contato com o expedidor e trate o dado na origem, preservando informação verdadeira.

Para falha estrutural, confira comprimento, conteúdo vazio, espaços, sequência e namespace. Não atribua um código de rejeição específico de e-mail sem que o retorno e a regra correspondam a esse XPath. Se a rejeição é 669, examine a presença do grupo e o modelo, não a caixa de e-mail.

Confira nova prévia depois de corrigir a causa comprovada. Não edite XML assinado, não envie mensagens de teste para caixas de terceiros e não retransmita a nota por tentativa. Nome do expedidor e telefone da retirada ajudam a comparar os outros dados de contato sem decidir quem é responsável tributário pela operação.