Domínios
Verifique domínios de envio com DNS guiado, BYODKIM e configuração por domínio.
Todo email precisa sair de um domínio que seu time verificou — a API
rejeita qualquer outro endereço em from com 422. Domínios são adicionados
e verificados no painel.
Verificação
Adicionar um domínio o registra no SES e mostra os registros DNS a criar:
- DKIM — um único registro TXT
rittomail._domainkey. O Ritto Mail gera um par de chaves RSA-2048 por domínio e entrega a chave privada ao SES (BYODKIM), então a verificação é um registro TXT em vez de três CNAMEs. A chave privada nunca é armazenada. Domínios adicionados antes da mudança de nome para Ritto Mail mantêm o seletor com que foram verificados, como aparece no painel. - MAIL FROM — registros MX e SPF (TXT) para o subdomínio de bounce.
Dois sinais de verificação aparecem lado a lado:
- Status no SES — o que o SES reporta. O SES faz cache da verificação e pode atrasar depois que você muda registros.
- Checagem de DNS ao vivo — o Ritto Mail resolve cada registro por conta própria e reporta Encontrado / Faltando / Divergente imediatamente.
A API (GET /domains/{id}, POST /domains/{id}/verify e as ferramentas MCP
get_domain / verify_domain) reporta o mesmo quadro por registro em
records[]. O status usa o vocabulário do Resend: para DKIM e MAIL FROM ele
combina a checagem ao vivo com o SES — encontrado no DNS mas ainda não
confirmado pelo SES lê pending, um valor publicado diferente lê failed,
nenhum registro lê not_started. Só essas linhas condicionam o envio. A linha
DMARC segue a descoberta da RFC 7489: lê verified quando uma política cobre o
domínio, inclusive o registro do domínio pai para um subdomínio remetente —
nesse caso inherited_from nomeia o registro _dmarc que respondeu e policy
traz o seu p= — e not_started quando nenhuma cobre. Todo registro também
traz live (found, missing, mismatch ou unknown: o que o DNS público
responde agora) e, quando a linha não está verificada, um detail de uma linha
dizendo por quê.
Regiões
O Ritto Mail envia a partir de sa-east-1 (São Paulo) hoje. O formulário de
novo domínio do dashboard lista as regiões de envio disponíveis e usa a
primeira por padrão. O campo opcional region da API (inclusive na
ferramenta MCP create_domain) aceita qualquer região disponível — os
valores que o schema lista — e usa a primeira por padrão; qualquer outro
valor é recusado com 422 informando as regiões disponíveis.
Um domínio tem exatamente uma região. Para mudá-la, exclua o domínio e adicione de novo na outra região — os registros DNS mudam, já que as identidades de envio são por região. Um nome de domínio que outro time já tem está tomado em todas as regiões.
Configuração por domínio
Depois de verificado, a aba Configuração de um domínio controla:
- Rastreamento de cliques — desligado por padrão. Ligado, os links são
reescritos para redirecionar pelo seu próprio subdomínio de rastreamento para
registrar eventos
email.clicked, e então seguem para a URL original. Desligado, seus links saem intocados. - Rastreamento de aberturas — desligado por padrão. Ligado, um pixel 1×1
servido por esse mesmo subdomínio de rastreamento registra eventos
email.opened. O rastreamento é na camada do app e roda no seu próprio domínio — nunca a reescrita de links do SES. - Modo TLS —
opportunistic(padrão) ouenforced, aplicado via configuration set do SES do domínio.
Pela API e pelo MCP, update_domain recebe as mesmas configurações de
rastreamento, e create_domain as aceita como extras opcionais, para criar um
domínio já rastreado em uma chamada (uma chamada no formato do Resend, sem eles,
segue igual). O rastreamento é servido pelo subdomínio de rastreamento do próprio
domínio: informe tracking_subdomain (um rótulo como links) e o records[]
da resposta ganha um CNAME de rastreamento, cujo status passa a verified assim
que ele resolve. Ligar qualquer um dos dois sem um subdomínio é recusado
com 422. Enquanto o CNAME não resolve, os links não passam por ele — saem
limpos — e o
domínio aparece como Parcial no dashboard: verificado para enviar, com o
rastreamento ainda não ativo. No Cloudflare, o registro de rastreamento precisa
ficar como somente DNS (nuvem cinza): um CNAME com proxy responde com os
endereços do Cloudflare em vez do alvo, o que a tabela de registros mostra como
divergência, e o TLS do host de rastreamento é servido pelo Ritto Mail.
Precisão da taxa de abertura
O rastreamento de aberturas injeta um pixel 1×1 transparente com uma referência
única no corpo HTML; uma pessoa carregar essa imagem registra um evento
email.opened. É um sinal direcional, não uma contagem exata.
Buscas que uma máquina plausivelmente fez são registradas como
pré-carregadas, não como aberturas: o Apple Mail Privacy Protection baixa
toda imagem em segundo plano, a mensagem sendo lida ou não; o Gmail pré-carrega
enquanto a caixa de entrada já está aberta; e scanners de segurança buscam o
pixel segundos após a entrega. Um pré-carregamento aparece na linha do tempo do
e-mail e como uma linha própria sob a taxa de abertura, mas nunca muda o status,
nunca entra na taxa de abertura e nunca dispara email.opened (endpoints podem
optar por email.prefetched). A janela da regra de tempo é
de 10 segundos. Links passam pelas mesmas regras, mais
duas só deles: um Chrome de desktop que informa um número de build que nenhum
navegador envia desde a redução de user agent do Chrome, e dois links de
uma mensagem acessados em um quarto de segundo, são de uma máquina, seja lá como ela se
apresente. Um clique registrado antes de o resto da rajada chegar é desfeito —
linha, abertura inferida, contadores, status e qualquer entrega ainda não
enviada.
Um clique também é uma abertura. Ninguém clica num link de uma mensagem que
nunca renderizou, então um clique num e-mail ainda sem abertura registra também
a abertura, marcada logo antes do clique e com reason: "click". Para um
destinatário cujas imagens vêm do cache do Apple Mail essa é a única abertura
que pode ser registrada, então públicos com muitos usuários de Apple Mail
mostram uma taxa de abertura menor até clicarem.
As aberturas são contadas a menos quando o cliente do destinatário bloqueia imagens, quando o e-mail não tem parte HTML (um envio só-texto não carrega pixel), ou quando o Gmail corta uma mensagem acima de ~102 KB e o destinatário nunca a expande.
Os cliques são o sinal de engajamento mais confiável. Para e-mails puramente transacionais — recibos, redefinições de senha — considere deixar o rastreamento de aberturas desligado: o pixel adiciona um elemento com cara de rastreamento que alguns filtros pesam contra a entrega na caixa de entrada, por uma métrica em que você não pode confiar totalmente de todo modo.
Chaves de API e domínios
Uma chave de API pode ficar restrita a um único domínio; essa chave só envia
a partir daquele domínio (outros domínios retornam 403 restricted_api_key).