SPF, DKIM & DMARC para Customer.io.
O Customer.io autentica o seu domínio da maneira tradicional e transparente: sem assistente de um clique e sem delegação de tudo por CNAMEs. Ele entrega a você um pequeno conjunto de registros DNS para publicar em um subdomínio de envio dedicado e depois os verifica. Você adiciona um único registro MX com dois hostnames (o que dá ao Customer.io um Return-Path personalizado no seu domínio para retorno de bounces e feedback de spam), um registro SPF TXT usando o mecanismo compartilhado include:customeriomail.com e um registro DKIM TXT cuja chave o Customer.io gera para você. O DMARC é um quarto registro que você mesmo adiciona, no seu domínio raiz. Tudo isso é gerenciado em Workspace Settings, na seção Email, na página Sending Domains. Assim que SPF e DKIM aparecerem verdes, o Customer.io passa a enviar totalmente como o seu próprio domínio em vez de se apoiar em customeriomail.com.
Por que autenticar o Customer.io?
O Customer.io é uma plataforma de mensagens comportamentais de alto volume — newsletters, campanhas de ciclo de vida, jornadas transacionais — então quase toda conta ultrapassa os limites de remetente em massa que hoje determinam a entrega na caixa de entrada. Desde fevereiro de 2024, o Gmail e o Yahoo passaram a exigir que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) passe por SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a aplicar o mesmo ao correio de alto volume para Outlook.com/Hotmail/Live em 2025. O Customer.io é mais rígido do que a maioria dos ESPs quanto a isso: ele não envia a partir de um domínio até que tanto o SPF quanto o DKIM estejam verificados — um domínio não autenticado simplesmente não consegue enviar, e se qualquer um dos registros quebrar depois, as entregas falham. Há também uma vantagem genuína de alinhamento que vale a pena configurar. Como o Customer.io provisiona um Return-Path personalizado no seu próprio subdomínio de envio (é para isso que serve o registro MX), a verificação de SPF é feita contra o seu domínio, não apenas contra customeriomail.com — então, diferentemente da configuração padrão do Mailchimp ou do Klaviyo, na qual apenas o DKIM pode carregar o DMARC, um domínio Customer.io corretamente configurado consegue passar no DMARC por ambos os mecanismos. Essa é a configuração resiliente que sobrevive ao encaminhamento, e significa que a reputação de envio que você constrói se acumula no seu próprio domínio.
A realidade do SPF para o Customer.io
O Customer.io é um genuíno provedor de "include" — você publica um único registro SPF TXT contendo o mecanismo compartilhado include:customeriomail.com (o registro completo é v=spf1 include:customeriomail.com ~all, terminando em ~all exatamente como o painel do Customer.io mostra). Mas duas verdades específicas do Customer.io mudam onde e como você o adiciona. Primeiro, esse registro não vai no seu domínio raiz — o Customer.io recomenda (e efetivamente espera) um subdomínio de envio dedicado, como mail.yourbrand.com ou email.yourbrand.com, e os registros SPF, DKIM e MX ficam todos ali. Isso é intencional: como o registro MX coloca o Return-Path do Customer.io no seu subdomínio, o remetente do envelope fica no seu domínio, então o SPF de fato ALINHA e pode contribuir para uma aprovação de DMARC — algo que ESPs que detêm o Return-Path não conseguem fazer. Segundo, o include não é plano. Uma consulta ao vivo de customeriomail.com retorna v=spf1 ip4:50.31.36.179 include:sendgrid.net ~all, e sendgrid.net por sua vez aninha include:ab.sendgrid.net — então include:customeriomail.com resolve para cerca de 3 consultas DNS em direção ao limite de 10 do RFC 7208, não a 1 que a maioria dos guias afirma. Mantê-lo em seu próprio subdomínio de envio isola esse custo do orçamento de SPF do seu domínio raiz por completo, que é justamente o objetivo da abordagem por subdomínio. Mantenha exatamente um registro SPF no subdomínio de envio e não mescle outros remetentes nele — esse subdomínio é do Customer.io.
Duas maneiras de configurar
Subdomínio de envio dedicado (recomendado)
- Todos os registros do Customer.io — MX, SPF e DKIM — ficam em um único subdomínio como mail.yourbrand.com
- O Return-Path personalizado baseado em MX permanece no subdomínio, então nunca pode interferir no seu correio de entrada principal
- O aninhado include:customeriomail.com de ~3 consultas fica fora do orçamento de 10 consultas de SPF do seu domínio raiz
- O volume de marketing/ciclo de vida constrói reputação em um subdomínio isolado, protegendo o seu domínio raiz
Autenticar o seu domínio raiz (evite)
- O Customer.io não exige o domínio raiz e não o recomenda
- O registro MX de dois hosts ficaria na sua raiz, competindo com o seu MX de entrada real
- O include aninhado consome ~3 das 10 consultas de SPF da sua raiz junto com o Google Workspace, o M365 e todos os outros remetentes
- Um único envio de marketing barulhento pode arrastar para baixo a reputação de envio de todo o seu domínio
Passo a passo
- 1
Abra a página Sending Domains
Faça login, clique no ícone de Settings e vá para Workspace Settings → Email → Sending Domains. Essa única página cuida de adicionar um domínio, revelar seus registros DNS e verificá-los. SPF, DKIM, MX e o CNAME de rastreamento de links são todos mostrados aqui; o DMARC não é — esse você adiciona separadamente no seu host de DNS.
- 2
Adicione o seu subdomínio de envio
Clique em Add Sending Domain e insira um subdomínio dedicado, não a sua raiz — mail.yourbrand.com ou email.yourbrand.com é a convenção. Enviar a partir de um subdomínio é o que permite ao Customer.io colocar um Return-Path personalizado ali, e mantém o registro MX fora do seu domínio raiz.
- 3
Revele os registros DNS
Na aba Authentication do domínio, o Customer.io exibe os registros exatos a publicar: um registro MX com dois hostnames, um registro SPF TXT, um registro DKIM TXT (a chave é gerada para a sua conta) e — na aba Link Tracking — um CNAME opcional para rastreamento de links com marca. Copie cada Host/Name e Value exatamente como mostrado; o selector do DKIM e os dois hostnames do MX são específicos da sua conta.
- 4
Adicione o registro MX de dois hosts
No seu host de DNS, no subdomínio de envio (host mail), crie o único registro MX com ambos os hostnames que o Customer.io lista, na prioridade que ele especifica. Esse MX existe apenas para dar ao Customer.io um Return-Path/endereço de bounce personalizado no seu domínio — ele não recebe o seu correio normal, e por estar em um subdomínio não pode afetar a entrega de entrada no seu domínio raiz.
- 5
Adicione o registro SPF TXT
No mesmo subdomínio (host mail), adicione um registro TXT: v=spf1 include:customeriomail.com ~all. Mantenha apenas este único registro SPF no subdomínio e não adicione mecanismos de outros remetentes a ele — este subdomínio pertence ao Customer.io. Termine em ~all como o painel mostra.
- 6
Adicione o registro DKIM TXT
Adicione o registro DKIM TXT exatamente como o Customer.io o gerou: o host é um selector sob o seu subdomínio (como selector._domainkey.mail) e o valor é v=DKIM1; k=rsa; p=<chave pública>. Este é um registro TXT que você cola, não um CNAME — então é estático, e o Customer.io não o rotaciona silenciosamente para você.
- 7
Opcional: adicione o CNAME de rastreamento de links
Se você quiser que os links com rastreamento de cliques tenham a marca do seu domínio em vez de customeriomail.com, adicione o CNAME mostrado na aba Link Tracking (um subdomínio de rastreamento apontando para o Customer.io). Não é obrigatório para a autenticação, mas pulá-lo deixa os links rastreados em customeriomail.com, o que enfraquece o alinhamento de marca.
- 8
Publique o seu registro DMARC na raiz
O Customer.io nunca cria o DMARC. Adicione um registro TXT em _dmarc no seu domínio RAIZ (não no subdomínio de envio): v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. p=none é apenas de monitoramento, então nada muda enquanto você confirma o alinhamento; o subdomínio de envio herda essa política automaticamente.
- 9
Clique em Verify domain
De volta à aba Authentication, clique em Verify (os checkmarks cinzas ficam verdes quando os registros resolvem). A propagação costuma levar minutos, mas pode levar até 24–48 horas. Você precisa de checkmarks verdes especificamente em SPF e DKIM — o Customer.io exige rigidamente ambos antes de enviar a partir do domínio; os registros MX e de rastreamento de links dão suporte ao Return-Path e à marca, mas SPF+DKIM são o portão.
- 10
Envie um teste e leia os cabeçalhos
Envie uma campanha ou broadcast a partir de um endereço From no subdomínio autenticado, abra no Gmail e escolha ⋮ → Show original. Confirme SPF: PASS (envelope no seu subdomínio), DKIM: PASS com d=yourbrand.com (não customeriomail.com) e DMARC: PASS. Depois passe o subdomínio por uma verificação de saúde do domínio para confirmar que todos os registros resolvem.
Registros a adicionar
O Customer.io 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 |
|---|---|---|
| MX | mxa.customeriomail.comPrimeiro de dois hostnames em um único registro MX — o Return-Path personalizado do Customer.io para retorno de bounces/feedback de spam, no subdomínio de envio. Ilustrativo: copie os dois hostnames exatos e a prioridade da aba Authentication. | |
| MX | mxb.customeriomail.comSegundo hostname no mesmo registro MX. Ilustrativo — use o valor e a prioridade exatos que o Customer.io mostra. | |
| TXT | v=spf1 include:customeriomail.com ~allSPF no subdomínio de envio — um registro SPF por host. include:customeriomail.com aninha para ~3 consultas (via sendgrid.net → ab.sendgrid.net); termina em ~all como o painel mostra. | |
| TXT | selector._domainkey.mail | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from Customer.io)DKIM TXT — o Customer.io gera o par de chaves e mostra o valor completo para colar. Ilustrativo: o selector e a chave reais são por conta, na aba Authentication. É um TXT estático, não um CNAME delegado. |
| CNAME | customeriomail.comRastreamento de links com marca opcional, em um subdomínio de rastreamento — copie o host/target exato da aba Link Tracking. Não é obrigatório para a verificação de SPF/DKIM. | |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.comVocê mesmo adiciona isto no domínio RAIZ — o Customer.io nunca o cria. Um por domínio; o subdomínio de envio o herda. Comece em p=none. |
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 Customer.io consome desse limite.
O Customer.io usa 3 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM do Customer.io é um registro TXT que você publica, não um CNAME delegado. Quando você adiciona um domínio de envio, o Customer.io gera um par de chaves DKIM para ele e mostra a você um único registro DKIM TXT: o host é um selector sob o seu subdomínio de envio (como selector._domainkey.mail.yourbrand.com) e o valor é v=DKIM1; k=rsa; p=<chave pública>. Você cola esse TXT exatamente como mostrado; o Customer.io guarda a chave privada correspondente e assina o seu correio de saída com ela como d=yourbrand.com — então a assinatura alinha ao seu domínio e pode carregar uma aprovação de DMARC. Duas coisas distinguem isso do DKIM delegado por CNAME usado pelo SendGrid ou pelo Microsoft 365. Primeiro, por ser um registro TXT estático em vez de um CNAME que aponta de volta para o provedor, o Customer.io não rotaciona a chave silenciosamente nos bastidores — se você regenerar ou rotacionar a chave no painel, precisa republicar você mesmo o novo valor TXT, ou a assinatura quebra. Segundo, o DKIM aqui não é opcional nem de melhor esforço: o Customer.io exige que tanto o SPF quanto o DKIM sejam verificados antes de enviar a partir do domínio, e se o DKIM TXT estiver ausente, truncado ou corrompido pelo seu painel de DNS, o domínio volta para não verificado e as entregas param. Publique o registro no subdomínio de envio exatamente como o Customer.io o formata, aguarde a propagação e depois clique em Verify.
DMARC
O DMARC é um registro de política separado que o Customer.io não cria para você — você mesmo o publica, e ele vai no seu domínio RAIZ, não no subdomínio de envio. Adicione um registro TXT em _dmarc.yourbrand.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. p=none é apenas de monitoramento: não muda nada na entrega enquanto os receptores enviam a você relatórios agregados (rua) para que você confirme que o Customer.io está passando no SPF e no DKIM alinhados ao seu domínio. É aqui que o design de subdomínio do Customer.io compensa — o DMARC usa alinhamento relaxado por padrão (aspf=r, adkim=r), então a assinatura DKIM em mail.yourbrand.com e o SPF/Return-Path nesse subdomínio ambos alinham ao seu domínio organizacional yourbrand.com, e o seu correio do Customer.io passa no DMARC por ambos os mecanismos. Mantenha exatamente um registro _dmarc na raiz; o seu subdomínio de envio herda a política do domínio pai automaticamente, então não adicione um segundo registro _dmarc no subdomínio (adicionar um ali é um erro comum que pode quebrar a herança). Acompanhe os relatórios rua por uma ou duas semanas até que toda fonte legítima — o Customer.io mais os seus outros remetentes — esteja autenticando, e então endureça a política para p=quarantine e, por fim, p=reject.
Confirme que funcionou de verdade
Não confie apenas nos checkmarks do painel — confirme em uma mensagem real. Na aba Authentication do Customer.io você quer checkmarks verdes em SPF e DKIM (os dois registros dos quais o Customer.io condiciona o envio); o MX dá suporte ao Return-Path e o CNAME dá suporte aos links com marca. Depois envie um broadcast ou campanha a partir de um endereço From no subdomínio autenticado, abra no Gmail e escolha ⋮ → Show original: você procura por SPF: PASS com o envelope/Return-Path no seu subdomínio, DKIM: PASS assinado por d=yourbrand.com (a falha reveladora é d=customeriomail.com, indicando que o DKIM personalizado não foi aplicado) e DMARC: PASS. Faça uma verificação pontual dos registros brutos com dig TXT mail.yourbrand.com, dig TXT selector._domainkey.mail.yourbrand.com e dig TXT _dmarc.yourbrand.com. Por fim, passe o subdomínio de envio pela verificação de saúde do domínio da Qualisend para confirmar que o SPF (e suas consultas aninhadas), o DKIM TXT, o MX e o seu DMARC raiz resolvem todos corretamente e, assim que os relatórios agregados começarem a chegar, jogue um deles no analisador de relatórios DMARC — o Customer.io deve aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Quebra a autenticação
O Customer.io exige rigidamente que TANTO o SPF quanto o DKIM sejam verificados antes de enviar a partir de um domínio — a maioria dos ESPs envia com autenticação parcial, o Customer.io não. Se qualquer um dos registros estiver ausente ou corrompido, o domínio aparece como não verificado e as entregas falham, não apenas ficam sem marca.
- Configuração de DNS
Publique tudo em um SUBDOMÍNIO DE ENVIO dedicado (mail.yourbrand.com), nunca na sua raiz. O registro MX de dois hosts em particular deve ficar no subdomínio — coloque-o na sua raiz e você redirecionaria o tratamento de bounces de todo o seu domínio e arriscaria o seu correio de entrada real.
- Cobertura
O registro MX não serve para receber o seu e-mail normal — ele existe apenas para dar ao Customer.io um Return-Path personalizado no seu domínio para retorno de bounces e feedback de spam. Não se assuste achando que está 'mudando o seu MX'; ele está em um subdomínio que nenhuma caixa de correio humana usa.
- Configuração de DNS
include:customeriomail.com NÃO é uma consulta DNS — uma consulta ao vivo mostra que ele aninha include:sendgrid.net, que aninha include:ab.sendgrid.net, então resolve para cerca de 3 consultas. Em um subdomínio dedicado isso fica isolado; se você algum dia o incorporar em um SPF raiz compartilhado, ele compete com todos os outros remetentes contra o limite de 10 consultas.
- Configuração de DNS
O DKIM aqui é um registro TXT estático, não um CNAME de rotação automática. O Customer.io não o rotaciona para você — se você regenerar a chave no painel, precisa republicar o novo valor TXT ou a assinatura quebra.
- Configuração de DNS
Duplicação do campo de host em subdomínios: muitos registradores acrescentam automaticamente a sua zona, então digitar mail.yourbrand.com produz mail.yourbrand.com.yourbrand.com. Digite apenas o rótulo que o painel espera (mail, selector._domainkey.mail) se ele adiciona o domínio para você.
- Cobertura
Coloque o DMARC na RAIZ (_dmarc.yourbrand.com), não no subdomínio de envio. O subdomínio herda a política raiz via alinhamento relaxado; adicionar um segundo _dmarc no subdomínio é um erro comum que pode quebrar a herança.
- Configuração de DNS
Pular o CNAME de rastreamento de links é aceitável para a autenticação, mas os seus links com rastreamento de cliques permanecem em customeriomail.com em vez do seu domínio — o que enfraquece o alinhamento de marca e pode parecer menos confiável para destinatários e filtros.
Monte seu registro SPF
O Customer.io não precisa de um include: de SPF no seu domínio raiz — use o gerador para montar um único registro limpo para os seus outros remetentes, e mantenha tudo em uma só linha.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
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).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- 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 Customer.io — 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.