Serviços de newsletter e de envio de e-mails

Módulo 7: Ligar serviços externos · Tempo de leitura: 8 minutos

Objetivo de aprendizagem: Depois desta lição, saberá ligar um serviço de newsletter ou de envio de modo a que o seu e-mail não acabe no spam.

Conceitos-chave: verificação de domínio (autenticação), DKIM via CNAME, selector, include de SPF apenas se o serviço o pedir, limite de 10 consultas, alinhamento DMARC via DKIM, não mexer no MX

Porque é que um serviço de newsletter pede registos

Um serviço de newsletter como o Mailchimp, o Brevo ou o MailerLite, ou um serviço de envio de faturas e confirmações, envia e-mail com o seu endereço como remetente, por exemplo nieuws@example.com. Mas o e-mail vem dos servidores desse serviço, não do seu servidor de e-mail.

Destinatários como o Gmail e o Outlook.com verificam então: este servidor pode enviar e-mail em nome de example.com, e a assinatura está correta (lições 4.3 a 4.5)? Se isso não estiver configurado, a sua newsletter vai parar ao spam, ou o serviço reescreve o seu remetente para um endereço próprio. Por isso o serviço pede-lhe para autenticar o seu domínio: alguns registos no seu DNS.

O que o serviço não precisa: os seus registos MX. Esses determinam para onde vai o seu e-mail recebido. Uma newsletter envia-se apenas; as respostas chegam normalmente à sua própria caixa de correio. Por isso, nunca altere o seu MX por causa de um serviço de newsletter.

DKIM via CNAME

A maioria dos serviços permite configurar o DKIM com registos CNAME. O serviço guarda a chave; você apenas aponta para ela. Assim, o serviço pode substituir a chave sem que seja necessário fazer nada.

No momento em que este texto foi escrito, o Mailchimp usa dois registos em contas mais recentes:

k2._domainkey.example.com.   3600   IN   CNAME   dkim2.mcsv.net.
k3._domainkey.example.com.   3600   IN   CNAME   dkim3.mcsv.net.

Contas mais antigas têm frequentemente apenas um registo k1._domainkey para dkim.mcsv.net. Outros serviços usam outros selectors, como brevo1._domainkey ou ml._domainkey. Utilize exatamente o que o painel do seu serviço indicar. Os nomes e destinos variam consoante o serviço e a conta, e por vezes mudam.

k2 e k3 são selectors (lição 4.4). Cada serviço tem o seu próprio selector, para que os registos não interfiram uns com os outros nem com a chave DKIM do seu próprio servidor de e-mail.

Três erros que quase toda a gente comete uma vez

1. Nome de domínio duplicado. O seu painel acrescenta frequentemente o nome de domínio no fim, automaticamente. Se introduzir k2._domainkey.example.com, o resultado será k2._domainkey.example.com.example.com. Introduza apenas k2._domainkey, a menos que o painel peça explicitamente o nome completo. Por baixo do campo costuma indicar-se como ficará o nome.
2. Esquecer o ponto final no valor. Sem o ponto, o seu painel pode transformar dkim2.mcsv.net em dkim2.mcsv.net.example.com. Alguns painéis acrescentam o ponto automaticamente; verifique como ficou o registo depois de guardar (lição 2.2).
3. TXT em vez de CNAME. Se o serviço pedir um CNAME, crie um CNAME. Um registo TXT com dkim2.mcsv.net como texto não tem qualquer efeito.

SPF: apenas se o serviço o pedir

Muitas pessoas pensam que, em relação ao SPF, todos os serviços que enviam e-mail têm de constar no seu registo SPF. Isso nem sempre é verdade.

O SPF verifica o endereço no envelope do e-mail (o Return-Path), não o endereço de remetente que você vê. Muitos serviços de newsletter, incluindo o Mailchimp, usam no envelope um domínio próprio. A verificação de SPF deles passa, portanto, pelo próprio domínio, e o seu registo SPF não desempenha qualquer papel. Por isso, o Mailchimp não pede um include no seu registo SPF.

Outros serviços usam um endereço no seu domínio no envelope, ou permitem configurar um subdomínio próprio (por exemplo, bounce.example.com). Esses pedem um include: no seu registo SPF, ou um registo SPF nesse subdomínio. Faça exatamente o que o serviço pedir:

• se o serviço pedir um include, coloque-o no seu registo SPF existente, nunca num segundo registo (lição 4.3);
• se o serviço não o pedir, não acrescente nada.

Porquê ser parcimonioso? Um registo SPF pode, numa verificação, provocar no máximo 10 consultas DNS. Cada include, a, mx, exists e redirect conta, e os includes de um serviço costumam, eles próprios, conter outros includes. Com um fornecedor de alojamento, o Microsoft 365, um serviço de newsletter, um programa de contabilidade e um CRM, ultrapassa-se rapidamente o limite. Nesse caso, todo o seu registo SPF fica inválido (permerror). Remova includes de serviços que já não utiliza, ou que não os pedem.

DMARC: é aqui que tudo se decide

O DMARC (lição 4.5) aprova um e-mail se o SPF ou o DKIM forem bem-sucedidos e corresponderem ao domínio no endereço de remetente (alinhamento). Num serviço de newsletter que use um domínio próprio no envelope, o SPF nunca pode alinhar-se com example.com. O DMARC só pode então ser bem-sucedido através do DKIM: uma assinatura com d=example.com, que só se obtém depois de configurar os registos CNAME.

Por isso:

1. configure primeiro os registos DKIM do serviço;
2. aguarde até o serviço indicar que o seu domínio está autenticado;
3. envie um teste para si próprio e verifique nos cabeçalhos se o DKIM está pass com d=example.com;
4. só depois ajuste a sua política DMARC de none para quarantine ou reject.

Se ainda não tiver um registo DMARC, muitos serviços pedem para criar um. Comece com p=none (lição 4.5). Grandes destinatários como o Gmail e o Yahoo exigem, desde 2024, que remetentes em massa tenham um registo DMARC.

Respostas e bounces

Se um leitor responder à sua newsletter, a resposta vai para o endereço de resposta que configurar no serviço, e chega, através do seu MX, à sua própria caixa de correio. As mensagens não entregues (bounces) vão para o endereço do envelope e, portanto, para o serviço, que as processa. Também nesse caso não precisa de alterar nada no seu MX.

Na prática: como se apresenta num painel

No painel de exemplo DirectAdmin, abra a Administração de DNS, clique em Adicionar registro, escolha CNAME, preencha em Nome apenas k2._domainkey e em Valor dkim2.mcsv.net. com o ponto. Depois faça o mesmo para k3. No O meu WebOké, no separador DNS, o procedimento é semelhante; a janela mostra, por baixo do campo do nome, o nome completo e avisa se o ponto estiver em falta.

Noutros painéis, como o cPanel, o Plesk, o Cloudflare ou o ecrã de DNS do seu registrar, os botões têm outros nomes, mas são os mesmos campos. No Cloudflare, tenha atenção ao proxy: coloque os registos para DKIM em "DNS only" (o Cloudflare costuma já fazer isso automaticamente para CNAMEs com _domainkey).

Resumo

• Um serviço de newsletter não precisa dos seus registos MX; deixe-os como estão.
• O DKIM processa-se geralmente através de registos CNAME com um selector próprio. Utilize exatamente o que o seu painel indicar.
• Preencha apenas a primeira parte do nome e tenha atenção ao ponto no fim do valor.
• Acrescente um include de SPF apenas se o serviço o pedir, no seu registo existente, e mantenha-se abaixo das 10 consultas.
• Nestes serviços, o DMARC é bem-sucedido através do alinhamento DKIM; só torne a sua política mais restritiva depois de o DKIM funcionar.

Quiz

Exercício

Exercício Z7.4: Reconhecer um serviço de newsletter. Veja como um serviço de newsletter configura o seu próprio DKIM.

1. Procure o registo CNAME de k2._domainkey.mailchimp.com e de k3._domainkey.mailchimp.com. Copie os nomes de destino.
2. Procure o registo SPF de mailchimp.com e conte quantas partes include: contém.

A verificação consulta os registos em tempo real no momento da entrega.

Exercício O7.4: Configurar você mesmo na sua zona de treino. Ligue um serviço de newsletter simulado à sua zona de treino <code>.dnspractice.eu. Na zona de treino utiliza o serviço fictício newsletter-demo.dnspractice.eu; no seu domínio real, utilize os valores indicados no painel do seu serviço de newsletter.

1. Crie um CNAME k2._domainkey.<code>.dnspractice.eu para dkim2.newsletter-demo.dnspractice.eu. Tenha atenção ao nome: sem a zona duplicada no fim.
2. Crie um CNAME k3._domainkey.<code>.dnspractice.eu para dkim3.newsletter-demo.dnspractice.eu.
3. Garanta que existe em <code>.dnspractice.eu exatamente um registo SPF que comece com v=spf1 e termine em ~all ou -all. Não acrescente nenhum include para este serviço.
4. Deixe os seus registos MX em <code>.dnspractice.eu como estão: este serviço não precisa deles.

Para saber mais

Estas páginas descrevem os passos nos painéis da WebOké (DirectAdmin e O meu WebOké). Noutros painéis, o funcionamento é semelhante.

• Gerir registos DNS no O meu WebOké (com exemplos para CNAME, TXT e serviços externos)
• Manual DirectAdmin 5.4: Registos CNAME e o ponto final
• Manual DirectAdmin 5.8: Ativar e verificar o DKIM
• Manual DirectAdmin 5.7: Configurar e complementar o SPF
• O que é o DMARC? Explicação em linguagem simples