Os 7 registros DNS que todo remetente auto-hospedado de email precisa

Email é incomum: um setup completo de remetente tem sete registros DNS distintos espalhados em três ou quatro tipos de registro. Falte um e o fio ainda move mensagens, mas provedores de mailbox vão te rebaixar silenciosamente para a pasta de spam. Publique todos os sete e você cruza o threshold "tudo o que o Google pede" do /guide/email-deliverability.

A ordem importa: SPF e DKIM devem pousar antes que DMARC comece a forçar alinhamento, senão mail legítimo é colocado em quarentena. A regra permanente entre vendors também é "esperar o DNS propagar" — deixe pelo menos 30 minutos entre publicar um registro e pedir ao provedor de mailbox que recheque.

Registros MX (RFC 1035 §3.3.9) dizem ao mundo onde entregar mail inbound para seu domínio. Mesmo se seu domínio de envio é "apenas outbound" (você não lê replies nele), um registro MX ainda é requerido — muitos provedores de mailbox rebaixam reputação para domínios sem MX, com a teoria de que remetentes legítimos aceitam replies. Um único registro apontando para qualquer servidor de mail acessível basta, mesmo se esse servidor só entrega para uma caixa postmaster.

SPF (RFC 7208) é um único registro TXT listando quais IPs são autorizados a enviar para o domínio. A regra dura: total de lookups DNS recursivos precisa ficar abaixo de 10 (RFC 7208 §4.6.4). Cada include: consome um; includes aninhados contam cumulativamente. Mecanismos ip4: / ip6: custam zero lookups, então colapse includes antigos em ranges de IP explícitos se sua contagem subir.

Termine com -all (hard-fail) uma vez que tenha verificado que todas as fontes de envio legítimas estão cobertas. Se ainda não tem certeza, comece com ~all (soft-fail) e aperte para -all depois de duas semanas de relatórios DMARC limpos.

DKIM (RFC 6376) publica a metade pública de um keypair de assinatura como um registro TXT em {selector}._domainkey.{domain}. O "selector" é um identificador que você escolhe — específico de vendor ou arbitrário. Para SES, a AWS te dá três CNAMEs que resolvem em registros TXT gerenciados pela AWS (para que a AWS possa rotacionar chaves sem você tocar no DNS):

Para Postal auto-hospedado ou Postfix+OpenDKIM, você gera o keypair localmente, configura o MTA para assinar e publica a metade pública como um TXT:

Qualquer caminho que você tome, verifique com dig TXT {selector}._domainkey.{domain} antes de declarar DKIM pronto.

DMARC (RFC 7489) vai em _dmarc.{domain}. Pular a rampa p=none é o erro mais comum — saltar direto para p=reject em um domínio cujos fluxos de mail você ainda não entende plenamente vai derrubar silenciosamente mail legítimo (forwarders, mailing lists, remetentes de CRM de terceiros).

Leia os relatórios agregados XML diários que caem na sua caixa rua entre stages. Ferramentas como o DMARC analyzer do Postmark ou Parsedmarc auto-hospedado visualizam; o XML cru é denso mas legível.

Por padrão, URLs do pixel de open e click-tracking do AcelleMail vêm do domínio primário do seu install. Provedores de mailbox gostam de ver root domains consistentes entre From, click dos links e URL de unsubscribe — todos no mesmo domínio registrado. Em termos de branding, links apontando para tracker.suaempresa.com são também mais trust-signaling do que links apontando para links.acellemail.com.

Uma vez que o CNAME resolva, o AcelleMail reescreve todas as URLs de click-tracking nas mensagens de saída para usá-lo. O domínio do link de unsubscribe segue a mesma regra (e o mesmo CNAME).

MTA-STS (RFC 8461) diz a outros remetentes "sempre exija TLS quando entregar para meu MX". Sem ele, um atacante no caminho pode rebaixar um handshake capaz de TLS para cleartext. Com ele, o servidor remetente recusa entregar se TLS não puder ser estabelecido. A implementação é um registro TXT apontando para um arquivo de policy hospedado:

Rode a policy em mode: testing pela primeira semana, depois vire para mode: enforce. Muitos bulk senders pulam MTA-STS — deployar é um sinal de confiança grátis.

BIMI (Brand Indicators for Message Identification) é o mais jovem dos sete e o único ainda não finalizado como RFC, mas é suportado por Gmail, Yahoo, Apple Mail, Fastmail e outros clients em produção. O deal: publique um registro TXT apontando para um logo SVG e (opcionalmente) um Verified Mark Certificate (VMC), e clients suportados exibem o logo ao lado das suas mensagens na lista da inbox.

Precondições: uma policy DMARC de no mínimo p=quarantine (BIMI não é honrado em p=none), e o SVG precisa ser SVG Tiny Portable / Secure (SVG-PS). Aceitação varia: Gmail exige um VMC pago ($1.500/ano via DigiCert / Entrust) para exibição completa na lista da inbox; Yahoo e Apple aceitam BIMI sem VMC. Aumentos de open rate de 5-20% são comumente reportados em case studies publicados.

Depois de publicar, mande uma mensagem de teste para você mesmo e cheque os headers. Gmail web: abra a mensagem, clique no menu de três pontos, "Mostrar original". Procure por:

Três vereditos pass é o bar. Qualquer coisa menos — fail, softfail, neutral — significa que um registro está errado, ou DNS ainda não propagou, ou o corpo do mail está sendo modificado em trânsito (raro). Cross-check com a spec canônica do header Authentication-Results (RFC 8601) se um veredito é ambíguo.