Ir diretamente para o conteúdo

Definições de cookies

Escolha que tipos de cookies permite. Pode alterar a sua escolha a qualquer momento em Definições de cookies, no fundo de cada página. Política de privacidade

Necessários

Sempre ativos

Necessários para iniciar sessão, manter o seu carrinho e memorizar as suas escolhas. Estão sempre ativos.

Que cookies?
  • weboke_sessie, weboke_klant, weboke_remember: a sua sessão e manter a sessão iniciada
  • weboke_basket: o seu carrinho
  • wkBtwIncl: mostrar preços com ou sem IVA
  • wok_cookies: a sua escolha de cookies, 12 meses

Mede que anúncio leva a uma visita ou encomenda, para não pagarmos por anúncios que não dão resultado.

Que cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), até 90 dias
  • OpenAI Ads, anúncios no ChatGPT
  • wok_aff: através de que parceiro chegou até nós (programa de afiliados), 60 dias

4,6

País e idioma

Cada país tem o seu próprio site, com os preços e o IVA desse país.

Ver

Newsletters a partir do seu próprio domínio

Módulo 7: Newsletters e email a partir do seu site · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Após esta lição, saberá associar um serviço de envio de forma a que a sua newsletter passe pelo SPF, DKIM e DMARC em nome do seu próprio domínio, e saberá verificar nas cabeçalhos se isso foi conseguido.

Conceitos-chave: serviço de envio, domínio From, Return-Path (domínio de bounce), domínio DKIM (d=), alinhamento (alignment), domínio de bounce próprio via CNAME, DKIM via CNAME, subdomínio para marketing, limite de envio, aquecimento (warm-up)

Porque é que uma newsletter é diferente de um email normal

Um email para um cliente ou colega é enviado a partir da sua própria caixa de correio. Uma newsletter é enviada para centenas ou milhares de pessoas ao mesmo tempo. Para destinatários como o Gmail, o Outlook.com e o T-Online, isso constitui um tipo de tráfego diferente: correio em massa (bulkmail). Estes destinatários são mais rigorosos nesse caso, porque praticamente todo o spam também é correio em massa.

Três fatores fazem a diferença entre uma newsletter que chega à caixa de entrada e uma que acaba no spam:

  1. Técnica: o email tem de ser comprovadamente proveniente do seu domínio. Isso é assegurado pelo SPF, DKIM e DMARC, e sobretudo pelo alinhamento entre eles.
  2. Reputação: os servidores e o domínio a partir dos quais envia têm de ter boa reputação (lição 5.2).
  3. Comportamento dos seus destinatários: abrem o seu email, ou clicam em "Isto é spam"? Isso depende da sua lista e do consentimento (lição 7.2).

Esta lição aborda o primeiro ponto. A base dos registos encontra-se no curso de DNS, lição 7.4. Aqui vemos como verificar na prática se tudo está correto.

Porque não enviar simplesmente a partir da sua própria caixa de correio?

Pode ser tentador enviar uma newsletter com BCC a partir do seu programa de correio habitual, ou com uma lista de distribuição no seu pacote de alojamento. Para uma pequena associação com trinta membros que se conhecem entre si, uma lista de distribuição é perfeitamente adequada. Para uma newsletter a sério, não, por quatro razões:

  • Limites de envio. Praticamente todos os fornecedores limitam a quantidade de correio que uma caixa de correio ou pacote pode enviar por dia, para limitar abusos. Na WebOké, esse limite é visível no DirectAdmin, nas estatísticas do utilizador; noutros fornecedores encontra-se nas condições ou no painel de cliente. Uma newsletter para 2.000 pessoas ultrapassa largamente esse limite.
  • Reputação partilhada. Partilha o servidor de envio com outros clientes. Se os destinatários se queixarem da sua newsletter, isso também afeta o correio deles, e vice-versa.
  • Sem botão de cancelamento de subscrição nem gestão de bounces. Um serviço de envio coloca automaticamente as cabeçalhos de cancelamento de subscrição em cada email (lição 7.2), remove da sua lista os endereços que já não existem e trata as reclamações. Isso nunca é feito corretamente de forma manual.
  • Privacidade. Um clique errado e está a enviar o endereço de todos para o campo Para de todos os outros.

Um serviço de envio (um serviço de newsletters como o Laposta, o Brevo, o MailerLite ou o Mailchimp, ou um serviço transacional para confirmações e faturas) foi criado precisamente para este trabalho. Mas, nesse caso, é outra entidade que envia em nome do seu domínio, e isso tem de ser comprovado.

Três domínios num só email

Cada email tem pelo menos três locais onde consta um domínio. Num email normal enviado a partir da sua própria caixa de correio, esses domínios são geralmente iguais. Num serviço de envio, não necessariamente.

LocalOnde se vêQuem verifica
From (remetente visível)From: Nieuws <nieuws@example.com>o DMARC verifica este domínio
Return-Path (remetente do envelope, endereço de bounce)Return-Path: <bounce-8f3a@mail.sender.example>o SPF verifica este domínio
Domínio DKIMDKIM-Signature: ... d=sender.example; s=s1; ...o DKIM verifica a assinatura deste domínio

O DMARC (lição 4.4) aprova um email se o SPF ou o DKIM forem bem-sucedidos, e o domínio que foi bem-sucedido estiver alinhado com o domínio From. Alinhado significa, na configuração predefinida (relaxed), que se trata do mesmo domínio organizacional: mail.example.com está alinhado com example.com, mas sender.example não.

Sem configurações próprias, uma newsletter apresenta-se assim:

Return-Path: <bounce-8f3a@mail.sender.example>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.sender.example;
       dkim=pass header.d=sender.example;
       dmarc=fail header.from=example.com

O SPF é bem-sucedido e o DKIM é bem-sucedido, mas ambos para o domínio do serviço. Nenhum dos dois está alinhado com example.com, pelo que o DMARC falha. Se a sua política de DMARC estiver definida como p=none, só notará isso nos seus relatórios (lição 4.5). Se estiver definida como quarantine ou reject, a sua newsletter acaba no spam ou é recusada.

A solução: autenticar o domínio junto do serviço

Todo o serviço de envio sério tem um passo designado "autenticar domínio", "verificar domínio" ou "configurar domínio de remetente". O serviço fornece-lhe então alguns registos para colocar no seu DNS. Normalmente, são estes:

  1. DKIM via CNAME, por exemplo s1._domainkey.example.com a apontar para um nome do serviço. Depois disso, o serviço assina o seu email com d=example.com. Este é o registo mais importante: é com ele que o DMARC é bem-sucedido através do DKIM.
  2. Um domínio de bounce próprio, geralmente um CNAME num subdomínio, por exemplo bounce.example.com a apontar para o serviço. Nesse caso, o Return-Path passa a ser ...@bounce.example.com. O SPF desse subdomínio aponta, através do CNAME, para o serviço, e o SPF fica então também alinhado. Nem todos os serviços oferecem isto; só o DKIM já é suficiente para o DMARC.
  3. Por vezes, um include de SPF no seu próprio registo, se o serviço utilizar o seu domínio principal como Return-Path. Faça isto apenas se o serviço o pedir, e sempre dentro do seu registo SPF existente (lição 4.2).
  4. Por vezes, um TXT de verificação para comprovar que o domínio lhe pertence.

Após a configuração correta, a mesma newsletter apresenta-se assim:

Return-Path: <bounce-8f3a@bounce.example.com>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Reproduza sempre os nomes e destinos exatamente como constam no painel do seu serviço. Variam consoante o serviço e, por vezes, consoante a conta.

Um subdomínio separado para marketing?

Os grandes remetentes utilizam frequentemente um subdomínio próprio para newsletters, como nieuws.example.com ou info.example.com, com nieuwsbrief@nieuws.example.com como remetente. A ideia é que a reputação do seu correio de marketing fica assim separada da do seu correio normal. Se uma campanha correr mal, o seu correio diário com clientes sofre menos com isso.

Para quem envia uma newsletter algumas vezes por mês, isso não é necessário. Torna a gestão mais complexa: o subdomínio precisa de DKIM próprio, e a sua política de DMARC para subdomínios (sp=) tem de ser coerente com isso. Considere esta opção se enviar muito correio ou se, além de newsletters, também tiver muito correio transacional (encomendas, palavras-passe). Esse correio nunca deve sofrer com uma campanha falhada.

Importante: não coloque num subdomínio de envio nenhum registo MX a apontar para o serviço, a menos que seja necessário, e nunca altere o MX do seu domínio principal por causa de uma newsletter. O MX determina onde o correio chega; as respostas à sua newsletter devem ser recebidas normalmente na sua própria caixa de correio.

Aquecimento: não começar logo com tudo

Está a enviar pela primeira vez com um novo serviço ou um novo domínio, ou envia de repente dez vezes mais do que o habitual? Os destinatários ainda não o conhecem. Os grandes destinatários travam remetentes desconhecidos (na Microsoft, isso traduz-se em recusas temporárias como 451 4.7.500, lição 6.4). Por isso, comece em pequena escala: primeiro os seus leitores mais ativos, depois, de cada vez, uma parte maior. A isto chama-se aquecimento. Num serviço de envio partilhado, o próprio serviço trata de grande parte disto, mas mesmo assim a reputação do seu domínio conta.

Na prática: como se apresenta num painel

Coloca os registos do serviço na administração de DNS do seu domínio. Na WebOké, é o separador DNS em O meu WebOké ou Administração de DNS no DirectAdmin; noutros fornecedores chama-se administração de DNS, gestão de zona ou registos DNS, e funciona de forma semelhante. Preste atenção aos dois erros clássicos: o nome de domínio duplicado no nome (s1._domainkey.example.com.example.com), e criar um registo TXT quando o serviço pede um CNAME.

Terminou? Envie uma newsletter de teste para um endereço Gmail ou Outlook.com seu e abra as cabeçalhos (lição 1.5). Em Authentication-Results, deve ver: dkim=pass com header.d= o seu domínio, e dmarc=pass.

Resumo

  • Uma newsletter é correio em massa: os destinatários são mais rigorosos. Utilize um serviço de envio, não a sua caixa de correio habitual.
  • Em cada email constam três domínios: From (DMARC), Return-Path (SPF) e o domínio DKIM d=.
  • O DMARC só é bem-sucedido se o SPF ou o DKIM forem bem-sucedidos para um domínio alinhado com o domínio From.
  • Autentique o seu domínio junto do serviço: o DKIM via CNAME é o mais importante, um domínio de bounce próprio é uma vantagem adicional.
  • Verifique com um email de teste: dkim=pass header.d=<o seu domínio> e dmarc=pass. Comece em pequena escala com um novo serviço.

Quiz

1. Uma newsletter tem From: nieuws@example.com, Return-Path @mail.sender.example e DKIM d=sender.example. O SPF e o DKIM são bem-sucedidos. O que faz o DMARC?



2. Qual é o registo do serviço de envio mais importante para que o DMARC seja bem-sucedido?



3. Porque é que bounce.example.com como Return-Path é melhor do que mail.sender.example?



4. A sua associação (25 membros) e uma loja online (8.000 subscritores) querem ambas enviar uma newsletter. O que é mais adequado?



5. Está a começar com um novo serviço de envio e tem 20.000 endereços. O que é aconselhável?



Exercício

Exercício Z7.1: Verificar o alinhamento de uma newsletter. Envie uma newsletter do seu próprio serviço de envio para si mesmo (ou utilize o ficheiro de exemplo nieuwsbrief-kopregels-1.txt do curso) e cole as cabeçalhos. Indique: o domínio From, o domínio Return-Path, o domínio DKIM (d=) e se, na sua opinião, o DMARC é bem-sucedido (sim/não) e por que via (SPF, DKIM, ambos ou nenhum). O programa analisa as cabeçalhos automaticamente, verifica o seletor DKIM em tempo real no DNS e o registo DMARC do domínio From, e compara o seu resultado com o do programa.

Exercício Z7.1: Verificar o alinhamento de uma newsletter

Ficheiro deste exercício: nieuwsbrief-kopregels-1.txt, nieuwsbrief-kopregels-2.txt, kopregels-1.txt

Cole as cabeçalhos de uma newsletter que você próprio envia, ou escolha um ficheiro de exemplo. O servidor analisa as cabeçalhos (apenas na memória) e, no caso de cabeçalhos reais, procura a chave DKIM e o registo DMARC.








O que preenche e o que encontramos não ficam guardados. O seu navegador memoriza as suas respostas e se concluiu o exercício com sucesso. Se tiver sessão iniciada, guardamos apenas que concluiu o exercício (quase) com sucesso em Os meus cursos; aí também o pode eliminar.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores, o funcionamento é semelhante.

Um momento…

Configurar os seus domínios

Para cada domínio, defina os servidores de nomes, a ligação ao seu alojamento e quem fica como titular.

A carregar os seus domínios…