{"id":18449,"date":"2026-03-27T11:51:13","date_gmt":"2026-03-27T10:51:13","guid":{"rendered":"https:\/\/webhosting.de\/mx-records-priorisierung-email-routing-hosting-mailflow\/"},"modified":"2026-03-27T11:51:13","modified_gmt":"2026-03-27T10:51:13","slug":"registos-mx-priorizacao-encaminhamento-de-correio-eletronico-alojamento-mailflow","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mx-records-priorisierung-email-routing-hosting-mailflow\/","title":{"rendered":"Registos MX e defini\u00e7\u00e3o de prioridades: explica\u00e7\u00e3o do encaminhamento de correio eletr\u00f3nico no alojamento"},"content":{"rendered":"<p>Os registos MX controlam quais os servidores de correio que recebem mensagens de entrada para um dom\u00ednio e utilizam prioridades para determinar a ordem em que as liga\u00e7\u00f5es s\u00e3o estabelecidas. Vou mostrar-lhe como <strong>Registos MX<\/strong> corretamente, estabele\u00e7a prioridades de forma sensata e planeie todo o percurso de entrega do correio eletr\u00f3nico para que o seu alojamento de correio eletr\u00f3nico funcione de forma fi\u00e1vel.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Para uma orienta\u00e7\u00e3o r\u00e1pida, resumirei brevemente os aspectos mais importantes do encaminhamento de registos mx e destacarei os t\u00f3picos principais com os quais deve estar familiarizado para o alojamento seguro de correio eletr\u00f3nico. Vou manter a lista curta e incluir apenas pontos que podem ser aplicados imediatamente. Com base na experi\u00eancia pr\u00e1tica, dou prioridade \u00e0s defini\u00e7\u00f5es que evitam o tempo de inatividade. Encontrar\u00e1 os detalhes relevantes para cada palavra-chave mais adiante neste artigo. Para configura\u00e7\u00f5es mais aprofundadas, forne\u00e7o dicas adicionais e obst\u00e1culos t\u00edpicos ao longo do caminho, para que possa <strong>Erro<\/strong> desde o in\u00edcio.<\/p>\n<ul>\n  <li><strong>Prioridade<\/strong> determina a ordem: n\u00famero mais pequeno = primeiro<\/li>\n  <li><strong>Redund\u00e2ncia<\/strong> Seguro com v\u00e1rios registos MX<\/li>\n  <li><strong>Caminho de entrega<\/strong> Compreens\u00e3o do DNS para a caixa de correio<\/li>\n  <li><strong>TTL<\/strong> e tempos de propaga\u00e7\u00e3o<\/li>\n  <li><strong>SPF\/DKIM<\/strong> combinar para uma melhor entrega<\/li>\n<\/ul>\n<p>Em seguida, aprofundo a tecnologia sec\u00e7\u00e3o por sec\u00e7\u00e3o e traduzo os conceitos em configura\u00e7\u00f5es compreens\u00edveis. Ao faz\u00ea-lo, concentro-me em <strong>Pr\u00e1tica<\/strong> e passos de a\u00e7\u00e3o claros.<\/p>\n\n<h2>Como os registos MX controlam o encaminhamento<\/h2>\n<p>Um registo MX indica aos servidores de envio qual o anfitri\u00e3o que aceita mensagens de correio eletr\u00f3nico do seu dom\u00ednio, direcionando assim os <strong>Encaminhamento<\/strong> a entrega. Defino pelo menos duas entradas MX por dom\u00ednio, para que outro anfitri\u00e3o possa ser contactado imediatamente se o primeiro falhar. Para os subdom\u00ednios, defino os meus pr\u00f3prios destinos MX a pedido, se forem necess\u00e1rias caixas de correio separadas ou gateways especiais. A zona DNS cont\u00e9m o nome, o anfitri\u00e3o de destino, a prioridade e um valor TTL bem doseado. Para come\u00e7ar, o compacto <a href=\"https:\/\/webhosting.de\/pt\/email-dominio-proprio-registos-mx-ferramentas-configuracao-instrucoes-alojamento\/\">Manual MX-Records<\/a>, que se utiliza para criar e verificar entradas de forma limpa; fa\u00e7o refer\u00eancia a isto quando se planeiam os primeiros testes.<\/p>\n<p>Ao enviar, a esta\u00e7\u00e3o remota de envio consulta primeiro o DNS para obter registos MX e, em seguida, estabelece uma liga\u00e7\u00e3o SMTP ao anfitri\u00e3o preferido. Tamb\u00e9m presto aten\u00e7\u00e3o aos registos A ou AAAA do anfitri\u00e3o de destino, porque um nome de destino incorreto impede qualquer fluxo de correio. Os valores TTL curtos aceleram as mudan\u00e7as, enquanto os valores mais longos reduzem a carga dos pedidos; selecciono o valor adequado em fun\u00e7\u00e3o do projeto. <strong>Compromisso<\/strong>. Isto significa que as suas caixas de correio permanecem acess\u00edveis, mesmo que troque de destino ou mude de gateway. \u00c9 sempre crucial que os pr\u00f3prios anfitri\u00f5es MX possam ser resolvidos corretamente e estejam acess\u00edveis via SMTP.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email-routing-serverraum-5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreens\u00e3o das prioridades: n\u00famero reduzido, pondera\u00e7\u00e3o elevada<\/h2>\n<p>A prioridade MX \u00e9 um n\u00famero inteiro, e o n\u00famero mais pequeno ganha a prioridade MX. <strong>direito de passagem<\/strong>. Se definir dois anfitri\u00f5es com a mesma prioridade, eles partilham o tr\u00e1fego de entrada alternadamente, por assim dizer. Eu gosto de usar isso para balanceamento de carga com sistemas equivalentes. Para um failover claro, no entanto, eu planeio um n\u00edvel mais alto, por exemplo 10 para o prim\u00e1rio e 20 para o backup. Desta forma, o sistema de backup entra em a\u00e7\u00e3o de forma fi\u00e1vel assim que o primeiro anfitri\u00e3o n\u00e3o responde ou apresenta um erro.<\/p>\n<p>A mesma prioridade \u00e9 adequada para clusters de peering, valores diferentes para alta disponibilidade com uma sequ\u00eancia clara. Ap\u00f3s cada altera\u00e7\u00e3o, confirmo atrav\u00e9s de um teste de envio e registo qual o MX que foi efetivamente aceite. Isto permite-me reconhecer as defini\u00e7\u00f5es incorrectas numa fase inicial e corrigi-las. <strong>Sequ\u00eancia<\/strong>, antes que os utilizadores passem por per\u00edodos de inatividade. Estabelecer prioridades de forma sensata reduz os pedidos de apoio e mant\u00e9m a entrega consistente. Tenha tamb\u00e9m em aten\u00e7\u00e3o que algumas gateways t\u00eam limites ou regras anti-abuso que podem afetar as liga\u00e7\u00f5es.<\/p>\n\n<h2>Caminho de entrega de correio eletr\u00f3nico passo a passo<\/h2>\n<p>Ao enviar, o servidor de envio resolve o dom\u00ednio do destinat\u00e1rio, l\u00ea os registos MX e estabelece a liga\u00e7\u00e3o SMTP ao anfitri\u00e3o preferido; chamo a este caminho o <strong>Caminho de entrega<\/strong>. Ap\u00f3s um aperto de m\u00e3o SMTP bem sucedido, o servidor de destino aceita a mensagem, guarda-a e transfere-a internamente para o sistema de caixa de correio. O destinat\u00e1rio acede ent\u00e3o \u00e0 mensagem atrav\u00e9s de IMAP ou POP3, enquanto o servidor aplica filtros de spam e verifica\u00e7\u00f5es de v\u00edrus em paralelo. Se um MX falhar, o remetente tenta automaticamente o n\u00edvel de prioridade seguinte. Isto significa que a entrega permanece dispon\u00edvel mesmo em caso de manuten\u00e7\u00e3o ou de problemas de localiza\u00e7\u00e3o.<\/p>\n<p>Verifico este processo com ferramentas como o dig\/host e um pequeno teste SMTP via Telnet ou OpenSSL. Estas verifica\u00e7\u00f5es mostram em segundos se o DNS e a cadeia MX est\u00e3o a funcionar corretamente. Sem uma resolu\u00e7\u00e3o correta do anfitri\u00e3o ou com um erro de digita\u00e7\u00e3o no nome de destino, o envio termina imediatamente com um erro. \u00c9 por isso que primeiro estabele\u00e7o uma base de DNS est\u00e1vel e depois treino recorrentemente <strong>Cheques<\/strong> para as equipas operacionais. Isto significa que o caminho desde o DNS at\u00e9 \u00e0 caixa de correio permanece transparente e rastre\u00e1vel.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/emailroutingbesprechung3452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00f5es t\u00edpicas e estrat\u00e9gias de failover<\/h2>\n<p>Para muitos projectos, utilizo dois ou tr\u00eas anfitri\u00f5es MX com a mesma classifica\u00e7\u00e3o e adiciono um anfitri\u00e3o de backup puro com uma classifica\u00e7\u00e3o superior. <strong>Prioridade<\/strong>. Isto combina a distribui\u00e7\u00e3o da carga e um n\u00edvel de recurso claro. Em configura\u00e7\u00f5es mais pequenas, um prim\u00e1rio e um de reserva s\u00e3o muitas vezes suficientes, pelo que ambos os locais devem utilizar liga\u00e7\u00f5es de rede separadas. Prefiro nomes de anfitri\u00f5es falantes como mx01.domain.tld, mx02.domain.tld e mxb.domain.tld para poder reconhecer imediatamente nos registos qual o anfitri\u00e3o que aceitou uma mensagem.<\/p>\n<p>O quadro seguinte resume os padr\u00f5es comuns e ajuda a estruturar o seu pr\u00f3prio planeamento. Organizo os exemplos por fun\u00e7\u00e3o e acrescento notas sobre a empresa. Isto permite-lhe transferir rapidamente a estrutura para o seu <strong>Alojamento de correio<\/strong> e minimizar as tentativas falhadas.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Prioridade<\/th>\n      <th>Nome do anfitri\u00e3o<\/th>\n      <th>Papel<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>10<\/td>\n      <td>mx01.example.de<\/td>\n      <td>Prim\u00e1rio<\/td>\n      <td>Objetivo principal: elevada disponibilidade, monitoriza\u00e7\u00e3o ativa<\/td>\n    <\/tr>\n    <tr>\n      <td>10<\/td>\n      <td>mx02.example.de<\/td>\n      <td>Prim\u00e1rio (de igual n\u00edvel)<\/td>\n      <td>Partilha a carga com mx01; pol\u00edticas id\u00eanticas<\/td>\n    <\/tr>\n    <tr>\n      <td>20<\/td>\n      <td>mxbackup.example.de<\/td>\n      <td>C\u00f3pia de seguran\u00e7a<\/td>\n      <td>Liga-se em caso de avaria; reten\u00e7\u00e3o limitada<\/td>\n    <\/tr>\n    <tr>\n      <td>30<\/td>\n      <td>filter.example.de<\/td>\n      <td>Porta de entrada<\/td>\n      <td>Apenas se estiver ligado a montante; caso contr\u00e1rio, omitir<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Testo cada configura\u00e7\u00e3o com entregas reais e comparo os registos de todos os anfitri\u00f5es. S\u00f3 quando todos os caminhos est\u00e3o a funcionar corretamente \u00e9 que reduzo o plano de testes a algumas verifica\u00e7\u00f5es regulares. <strong>Cheques<\/strong>. Deste modo, as opera\u00e7\u00f5es s\u00e3o reduzidas e os tempos de resposta a falhas s\u00e3o curtos. Para locais com elevados volumes de correio, tamb\u00e9m vale a pena planear a capacidade com limites de alarme claros. Isto compensa especialmente durante os picos de carga.<\/p>\n\n<h2>TTL, caching e propaga\u00e7\u00e3o sem surpresas<\/h2>\n<p>O valor TTL determina por quanto tempo os resolvedores armazenam em cache suas respostas MX; eu geralmente come\u00e7o com <strong>3600s<\/strong>, porque isto torna as altera\u00e7\u00f5es vis\u00edveis mais rapidamente. TTLs mais curtos s\u00e3o adequados antes de altera\u00e7\u00f5es planeadas, TTLs mais longos protegem a carga do DNS em fases calmas. Ap\u00f3s uma altera\u00e7\u00e3o, dependendo do fornecedor e do tempo de execu\u00e7\u00e3o da cache, \u00e9 preciso um pouco de paci\u00eancia para que todos os remetentes vejam o novo MX. Por isso, eu planeio as altera\u00e7\u00f5es fora dos tempos centrais e tenho um rollback pronto. Se planearmos com sobriedade, poupamos turnos noturnos e per\u00edodos de inatividade \u00f3bvios.<\/p>\n<p>Tamb\u00e9m \u00e9 importante que os TTLs de todos os registos envolvidos coincidam: MX, A\/AAAA e, se aplic\u00e1vel, destinos CNAME. Tempos de execu\u00e7\u00e3o diferentes podem criar temporariamente estados mistos. Com janelas TTL controladas e marcos claros, mantenho a mudan\u00e7a clara. Isso inclui uma verifica\u00e7\u00e3o final com v\u00e1rios resolvedores independentes. Esta rotina traz <strong>Migra\u00e7\u00f5es<\/strong> Calma no processo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/mx-records-email-priority-ef76.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Encaminhamento de registos MX com o Microsoft 365 e o Google Workspace<\/h2>\n<p>Se mudar para o Microsoft 365 ou o Google Workspace, substituo completamente os alvos MX existentes pelas especifica\u00e7\u00f5es do <strong>servi\u00e7o<\/strong>. As constela\u00e7\u00f5es mistas com caixas de correio locais e suites externas conduzem rapidamente a loops. Nesses cen\u00e1rios, removo o encaminhamento sup\u00e9rfluo e verifico novamente as regras de transporte. Tamb\u00e9m verifico se as entradas SPF incluem os novos IPs de envio. Esta \u00e9 a \u00fanica forma de evitar rejei\u00e7\u00f5es por parte de sistemas de destinat\u00e1rios restritivos.<\/p>\n<p>Ap\u00f3s a mudan\u00e7a de MX, testo sempre uma expedi\u00e7\u00e3o a partir do exterior e do interior para verificar as rotas de linha e de retorno. Os registos na suite e nas gateways mostram claramente qual o MX que entrou em vigor. Em seguida, adapto as pol\u00edticas de spam e malware \u00e0 nova plataforma. Isto garante a consist\u00eancia <strong>Pol\u00edticas<\/strong> em todas as caixas de correio. Quem fizer uma migra\u00e7\u00e3o limpa n\u00e3o ter\u00e1 surpresas desagrad\u00e1veis no dia seguinte.<\/p>\n\n<h2>Pr\u00e1tica: Configurar o MX nos pain\u00e9is de alojamento<\/h2>\n<p>Na maioria dos pain\u00e9is, abro a gest\u00e3o do DNS, selecciono o tipo MX, defino o nome do anfitri\u00e3o, o destino e a prioridade, defino o TTL e guardo o <strong>Altera\u00e7\u00e3o<\/strong>. Em seguida, verifico a apresenta\u00e7\u00e3o no ficheiro de zona e acciono manualmente uma verifica\u00e7\u00e3o dig\/host. Em seguida, testo o envio a partir de uma conta externa e verifico o MX aceite no cabe\u00e7alho. Se a resolu\u00e7\u00e3o ainda mostrar valores antigos, espero pelo tempo de execu\u00e7\u00e3o do TTL e valido novamente. S\u00f3 quando o encaminhamento e a entrega est\u00e3o limpos \u00e9 que informo os utilizadores sobre as caixas de correio prontas.<\/p>\n<p>Como um pequeno lembrete, mantenho os nomes dos anfitri\u00f5es consistentes e documento cada prioridade com um objetivo, tal como Prim\u00e1rio, Prim\u00e1rio2, Backup. Esta clareza ajuda imenso na an\u00e1lise de falhas. Tamb\u00e9m verifico se n\u00e3o existem mais entradas MX hist\u00f3ricas. Destinos antigos geralmente causam confus\u00e3o no <strong>Funcionamento<\/strong>. Um r\u00e1pido controlo de higiene do ADN evitar\u00e1 longas multas.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/MXRecordsRouting_3927.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Retificar rapidamente erros comuns<\/h2>\n<p>Prioridades incorrectas levam a tentativas de entrega desnecess\u00e1rias em anfitri\u00f5es menos adequados; eu corrijo-as <strong>Valores<\/strong> imediatamente e testo novamente. Os erros tipogr\u00e1ficos no anfitri\u00e3o de destino impedem qualquer entrega, pelo que verifico meticulosamente a ortografia. MXs de backup em falta s\u00e3o um inc\u00f3modo em caso de falhas, raz\u00e3o pela qual defino pelo menos uma rota alternativa. As entradas antigas esquecidas causam erros de encaminhamento espor\u00e1dicos, pelo que elimino sistematicamente registos obsoletos. Se a propaga\u00e7\u00e3o demorar algum tempo, planeio esta fase de forma transparente e espero pacientemente em vez de voltar a guardar a cada minuto.<\/p>\n<p>Se um anfitri\u00e3o apresentar rejei\u00e7\u00f5es persistentes, verifico as pol\u00edticas de spam, as listas cinzentas e os requisitos de TLS. Nos registos, reconhe\u00e7o se os limites de taxa ou as listas de bloqueio s\u00e3o a causa. Se ocorrer um erro ap\u00f3s uma altera\u00e7\u00e3o, reverto a situa\u00e7\u00e3o e analiso-a \u00e0 vontade. Esta rea\u00e7\u00e3o controlada reduz <strong>Tempo de inatividade<\/strong> e evita danos consequentes agitados. Boas notas fazem toda a diferen\u00e7a aqui.<\/p>\n\n<h2>Refor\u00e7ar a capacidade de entrega: SPF, DKIM, DMARC<\/h2>\n<p>Uma configura\u00e7\u00e3o MX limpa apenas resolve parte dos desafios de entrega; adiciono sempre SPF, DKIM e DMARC para uma configura\u00e7\u00e3o limpa <strong>Autentica\u00e7\u00e3o<\/strong>. O SPF define quais os servidores autorizados a enviar mensagens para o seu dom\u00ednio. O DKIM assina e-mails criptograficamente e o DMARC define diretrizes para lidar com mensagens defeituosas. Esta combina\u00e7\u00e3o aumenta a confian\u00e7a e reduz a suspeita de spam. Para uma r\u00e1pida introdu\u00e7\u00e3o, a vis\u00e3o geral do <a href=\"https:\/\/webhosting.de\/pt\/spf-dkim-dmarc-hosting-email-security-serverauth-server\/\">SPF, DKIM e DMARC<\/a>, que utilizo regularmente como lista de controlo.<\/p>\n<p>Depois de o configurar, verifico a avalia\u00e7\u00e3o dos cabe\u00e7alhos dos destinat\u00e1rios atrav\u00e9s de envios de teste. Se todas as verifica\u00e7\u00f5es forem aprovadas, as devolu\u00e7\u00f5es e as quarentenas diminuem consideravelmente. Certifique-se de que mant\u00e9m as chaves DNS actualizadas e renova atempadamente as chaves expiradas. Com lembretes autom\u00e1ticos, o <strong>Integridade<\/strong> s\u00e3o mantidas. Isto significa que as defini\u00e7\u00f5es MX e de pol\u00edtica actuam como uma unidade coesa.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/MXRecordsRoutingErklaert1491.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e testes: ferramentas e CLI<\/h2>\n<p>Verifico regularmente o MX e os anfitri\u00f5es de destino com verifica\u00e7\u00f5es de dig, anfitri\u00e3o e SMTP curtas, porque o <strong>Avisos<\/strong> Reduzir as interrup\u00e7\u00f5es. Um monitor verifica a porta 25, os certificados TLS e os tempos de resposta. Tamb\u00e9m analiso os registos do servidor de correio e defino alarmes para c\u00f3digos de erro que indicam problemas de entrega. Uma documenta\u00e7\u00e3o clara dos passos do teste \u00e9 \u00fatil para as equipas de administra\u00e7\u00e3o. A normaliza\u00e7\u00e3o dos testes poupa tempo e reduz significativamente os custos de acompanhamento.<\/p>\n<p>Os retoques finais tamb\u00e9m incluem uma verifica\u00e7\u00e3o da qualidade do DNS, que reconhece inconsist\u00eancias e garante TTLs consistentes. Pode encontrar uma vis\u00e3o geral pr\u00e1tica \u00fatil em <a href=\"https:\/\/webhosting.de\/pt\/tudo-incl-gestao-de-dns-melhores-praticas-verificacao-de-desempenho\/\">Gest\u00e3o de DNS no all-inkl<\/a>, que gosto de utilizar como guia para verifica\u00e7\u00f5es recorrentes. Tamb\u00e9m utilizo testes peri\u00f3dicos em direto com mensagens de correio eletr\u00f3nico reais para poder ver toda a cadeia, desde o DNS at\u00e9 \u00e0 caixa de correio. Estas verifica\u00e7\u00f5es no mundo real revelam casos especiais que os testes sint\u00e9ticos n\u00e3o abordam. Isto mant\u00e9m o seu <strong>qualidade<\/strong> elevados na atividade quotidiana.<\/p>\n\n<h2>Destinos MX v\u00e1lidos: Armadilhas RFC e resolu\u00e7\u00e3o de nomes<\/h2>\n<p>Para uma entrega est\u00e1vel, asseguro-me rigorosamente de que um registo MX se baseia num <strong>Nomes de anfitri\u00e3o<\/strong> nunca aponta diretamente para um IP. O pr\u00f3prio nome do anfitri\u00e3o deve ser resolvido com registos A e, se desejado, AAAA. Eu evito CNAMEs como alvos MX porque, na pr\u00e1tica, eles podem levar a caminhos de resolu\u00e7\u00e3o inesperados e erros. Se um fornecedor introduzir tecnicamente um CNAME, eu testo toda a cadeia intensivamente usando tra\u00e7os de DNS e entregas reais.<\/p>\n<p>No painel, defino o nome de destino como um host totalmente qualificado (FQDN). Algumas interfaces esperam um ponto final, outras adicionam a zona automaticamente; eu verifico o ficheiro de zona resultante para que n\u00e3o seja criado nenhum nome relativo. Um anfitri\u00e3o relativo acidentalmente (por exemplo, \u201emx01\u201c em vez de \u201emx01.example.de.\u201c) acaba muitas vezes em situa\u00e7\u00f5es de NXDOMAIN. Por fim, valido cada MX com uma consulta autoritativa aos servidores de nomes relevantes e verifico se os anfitri\u00f5es podem ser resolvidos corretamente atrav\u00e9s de IPv4 e IPv6 - incluindo testes negativos para erros de digita\u00e7\u00e3o, para que possa evitar esses problemas numa fase inicial.<\/p>\n\n<h2>Funcionamento correto do Backup-MX: Fila de espera, pol\u00edticas, mal-entendidos<\/h2>\n<p>Um MX de backup s\u00f3 \u00e9 \u00fatil se tiver o mesmo <strong>Pol\u00edticas<\/strong> como o anfitri\u00e3o principal. Por conseguinte, ativo regras anti-spam, comportamentos de lista cinzenta e verifica\u00e7\u00f5es de destinat\u00e1rios id\u00eanticos. A c\u00f3pia de seguran\u00e7a deve reconhecer os destinat\u00e1rios desconhecidos <strong>enquanto<\/strong> do di\u00e1logo SMTP (verifica\u00e7\u00e3o do destinat\u00e1rio, por exemplo, atrav\u00e9s de chamadas ou de mapas de destinat\u00e1rios sincronizados) e n\u00e3o gerar NDRs apenas ap\u00f3s a aceita\u00e7\u00e3o - desta forma evita-se a retrodifus\u00e3o. Caso contr\u00e1rio, os autores de spam escolher\u00e3o deliberadamente o alvo mais \u201esuave\u201c.<\/p>\n<p>Para a fila de espera, planeio uma reten\u00e7\u00e3o conservadora mas limitada (cerca de 2-5 dias) e um intervalo de repeti\u00e7\u00e3o rastre\u00e1vel. Monitorizo o espa\u00e7o no disco r\u00edgido, o comprimento da fila e as taxas de adiamento para que uma falha n\u00e3o provoque congestionamento sem ser notada. O MX de backup nunca deve se referir ao prim\u00e1rio como um host inteligente se ele j\u00e1 for o alvo da entrega - caso contr\u00e1rio, h\u00e1 um risco de <strong>La\u00e7os<\/strong>. Tamb\u00e9m importante: a identidade HELO\/EHLO e o banner do anfitri\u00e3o de backup s\u00e3o definidos corretamente para que os remetentes mantenham a confian\u00e7a e possam atribuir claramente os registos, se necess\u00e1rio.<\/p>\n\n<h2>Pilha dupla, TLS e certificados em hosts MX<\/h2>\n<p>Prefiro utilizar MX-Hosts <strong>pilha dupla<\/strong> com registos A e AAAA. Muitos remetentes testam primeiro o IPv6; se a porta 25 v6 estiver fechada ou limitada, o envio muda para o IPv4 - mas perde-se tempo no processo. Por conseguinte, certifico-me de que as firewalls abrem a porta 25 para ambos os protocolos, o ICMP \u00e9 essencialmente permitido (para o MTU do caminho) e a monitoriza\u00e7\u00e3o verifica ambas as pilhas. Para o STARTTLS, defino certificados que cont\u00eam os nomes de host MX espec\u00edficos na SAN. Os curingas ajudam se houver muitos n\u00f3s, mas eu ainda prefiro entradas claras e expl\u00edcitas.<\/p>\n<p>Para uma encripta\u00e7\u00e3o de transporte refor\u00e7ada, planeio suites de cifras modernas e activei o TLS 1.2\/1.3. Opcionalmente, configuro o MTA-STS numa fase de \u201eteste\u201c suave e s\u00f3 mudo para \u201eEnforce\u201c quando os resultados s\u00e3o est\u00e1veis. O DANE (TLSA) pode ser complementado com DNSSEC; verifico a cadeia de DNS com especial aten\u00e7\u00e3o porque os registos TLSA defeituosos podem prejudicar gravemente as liga\u00e7\u00f5es de entrada.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email-routing-hosting-9217.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Horizonte dividido, gateways e rotas internas<\/h2>\n<p>Em redes com destinat\u00e1rios internos e externos separados, utilizo frequentemente <strong>DNS de horizonte dividido<\/strong> os resolvedores externos v\u00eaem destinos MX p\u00fablicos, os clientes internos recebem entradas MX para gateways internos ou diretamente para os servidores de caixas de correio. Isto reduz as lat\u00eancias e evita desvios desnecess\u00e1rios atrav\u00e9s de gateways da Internet. Garanto que as zonas internas n\u00e3o s\u00e3o inadvertidamente publicadas externamente e que as conven\u00e7\u00f5es de atribui\u00e7\u00e3o de nomes permanecem consistentes.<\/p>\n<p>Em ambientes h\u00edbridos com filtros a montante ou sistemas DLP, verifico se os destinos MX mostram apenas as portas de entrada dedicadas. As regras de transporte interno n\u00e3o devem fazer com que um correio aceite do exterior seja enviado de volta para a Internet. Documentei a dire\u00e7\u00e3o de todas as rotas (entrada, interna, sa\u00edda) e testei especificamente casos especiais, como anexos de grandes dimens\u00f5es, NDRs e reencaminhamento. \u00c9 assim que mantenho o <strong>Caminho de entrega<\/strong> livre de loops e becos sem sa\u00edda.<\/p>\n\n<h2>Migra\u00e7\u00e3o ordenada: sequ\u00eancia de passos e revers\u00e3o<\/h2>\n<p>Para as mudan\u00e7as de MX, sigo um calend\u00e1rio claro com um n\u00edvel de avan\u00e7o e um n\u00edvel de recuo:<\/p>\n<ul>\n  <li>Invent\u00e1rio: verifique o MX atual, a resolu\u00e7\u00e3o do anfitri\u00e3o, os certificados, as pol\u00edticas e a monitoriza\u00e7\u00e3o.<\/li>\n  <li>Reduzir o TTL: MX e anfitri\u00f5es de destino para 600-1800 segundos, com tempo suficiente antes da mudan\u00e7a.<\/li>\n  <li>Ligar um novo destino: Introduzir primeiro o novo MX com um n\u00famero de prioridade mais elevado, efetuar testes e monitorizar os registos.<\/li>\n  <li>Prova de funcionalidade: Valide o aperto de m\u00e3o SMTP, o TLS, o filtro de spam, a verifica\u00e7\u00e3o do destinat\u00e1rio e o comportamento da fila com mensagens de correio eletr\u00f3nico reais.<\/li>\n  <li>Mudan\u00e7a: Dar prioridade ao novo prim\u00e1rio para o n\u00famero mais baixo, refor\u00e7ar temporariamente os limiares de monitoriza\u00e7\u00e3o.<\/li>\n  <li>Observar: Monitorizar de perto durante 24-48 horas, estar atento aos c\u00f3digos de erro e \u00e0s lat\u00eancias.<\/li>\n  <li>Arrumar: Remover entradas MX antigas, aumentar novamente os TTLs, atualizar a documenta\u00e7\u00e3o.<\/li>\n  <li>Pronto para a revers\u00e3o: Enquanto a infraestrutura antiga ainda estiver em vigor, posso reverter rapidamente quaisquer anomalias.<\/li>\n<\/ul>\n<p>Com esta disciplina, mesmo as grandes mudan\u00e7as podem ser efectuadas sem que se note <strong>Tempo de inatividade<\/strong> perceber. \u00c9 importante que todas as equipas envolvidas conhe\u00e7am o plano e que exista um canal de comunica\u00e7\u00e3o fixo para a resolu\u00e7\u00e3o de d\u00favidas.<\/p>\n\n<h2>Casos especiais: subdom\u00ednios, curingas e endere\u00e7os internacionais<\/h2>\n<p>Se tiver subdom\u00ednios, como support.example.de, entregues separadamente, defino registos MX separados para cada subdom\u00ednio. Isto ajuda a separar claramente as equipas ou os sistemas. Evito MXs curinga (\u201e*.exemplo.de\u201c) porque podem atrair erros de digita\u00e7\u00e3o e \u00e1reas de destinat\u00e1rios indesejados. \u00c9 melhor definir explicitamente apenas os subdom\u00ednios necess\u00e1rios e deixar todos os outros desocupados.<\/p>\n<p>Para dom\u00ednios internacionais (IDN), certifico-me de que o DNS est\u00e1 corretamente mapeado em Punycode e que os destinos MX permanecem compat\u00edveis com ASCII. Para as partes locais do endere\u00e7o com tremas (EAI\/SMTPUTF8), verifico cuidadosamente o suporte do MTA. Se os sistemas tiverem limita\u00e7\u00f5es neste dom\u00ednio, comunico conven\u00e7\u00f5es de nomenclatura claras ou utilizo gateways que rejeitam de forma fi\u00e1vel caminhos incompat\u00edveis, em vez de me deparar com mensagens de erro pouco leg\u00edveis.<\/p>\n\n<h2>Planeamento da capacidade, limites e consist\u00eancia do cluster<\/h2>\n<p>Para evitar que os picos de carga se tornem uma armadilha, planeio a capacidade ao n\u00edvel da liga\u00e7\u00e3o e do conte\u00fado. Defino <strong>Limites uniformes<\/strong> para anfitri\u00f5es MX da mesma categoria (mesma liga\u00e7\u00e3o e limite de d\u00e9bito de mensagens) e manter sincronizados os estados de spam e de greylisting, se os produtos o permitirem. Caso contr\u00e1rio, pode acontecer que um remetente seja rejeitado no mx01 mas aceite no mx02, o que cria um comportamento inconsistente. O estado partilhado ou as pol\u00edticas determin\u00edsticas reduzem esses efeitos.<\/p>\n<p>Me\u00e7o constantemente valores-chave como tentativas de liga\u00e7\u00e3o, taxa de aceita\u00e7\u00e3o, taxas de adiamento e rejei\u00e7\u00e3o, comprimento da fila, lat\u00eancia at\u00e9 \u00e0 aceita\u00e7\u00e3o, taxa de utiliza\u00e7\u00e3o de TLS e tamanho m\u00e9dio das mensagens. Estas m\u00e9tricas mostram desde logo quando se aproximam estrangulamentos (por exemplo, devido ao desempenho da verifica\u00e7\u00e3o de v\u00edrus ou ao I\/O limitado no diret\u00f3rio de filas). Quando s\u00e3o efectuadas altera\u00e7\u00f5es no cluster, sincronizo as configura\u00e7\u00f5es automaticamente para que n\u00e3o haja desvios de pol\u00edtica. O resultado \u00e9 um comportamento est\u00e1vel e previs\u00edvel de todos os MX<strong>Anfitri\u00f5es<\/strong> na rede.<\/p>\n\n<h2>Interpreta\u00e7\u00e3o de mensagens de erro e testes espec\u00edficos<\/h2>\n<p>A experi\u00eancia tem demonstrado que um pequeno compasso de mensagens de erro acelera a an\u00e1lise. Os erros tempor\u00e1rios (4xx) indicam frequentemente limites de taxa, greylisting ou problemas de rede a curto prazo; os erros permanentes (5xx) indicam viola\u00e7\u00f5es de pol\u00edticas, destinat\u00e1rios inexistentes ou viola\u00e7\u00f5es de TLS. Provoco deliberadamente casos de teste: destinat\u00e1rio errado, TLS aplicado\/n\u00e3o aplicado, anexos demasiado grandes, falta de pesquisa inversa no sistema de teste de envio. \u00c9 assim que verifico se as reac\u00e7\u00f5es da sua pilha s\u00e3o consistentes e compreens\u00edveis.<\/p>\n<p>N\u00e3o confio no \u201eround robin\u201c para anfitri\u00f5es MX com a mesma prioridade. Muitos MTAs escolhem por ordem aleat\u00f3ria ou com base em m\u00e9tricas internas se tiverem a mesma prefer\u00eancia. Na pr\u00e1tica, verifico se a distribui\u00e7\u00e3o se equilibra de facto durante um per\u00edodo de tempo mais longo e ajusto os limites ou o n\u00famero de anfitri\u00f5es com a mesma prioridade, se necess\u00e1rio, para evitar pontos cr\u00edticos.<\/p>\n\n<h2>Breve resumo para o seu encaminhamento<\/h2>\n<p>Registos MX corretamente definidos com prioridades bem pensadas formam a base de um encaminhamento de correio eletr\u00f3nico fi\u00e1vel, que eu asseguro com testes claros e complemento com SPF, DKIM, DMARC; isto resulta num encaminhamento de correio eletr\u00f3nico limpo. <strong>Processos<\/strong> sem estrangulamentos. Defina pelo menos um MX de reserva, planeie conscientemente as janelas TTL e verifique os registos ap\u00f3s cada ajuste. Evitar cargas antigas na zona e gerir os nomes de anfitri\u00e3o de forma consistente. Mantenha uma documenta\u00e7\u00e3o simples pronta para tornar as altera\u00e7\u00f5es rastre\u00e1veis. Com esta configura\u00e7\u00e3o, o seu caminho de entrega de correio eletr\u00f3nico permanece transparente, \u00e0 prova de falhas e f\u00e1cil de manter.<\/p>\n<p>Se quiser saber mais pormenores ou implementar a configura\u00e7\u00e3o passo a passo, remeto-o para um compacto <a href=\"https:\/\/webhosting.de\/pt\/email-dominio-proprio-registos-mx-ferramentas-configuracao-instrucoes-alojamento\/\">Instru\u00e7\u00f5es para registos MX<\/a>, que pode utilizar como um guia de refer\u00eancia \u00fatil. Planeie cuidadosamente as altera\u00e7\u00f5es, teste cuidadosamente cada caminho e tenha as correc\u00e7\u00f5es prontas. Isto ajud\u00e1-lo-\u00e1 a conseguir uma <strong>Entrega<\/strong> - hoje e no futuro.<\/p>","protected":false},"excerpt":{"rendered":"<p>Os registos MX e a defini\u00e7\u00e3o de prioridades explicam o encaminhamento de registos mx no alojamento. Otimizar o caminho de entrega de correio eletr\u00f3nico para um alojamento de correio fi\u00e1vel.<\/p>","protected":false},"author":1,"featured_media":18442,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[708],"tags":[],"class_list":["post-18449","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-email"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"568","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MX Records","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18442","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18449","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=18449"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18449\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18442"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18449"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18449"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}