E-mails do seu próprio domínio

Seu bot pode escrever aos seus clientes por e-mail a partir de um endereço no seu domínio, como noreply@example.com. A mensagem, porém, é enviada pelo nosso servidor. Por isso, antes do primeiro envio é preciso adicionar uma vez três registros ao DNS do seu domínio. A seguir: por que isso é necessário, o que exatamente adicionar e o que acontece depois.

Por que sem registros DNS os e-mails não chegam

Olhe pelo lado de quem recebe — Gmail, Outlook ou o servidor de e-mail do seu cliente. Chega uma mensagem que afirma vir do seu domínio, mas vem de um servidor que não pertence ao seu domínio. É exatamente a aparência de uma falsificação: é assim que funciona o phishing.

A única forma de o destinatário distinguir os dois casos é perguntar ao próprio domínio: «este remetente age mesmo em seu nome?». A resposta você publica no DNS do seu domínio, porque o DNS é o único lugar que só você controla — e, portanto, o único em que o destinatário acredita.

Enquanto essa resposta não existe, um servidor de e-mail responsável precisa tratar a mensagem como suspeita. Na melhor hipótese ela cai no spam; na pior é rejeitada e o destinatário nunca fica sabendo que ela existiu.

Portanto, os três registros abaixo não são burocracia nem uma caixinha de marcar. Eles são a sua autorização.

Os três registros e o que cada um faz

DKIM — a assinatura que prova autenticidade

DKIM é uma assinatura criptográfica colocada em cada mensagem enviada. A plataforma gera para o seu domínio um par de chaves: a privada fica conosco e assina os envios, a pública você publica no DNS. O destinatário pega a chave pública do seu DNS e confere a assinatura. Se bater, a mensagem foi enviada por quem tem a chave privada e o conteúdo não foi alterado no caminho.

Sem DKIM: não há contra o que conferir a assinatura. A mensagem parece não assinada e sem crédito, e nenhum outro ajuste compensa isso. DKIM é o mais importante dos três.

SPF — quais servidores podem enviar em seu nome

O SPF responde a outra pergunta: de quais servidores é admissível haver e-mail deste domínio. É uma lista de origens: os servidores de e-mail da sua hospedagem, os serviços de envio que você já usa e, para o bot poder escrever, os nossos servidores de envio.

Sem SPF: a mensagem chega de um servidor que o seu domínio não reconhece. Para um filtro isso é sinal clássico de falsificação, e soma-se a todas as outras suspeitas.

DMARC — o que o destinatário deve fazer quando as verificações falham

DKIM e SPF respondem «a mensagem é autêntica». O DMARC responde à pergunta seguinte: o que fazer se não for. É a sua instrução ao destinatário — não fazer nada e apenas relatar, mandar para o spam, ou rejeitar. O DMARC também é o endereço para onde os destinatários enviam relatórios agregados sobre o e-mail em seu nome, inclusive tentativas alheias de falsificação.

Comece pela política mais branda, «apenas relatórios». Endureça depois, quando tiver certeza de que todos os seus remetentes legítimos (contabilidade, CRM, newsletters, este bot) passam nas verificações. Uma política rígida ligada cedo demais começa a devorar o seu próprio e-mail.

Sem DMARC: cada destinatário decide por conta própria e você nunca descobre o que acontece com o e-mail enviado em seu nome.

Quais registros adicionar

Primeiro cadastre o domínio no painel: seção Email → «Sending domains» → botão «Add domain». A caixa tem três campos: o domínio em si (por exemplo shop.example.com), a parte local do endereço (o que vem antes do @, normalmente noreply) e o nome do remetente, que o destinatário vê no lugar de um endereço. Ao salvar, os seus registros DNS aparecem na tela.

Os três são registros TXT no DNS do seu domínio. São adicionados onde você gerencia o domínio: o painel do registrador ou o seu provedor de DNS.

Os valores abaixo usam example.com como exemplo — troque pelo seu. Os valores exatos do seu domínio aparecem no cartão do domínio no painel: copie de lá, especialmente o DKIM, cujo valor contém a sua própria chave pública, diferente para cada domínio e impossível de tirar da documentação.

Na tela cada registro é dividido em dois campos separados — «Host» e «Value» — cada um com seu botão «Copy». Copie um de cada vez para os campos correspondentes no seu provedor de DNS: as duas partes não colam como um bloco único.

Dois tropeços frequentes:

• Muitos painéis acrescentam o domínio ao nome sozinhos. Se o campo do nome já mostra «.example.com», digite apenas mybot._domainkey e não o nome completo, senão você fica com mybot._domainkey.example.com.example.com.
• O valor do DKIM é longo e não pode ter quebras de linha nem espaços dentro da chave. Copie com o botão, não arrastando com o mouse.

Se o domínio já tem um registro SPF

Um domínio pode ter apenas um registro SPF. Se você já envia e-mail pela hospedagem, por um CRM ou outro serviço de newsletter, ele já existe. Não crie um segundo: complete o existente com mais um include, antes do ~all final:

v=spf1 include:spf.seuprovedor.com.br include:esp.getmybot.dev ~all

Dois registros SPF em um domínio é o mesmo erro que nenhum: a verificação não passa, porque o destinatário não tem como saber em qual dos dois acreditar.

Atenção: estar «coberto» pelo registro de outro não basta. Mesmo que o seu provedor atual nos inclua no SPF dele, o nosso include precisa estar no seu registro diretamente — o porquê está abaixo, na seção de verificação do domínio.

Por que include no SPF e não um endereço IP

O erro mais comum é colar um endereço IP visto em um cabeçalho de mensagem ou em um fórum. Não faça isso.

include:esp.getmybot.dev é um ponteiro para a nossa própria lista mantida de servidores de envio. Hoje esse nome resolve para um único relay. Amanhã podem ser vários, podem mudar de lugar ou ser substituídos. Quando isso acontecer, atualizamos a lista do nosso lado e o seu registro continua funcionando sem que você mexa em nada. É esse o sentido todo: o endereço muda em um único lugar, e não no DNS de cada cliente.

Um IP escrito à mão simplesmente deixa de ser verdade naquele momento. As mensagens começam a falhar no SPF sem aviso nenhum: nem erro no painel, nem notificação. Você descobre por clientes que «não receberam nada».

Escreva exatamente include:esp.getmybot.dev e não acrescente nada.

Verificação do domínio

Verificar o domínio é a plataforma consultar por si mesma o DNS do seu domínio e confirmar que os três registros estão em ordem. Se os três passarem, o domínio fica verificado e o envio é liberado. Enquanto um falhar, ele fica pendente.

O que se confere vai além de «o registro existe»:

Por que o DMARC é conferido de forma mais frouxa: ele diz aos destinatários o que fazer com os resultados de DKIM e SPF, mas não nos dá o direito de enviar em seu nome. Esse direito vem apenas dos dois primeiros registros, e ambos são conferidos por conteúdo integralmente.

Include alheio não conta

include:esp.getmybot.dev precisa estar no seu próprio registro SPF. Se o seu SPF inclui um provedor terceiro cujo registro por sua vez nos inclui, a verificação não aceita: a plataforma não resolve cadeias de includes alheios. O motivo é simples — assim a resposta a «este domínio nos autorizou?» fica sem ambiguidade.

Na prática: mesmo que você tenha certeza de estar «coberto pelo provedor», acrescente o nosso include diretamente ao seu registro. É isso que a própria tela diz na explicação do registro SPF: se o domínio já tem um registro SPF, acrescente nele o valor include:... em vez de substituir o registro inteiro, porque o domínio pode enviar e-mail por outros caminhos também. Esse aviso fica sempre visível, não aparece só depois de uma verificação malsucedida.

O DNS não atualiza na hora. Depois de salvar os registros no registrador, eles precisam se propagar pelos servidores de nomes: normalmente minutos, às vezes horas, raramente até um dia. Depende do seu provedor e do TTL. Isso é normal e não está sob nosso controle.

Mesmo assim não é preciso esperar de braços cruzados. A plataforma reverifica domínios pendentes uma vez por hora, mas o cartão do domínio tem o botão «Verify now»: a mesma verificação executada na hora, com o resultado logo na tela. Use assim que salvar os registros: se houver um erro de digitação, você descobre em um segundo e não em uma hora. Pode repetir quantas vezes quiser.

O status do domínio aparece no cartão: «Pending verification», «Verified» ou «Not verified». Enquanto não estiver verificado, o cartão traz também o aviso «Sending from this domain is disabled until it is verified.»

O resultado não é um simples «falhou». Cada um dos três registros tem o seu próprio status na tela — «Passing», «Not passing» ou «Not checked yet» — e a sua própria linha explicando o que está errado.

Para o SPF a tela distingue duas situações, e essa é a distinção que mais importa em todo o processo:

• O domínio não tem registro SPF algum. Publique um, com o valor da tabela acima.
• Existe um registro SPF, mas ele não contém o nosso include. Acrescente o include ao registro existente: não crie um segundo e não o substitua por inteiro. A mesma mensagem trata explicitamente do caso encadeado: se o include só chega até nós pelo registro SPF de outro provedor, não vale, porque cadeias não são resolvidas.

O segundo caso é o momento mais confuso de todo o processo: o registro já está lá, você acabou de relê-lo, e a verificação continua recusando. A mensagem de erro agora diz exatamente o mesmo que o aviso sempre visível ao lado do registro: acrescente o nosso include ao que você já tem.

Se a verificação não passar:

1. Leia qual dos três registros está marcado como «Not passing» e o que diz a explicação dele, e siga por ela.
2. Confirme que os registros estão mesmo publicados — muitos painéis exigem um «aplicar alterações» à parte.
3. Confira o nome do registro quanto ao domínio duplicado (veja acima).
4. Confira que há apenas um registro SPF e que o nosso include está dentro desse mesmo registro.
5. Espere um pouco e verifique de novo: a mudança pode ainda não ter se propagado.

Até a verificação, o envio se recusa a funcionar

Enquanto o domínio não estiver verificado, os e-mails não são enviados. Não é «enviados e caem no spam»: não saem de jeito nenhum, a tentativa falha com erro de domínio não verificado, visível no registro.

Isso é proposital e não é defeito. E-mail de um domínio que não respondeu por si mesmo vira reclamação de spam, e reclamações estragam a reputação de uma infraestrutura de envio compartilhada por todos os clientes da plataforma. Sai mais barato não enviar uma mensagem do que enviá-la e depois passar meio ano saindo de listas de bloqueio. Daí a proibição em vez de um aviso.

Se você vir esse erro, confira os registros DNS e acione a verificação antes de escrever ao suporte. Na esmagadora maioria dos casos é um erro de digitação no nome de um registro.

Descadastros, reclamações e rejeições

Três regras que surpreendem quem não foi avisado antes.

Toda mensagem promocional traz descadastro em um clique. A plataforma adiciona sozinha o link de descadastro no rodapé e os cabeçalhos técnicos com que o cliente de e-mail desenha um botão «Cancelar inscrição» ao lado do endereço do remetente. Não dá para remover: nem por ajuste nem pela diagramação da mensagem. O descadastro vale na hora, sem abrir a mensagem e sem etapa de confirmação. O Gmail e os demais grandes provedores exigem isso de quem envia em massa: uma mensagem sem essa opção vai para o spam com certeza.

O descadastro é definitivo e não dá para desfazer pela interface. Um endereço descadastrado não recebe mais nada deste bot. Não existe botão «restaurar» nem atalho por reimportação de lista: o descadastro nunca é revertido passando por cima da pessoa. Voltar só ela mesma pode, deixando o endereço de novo no seu formulário de inscrição.

Há um caso ainda mais duro: se alguém apertou «Isto é spam» no cliente de e-mail, o endereço é fechado para sempre. Nem uma nova inscrição pelo seu formulário o reabre — porque já sabemos como terminou a tentativa anterior, e escrever para esses endereços é o que destrói mais rápido a reputação de um domínio. Endereços fechados manualmente por exigência legal se comportam igual.

Uma rejeição definitiva suprime o endereço para sempre. Se o servidor do destinatário responder que essa caixa não existe, o endereço é marcado como não entregável e sai dos envios seguintes. Não é um estado temporário: continuar batendo em uma caixa inexistente é o caminho mais rápido para os filtros de spam, levando junto todos os outros endereços.

Rejeições temporárias (caixa cheia, servidor fora do ar por ora) não fecham o endereço: o envio continua.

Por que as aberturas são subestimadas

As estatísticas de e-mail incluem um número de aberturas, e ele é sempre menor do que a realidade. Não é erro de contagem — é o modo como aberturas são medidas.

Uma abertura é registrada quando o cliente de e-mail carrega de um servidor uma imagem minúscula de rastreio ao exibir a mensagem. Clientes modernos não carregam imagens remotas por padrão; e os que carregam (Apple Mail e recursos de privacidade parecidos) fazem isso antecipadamente para todo mundo, inclusive para quem nunca abriu a mensagem. No primeiro caso a abertura se perde; no segundo é creditada a alguém que não estava lá. Não há como contar aberturas com mais precisão — nem para nós nem para ninguém.

Por isso a interface traz uma ressalva ao lado do número: é um limite inferior, não um valor exato. Use-o para comparar mensagens entre si, onde a mesma distorção vale para todas, mas não como resposta a «quantas pessoas leram a mensagem».

Se precisa de uma métrica confiável de engajamento, olhe «Link clicks». Um clique em link é ação real de uma pessoa real; ninguém a executa antecipadamente no lugar dela. «Delivered», «Unsubscribes», «Complaints» e «Bounces» também são contados com exatidão: são relatados por servidores de e-mail, não por uma imagem dentro da mensagem. Tudo isso fica no bloco «Sending stats» da mesma tela Email.

O que vem depois

• Canais — multicanalidade e recursos dos canais.
• Transmissões — envio em massa.
• Análises — onde ver os números.