E-mail do destinatário na NF-e: campo dest/email

dest/email registra o endereço eletrônico indicado pelo destinatário para recepção da NF-e. É um contato opcional do grupo dest; sua presença no XML não comprova que a nota foi enviada por e-mail ou recebida, nem concede autorização de acesso ao documento.

O caminho é /nfeProc/NFe/infNFe/dest/email, no namespace http://www.portalfiscal.inf.br/nfe. A escrita da tag é email, com letras minúsculas. MOC 7.0, E19, p. 15.

Contato indicado pelo destinatário

O campo representa o contato de recepção que a pessoa destinatária informou. Ele pode vir do cadastro de cliente ou de uma indicação conferida para a operação. Não é o nome fiscal da pessoa, o endereço físico de entrega ou a inscrição estadual.

Uma empresa pode indicar um setor para receber documentos. Esse contato não altera o CNPJ de dest/CNPJ. Da mesma forma, um e-mail do funcionário que recebe a mercadoria não deve substituir automaticamente o contato indicado para documentação fiscal. A origem precisa ser verificável no cadastro ou na indicação recebida.

O leiaute comporta os modelos 55 e 65. Mesmo quando a identificação do destinatário é obrigatória, isso não torna o e-mail obrigatório: documento, nome, endereço e e-mail têm funções e condições próprias. Não complete um contato desconhecido com texto inventado, como se fosse uma exigência da autorização.

Limite de tamanho e validação do endereço

email admite zero ou uma ocorrência. Quando informado, seu conteúdo tem de 1 a 60 caracteres. Se não há um endereço a registrar, a ausência da tag difere de enviá-la vazia.

O XSD usa uma restrição textual baseada em TString, com tamanho e regras gerais de caracteres. Essa estrutura não valida, por si só, a sintaxe completa de um endereço eletrônico, a existência da caixa ou a possibilidade de entrega. A referência estrutural anterior do pacote 010c demonstra essa distinção; uma integração deve sempre validar com o pacote correspondente à versão aceita no ambiente.

Para a conferência prática, veja se o contato inteiro foi preservado, se há espaços indevidos nas extremidades e se o valor não ultrapassa o tamanho. Não corte um endereço maior que 60 caracteres para fazê-lo caber: o corte pode transformar a caixa e o domínio. Confirme outro contato válido com o destinatário ou trate a incompatibilidade na origem, conforme o fluxo de cadastro e envio.

Também não presuma que várias caixas separadas por ponto e vírgula formem um único endereço de recepção válido só porque cabem no limite. A tag é uma ocorrência de contato; uma lista de destinatários do serviço de e-mail precisa ser tratada pelo contrato desse serviço.

Posição no XML e contatos diferentes

O e-mail é filho direto de dest, depois de indIEDest e dos campos cadastrais opcionais que estiverem presentes. Ele não fica dentro de enderDest. O endereço do destinatário possui fone, mas não uma tag email nessa estrutura.

Este é um fragmento parcial e sintético, com contato demonstrativo. Ele omite endereço e o restante da nota, portanto não está pronto para transmissão e não comprova atendimento às exigências de uma NF-e modelo 55:

<dest xmlns="http://www.portalfiscal.inf.br/nfe">
  <CPF>12345678909</CPF>
  <xNome>Destinatário de Exemplo</xNome>
  <indIEDest>9</indIEDest>
  <email>documentos@example.com</email>
</dest>

O CPF e o indicador são hipóteses demonstrativas, não dados a copiar. O ponto do exemplo é que email é irmão de indIEDest e de enderDest, quando esse endereço existir.

Não confunda dest/email com entrega/email, retirada/email ou infRespTec/email: os últimos pertencem, respectivamente, ao local de entrega, ao de retirada e ao responsável técnico. O grupo autXML identifica pessoas autorizadas por CPF/CNPJ; ele não é preenchido por endereço de e-mail. Uma caixa de terceiro no contato de recepção não substitui esse controle de autorização.

Diagnóstico: campo ausente ou e-mail não recebido

Quando o problema é o contato não aparecer no XML, compare a indicação do destinatário, o cadastro usado na nota e o XML efetivamente gerado. Confira se a integração leu o campo certo, se o contato foi inserido em dest e se não foi perdido ao trocar de cadastro. Um contato salvo depois da emissão não muda o XML já autorizado.

Quando há erro de estrutura, leia a mensagem completa do validador e o caminho apontado. Tag vazia, tamanho excedido, posição incorreta e texto incompatível são causas técnicas diferentes. Corrija a origem ou a serialização comprovadamente errada e confira a nova geração no fluxo apropriado; não edite XML assinado.

Quando a nota não chega à caixa, comece separando três evidências: contato que consta no XML, endereço usado pelo serviço de envio e resultado desse serviço. Se existe registro de envio, examine retorno de falha ou rejeição da mensagem e confirme com o destinatário a caixa correta e o recebimento. O XML sozinho não permite afirmar que a mensagem saiu, chegou ou foi lida. A autorização da nota também não é uma confirmação de entrega de e-mail.

Essa separação evita mudar dados fiscais para resolver um problema de comunicação. Atualizar um contato para documentos futuros e investigar um envio anterior são tarefas distintas; nenhuma delas justifica substituir a identidade do destinatário ou retransmitir uma nota para testar uma caixa de e-mail.

Campos relacionados

dest no contexto do destinatário, enderDest no contexto do destinatário, fone no contexto do destinatário.