SPF, DKIM & DMARC para Front.
O Front (front.com) é uma plataforma de caixa de entrada compartilhada e comunicação com clientes, não um provedor de hospedagem de e-mail — então "enviar em nome do seu domínio" pelo Front tem um significado específico. Quando você conecta um canal SMTP personalizado, o Front retransmite seu e-mail de saída pelo SendGrid, sua infraestrutura de e-mail subjacente (contas mais antigas retransmitiam pelo Mandrill, e é por isso que você talvez tenha visto uma tag legada "via mandrillapp.com"). Até você autenticar esse caminho, os destinatários veem uma nota "via sendgrid.net" no seu endereço De e seu e-mail tem uma probabilidade muito maior de cair no spam. As configurações de Deliverability do Front entregam três registros DNS — um MX, um SPF (como um TXT) e um DKIM (como um TXT) — que você adiciona a um subdomínio de envio dedicado front-mail. Como esses registros ficam no subdomínio em vez do seu domínio raiz, eles autorizam o SendGrid a enviar em seu nome, removem a tag "via" e alinham seu e-mail ao seu domínio para o DMARC, tudo isso sem tocar no seu SPF existente nem mudar para onde o seu e-mail de entrada é entregue.
Por que autenticar o Front?
Autenticar o domínio de envio do seu Front decide se as suas respostas vão chegar à caixa de entrada. Desde fevereiro de 2024, o Gmail e o Yahoo passaram a exigir que todo remetente em massa (mais ou menos 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a aplicar a mesma exigência para remetentes de alto volume em 2025 — e as equipes de suporte e sucesso que vivem no Front rotineiramente atingem esses volumes. Até você adicionar os registros, o Front envia seu e-mail pela infraestrutura compartilhada do SendGrid: os destinatários veem a tag "via sendgrid.net", seu endereço De não se alinha ao seu domínio, o DMARC não consegue passar pelo SPF e sua reputação de envio fica misturada com todos os outros inquilinos não autenticados dessa plataforma. Autenticar corrige tudo isso de uma vez — o SendGrid assina com uma chave DKIM publicada no seu subdomínio front-mail (para que a assinatura se alinhe ao seu domínio), o Return-Path do envelope fica nesse mesmo subdomínio (para que o SPF se alinhe no modo relaxado), a tag "via" desaparece, o DMARC passa e a reputação que você constrói fica acumulada no seu próprio domínio em vez do pool compartilhado.
A realidade do SPF para o Front
O Front é uma configuração de delegação de subdomínio, não um provedor de "include" — NÃO existe um include:sendgrid.net para você colar no seu domínio raiz. Em vez disso, todo o caminho autenticado fica em um subdomínio de envio dedicado que o Front rotula como front-mail. Esse subdomínio recebe três registros diretamente do painel Deliverability do Front: um registro MX apontando para o host de e-mail do SendGrid (mx.sendgrid.net) para que o SendGrid possa processar bounces, um registro SPF TXT (v=spf1 include:sendgrid.net ~all) restrito ao subdomínio e uma chave pública DKIM em um seletor sob esse mesmo subdomínio. O registro SPF do seu domínio organizacional é deixado exatamente como está — o include do Front fica em front-mail.yourdomain.com, então ele não custa nada do orçamento de 10 consultas DNS do seu SPF raiz. O DMARC ainda passa, mas observe o detalhe específico do Front: como TANTO o Return-Path do envelope QUANTO a chave DKIM ficam no subdomínio front-mail, tanto o SPF quanto o DKIM se alinham ao seu domínio organizacional no modo relaxado (o subdomínio compartilha o seu domínio registrável) — e nenhum dos dois se alinha no modo estrito. O relaxado é o padrão do DMARC, então o Front passa de imediato; apenas não force o alinhamento estrito (aspf=s ou adkim=s) para este domínio. Por fim, isso só se aplica a canais SMTP do Front; se o seu canal do Front for uma caixa de entrada conectada do Gmail ou do Microsoft 365, o Front envia pelos servidores desse próprio provedor e você autentica no Google/Microsoft — nenhum dos registros front-mail se aplica.
Duas maneiras de configurar
Canal SMTP do Front — adicione os registros do SendGrid (este guia)
- Aplica-se quando o seu canal é um canal SMTP personalizado — o Front retransmite seu e-mail de saída pelo SendGrid e você precisa autenticá-lo.
- Adicione MX + SPF (TXT) + DKIM (TXT) a um subdomínio de envio dedicado front-mail, copiados do painel Deliverability do Front.
- Os três registros ficam no subdomínio, então o SPF do seu domínio raiz permanece intocado — zero das suas 10 consultas SPF consumidas.
- Até o Front mostrar os registros como Verified, o e-mail sai 'via sendgrid.net' no pool compartilhado e corre risco de cair na pasta de spam.
Canal conectado do Gmail / Microsoft 365 — autentique lá em vez disso
- Aplica-se quando você adicionou sua caixa de entrada ao Front pela integração do Google ou do Microsoft 365 — o Front envia por esse provedor, não pelo SendGrid.
- A autenticação é herdada do SPF, DKIM e DMARC do seu Google Workspace ou Microsoft 365 — configure-os nesse provedor.
- Não há subdomínio front-mail, nem MX para mx.sendgrid.net, e nenhum dos registros SPF/DKIM do SendGrid se aplica.
- A tag 'via sendgrid.net' nunca aparece porque o SendGrid não está no caminho de envio.
Passo a passo
- 1
Confirme que o canal é um canal SMTP
Estes registros só se aplicam a canais SMTP do Front (e-mail retransmitido pelo SendGrid). Se o seu canal for uma caixa de entrada conectada do Gmail ou do Microsoft 365, o Front envia por esse provedor — pare aqui e autentique no Google/Microsoft. Verifique o tipo de canal em Settings → Channels.
- 2
Abra as configurações de Deliverability
Para canais de toda a empresa, clique na engrenagem Settings → Company settings → Security na barra lateral → a aba Deliverability. Esta página só aparece para administradores da empresa quando existe pelo menos um canal SMTP compartilhado. Para o canal de um colega de equipe individual, abra Settings → o canal SMTP do colega → aba Settings → a seção 'Improve delivery rates - SPF / DKIM'.
- 3
Selecione o domínio de envio
Em Domains, escolha o domínio de onde você envia. Qualquer domínio sem SPF/DKIM exibe um ícone de aviso amarelo. O Front então mostra o Name e o Value de três registros a adicionar: um MX, um SPF (TXT) e um DKIM (TXT). Mantenha este painel aberto para copiar — o seletor, o host e os valores de chave exatos são únicos para a sua conta.
- 4
Adicione o registro MX no subdomínio front-mail
Crie um registro MX: Host/Name = o rótulo de subdomínio que o Front mostra (por exemplo, front-mail), Value/Target = o host de e-mail do SendGrid (por exemplo, mx.sendgrid.net), Priority = conforme mostrado (o Front comumente usa 10). Este é um NOVO MX no subdomínio para o tratamento de bounces do SendGrid — ele NÃO altera o seu MX principal (host @) nem para onde o seu e-mail de entrada é entregue.
- 5
Adicione o registro SPF (TXT)
Crie um registro TXT: Host/Name = front-mail, Value = exatamente o que o Front mostra (por exemplo, v=spf1 include:sendgrid.net ~all). Este SPF é restrito apenas ao subdomínio de envio — NÃO adicione include:sendgrid.net ao registro SPF do seu domínio raiz.
- 6
Adicione o registro DKIM (TXT)
Crie um registro TXT com o host do seletor que o Front mostra (por exemplo, s1._domainkey.front-mail) e cole o longo valor da chave pública do Front exatamente, sem espaços ou quebras de linha adicionais. O Front usa o whitelabel clássico do SendGrid, então esta é uma única chave TXT estática, não os CNAMEs que rotacionam automaticamente da autenticação de domínio moderna do SendGrid.
- 7
Insira os hosts apenas como rótulos e não toque nos registros existentes
Digite apenas o rótulo (front-mail, s1._domainkey.front-mail) — a maioria dos registradores acrescenta o seu domínio automaticamente, e inserir o front-mail.yourdomain.com completo produz um nome duplicado que não resolve. Adicione apenas estes três NOVOS registros; não edite nem apague nenhum registro DNS existente, o que pode quebrar a entrega.
- 8
Publique sua política DMARC (se você ainda não tiver uma)
No seu domínio raiz, adicione um registro TXT em _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Mantenha exatamente um registro _dmarc para o domínio inteiro. Deixe o alinhamento no seu padrão relaxado — o subdomínio front-mail do Front carrega tanto o SPF quanto o DKIM no modo relaxado, então não configure aspf=s ou adkim=s, pois qualquer um deles quebraria a autenticação do Front.
- 9
Clique em 'Check DNS settings' no Front
Volte ao painel Deliverability do Front e clique em Check DNS settings — isso dispara uma verificação através do SendGrid. Quando os registros resolvem, cada um vira Verified e o ícone de aviso amarelo some do canal. A propagação de DNS geralmente leva minutos, mas pode levar até 24–48 horas.
- 10
Envie um teste real e confirme o alinhamento
Envie uma mensagem para você mesmo pelo canal do Front, abra-a no Gmail e use ⋮ → Show original. Confirme SPF: PASS, DKIM: PASS signed-by front-mail.yourdomain.com, DMARC: PASS, e que a tag 'via sendgrid.net' sumiu da linha De.
Registros a adicionar
O Front 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 | front-mail | mx.sendgrid.netReturn-Path do subdomínio de envio — o host de bounces do SendGrid, prioridade conforme mostrada pelo Front (comumente 10). O subdomínio e o host exatos vêm do painel Deliverability do Front. Este NÃO é o seu MX principal e não afeta o e-mail de entrada. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF apenas para o subdomínio de envio — nunca adicionado ao seu domínio raiz, então ele custa 0 das 10 consultas do seu SPF raiz. Copie o valor exato do Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Chave pública DKIM (única TXT estática). O Front/SendGrid fornece o seletor e a chave exatos — o host e o valor são únicos para a sua conta; este é apenas ilustrativo. Como a chave fica sob front-mail, o d= da assinatura é o subdomínio e se alinha ao seu domínio no modo relaxado. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSua política DMARC — uma por domínio raiz. O Front autentica inteiramente através do subdomínio front-mail, então mantenha o alinhamento relaxado (o padrão); estrito (aspf=s ou adkim=s) quebra o Front. |
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 Front consome desse limite.
A configuração recomendada do Front adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O DKIM do Front é um único registro TXT estático de chave pública que o Front gera através do SendGrid e mostra a você no painel Deliverability. Você o publica no seletor do subdomínio de envio (algo como s1._domainkey.front-mail.yourdomain.com); o SendGrid guarda a chave privada correspondente e assina cada mensagem que o Front retransmite. Como a chave fica sob front-mail, a assinatura DKIM carrega d=front-mail.yourdomain.com, que se alinha ao seu domínio organizacional no modo relaxado — o padrão do DMARC — do mesmo jeito que o Return-Path do SPF. Ela não se alinha no modo estrito, então não configure adkim=s para este domínio. Duas coisas tornam o DKIM do Front diferente da autenticação de domínio moderna do SendGrid. Primeiro, é uma chave TXT estática, não um CNAME que rotaciona automaticamente — o Front usa o whitelabel clássico do SendGrid, então você cola a chave uma vez e ela não rotaciona sozinha (nada é delegado para re-resolver, mas também nada rotaciona as chaves por você). Segundo, como é uma chave pública completa em um valor TXT, ela pode ultrapassar o limite de 255 caracteres de uma única string; a maioria dos painéis DNS a armazena automaticamente como um único registro dividido em partes, mas se depois um verificador reportar a chave como inválida, um valor adulterado ou truncado costuma ser a causa — cole-a de novo exatamente como o Front mostra. O seletor atribuído pelo SendGrid não vai colidir com os seletores DKIM do seu Google (google) ou da Microsoft (selector1/selector2), então o DKIM do Front convive com o do seu provedor de caixa de entrada. O DKIM ainda é o mais resistente a encaminhamento dos seus dois sinais — ele sobrevive ao encaminhamento de mensagens onde o SPF quebra — mas, para o alinhamento DMARC, ele usa o mesmo modo relaxado do SPF, então mantenha o alinhamento da sua política em relaxado.
DMARC
O DMARC é um registro de política separado que você publica no seu domínio raiz — o Front não o cria para você, embora sua documentação de deliverability oriente você pela interação. Adicione um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. O p=none é apenas de monitoramento, então ele não vai afetar a entrega enquanto você confirma que o e-mail do Front autentica. O detalhe específico do Front é o alinhamento: como o SendGrid usa o subdomínio front-mail TANTO para o Return-Path do envelope QUANTO para o domínio d= do DKIM, o e-mail do Front se alinha ao seu domínio organizacional no modo RELAXADO tanto no SPF quanto no DKIM — e no modo ESTRITO em nenhum dos dois. O relaxado é o padrão do DMARC, então uma política padrão passa o Front de imediato; você não precisa adicionar nada. O problema só aparece se o seu DMARC existente forçar o alinhamento estrito: aspf=s quebra o alinhamento SPF do Front e adkim=s quebra o alinhamento DKIM, e estrito em ambos reprova o Front por completo. Mantenha o alinhamento relaxado (você pode deixá-lo explícito com aspf=r; adkim=r). Mantenha exatamente um registro _dmarc para o domínio inteiro, não importa quantos remetentes (Front, seu provedor de caixa de entrada, ferramentas de marketing) você use — nunca adicione um segundo registro DMARC para o Front. Assim que os relatórios agregados confirmarem que o Front/SendGrid está autenticando corretamente, aperte de p=none para p=quarantine e, por fim, p=reject.
Confirme que funcionou de verdade
Não confie apenas no selo Verified do Front — confirme em uma mensagem real. Depois que o Check DNS settings mostrar os registros como Verified, envie um e-mail para você mesmo pelo canal do Front, abra-o no Gmail e escolha ⋮ → Show original. Você quer ver SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS com signed-by: front-mail.yourdomain.com e DMARC: PASS — e a tag 'via sendgrid.net' deve ter sumido da linha De. Você pode verificar os registros brutos com dig MX front-mail.yourdomain.com (espere mx.sendgrid.net), dig TXT front-mail.yourdomain.com (espere a linha v=spf1 include:sendgrid.net), dig TXT s1._domainkey.front-mail.yourdomain.com (espere a chave DKIM) e dig TXT _dmarc.yourdomain.com. Depois, passe seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que cada registro resolve e que o seu SPF raiz continua 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 Front deve aparecer como uma fonte alinhada e aprovada (a infraestrutura do SendGrid assinando em nome do seu domínio).
Pegadinhas comuns
- Cobertura
O registro MX que o Front pede NÃO é o seu MX principal. Ele fica no subdomínio front-mail e só permite que o SendGrid processe bounces do e-mail de saída do Front — ele não redireciona a sua caixa de entrada nem muda para onde o e-mail de entrada é entregue. O seu MX existente no host @ permanece intocado.
- Cobertura
Insira os hosts apenas como o rótulo — front-mail, s1._domainkey.front-mail — não o front-mail.yourdomain.com completo. A maioria dos registradores acrescenta o seu domínio automaticamente, e o nome duplicado (front-mail.yourdomain.com.yourdomain.com) não resolve, então o Check DNS settings falha.
- Cobertura
Adicione apenas três NOVOS registros. O Front avisa explicitamente para não editar nem apagar registros DNS existentes durante este processo — modificar o seu SPF, MX ou DKIM atual pode quebrar a entrega.
- Configuração de DNS
Não adicione include:sendgrid.net ao seu SPF RAIZ. O Front restringe o SPF ao subdomínio front-mail, então um include na raiz é redundante, consome desnecessariamente uma das suas 10 consultas SPF e não é o que o SendGrid verifica para o Front.
- Cobertura
O alinhamento estrito do DMARC quebra o Front. Tanto o Return-Path do envelope quanto a chave DKIM ficam no subdomínio front-mail, então o SPF e o DKIM se alinham ao seu domínio apenas no modo relaxado. Configurar aspf=s quebra o alinhamento SPF do Front e adkim=s quebra o alinhamento DKIM — estrito em ambos reprova o Front por completo. O relaxado é o padrão, então deixe o alinhamento como está.
- Cobertura
Canais conectados do Gmail / Microsoft 365 não usam estes registros de jeito nenhum. Se o Front envia pela sua caixa de entrada do Google ou da Microsoft em vez de um canal SMTP, não há subdomínio front-mail nem tag via — autentique nesse provedor.
- Configuração de DNS
Registros MX e TXT não podem ser proxied, então no Cloudflare não há etapa de nuvem laranja/nuvem cinza aqui (diferente da autenticação de domínio do SendGrid baseada em CNAME). Apenas garanta que você os criou como MX e TXT, não como algum outro tipo.
- Cobertura
Cada domínio e canal de envio SMTP é autenticado separadamente. Configurar um domínio não cobre os outros — o painel Deliverability sinaliza qualquer domínio que ainda esteja sem registros com um ícone de aviso amarelo.
Monte seu registro SPF
O Front 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.
Fontes de envio
Pesquise cada plataforma pela qual você envia e-mail e marque-a.
Pesquise sua plataforma de e-mail acima ou .
Os servidores próprios deste domínio
Autorize o próprio domínio, se ele envia e-mail diretamente (não por uma plataforma acima).
Outros remetentes e IPs
Qualquer coisa fora da lista — o host SPF de outro provedor ou endereços IP específicos.
Nós adicionamos o prefixo include: — informe o nome de host que seu provedor documenta.
Política para todos os demais
O que os destinatários devem fazer com e-mails de qualquer servidor não listado acima (o mecanismo all).
Ainda não há remetentes, então cada mensagem seria tratada pela política ~all. Adicione na etapa 1 as plataformas pelas quais você envia.
- Publique-o como um registro TXT no seu domínio raiz — host @ (o domínio puro), valor a string completa acima.
- Mantenha apenas um registro SPF por domínio. Mescle toda fonte de envio nesta única linha — um segundo registro TXT começando com v=spf1 invalida os dois.
- Fique em 10 consultas DNS ou menos. Cada include:, a e mx conta, e um include pode disparar mais consultas dentro de si — ip4: e ip6: são gratuitos.
Autenticação publicada? O próximo passo é enviar para uma lista limpa e verificada.
Verificar uma listaSPF do Front — 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.