Email domains guide says Void preserves foreign MX records, but `domain add` refuses apexes that have MX records
Mantenedores costumam responder em até 1 dia
Um pull request relacionado já foi integrado.
- #518 de @Brooooooklyn — integrado
Avaliação
- Dificuldade
- 2/5
- Tempo estimado
- 1-3 horas
- Facilidade para iniciantes
- 58/100
- Tipo de issue
- Documentação
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- typescript
- Domínio
- documentation
Direção de pesquisa
Read docs/guide/email/domains.md alongside docs/reference/cli/platform-email.md and the MX checks in platform/packages/api/src/email/connection-service.ts. The issue asks maintainers to clarify whether refusal is intended or foreign MX coexistence should work, so first establish that decision before editing. Done means the guide clearly describes the intended behavior and does not imply unsupported registration.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Summary
The platform section of the email domains guide says Void "preserves foreign MX records" (docs/guide/email/domains.md L19). Read on its own, that suggests registering an apex whose mail is hosted elsewhere (for example Microsoft 365 or Google Workspace) is supported and leaves that mail alone.
The code refuses that case. Registering a custom apex fails when the domain already has MX records:
platform/packages/api/src/email/connection-service.ts L1459-L1474: "already has MX records; use an unused domain apex or a platform shared email address". On a fresh assignment any MX counts, including Cloudflare's own. On an existing assignment, any non-Cloudflare MX counts.
Use case
I operate a self-hosted Void platform serving several brands whose apex domains use Microsoft 365 for mail. I read the sentence as "register the apex, keep your mailboxes, add Void". It took a failed registration to learn that was not the intent.
What the rest of the docs say
Other text already matches the code. The same paragraph tells readers to choose an apex without another mail provider, the own-account section says Void refuses to replace another provider's MX records (L47), and docs/reference/cli/platform-email.md L76 says to use the shared address or another zone when the MX belongs to another provider. So the sentence may mean "Void does not modify them because it refuses the domain". If so, it is easy to misread.
Question
Which behaviour is intended?
- Refusal is intended. I can send a docs PR that rewords the sentence, for example to say that registration is refused when the apex has MX records, and that existing catch-alls on a Void-managed apex are left in place.
- Coexistence is intended and the refusal is a bug. In that case I would like to understand the intended design before touching code.
There is also a middle path, outbound-only custom domains, where an apex with foreign MX can send through Void while Void manages no inbound. I intend to raise that separately. If you prefer to solve the mismatch there, I can word the docs change to point at it once it lands.
- Linguagem predominante
- TypeScript
- Estrelas
- 402
- Forks
- 32
- Merge médio
- 8h 32min
- PRs com merge (30d)
- 111
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de voidzero-dev/void
-
Dev: `better-auth/client/plugins` fails to resolve when auth is enabled (the `better-auth/client` alias matches it as a prefix)Talvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
voidzero-dev/void#565 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
voidzero-dev/void#529 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 78/100
voidzero-dev/void#428 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 53/100
voidzero-dev/void#567 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 55/100
voidzero-dev/void#564 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de voidzero-dev/void
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
braintrustdata/braintrust-sdk-javascript#2659 ·
Mantenedores costumam responder em até 1 dia
-
body-parser 2.3.0 in the published ai-dial-chat-bff image is vulnerable (CVE-2026-111181, HIGH)Talvez já em andamento @illya-havsiyevych assumiu hoje. Abertabug
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 87/100
epam/ai-dial-chat#9566 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 83/100
Mantenedores costumam responder em até 1 dia
-
はさみアイコンを修正するAbertabug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
-
resource.reload() while params is in error switches the resource to 'idle' instead of retryingAbertaarea: core
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia