A mudança no DNS: MX, SPF, DKIM e DMARC

Módulo 4: Mudar de correio eletrónico · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: Após esta lição, será capaz de planear e executar a mudança de DNS para o correio eletrónico na ordem correta, de forma a que não se perca correio, a que o seu correio de saída não caia no spam e a que o Outlook não continue secretamente a contactar o antigo fornecedor.

Conceitos-chave: TTL, mudança de MX, SPF (um único registo), seletor DKIM, DMARC (p=none, rua), autodiscover, autoconfig, registo de verificação, domínio aceite

Cinco registos, um único momento

Para o correio eletrónico no seu próprio domínio existem alguns registos no DNS que, em conjunto, determinam se o correio chega e se o seu correio é considerado fiável:

Numa mudança, quase tudo isto é alterado. A arte está na ordem. Se alterar o MX enquanto o SPF e o DKIM ainda só são válidos para o Microsoft, o seu correio chega, mas o correio que envia cai no spam. Se alterar primeiro o SPF, o Microsoft deixa de conseguir enviar corretamente em seu nome nos dias anteriores.

Esta lição é sobre a ordem a seguir. Para perceber exatamente como funciona cada registo, consulte o curso de DNS (lições 4.1 a 4.5).

Passo 1, dois dias antes: baixar o TTL e fazer cópia de segurança

Cada registo DNS tem um TTL (time to live): durante quanto tempo os outros servidores podem guardar a resposta em memória. Se o TTL do seu MX estiver definido para 86400 segundos (um dia), alguns servidores continuarão a enviar para o servidor antigo durante até um dia após a mudança.

Por isso, reduza, pelo menos um TTL antigo antes, o TTL do MX, do SPF e do autodiscover para 300 ou 3600 segundos. Com um TTL de um dia, faça isto com pelo menos um dia de antecedência; dois dias é uma margem confortável. Ao mesmo tempo, faça uma cópia de segurança da sua zona DNS, ou anote todos os registos atuais. Assim pode sempre recuar.

A Bakkerij De Korrel vê:

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

O TTL já está em 3600 (uma hora). Colocam o MX e o SPF em 300.

Passo 2, antes da mudança: preparar o DKIM e o SPF para o novo fornecedor

Os registos que não causam nenhum dano podem ser colocados com antecedência:

• DKIM do novo fornecedor. O novo fornecedor fornece um seletor e uma chave, por exemplo x._domainkey com um registo TXT v=DKIM1; k=rsa; p=.... Como o seletor tem um nome diferente do da Microsoft (selector1 e selector2), ambos coexistem sem problema. Cada destinatário verifica apenas o seletor indicado na assinatura da mensagem.
• Alargar o SPF, não substituí-lo. Só pode existir um registo SPF. Acrescente o novo fornecedor ao mesmo registo, para que, durante os dias de transição, ambos possam enviar correio:

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

A padaria tinha -all. Durante a transição, optam temporariamente por ~all (softfail): se, ainda assim, faltar algum servidor, a mensagem é antes considerada suspeita do que recusada. Isto segue a regra geral: ~all quando não tem a certeza absoluta, -all quando tem a certeza de que todos os remetentes estão incluídos.

Não se esqueça dos outros remetentes da sua lista da lição 4.1: a loja online, o serviço de newsletter, a contabilidade. Esses permanecem no registo SPF.

Passo 3, o momento da mudança: MX e autodiscover

No momento combinado, depois de a primeira cópia das caixas de correio estar pronta (lição 4.2):

1. Substitua os registos MX pelos do novo fornecedor. Remova o MX antigo; não o deixe como "reserva" com uma prioridade mais alta, porque isso faz com que chegue correio ao fornecedor antigo sempre que o novo estiver um pouco lento.
2. Ajuste o autodiscover. O Outlook procura as suas definições através de autodiscover.example.com. Se este ainda apontar para autodiscover.outlook.com, o Outlook continua a tentar iniciar sessão no Microsoft, mesmo ao adicionar uma nova conta. Remova-o ou faça-o apontar para o que o seu novo fornecedor indicar. Alguns fornecedores utilizam, em alternativa, autoconfig.example.com (Thunderbird) ou registos SRV como _imaps._tcp e _submission._tcp (RFC 6186).
3. Execute uma segunda cópia das caixas de correio, para que o correio das últimas horas também seja incluído.

Há uma surpresa no Microsoft 365 que apanha muita gente desprevenida. Enquanto example.com estiver definido no ambiente Microsoft 365 como domínio aceite, o Microsoft entrega internamente o correio entre utilizadores do mesmo ambiente, sem verificar o MX. Se um colega que ainda trabalha no Outlook do Microsoft enviar correio para outro colega, essa mensagem chega à caixa de correio antiga. Por isso, mude todos os colaboradores no mesmo dia e remova o domínio do ambiente Microsoft depois do período de transição.

Passo 4, DMARC: acompanhar durante a transição

O DMARC indica aos destinatários o que fazer quando uma mensagem não passa no SPF ou no DKIM, e envia-lhe relatórios. A padaria tinha p=quarantine. Isso é positivo, mas perigoso durante uma mudança: se o DKIM no novo fornecedor ainda não estiver ativo, o seu próprio correio acaba no spam dos clientes.

A abordagem segura:

• Se ainda não tiver DMARC, comece com p=none e um endereço rua. Assim, não acontece nada ao seu correio, mas começa a receber relatórios.
• Se já tiver quarantine ou reject, verifique antes da mudança, com uma mensagem de teste, que o DKIM do novo fornecedor funciona (o cabeçalho de uma mensagem recebida mostra dkim=pass com d=example.com). Em caso de dúvida, coloque temporariamente p=none e acompanhe os relatórios durante algumas semanas.
• Depois, aperte gradualmente: none, depois quarantine, depois eventualmente reject. Segundo a nova norma DMARC (RFC 9989), também pode utilizar t=y na fase de teste; a antiga etiqueta pct deixa de existir.

Passo 5, passadas algumas semanas: limpeza

Se tudo funcionar bem durante algumas semanas, limpe os registos antigos:

• o antigo include do SPF (e, eventualmente, voltar a -all);
• os antigos registos DKIM (selector1 e selector2);
• o registo de verificação MS=ms... e eventuais outros registos para o Microsoft, como enterpriseregistration e lyncdiscover, se os tivesse;
• o TTL de volta a um valor normal, como 3600;
• o domínio removido do antigo ambiente Microsoft ou Google.

Se deixar o antigo include no registo, o antigo fornecedor continua autorizado a enviar correio em nome do seu domínio durante anos. Isso é uma porta aberta.

Na prática: como isto aparece num fornecedor

N'O meu WebOké, no separador DNS, encontra o cartão Definições de E-mail. Este mostra o MX, o SPF e o DMARC com um ponto colorido, e no canto superior direito indica qual o fornecedor de correio eletrónico reconhecido através do seu MX. Com Definir rapidamente, define de uma só vez os registos para um fornecedor, e o aviso a amarelo alerta que os registos MX e SPF existentes serão substituídos. Por isso, faça primeiro uma cópia de segurança do DNS e verifique depois se o registo SPF ainda contém os seus outros remetentes. Na página de produto de um pacote de alojamento encontra o cartão Definir E-mail, que indica, por registo, se está Correto, Atenção, Incorreto ou Não encontrado, apresentando o valor com um botão de copiar. Se o DNS estiver noutra entidade, aplique lá esses valores. Outros fornecedores e painéis de DNS têm resumos semelhantes; os registos em si são iguais em todo o lado.

Resumo

• Reduza o TTL, pelo menos, um TTL antigo antes e faça uma cópia de segurança da sua zona DNS.
• Prepare o DKIM do novo fornecedor e um registo SPF alargado (um único registo, com ambos os fornecedores) antes da mudança.
• Mude o MX e o autodiscover em simultâneo, e mude todos os colaboradores no mesmo dia; caso contrário, o Microsoft continua a entregar o correio interno nas caixas de correio antigas.
• Durante a transição, não torne o DMARC mais rigoroso do que aquilo que tem a certeza; se ainda não tiver DMARC, comece com p=none e relatórios.
• Passadas algumas semanas, limpe o antigo include, os registos DKIM, os registos de verificação e o domínio do ambiente antigo.

Quiz

Exercício

Exercício A4.3: Os seus registos de correio eletrónico em resumo. Indique o seu domínio e o seletor DKIM do seu (novo) fornecedor. O programa verifica se o MX aponta para o seu fornecedor, se existe exatamente um registo SPF, se a chave DKIM está presente nesse seletor e se existe exatamente um registo DMARC. Também mede o TTL do seu MX junto do servidor de nomes autoritativo: para uma mudança planeada, este deve ser 3600 ou inferior.

Exercício E4.3: O seu plano de mudança. Escreva, para o seu próprio domínio, o plano de ação desta lição: por passo, a data e a hora, os registos antes e depois (SPF antigo e novo numa única linha), quem o executa e o que verifica após cada passo.

Para saber mais

Os passos nestes artigos aplicam-se aos serviços da WebOké; noutros fornecedores o funcionamento é semelhante.

• Manual do WebOké 6.7: O cartão Configurar e-mail (MX, SPF, DKIM, DMARC)
• Manual do WebOké 5.6: Configurar rapidamente o e-mail no DNS
• Manual do WebOké 5.7: Repor o DNS e criar uma cópia de segurança do DNS
• Manual DirectAdmin 10.4: Depois da mudança: registos MX e os seus dispositivos
• Curso gratuito de DNS 4.3: SPF: quem pode enviar e-mails em nome do seu domínio?
• Curso gratuito de DNS 4.4: DKIM: a assinatura por baixo do seu e-mail
• Curso gratuito de DNS 4.5: DMARC: o que os destinatários devem fazer com e-mails falsos
• Curso gratuito de DNS 6.3: O DNS numa transferência
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (registos SRV para programas de correio eletrónico)