Como Configurar DKIM, SPF e DMARC no Route 53

Como Configurar DKIM, SPF e DMARC no AWS Route 53

Acertar a autenticação de e-mail no AWS Route 53 é, em grande parte, um exercício de DNS, mas a ordem importa. Se você publicar o valor errado na zona hospedada errada, o e-mail ainda sai do seu app e ainda chega a algum lugar; só que chega com sinais de confiança fracos, e isso pode prejudicar a entrega.

Este guia segue um caminho prático para configurar dkim spf dmarc no aws route 53 sem transformar o processo em tentativa e erro. Se você busca como configurar spf no route 53 ou como configurar dkim e dmarc no aws route 53, vai confirmar a zona hospedada, coletar os registros do seu provedor de e-mail, publicar o registro SPF, adicionar os registros de configuração do DKIM, criar o DMARC e então testar com uma mensagem controlada.

1. Confirme sua zona DNS no AWS Route 53 e a configuração de envio de e-mail

Comece no Route 53 e identifique a zona hospedada exata do domínio que envia e-mails. Um erro comum é editar o domínio pai quando o remetente na verdade usa um subdomínio, como mail.example.com, o que faz com que seu registro nunca seja consultado quando a mensagem é enviada.

Verifique o caminho de envio antes de editar o DNS. Um app pode enviar a partir do domínio raiz, outro de um subdomínio de marketing, e um terceiro de um serviço transacional que só assina e-mails de notificação; são três configurações diferentes, não uma só.

Anote qual é o provedor ou app que envia os e-mails. AWS SES, uma plataforma SaaS ou seu próprio aplicativo fornecem valores de DNS diferentes, e esses valores nem sempre chegam no mesmo formato.

Se você tiver mais de uma zona hospedada com o mesmo nome de domínio, pare e verifique qual delas está delegada no registrador. Duas zonas com nomes idênticos podem tornar a tarde bem confusa.

A primeira passada mais segura é simples: um domínio, uma origem de envio, uma zona hospedada do Route 53 e uma pessoa conferindo os nomes exatos dos registros. Não é glamouroso. Evita erros.

2. Reúna os registros DNS que o seu provedor de e-mail fornece

Abra o painel do seu provedor e encontre a seção de autenticação. A maioria dos serviços agrupa isso em verificação de domínio, autenticação de e-mail ou identidade de envio, e os valores normalmente aparecem como registros TXT ou CNAME com um nome, um tipo e um token longo.

Separe os registros por finalidade. O registro SPF normalmente fica em uma entrada TXT para o domínio, enquanto a configuração de DKIM pode vir como um único registro TXT ou vários registros CNAME, dependendo do serviço de assinatura.

Observe bem os rótulos dos campos. Se o provedor disser “selector”, isso é uma pista de DKIM. Se mostrar um mecanismo include ou uma permissão de IP, isso está ligado ao registro SPF.

Copie os valores exatamente como foram fornecidos. Um hífen faltando, um sublinhado removido ou um valor colado com texto extra do painel podem fazer a validação falhar mesmo quando o registro “parece correto” no Route 53.

Alguns provedores mostram os valores em uma única página de configuração, enquanto outros dividem isso em várias etapas. A página pode dizer “copie isto para o DNS” e depois listar três nomes diferentes abaixo; isso é normal, e importa porque cada nome vai para um registro diferente no Route 53.

Se você quiser uma introdução mais ampla sobre autenticação de e-mail antes de editar o Route 53, o guia de configuração de autenticação de e-mail cobre os termos de um jeito que combina bem com este trabalho de DNS.

3. Adicione o registro SPF no Route 53

No Route 53, crie ou edite um registro TXT para o domínio que envia e-mails. O valor deve conter a sintaxe SPF do provedor, geralmente começando com v=spf1, e precisa estar no hostname exato que o provedor espera, muitas vezes o domínio raiz.

Não publique dois registros SPF para o mesmo hostname. O SPF é avaliado como uma política única, então dividir remetentes em vários registros TXT na raiz muitas vezes causa falhas de consulta ou resultados inconsistentes.

O Route 53 solicita nome do registro, valor e TTL. Para o domínio raiz, o nome pode ficar em branco ou ser informado como o nome da zona, dependendo da visualização do editor. Use as instruções do provedor, não a memória.

É aqui que muitas equipes tropeçam: colam a string SPF no campo errado ou a colocam entre aspas porque copiaram de uma captura de tela. O Route 53 lida bem com dados TXT, mas o conteúdo ainda precisa estar exato.

Uma configuração típica de SPF lista os serviços aprovados com mecanismos include e termina com uma interrupção rígida como -all. Essa parte final muda o grau de rigor com que os destinatários interpretam o registro, então mantenha a versão recomendada pelo provedor, a menos que você saiba por que está alterando.

Se o seu remetente usa mais de um sistema, como um app de produto e uma plataforma de newsletter, certifique-se de que o registro SPF contemple ambos antes de publicar. Um include faltando pode quebrar o envio de um serviço que só dispara uma vez por semana, o que torna o problema mais difícil de perceber.

Para leitores que também gerenciam feeds de publicação e atualizações, o blog muitas vezes ajuda a conectar mudanças de DNS com outras tarefas de infraestrutura que entram em produção em um cronograma.

4. Publique os registros de configuração do DKIM no Route 53

A configuração de DKIM serve para provar que a mensagem foi assinada pelo dono do domínio e não foi alterada depois do envio. No Route 53, isso normalmente significa adicionar um ou mais registros TXT ou CNAME usando os nomes de selector fornecidos pelo provedor de e-mail.

Selectors importam. Um selector é o rótulo que permite aos destinatários encontrar a chave correta, e ele costuma parecer s1, selector1 ou um token específico do provedor. Se o nome do selector estiver errado por um único caractere, a validação simplesmente não encontra o registro.

Alguns provedores fornecem registros TXT com a chave pública diretamente no campo de valor. Outros usam registros CNAME que apontam para a chave hospedada pelo provedor. Ambas as abordagens podem funcionar, mas você precisa seguir o formato que o provedor forneceu, não o que viu em outra plataforma.

Digite o nome do registro DKIM exatamente como mostrado, incluindo qualquer prefixo de subdomínio. O Route 53 é tolerante ao gerenciar DNS, mas não adivinha o que o provedor quis dizer quando o selector está malformado.

Valores longos de DKIM podem parecer estranhos no console. Isso é normal. Uma chave longa não é sinal de problema; é apenas uma chave longa.

Se o seu provedor gerar dois ou três selectors, publique cada um separadamente. Muitos sistemas rotacionam chaves ou mantêm um selector reserva ativo, e deixar um deles de fora pode fazer mensagens antigas ficarem sem assinatura enquanto as novas passam.

Para equipes que enviam notificações, recibos e redefinições de senha, a configuração do remetente muitas vezes se sobrepõe a outras tarefas de e-mail de saída. Uma referência rápida como o e-mail webhook para e-mail transacional pode ajudar a manter eventos do app e valores de DNS no mesmo plano.

5. Crie o registro DMARC em _dmarc no Route 53

Crie um registro TXT em _dmarc para o domínio de envio. O DMARC fica acima do SPF e do DKIM, então ele diz aos destinatários o que fazer quando a autenticação falha e para onde enviar relatórios sobre essa falha.

O nome do registro precisa ser _dmarc, não dmarc, não _DMARC e não o domínio raiz. Esse sublinhado faz parte do caminho de consulta, e a falta dele faz os destinatários procurarem no lugar errado.

Comece com uma política cautelosa. Muitas equipes começam com p=none para observar os dados dos relatórios antes de impor quarentena ou rejeição.

As tags do DMARC podem incluir endereços de relatório rua e ruf, configurações de alinhamento e controles de porcentagem. Algumas são opcionais, e o conjunto exato de que você precisa depende do seu provedor e do plano de relatórios.

Use um endereço que você realmente acompanha. Relatórios DMARC não são decorativos. Eles frequentemente chegam em XML, podem ser ruidosos e são mais importantes na primeira semana após a publicação.

Se você já monitora tendências de autenticação ou quer um contexto mais profundo de configuração de e-mail, as melhores práticas de entregabilidade de e-mail · YourTrend fazem uma boa ponte entre política e colocação na caixa de entrada.

6. Verifique detalhes de DNS específicos do Route 53 que podem quebrar a validação

TTL não é glamouroso, mas importa. Um TTL alto pode atrasar o tempo para ver mudanças, enquanto um TTL baixo pode facilitar a atualização de registros durante a configuração; escolha com o ritmo dos seus testes em mente, em vez de copiar um número às cegas.

Fique atento a problemas de aspas nos registros TXT. O Route 53 pode exibir a string em uma única linha longa ou dividi-la em blocos para facilitar a leitura, e essa diferença de exibição é normal desde que o valor real permaneça intacto.

Pontos finais também causam confusão. Algumas ferramentas de DNS esperam isso nos nomes de destino, enquanto outras os ocultam, e o Route 53 pode fazer um registro parecer diferente do formato mostrado pelo seu provedor.

Conflitos de registros são outro problema silencioso. Se outro serviço já criou um registro TXT no mesmo nome, adicionar outro com o mesmo nome pode combinar os valores de um jeito que você não planejou, o que é especialmente perigoso quando o registro SPF deveria ser uma política única.

Registros alias não são a ferramenta certa para SPF, DKIM ou DMARC. Esses registros de autenticação precisam do texto exato ou do destino canônico, não de um alias apontando para outro lugar.

Confira a zona hospedada mais uma vez antes de salvar. É nesse momento que um registro da raiz pode acabar acidentalmente em uma zona de subdomínio, e esse erro parece válido dentro do Route 53 até os validadores externos falharem.

7. Verifique a propagação e envie uma mensagem de teste controlada

Depois de publicar, teste a partir do mesmo domínio que você configurou. Envie uma mensagem controlada para uma caixa de e-mail que você consiga inspecionar e depois revise os cabeçalhos recebidos para ver os resultados de SPF, DKIM e DMARC.

Observe o alinhamento, não apenas aprovação/reprovação. Uma mensagem pode passar no SPF e ainda falhar no DMARC se os domínios não estiverem alinhados, e uma mensagem pode carregar uma assinatura DKIM válida, mas associada ao domínio errado.

Ferramentas de teste podem ajudar, mas a visualização dos cabeçalhos em uma caixa de correio real mostra o resultado como o destinatário vê.

Se o SPF passar e a configuração de DKIM passar, mas o DMARC ainda falhar, verifique o domínio From em relação ao domínio autenticado. Essa diferença é comum quando um serviço envia e-mails em nome de uma marca, mas assina com um subdomínio diferente.

Aguarde a propagação antes de julgar a configuração. Mudanças no Route 53 podem aparecer rapidamente, mas nem todo destinatário atualiza no mesmo ritmo, e valores em cache podem atrasar o que o mundo externo enxerga.

Não teste primeiro com uma campanha de alto volume. Uma única mensagem controlada de um remetente conhecido é suficiente para expor um selector ruim, um include inválido ou um registro _dmarc com nome incorreto.

8. Aperfeiçoe a configuração após a primeira passagem

Depois que os registros validarem, revise o que vai mudar no próximo mês. Se um novo serviço de e-mail for adicionado, o registro SPF precisa ser atualizado antes que esse remetente entre no ar, e se uma chave DKIM for rotacionada, o novo selector precisa ser publicado antes que o antigo seja desativado.

Avance a política de DMARC em pequenos passos. Uma equipe pode começar com monitoramento, depois passar para uma etapa de aplicação parcial e, por fim, impor rejeição, mas cada passo deve seguir dados reais dos relatórios, não otimismo.

Revise o mapa de remetentes sempre que seu app mudar. Novas notificações do produto, uma plataforma de marketing ou um help desk podem adicionar um remetente que precisa aparecer no DNS, e um único remetente esquecido já é suficiente para criar uma falha confusa.

Mantenha a zona do Route 53 organizada. Registros TXT antigos, selectors duplicados e tokens de verificação não usados devem ser removidos apenas depois de você ter certeza de que nenhum serviço ativo depende deles, porque um registro obsoleto ainda pode ser a única coisa mantendo um fluxo de backup funcionando.

Se sua equipe também acompanha mudanças por outros canais, lembre-se de que o DNS é apenas uma parte. Configuração de e-mail, eventos de webhook e fluxos de assinantes muitas vezes avançam juntos, e os registros no Route 53 devem mudar no mesmo ritmo do app que envia o e-mail.

Um último ponto prático: revise como configurar dkim spf dmarc no aws route 53 sempre que seu domínio de envio, provedor ou cronograma de rotação de chaves mudar, porque um DNS correto em janeiro pode estar errado em junho, e os provedores de e-mail não se importam com o motivo.