SPF, DKIM & DMARC para Zendesk.
O Zendesk envia suas respostas de tickets, notificações e automações a partir do seu endereço de suporte (support@yourdomain.com), então autenticá-lo é o que impede que essas mensagens caiam na caixa de spam dos clientes ou recebam o rótulo "via zendesk.com". A autenticação é dividida entre o seu provedor de DNS e o Admin Center do Zendesk. O SPF é um include compartilhado genuíno — você adiciona include:mail.zendesk.com ao único registro SPF do seu domínio — e o DKIM são dois registros CNAME de "assinatura digital" que você publica e depois ativa em Channels → Talk and email → Email. O DMARC é um terceiro registro, separado, que o Zendesk nunca cria para você. Um pré-requisito importa: a autenticação por DNS só se aplica quando você envia a partir de um domínio de e-mail externo seu; endereços no domínio padrão yourbrand.zendesk.com já são assinados pelo Zendesk e não precisam de nada.
Por que autenticar o Zendesk?
Autenticar o Zendesk não é burocracia — é o que decide se suas respostas de suporte chegam aos clientes ou não. Uma fila de suporte movimentada facilmente ultrapassa o limite de 5.000 mensagens por dia que, desde fevereiro de 2024, obriga os remetentes em massa do Gmail e do Yahoo a passar em SPF, DKIM e DMARC com alinhamento; a Microsoft começou a aplicar regras semelhantes para remetentes de alto volume em 2025. Até você autenticar um domínio de suporte externo, o Zendesk envia respostas que só são fracamente atribuíveis a você: os destinatários veem a nota "via zendesk.com", seu endereço From não é criptograficamente seu, o DMARC não pode passar, e qualquer reclamação de spam se acumula contra a infraestrutura compartilhada do Zendesk em vez de construir a sua própria reputação. Há também uma peculiaridade específica do Zendesk que torna o DKIM inegociável aqui: o SPF do Zendesk nunca alinha ao seu domínio (ele devolve o e-mail pelo seu próprio Return-Path em zendesk.com), então, diferente do Google Workspace ou do Microsoft 365, você não pode se apoiar no SPF para carregar o DMARC — o DKIM é o único mecanismo que alinha. Configure o include do SPF, os dois CNAMEs de DKIM e uma política DMARC, e suas respostas saem assinadas como seu próprio domínio, o rótulo "via" desaparece, o DMARC passa, e a reputação que você conquista é sua.
A realidade do SPF para o Zendesk
O Zendesk é um provedor de "include" genuíno — você adiciona um mecanismo compartilhado real, include:mail.zendesk.com, ao único registro SPF TXT do seu domínio, e o Zendesk recomenda oficialmente o registro completo v=spf1 include:mail.zendesk.com -all (recomenda o hard fail -all para a proteção mais forte contra spoofing). Verificado contra o DNS ao vivo, mail.zendesk.com resolve para um registro plano contendo apenas faixas ip4: e seu próprio ~all, sem includes aninhados, portanto custa exatamente UMA das suas 10 consultas de DNS do SPF. Aqui está a parte que quase todo tutorial ignora, e é a coisa mais importante de entender sobre o SPF do Zendesk: ele passa, mas NÃO ALINHA. Por padrão, o Zendesk envia e-mail de saída com o Return-Path do envelope (o MAIL FROM contra o qual os receptores de fato rodam o SPF) em um dos domínios de bounce zendesk.com do próprio Zendesk, e não no seu domínio — e o Zendesk não oferece mecanismo para mover esse Return-Path para o seu domínio. Assim, o SPF autentica contra a infraestrutura do Zendesk e passa, mas como o domínio verificado é um subdomínio zendesk.com em vez do seu domínio From, ele não está alinhado, e o DMARC só conta o SPF quando ele alinha. Isso significa que include:mail.zendesk.com não pode carregar sozinho um pass de DMARC. Ainda vale a pena adicioná-lo — o Zendesk recomenda, alguns receptores fazem uma verificação de SPF não alinhada no domínio From visível, e ele evita bounces relacionados a SPF e o envio para spam — mas o mecanismo que de fato faz o DMARC passar para o Zendesk é o alinhamento de DKIM, não o SPF. Mantenha exatamente um registro SPF no domínio (mescle o include se você já envia via Google Workspace, Microsoft 365, etc.), mantenha include:mail.zendesk.com como um mecanismo de primeira camada nesse registro, e comece com ~all em vez de -all até que todos os outros remetentes legítimos estejam enumerados.
Duas maneiras de configurar
Domínio de e-mail externo — include de SPF + DKIM (recomendado)
- As respostas vêm da sua própria marca (support@yourdomain.com), não de um endereço zendesk.com
- O DKIM assina como d=yourdomain.com, então o DMARC passa por alinhamento de DKIM
- Adicione include:mail.zendesk.com mais os dois CNAMEs de DKIM zendesk1/zendesk2 ao seu DNS
- Custa uma consulta de DNS do SPF; as chaves rotacionam automaticamente assim que os CNAMEs estão no ar
Endereço padrão yourbrand.zendesk.com — nada para configurar
- O Zendesk já autentica e assina seu próprio domínio zendesk.com
- Nenhum registro SPF, DKIM ou DMARC para você publicar
- Mas os clientes veem um endereço From genérico zendesk.com em vez da sua marca
- Sem controle sobre a reputação — você compartilha o domínio do Zendesk com todos os outros inquilinos
Passo a passo
- 1
Adicione e verifique seu endereço de suporte externo
No Admin Center, abra Channels → Talk and email → Email e adicione um endereço de suporte no seu próprio domínio (ex.: support@yourdomain.com), depois verifique-o — seja encaminhando o e-mail recebido dessa caixa para o seu endereço yourbrand.zendesk.com, seja conectando o Google Workspace / Microsoft 365. Isso importa porque a autenticação por DNS (include de SPF + CNAMEs de DKIM) só se aplica a domínios externos; endereços no domínio padrão yourbrand.zendesk.com já são assinados pelo Zendesk.
- 2
Adicione ou mescle o include do SPF
No seu domínio raiz, adicione um registro TXT com v=spf1 include:mail.zendesk.com -all (o Zendesk recomenda o hard fail -all). Se já existir um registro SPF, não publique um segundo — mescle include:mail.zendesk.com na linha v=spf1 existente, mantendo-o como um mecanismo de primeira camada, e use ~all até que todos os outros remetentes estejam listados.
- 3
Adicione os dois registros CNAME de DKIM
Crie dois registros CNAME: o host zendesk1._domainkey.yourdomain.com apontando para zendesk1._domainkey.zendesk.com, e o host zendesk2._domainkey.yourdomain.com apontando para zendesk2._domainkey.zendesk.com. Há dois porque o Zendesk rotaciona as chaves de DKIM por segurança. Estes precisam ser registros CNAME, não TXT — o Zendesk guarda as chaves por trás desses hostnames.
- 4
Publique um registro DMARC
Adicione um registro TXT em _dmarc.yourdomain.com com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento — não muda nada na entrega enquanto você confirma que o Zendesk está passando no DKIM alinhado ao seu domínio. Mantenha apenas um registro _dmarc para todo o domínio.
- 5
Aguarde a propagação dos registros
Dê ao DNS algumas horas (ocasionalmente até um dia) para propagar antes da próxima etapa. NÃO ative a assinatura DKIM no Zendesk ainda — ligá-la antes de os CNAMEs resolverem é a causa isolada mais comum de falhas de entrega do Zendesk.
- 6
Ative a assinatura DKIM (deve ser a etapa final)
De volta ao Admin Center → Channels → Talk and email → Email, encontre a configuração de DKIM / assinatura digital e selecione Custom domain for DKIM, depois clique em Save. O Zendesk é explícito de que isso deve ser a última coisa que você faz: ativá-la antes de os registros CNAME do seu domínio estarem no ar causará falhas de entrega.
- 7
Envie uma resposta de teste e leia os cabeçalhos
Responda a um ticket de teste para que o Zendesk envie uma mensagem de saída real, abra-a no Gmail e use ⋮ → Show original. Confirme DKIM: PASS assinado por yourdomain.com (seletor zendesk1 ou zendesk2) e DMARC: PASS. O SPF vai mostrar pass, mas não alinhado (Return-Path em um domínio zendesk.com) — isso é esperado e está tudo bem; o DKIM é quem carrega o DMARC.
- 8
Repita para cada marca e domínio de suporte
Cada endereço de suporte externo em um domínio diferente precisa do seu próprio include de SPF, dos seus próprios CNAMEs de DKIM zendesk1/zendesk2, do seu próprio registro DMARC e da opção Custom domain for DKIM ativada. Autenticar um domínio não cobre os outros.
Registros a adicionar
O Zendesk gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:mail.zendesk.com -allSPF raiz — mantenha um registro SPF e mescle include:mail.zendesk.com nele. Passa, mas NÃO alinha (o Return-Path do Zendesk é um domínio zendesk.com), então não carrega o DMARC sozinho. Custa 1 consulta de DNS. |
| CNAME | zendesk1._domainkey | zendesk1._domainkey.zendesk.comChave DKIM 1. Este alvo é o mesmo para todos os clientes do Zendesk (não é um valor por conta); apenas o domínio do host é seu. O Zendesk rotaciona a chave por trás dele automaticamente. |
| CNAME | zendesk2._domainkey | zendesk2._domainkey.zendesk.comChave DKIM 2 — ambas são obrigatórias porque o Zendesk rotaciona as chaves. Também é um alvo compartilhado, idêntico para todos os clientes. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUm registro DMARC por domínio. É este que carrega o pass de DMARC do Zendesk — via alinhamento de DKIM. Comece em p=none, depois endureça para quarantine/reject assim que o DKIM for confirmado. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Zendesk consome desse limite.
O Zendesk usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM é onde o e-mail do Zendesk de fato conquista seu pass de DMARC, então é o registro que mais importa. Você publica dois registros CNAME — zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.com e zendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.com — e depois ativa a assinatura no Admin Center. Algumas coisas específicas do Zendesk que você precisa saber. Primeiro, estes são CNAMEs, não chaves TXT que você cola: o Zendesk guarda as chaves privadas e publica as chaves públicas por trás de zendesk1._domainkey.zendesk.com e zendesk2._domainkey.zendesk.com, então ele pode rotacioná-las (mais ou menos trimestralmente) sem que você jamais precise tocar no DNS de novo — a consulta ao CNAME sempre resolve para a chave atual. Segundo, ambos os hostnames apontam para os mesmos alvos compartilhados em zendesk.com para todos os clientes; não há valor por conta, então não tente personalizar o alvo nem colar um ID de conta nele. A razão de haver dois seletores (zendesk1 e zendesk2) é exatamente para tornar essa rotação transparente — um fica ativo enquanto o outro fica preparado. Terceiro, o DKIM só funciona para um domínio de e-mail externo; você não pode assinar com DKIM, como seu próprio domínio, e-mail enviado de um endereço yourbrand.zendesk.com. Por fim, publicar os CNAMEs não faz nada até você ativar a assinatura: vá a Admin Center → Channels → Talk and email → Email e selecione Custom domain for DKIM, depois Save — mas só depois que os CNAMEs tiverem propagado, porque ativar cedo demais causa falhas de entrega. Uma vez no ar, o Zendesk assina com d=yourdomain.com, que alinha ao seu domínio From e passa no DMARC.
DMARC
O DMARC é um registro de política separado que o Zendesk nunca cria para você — você mesmo o publica como um registro TXT em _dmarc.yourdomain.com, começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega, mas pede aos receptores que enviem por e-mail relatórios agregados para que você confirme que o e-mail do Zendesk está passando. A ressalva específica do Zendesk é que seu pass de DMARC depende inteiramente do DKIM, porque o SPF do Zendesk nunca alinha (seu Return-Path fica em um domínio de bounce zendesk.com). Então, antes de endurecer a política, use os relatórios rua para garantir que o Zendesk está aparecendo como alinhado por DKIM e passando — se você pular para p=quarantine ou p=reject enquanto o DKIM está mal configurado, o SPF não pode cobrir por ele e suas respostas de suporte começarão a ser colocadas em quarentena ou rejeitadas. Acompanhe os relatórios por uma ou duas semanas, confirme que o Zendesk e todos os outros remetentes legítimos alinham, depois passe para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para todo o domínio, não importa quantos remetentes você use; nunca adicione um segundo só para o Zendesk.
Confirme que funcionou de verdade
Não confie apenas no status do Admin Center — confirme em uma mensagem real. Responda a um ticket de teste para que o Zendesk envie um e-mail de saída a partir do seu endereço de suporte externo, abra-o no Gmail e escolha ⋮ → Show original. Você quer ver DKIM: PASS com signed-by: yourdomain.com (seletor zendesk1 ou zendesk2) e DMARC: PASS. O SPF vai marcar pass, mas não alinhado — o mailed-by/Return-Path será um domínio zendesk.com — e isso é esperado para o Zendesk, não uma má configuração, então não persiga o alinhamento de SPF. Você pode verificar por amostragem os registros brutos com dig CNAME zendesk1._domainkey.yourdomain.com (deve resolver até zendesk.com) e dig TXT _dmarc.yourdomain.com. Depois rode seu domínio pela verificação de saúde do domínio da Qualisend para confirmar que cada registro resolve e que seu SPF permanece abaixo do limite de 10 consultas, e assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o Zendesk deve aparecer como uma fonte alinhada por DKIM e passando, mesmo que seu SPF esteja não alinhado.
Pegadinhas comuns
- Configuração de DNS
Ative o DKIM por último. O Zendesk é explícito de que selecionar Custom domain for DKIM antes de seus CNAMEs zendesk1/zendesk2 terem propagado causará falhas de entrega — publique e deixe o DNS assentar (algumas horas a um dia) primeiro, depois vire a chave.
- Cobertura
O SPF não vai alinhar, por design. O Zendesk devolve o e-mail de saída pelo seu próprio Return-Path zendesk.com, então include:mail.zendesk.com faz a verificação bruta de SPF passar, mas nunca alinha ao seu domínio e não pode carregar o DMARC sozinho. O DKIM é o que alinha — não perca tempo tentando forçar o alinhamento de SPF; o Zendesk não oferece forma de fazê-lo.
- Cobertura
O DKIM só funciona em um domínio de e-mail externo. E-mail enviado de um endereço yourbrand.zendesk.com não pode ser assinado como seu domínio — você precisa adicionar e verificar um endereço de suporte no seu próprio domínio primeiro (support@yourdomain.com).
- Configuração de DNS
Os alvos dos CNAMEs de DKIM são compartilhados, não únicos. Ambos apontam para zendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.com para todos os clientes do Zendesk — não tente adicionar um ID de conta ou 'personalizar' o alvo, e não os publique como registros TXT.
- Quebra a autenticação
Mantenha exatamente um registro SPF e mantenha o include na primeira camada. Se você já envia via Google Workspace, Microsoft 365, etc., mescle include:mail.zendesk.com nessa única linha v=spf1 — dois registros SPF é um PermError, e enterrar o include dentro de uma consulta aninhada pode impedir que ele resolva na primeira camada.
- Cobertura
-all vs ~all. O Zendesk recomenda o hard fail -all, mas se seu SPF ainda não lista todos os remetentes legítimos, -all vai reprovar em hard fail esse outro e-mail. Use ~all até ter enumerado todos os remetentes, depois endureça para -all.
- Configuração de DNS
Duplicação do campo de host. Muitos registradores anexam automaticamente seu domínio, então inserir zendesk1._domainkey.yourdomain.com produz zendesk1._domainkey.yourdomain.com.yourdomain.com. Insira apenas o rótulo zendesk1._domainkey se o painel adicionar o domínio para você.
- Configuração de DNS
Várias marcas e domínios precisam, cada um, do conjunto completo. Todo domínio de suporte externo precisa do seu próprio include de SPF, dos seus próprios dois CNAMEs de DKIM, do seu próprio registro DMARC e da opção Custom domain for DKIM ativada — a configuração de um domínio não cobre os outros.
Monte seu registro SPF
O Zendesk já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF do Zendesk — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.