O RFC 9979 define $maskedemail como um marcador de que uma mensagem chegou por um endereço oculto associado a um contato específico; isso não significa que todos os servidores o enviarão nem que todo cliente precise exibi-lo. Para avaliar a compatibilidade, teste separadamente o suporte do servidor, a presença ou ausência do marcador e o comportamento da interface. Não use o marcador para criar ou desativar aliases, validar remetentes ou prometer anonimato. O texto do RFC 9979 é a referência para esse limite.
Este guia é para desenvolvedores de clientes de e-mail que precisam ler e apresentar o marcador em IMAP ou JMAP.
Também atende equipes de QA que preparam casos de teste para mensagens com e sem o marcador.
Pessoas que organizam a caixa de entrada com aliases encontrarão aqui o que o padrão permite concluir — e o que não permite.
Atualizado em 13 de novembro de 2026. Conferimos a definição no RFC 9979 e no registro oficial de palavras-chave; a compatibilidade de cada produto ainda precisa ser validada no respectivo ambiente.
Comece separando padrão, servidor e interface
A palavra-chave $maskedemail ajuda a identificar uma pista sobre o endereço usado para receber uma mensagem. O RFC a descreve como um indicador de que o e-mail foi recebido por meio de um endereço oculto destinado a um contato específico. Essa descrição não transforma a palavra-chave em um recurso universal de alias, de filtragem ou de proteção da identidade.
Para a implementação, separe três camadas:
- Padrão: define o significado atribuído ao marcador e o registra como uma palavra-chave de uso especial.
- Servidor: decide se reconhece essa situação e inclui o marcador na mensagem entregue. A definição não comprova, por si só, que determinado serviço o faça.
- Cliente: pode ler a palavra-chave e escolher como apresentá-la. O RFC não impõe uma interface única para todos os produtos.
Essa separação também evita uma confusão recorrente: encontrar $maskedemail é uma pista sobre o caminho de recebimento, não uma prova de que o remetente foi validado, de que a conta é anônima ou de que o alias pode ser desligado pelo cliente.
O que o marcador $maskedemail significa na prática? Ele informa que o servidor marcou a mensagem como recebida por um endereço oculto associado a um contato específico. Não identifica necessariamente o provedor do alias nem concede ao cliente controle sobre esse endereço.
Para desenvolvedores: defina o que o cliente fará
Comece verificando como o cliente acessa as palavras-chave de uma mensagem. Em IMAP, consulte o estado das palavras-chave e preserve as palavras-chave que o cliente não interpreta; o RFC 9051, que descreve flags e keywords no IMAP4rev2, oferece o contexto do protocolo. A presença de $maskedemail deve ser tratada como metadado recebido, não como comando para alterar uma conta.
Em JMAP, confirme que o código lê as keywords associadas à mensagem e não depende de uma apresentação idêntica à do IMAP. O RFC 8621, que define as propriedades de e-mail no JMAP, descreve o uso de keywords nesse modelo. O protocolo e a implementação do servidor determinam o que o cliente recebe; não presuma que um mesmo teste de interface cubra os dois caminhos.
Antes de incluir um rótulo, defina uma regra de produto explícita. Por exemplo: se a mensagem contém o marcador, apresentar uma indicação discreta de “recebido por endereço oculto”; se ele não aparece, não afirmar que o endereço original foi usado. Evite traduzir o estado técnico para afirmações mais fortes, como “este contato é seguro” ou “este endereço foi vazado”.
| Camada | O que verificar | O que não concluir |
|---|---|---|
| RFC 9979 | Significado e registro de $maskedemail |
Que todo serviço implementa o marcador |
| Servidor IMAP ou JMAP | Se inclui a keyword nas mensagens pertinentes | Que sua ausência invalida o endereço |
| Cliente de e-mail | Se lê e apresenta a keyword sem alterar seu sentido | Que mostrar o marcador cria ou desativa um alias |
Para quem mantém servidores: registre a origem do resultado
O servidor é a camada que pode definir o marcador ao entregar a mensagem, conforme a situação descrita no RFC. Por isso, teste a geração no serviço de entrega, não apenas a renderização no cliente. Se a mensagem de teste já chega sem a keyword, um cliente que não a mostra não permite distinguir entre ausência de suporte no servidor e falha na leitura da mensagem.
Mantenha um registro por ambiente. Inclua o nome ou a identificação interna do servidor, o protocolo usado, a configuração relevante e se a keyword apareceu na mensagem entregue. Não generalize o resultado de uma instalação para outras: uma implementação pode adicionar o marcador e outra pode não fazê-lo, sem que isso transforme o comportamento observado em regra para todos os serviços.
O registro de keywords para IMAP e JMAP da IANA ajuda a confirmar que $maskedemail está registrado. Para interpretar o registro com cautela, consulte também a documentação do RFC 5788 sobre registro de keywords no IMAP. Registro e suporte efetivo são verificações diferentes: o primeiro documenta a palavra-chave; o segundo precisa ser observado na implementação que está sob teste.
Faça a validação por protocolo e por cenário
A matriz abaixo transforma a distinção entre padrão, servidor e cliente em casos de aceite. Ela compara o que precisa ser verificado, não presume que IMAP e JMAP apresentem a mesma estrutura ou o mesmo resultado em cada produto.
| Caminho de leitura | Entrada a preparar | Resultado a observar |
|---|---|---|
| IMAP | Mensagem recebida com $maskedemail |
O cliente lê a keyword e, se a interface tiver esse recurso, apresenta uma indicação coerente |
| IMAP | Mensagem sem $maskedemail |
O cliente não inventa a indicação nem declara que o endereço falhou |
| JMAP | Mensagem cuja keyword inclui $maskedemail |
O cliente interpreta a propriedade de keywords sem confundi-la com outro campo |
| JMAP | Mensagem sem a keyword | A interface não atribui ao recebimento um alias que não foi indicado |
Para QA: cubra presença, ausência e endereço comum
Inclua mensagens que tenham o marcador, mensagens sem ele e mensagens recebidas por um endereço comum. Use dados de teste cuja rota de recebimento seja conhecida; caso contrário, a equipe não saberá se a ausência do marcador é um resultado esperado do servidor ou uma falha do cliente. Quando possível, guarde uma cópia da mensagem original e compare-a com o estado apresentado na interface.
Como testar a compatibilidade de um cliente IMAP ou JMAP com o marcador de alias? Execute os casos separadamente em cada protocolo e registre o servidor usado, o estado da keyword na mensagem e o resultado visual. Não deduza suporte a JMAP a partir de um teste IMAP, nem o contrário: a leitura, o modelo de dados e a resposta do serviço precisam ser verificados no caminho correspondente.
| Caso de teste | O que confirmar na mensagem original | O que confirmar na interface |
|---|---|---|
Com $maskedemail |
Se a keyword está realmente presente | A indicação corresponde à mensagem e não promete anonimato |
Sem $maskedemail |
Que a keyword não está presente | Não aparece uma indicação positiva sem evidência |
| Endereço comum | Qual endereço foi usado no cenário de teste | O cliente não o apresenta como alias oculto |
| Divergência entre mensagem e tela | Se o valor foi preservado durante a leitura | O estado exibido não contradiz a mensagem original |
Se o servidor não enviar $maskedemail, qual deve ser o comportamento do cliente? Trate a ausência como “não observado neste ambiente”, não como prova de que o endereço deixou de funcionar. Registre se o servidor declara suporte e repita o teste com uma mensagem controlada; sem essa informação, não atribua a causa à interface nem ao endereço.
Quando o marcador aparece na mensagem original, mas não na tela, investigue o parser, a conversão de dados e a apresentação da keyword. Se a mensagem não contém o marcador, comece pela configuração ou pelas capacidades do servidor. Esse diagnóstico reduz o risco de abrir um defeito no componente errado.
Revise textos e ações antes de publicar
Para equipes de produto e UX, a decisão principal é o que a interface pode afirmar sem exagerar a evidência. Uma indicação como “recebido por endereço oculto” permanece próxima do significado do marcador. Já frases como “contato verificado”, “remetente confiável” ou “seu endereço está protegido” atribuem propriedades que o marcador não estabelece.
Também separe a indicação de uma ação sobre o alias. Se o produto tiver uma função para desativar ou excluir um endereço, teste essa função como capacidade independente, com seus próprios controles e confirmação. $maskedemail não cria o alias, não revela necessariamente onde ele é gerenciado e não autoriza o cliente a desligá-lo.
| Elemento de produto | Aceite recomendado | Rejeite se |
|---|---|---|
| Texto de status | Descreve a pista de recebimento sem ampliar seu alcance | Afirma segurança, anonimato ou validação do remetente |
| Ausência do marcador | Informa apenas que a indicação não está disponível | Trata a ausência como endereço inválido |
| Controle de desativação | Tem fluxo próprio e confirma qual endereço será afetado | Usa a presença da keyword como autorização automática |
| Preferência de interface | Permite apresentar ou ocultar a indicação, se esse recurso existir | O texto sugere que todos os clientes precisam usar a mesma interface |
O cliente é obrigado a exibir $maskedemail? A definição da keyword não exige uma interface uniforme. A equipe pode decidir como apresentá-la, desde que não altere seu sentido nem apresente como fato uma informação que o servidor não forneceu.
Feche a homologação com um registro reproduzível
Antes de liberar uma versão, anote o resultado de forma que outra pessoa consiga repetir a validação. Um registro curto, mas específico, costuma ser mais útil do que marcar apenas “compatível”:
- Identifique o cliente e a versão testada.
- Informe se o caminho foi IMAP ou JMAP.
- Registre o servidor e o ambiente de teste.
- Guarde o estado da keyword na mensagem original.
- Descreva o que a interface mostrou para a mensagem com marcador, sem marcador e de endereço comum.
- Separe requisitos do padrão, comportamento observado do produto e recomendação da equipe.
- Repita a verificação quando houver mudança no cliente, no protocolo implementado pelo servidor ou na regra de apresentação.
Essa última distinção evita uma conclusão enganosa: uma versão pode ler corretamente a keyword em um ambiente e não receber a mesma informação em outro. O resultado do teste comprova o comportamento daquela combinação de cliente, protocolo e servidor; não comprova suporte universal.
Para quem organiza a caixa de entrada, a consequência prática é modesta, mas útil: um marcador pode ajudar a reconhecer mensagens recebidas por um alias, sem substituir a gestão do próprio endereço. Se a diferença entre alias, encaminhamento e endereço temporário ainda não estiver clara, consulte nosso guia sobre alias de e-mail e endereço temporário antes de definir uma regra de longo prazo. Para planejar o encerramento de um endereço, use também a lista de verificação para desativar um alias.
Se o objetivo for apenas criar uma conta pontual ou receber um código sem expor o e-mail principal, um endereço temporário pode ser mais simples do que configurar e manter um alias. O InboxCloak oferece acesso a uma caixa de entrada temporária sem cadastro para esse tipo de uso; isso não significa suporte ao $maskedemail nem substitui um endereço que precisa receber mensagens por longo prazo. Para uma inscrição passageira, você pode abrir o InboxCloak; para contas importantes, recuperação de acesso ou correspondência contínua, prefira um alias duradouro ou o endereço principal.
Volte a usar a ferramenta com apenas as pistas necessárias
Volte à caixa de entrada para conferir se há emails reais. Se ainda não recebeu nada, siga a lista de diagnóstico independente, item por item; não é preciso capturar a tela inteira novamente.