Configure SPF, DKIM e DMARC no AWS Route 53

O AWS Route 53 é um lugar rápido e confiável para publicar os três registros DNS que autenticam o seu e-mail — SPF, DKIM e DMARC —, mas o seu console tem algumas convenções que costumam confundir as pessoas: nomes de registro totalmente qualificados e o uso obrigatório de aspas duplas em cada valor TXT. Os registros em si são idênticos aos que você publicaria em qualquer provedor de DNS; só o editor muda. Este guia mostra exatamente onde, no console do Route 53, você adiciona cada registro, o que digitar no campo de nome de registro para o domínio raiz versus _dmarc versus o seu seletor DKIM, e a única peculiaridade das aspas que quebra silenciosamente chaves DKIM longas se você não prestar atenção.

A resposta curta#

Os três registros são registros TXT comuns dentro da sua zona hospedada do Route 53. O que difere de um provedor para outro é apenas a convenção de nomenclatura e o formato de entrada:

• SPF — um registro TXT na raiz do seu domínio. No Route 53 você deixa o campo de nome de registro em branco, e o registro se aplica ao ápice da zona.
• DKIM — um registro TXT em <selector>._domainkey.yourdomain.com. Você digita apenas a parte <selector>._domainkey no campo de nome de registro; o seletor e o valor longo da chave vêm ambos do seu provedor de e-mail.
• DMARC — um registro TXT em _dmarc.yourdomain.com. Você digita _dmarc no campo de nome de registro e o Route 53 acrescenta a zona para você.

Os valores são específicos de cada provedor, então não os escreva à mão. Gere sua linha SPF com o gerador de registro SPF, sua linha de política com o gerador de registro DMARC, e copie sua chave DKIM diretamente do painel da sua plataforma de e-mail. Para os conceitos por trás de cada registro, o guia explicativo de SPF, DKIM e DMARC cobre o que eles fazem e por que importam.

Como SPF, DKIM e DMARC se mapeiam para registros do Route 53#

O Route 53 organiza o DNS em torno de uma zona hospedada — uma zona por domínio. Dentro de uma zona, cada registro tem um nome totalmente qualificado em relação ao ápice da zona, e o console deixa isso explícito: ao lado da caixa "Record name" ele exibe o sufixo do seu domínio, e o que quer que você digite é prefixado a ele. Esse único detalhe explica os três locais de registro.

Onde adicionar registros no console do Route 53#

O caminho é o mesmo para os três registros. Abra o console do Route 53, escolha Hosted zones na navegação à esquerda e clique na zona do domínio a partir do qual você envia e-mails. Clique em Create record e, se o console oferecer uma alternância entre "Quick create" e "Wizard", o Quick create é o caminho mais simples para uma única entrada TXT.

No formulário de criação de registro você define três coisas: o Record name (o prefixo, conforme a tabela acima), o Record type (TXT para os três) e o Value. Deixe a política de roteamento no padrão "Simple routing" — estes são registros puramente informativos, não roteamento de tráfego. O TTL pode permanecer no padrão (300 ou 3600 segundos está ótimo); um TTL mais curto apenas significa que as alterações se propagam mais rápido enquanto você testa.

Publicando seu registro SPF no domínio raiz#

O SPF autoriza quais servidores podem enviar e-mail usando o seu domínio. Crie um registro TXT, deixe o nome do registro em branco para que ele fique no domínio raiz, e cole seu valor SPF. Um valor típico se parece com isto:

"v=spf1 include:amazonses.com include:_spf.google.com ~all"

Repare nas aspas duplas que envolvem o valor — o Route 53 espera que valores TXT estejam entre aspas, e o console normalmente as adiciona se você esquecer, mas é mais limpo incluí-las você mesmo. O ~all no final é um soft-fail; -all é um hard-fail que diz aos receptores para rejeitarem de imediato remetentes não autorizados.

Duas regras importam mais do que qualquer outra coisa aqui. Primeiro, publique exatamente um registro SPF. Se um segundo registro TXT na raiz também começar com v=spf1, o SPF fica inválido e toda verificação falha — então, se você já envia por outro serviço, mescle todos os mecanismos include: em uma única linha em vez de adicionar um novo registro. Segundo, mantenha-o dentro de dez consultas DNS; cada include: conta, e ultrapassar esse limite causa um erro permanente de SPF. O gerador de registro SPF monta uma única linha válida a partir dos provedores que você realmente usa e sinaliza o limite de consultas para você.

Adicionando seu registro DKIM no seletor#

O DKIM publica a metade pública de uma chave de assinatura para que os receptores possam verificar que suas mensagens não foram forjadas ou alteradas. Seu provedor de e-mail fornece duas coisas: um seletor (um rótulo curto como s1, google ou uma string aleatória) e o longo valor da chave pública. Você publica essa chave como um registro TXT em <selector>._domainkey.

Crie um registro TXT, digite o seletor mais ._domainkey no campo de nome de registro — por exemplo s1._domainkey — e cole o valor que seu provedor forneceu. O valor se parece com isto:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Não invente nem edite esse valor — copie-o exatamente como está das configurações de autenticação da sua plataforma de e-mail, porque a chave pública precisa corresponder com precisão à chave privada que faz a assinatura. Alguns provedores (o Amazon SES entre eles) emitem três registros DKIM baseados em CNAME em vez de um único registro TXT; nesse caso, crie três registros CNAME com os nomes e destinos que eles fornecerem, seguindo a mesma regra do "digite o prefixo, o Route 53 acrescenta a zona". Qualquer que seja a forma usada pelo seu provedor, os valores vêm dele, nunca de você.

Publicando seu registro DMARC em _dmarc#

O DMARC vincula SPF e DKIM ao endereço "From" visível, diz aos receptores o que fazer com mensagens que falham e envia relatórios para você. Crie um registro TXT, digite _dmarc no campo de nome de registro e cole uma política inicial:

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Comece em p=none. Esse é o modo de monitoramento — ele não muda nada em como seu e-mail é tratado, mas ativa os relatórios agregados diários que tornam possível uma implantação segura. Só depois que os relatórios confirmarem que todo fluxo legítimo autentica em alinhamento você deve apertar para p=quarantine e então p=reject. Publicar p=reject logo no primeiro dia é o jeito mais rápido de mandar seu próprio e-mail para o spam. O gerador de registro DMARC monta uma política sintaticamente correta, e o guia completo passo a passo de implantação do DMARC cobre em detalhes a sequência monitorar-para-depois-aplicar; assim que os relatórios começarem a chegar, o texto sobre como ler relatórios agregados de DMARC explica como agir sobre eles.

A peculiaridade das aspas que quebra chaves DKIM longas#

Este é o detalhe específico do Route 53 no qual vale a pena ir devagar, porque ele falha silenciosamente. Uma única string TXT de DNS é limitada a 255 caracteres. Valores curtos — sua linha SPF, sua política DMARC — cabem confortavelmente dentro de uma única string entre aspas. Mas uma chave pública DKIM de 2048 bits tem mais de 255 caracteres, então ela não pode ficar em uma única string.

A resposta do Route 53 é dividir o valor em várias strings entre aspas, cada uma com 255 caracteres ou menos, colocadas juntas no mesmo valor de registro. Os resolvedores de DNS concatenam as strings de volta em uma única chave. Na caixa Value do console, isso se parece com duas strings adjacentes entre aspas:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"

A pegadinha: as duas strings se concatenam em uma única chave contínua sem espaço entre elas, então não adicione caracteres no ponto de divisão e mantenha ambas as strings em um único valor de registro TXT, em vez de deixá-las virarem dois registros separados. Se a sua verificação de DKIM falhar logo após a configuração e a chave parecer completa, uma divisão incorreta é o culpado habitual. Cole a chave inteira, deixe o console ou sua ferramenta cuidar do fatiamento onde puderem, e verifique o resultado em vez de confiar nele.

Gerenciando os registros como código#

O Route 53 é o preferido de equipes que rodam infraestrutura como código, e você não precisa usar o console de forma alguma. A AWS CLI publica registros com aws route53 change-resource-record-sets, passando um change batch em JSON que especifica o nome, o tipo TXT, o TTL e o valor. No Terraform, cada registro é um recurso aws_route53_record:

resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "_dmarc.example.com"
  type    = "TXT"
  ttl     = 3600
  records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}

As mesmas regras se aplicam: um registro SPF no ápice, o valor DKIM direto do seu provedor, DMARC começando em p=none. O limite de 255 caracteres por string também vale aqui — uma chave DKIM longa ainda precisa ser fatiada em várias strings dentro do valor do registro, então aplique o registro e verifique o resultado publicado.

Verifique antes de aplicar#

Alterações de DNS no Route 53 normalmente se propagam em um ou dois minutos, embora o seu TTL e caches downstream possam esticar isso. Assim que os registros estiverem no ar, confirme que os três resolvem e são interpretados corretamente com o verificador de SPF, DKIM e DMARC — ele sinaliza um registro SPF ausente ou duplicado, uma chave DKIM que foi dividida ou colada de forma errada, e uma política DMARC com erro de sintaxe, que são as três coisas com maior probabilidade de dar errado no Route 53. Só depois que o verificador estiver verde é que você deve começar a subir a política DMARC de none em direção a reject.

Ter os três publicados e passando é o que atende aos requisitos de remetente do Google e do Yahoo para remetentes em massa. Mas lembre-se do limite: a autenticação prova quem você é, não que você é um bom remetente. Uma mensagem perfeitamente autenticada para uma lista cheia de endereços mortos ainda cai no spam. O guia de entregabilidade de e-mail cobre o trabalho de reputação e higiene de lista que transforma uma identidade confiável em colocação na caixa de entrada.

Perguntas frequentes#

O que devo colocar no campo de nome de registro do Route 53 para o registro SPF raiz?#

Deixe em branco. O Route 53 aplica um registro com nome vazio ao ápice da zona — o próprio domínio raiz — que é exatamente onde o registro TXT do SPF deve ficar. Defina o tipo como TXT e cole seu único valor v=spf1 .... Não digite @ nem o nome do seu domínio no campo; um nome de registro vazio é como o Route 53 expressa a raiz.

Por que meu registro DKIM falha no Route 53 mesmo com a chave parecendo correta?#

Quase sempre por causa do limite de 255 caracteres por string. Uma chave DKIM de 2048 bits é longa demais para uma única string TXT, então o Route 53 exige que ela seja dividida em várias strings entre aspas que os resolvedores concatenam. Se a divisão inserir um espaço perdido, remover um caractere, ou as partes acabarem como dois registros separados em vez de um único valor, a chave não será validada. Cole a chave completa novamente, mantenha-a como um único valor de registro e confirme com um verificador de DKIM.

Devo digitar _dmarc ou o nome completo _dmarc.example.com no nome do registro?#

Digite apenas _dmarc. O Route 53 exibe o sufixo do seu domínio ao lado do campo e o acrescenta automaticamente, então _dmarc vira _dmarc.example.com. Digitar o nome completo produziria um _dmarc.example.com.example.com duplicado, que nenhum receptor jamais consultará. A mesma regra de prefixação vale para o seu seletor DKIM.

Posso gerenciar SPF, DKIM e DMARC no Route 53 com Terraform ou pela CLI?#

Sim. Cada registro é um recurso aws_route53_record no Terraform ou um change batch para aws route53 change-resource-record-sets na CLI. Os nomes, tipos e valores dos registros são idênticos ao que você inseriria no console, e a mesma divisão de 255 caracteres para chaves DKIM longas se aplica. Gere os valores primeiro, depois faça o commit deles no código e verifique o resultado publicado.

O Route 53 torna os três registros simples uma vez que você conhece suas convenções de nomenclatura e de aspas — mas a autenticação é apenas o ingresso de entrada para a caixa de entrada. Monte seus registros com as ferramentas gratuitas, depois limpe a lista por trás deles com o verificador de e-mail gratuito: ele detecta domínios mortos, erros de digitação e armadilhas de spam antes que retornem, porque uma identidade confiável só conquista colocação quando a lista para a qual ela assina está limpa.