SPF, DKIM & DMARC para SocketLabs.
O SocketLabs autentica o seu domínio dentro do On-Demand Portal, e essa configuração é genuinamente diferente da de um provedor que só pede para "colar esta linha de SPF". Toda mensagem que você envia já sai da plataforma autenticada por SPF e assinada por DKIM — mas, por padrão, essa autenticação pertence ao próprio domínio do SocketLabs, o email-od.com, e é por isso que o e-mail não configurado carrega a observação "via email-od.com" e não consegue alinhar ao seu domínio para o DMARC. Para fazer o SocketLabs enviar como o seu domínio, você adiciona dois registros em Configuration → Domain Management: um CNAME de Custom Bounce Domain (que move o return-path para um subdomínio seu, de modo que o SPF alinhe) e um registro DKIM (um único CNAME, ou um seletor TXT gerado, para que o DKIM assine como o seu domínio). Uma política DMARC à parte completa o conjunto. A virada importante: o caminho de SPF recomendado pelo SocketLabs é o CNAME do bounce domain, e não adicionar include:email-od.com ao SPF da sua raiz.
Por que autenticar o SocketLabs?
Autenticar o SocketLabs não é burocracia — isso decide se o seu e-mail chega ou não à caixa de entrada. Desde fevereiro de 2024, o Gmail e o Yahoo exigem que todo remetente em massa (cerca de 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a aplicar o mesmo em 2025 para e-mails de alto volume enviados ao Outlook.com/Hotmail. O detalhe específico do SocketLabs: de fábrica, ele autentica o SPF contra o seu bounce domain email-od.com e assina o DKIM com d=email-od.com. Ambas as verificações PASSAM no email-od.com, mas nenhuma alinha ao seu domínio de From, então o DMARC falha no alinhamento, os destinatários veem a marca "via email-od.com" e a reputação de envio que você constrói fica misturada com a de todos os outros remetentes não autenticados do SocketLabs, em vez de se acumular no seu próprio domínio. Configurar um custom bounce domain (o SPF alinha) somado ao custom DKIM (o DKIM alinha) fecha essa lacuna em dois registros — o DMARC então passa nos dois mecanismos, a marca "via" desaparece e o seu domínio passa a ser dono da própria reputação.
A realidade do SPF para o SocketLabs
Tecnicamente, o SocketLabs é um provedor de "include" — o include:email-od.com existe e é verificável por DNS (ele resolve para um único registro plano, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, apenas com faixas ip4 e sem includes aninhados, de modo que custaria exatamente UMA das suas 10 consultas de SPF) — mas ele NÃO é o caminho de SPF recomendado pelo SocketLabs e, sozinho, não produz alinhamento de DMARC. Eis o motivo: o SPF é avaliado contra o domínio do return-path (bounce/envelope), e não contra o seu endereço From visível. Por padrão, o return-path do SocketLabs é o email-od.com, então a verificação de SPF atinge o registro do email-od.com e o SPF da sua raiz nunca é consultado para o e-mail do SocketLabs. O SocketLabs implementa o SPF, em vez disso, por meio de um Custom Bounce Domain: você publica um CNAME em um subdomínio do seu próprio domínio — por exemplo, email.yourdomain.com CNAME tracking.socketlabs.com — e, como o próprio tracking.socketlabs.com publica v=spf1 include:email-od.com ~all, mover o return-path para o seu subdomínio ao mesmo tempo faz o SPF PASSAR (ele herda os IPs em lista branca do SocketLabs através desse CNAME) E o ALINHA ao seu domínio organizacional, tudo sem editar o seu registro SPF de raiz existente. É por isso que a configuração recomendada adiciona zero consultas ao SPF da sua raiz. O mecanismo include:email-od.com é uma opção de reforço redundante: você pode adicioná-lo ao SPF da sua raiz (ele também autoriza ali os IPs de envio, ao custo de uma consulta), mas ele não confere alinhamento por si só e não é obrigatório uma vez que o custom bounce domain esteja no lugar. Como sempre, mantenha exatamente UM registro TXT de SPF por domínio — se você de fato adicionar o include, funda-o na sua única linha v=spf1 em vez de publicar um segundo registro.
Duas maneiras de configurar
CNAME de Custom Bounce Domain (recomendado)
- Move o return-path para um subdomínio do seu domínio, de modo que o SPF ao mesmo tempo passa e ALINHA para o DMARC
- Adiciona zero consultas de DNS ao SPF da sua raiz — não há nada para fundir nem achatar
- O CNAME para tracking.socketlabs.com herda automaticamente os IPs em lista branca do SocketLabs; você nunca precisa reeditá-lo quando os IPs mudam
- O mesmo CNAME de subdomínio pode ser reaproveitado para white-label dos seus links de rastreamento de engajamento de abertura/clique
include:email-od.com no SPF da sua raiz (opcional)
- Você mesmo adiciona v=spf1 include:email-od.com ~all ao SPF da sua raiz
- Custa uma das suas 10 consultas de DNS de SPF (o email-od.com é um registro plano só com ip4, então exatamente uma)
- Autoriza os IPs de envio sob o seu domínio, mas NÃO alinha o SPF por si só — o return-path continua sendo email-od.com a menos que você também configure o CNAME de bounce
- Um complemento, na melhor das hipóteses, nunca um substituto para o custom bounce domain
Passo a passo
- 1
Abra o Domain Management
Faça login no On-Demand Portal, clique em Configuration no menu à esquerda, escolha Domain Management e então selecione o domínio de envio que você quer autenticar (ou clique para adicioná-lo). Tudo o que vem a seguir fica no card deste domínio.
- 2
Inicie o Custom Bounce Domain e o SPF
No domínio, abra "Custom Bounce Domain and SPF Authentication." O SocketLabs gera um registro CNAME em um subdomínio do seu domínio (algo como email.yourdomain.com ou bounce.yourdomain.com) cujo destino é tracking.socketlabs.com. É assim que o SocketLabs implementa o SPF — ele move o seu return-path para o seu próprio domínio, de modo que o SPF alinhe.
- 3
Publique o CNAME do bounce domain
No seu provedor de DNS, crie um CNAME: Host = o subdomínio que o SocketLabs mostra (por exemplo, email), Value = tracking.socketlabs.com. Não o altere para um registro TXT ou A e não mexa no seu registro SPF de raiz existente — é este CNAME que carrega o SPF.
- 4
Escolha o seu método de DKIM
De volta ao domínio, abra a seção DKIM. Você tem duas opções: o recurso CNAME DKIM Signing (o mais fácil — o SocketLabs é dono da chave e a rotaciona por você) ou o método Advanced/TXT via DKIM Key Generator (você escolhe um seletor e publica um registro TXT de chave pública). Escolha um; você não precisa dos dois.
- 5
Publique o registro DKIM
Para o método CNAME, adicione um CNAME: Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. Para o método TXT, adicione um registro TXT em Host = <selector>._domainkey (o seletor que você escolheu no gerador, alfanumérico e com menos de 10 caracteres) com o valor v=DKIM1; k=rsa; p=… que o SocketLabs exibe. De qualquer forma, o DKIM agora vai assinar como o seu domínio.
- 6
Adicione o registro DMARC
O SocketLabs não cria o DMARC para você. Adicione um registro TXT em Host = _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é somente monitoramento, então nada na entrega muda enquanto você confirma o alinhamento — você vai apertá-lo depois.
- 7
Verifique no portal
Volte ao Domain Management e clique em "Verify Bounce" para o custom bounce domain e em "Verify" para o DKIM. O status do bounce domain deve ficar como authenticated e o DKIM deve ficar como active. A propagação costuma levar minutos, mas o SocketLabs pode levar de 24 a 48 horas para confirmar os registros.
- 8
Envie um teste e leia os cabeçalhos
Envie uma mensagem de um endereço no domínio configurado para uma conta do Gmail, abra-a e escolha ⋮ → Show original. Você quer SPF: PASS mostrando o seu subdomínio de bounce (não email-od.com), DKIM: PASS com d=yourdomain.com e DMARC: PASS. A observação "via email-od.com" deve ter sumido.
Registros a adicionar
O SocketLabs 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 |
|---|---|---|
| CNAME | tracking.socketlabs.comCustom Bounce Domain — é isto que carrega e ALINHA o SPF. O rótulo do subdomínio (email/bounce/…) é o que o SocketLabs atribuir; reaproveite-o também para o white-label do rastreamento de engajamento. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (recomendado, o mais fácil) — o SocketLabs é dono da chave e a rotaciona. O seletor é dkim; d= passa a ser o seu domínio, de modo que o DKIM alinha. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternativa ao método CNAME — use o caminho Advanced/TXT DKIM apenas se você quiser controlar a chave. O seletor (aqui sl2026) é escolha sua: alfanumérico, com menos de 10 caracteres. Valor ilustrativo — o gerador usa por padrão uma chave de 2048 bits, gerada por conta. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê mesmo adiciona este — o SocketLabs nunca o cria. Um por domínio; comece em p=none e depois aperte para quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allOPCIONAL, apenas reforço redundante. Não é necessário se você configurar o custom bounce domain, e não alinha o SPF por si só. Custa 1 consulta; funda-o na sua única linha de SPF de raiz se você o usar. |
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 SocketLabs consome desse limite.
A configuração recomendada do SocketLabs adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O SocketLabs assina toda mensagem por padrão, mas com d=email-od.com, que não alinha ao seu domínio — então o custom DKIM é o que faz o DKIM realmente funcionar para você, e há duas maneiras de configurá-lo. O recurso CNAME DKIM Signing é o mais fácil: você publica um único CNAME, Host = dkim._domainkey.yourdomain.com apontando para dkim._domainkey.email-od.com, e, por ser um CNAME (e não uma chave que você cola), o SocketLabs mantém o controle das chaves privada e pública e as rotaciona por você — você nunca mais edita o DNS. O seletor é simplesmente dkim e, uma vez verificado, o SocketLabs assina o seu e-mail com d=yourdomain.com, de modo que o DKIM alinha. O método Advanced/TXT dá mais controle: em Domain Management, você executa o DKIM Key Generator, escolhe um seletor (alfanumérico, com menos de 10 caracteres, por exemplo sl2026) e o SocketLabs gera o par de chaves — guardando a chave privada na sua conta e entregando a você a chave pública para publicar como um registro TXT em <selector>._domainkey.yourdomain.com no formato v=DKIM1; k=rsa; p=…. O gerador usa por padrão uma chave de 2048 bits (existe uma opção de 1024 bits, mas deixe em 2048 — a chave mais forte é o padrão moderno e o SocketLabs recomenda não reduzi-la). Há também uma variante de "traga o seu próprio registro TXT", em que você fornece uma chave privada gerada externamente. Um requisito rígido do caminho TXT: o portal não deixará você salvar até conseguir resolver a sua chave pública publicada no DNS e, uma vez salva, a chave pública não é mais exibida no portal, então publique-a primeiro. Uma ressalva que se aplica a AMBOS os métodos: a sua assinatura de custom DKIM só é aplicada às mensagens cujo endereço From (o Purported Responsible Address) corresponde exatamente ao domínio configurado — e-mail enviado a partir de qualquer outro domínio de From recai para a assinatura padrão email-od.com e não alinha, então configure o DKIM para cada domínio a partir do qual você envia.
DMARC
O DMARC é um registro TXT de política à parte que o SocketLabs não cria — você mesmo o publica no seu provedor de DNS. Adicione um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é somente monitoramento: não muda nada na entrega enquanto você acompanha os relatórios agregados (rua) para confirmar que o e-mail do SocketLabs está passando em SPF e DKIM alinhados ao seu domínio. Como o custom bounce domain dá o alinhamento de SPF e o custom DKIM dá o alinhamento de DKIM, um domínio SocketLabs corretamente configurado passa no DMARC pelos DOIS mecanismos — a configuração resiliente que sobrevive ao encaminhamento, já que um encaminhamento que quebra o SPF ainda deixa uma assinatura DKIM alinhada. Acompanhe os relatórios por uma ou duas semanas, certifique-se de que todo remetente legítimo (o SocketLabs mais quaisquer outras ferramentas no domínio) está autenticando e então aperte a política para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para todo o domínio organizacional, não importa quantos remetentes você use; nunca adicione um segundo registro DMARC só para o SocketLabs.
Confirme que funcionou de verdade
Não confie apenas nos selos "authenticated" e "active" do portal — confirme em uma mensagem real. Envie um teste de um endereço no domínio configurado para uma caixa do Gmail, abra-a e escolha ⋮ → Show original: você quer SPF: PASS mostrando o seu subdomínio de bounce (por exemplo, email.yourdomain.com, NÃO email-od.com), DKIM: PASS com d=yourdomain.com e DMARC: PASS. O sintoma revelador de falha é o SPF/DKIM ainda mostrando email-od.com, o que significa que o bounce domain e/ou o custom DKIM ainda não estão no ar, ou que você enviou de um domínio de From que não está configurado. Você pode conferir os registros brutos com dig CNAME email.yourdomain.com (deve resolver para tracking.socketlabs.com), dig CNAME dkim._domainkey.yourdomain.com (ou dig TXT <selector>._domainkey.yourdomain.com para o método TXT) e dig TXT _dmarc.yourdomain.com. Depois, passe o seu domínio pela verificação de saúde do domínio da Qualisend para confirmar que todos os registros resolvem de forma limpa e, assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o SocketLabs deve aparecer como uma fonte alinhada e totalmente aprovada.
Pegadinhas comuns
- Cobertura
A marca padrão "via email-od.com" significa que você ainda não está alinhado: até você configurar TANTO um custom bounce domain QUANTO um custom DKIM, o SocketLabs autentica como email-od.com, então SPF e DKIM passam, mas o DMARC falha no alinhamento. A marca só desaparece quando ambos apontarem para o seu domínio.
- Configuração de DNS
Adicionar include:email-od.com ao SPF da sua raiz NÃO é a solução por si só. Ele autoriza os IPs de envio, mas o return-path continua sendo email-od.com a menos que você publique o CNAME do bounce domain — e é o CNAME de bounce, não o include, que de fato alinha o SPF. Não pule o CNAME achando que o include cobre isso.
- Cobertura
O custom DKIM só assina e-mail cujo endereço From corresponde exatamente ao domínio configurado (o Purported Responsible Address). Envie de um domínio de From diferente e o SocketLabs recai silenciosamente para a assinatura padrão email-od.com, então o DKIM não vai alinhar — configure cada domínio de envio.
- Configuração de DNS
Alguns provedores de DNS não aceitam um underscore no host de um CNAME, o que bloqueia o método de CNAME dkim._domainkey. Se o seu rejeitar, use o caminho Advanced/TXT DKIM (DKIM Key Generator) em vez dele — o registro TXT de chave pública contorna a limitação de underscore no CNAME.
- Configuração de DNS
O proxy da Cloudflare quebra ambos os CNAMEs: defina o CNAME do bounce domain e o CNAME do DKIM como "DNS only" (nuvem cinza). Um CNAME com proxy de nuvem laranja não vai resolver para tracking.socketlabs.com / email-od.com e a verificação falha.
- Cobertura
Subcontas autenticam separadamente. O modelo de subconta do SocketLabs faz com que cada subconta precise do seu próprio custom bounce domain e da sua própria autenticação DKIM — autenticar a conta master não cobre as subcontas.
- Configuração de DNS
A verificação pode atrasar de 24 a 48 horas. A propagação costuma levar minutos, mas o SocketLabs reverifica o CNAME/TXT com atraso, então "authenticated"/"active" pode não mudar de imediato mesmo quando o seu DNS já está correto — verifique com o Show original em vez de esperar pelo selo.
- Configuração de DNS
Duplicação do campo Host: registradores que auto-anexam o seu domínio transformam dkim._domainkey.yourdomain.com em dkim._domainkey.yourdomain.com.yourdomain.com. Insira apenas o rótulo (email, dkim._domainkey, <selector>._domainkey) se o seu painel adicionar o domínio por você.
- Quebra a autenticação
Mantenha exatamente um registro SPF e um DMARC por domínio. Se você adicionar o include:email-od.com opcional, funda-o na sua única linha v=spf1 — dois registros SPF é um PermError, e um segundo registro _dmarc também.
Monte seu registro SPF
O SocketLabs 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 SocketLabs — 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.