Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Email domains guide says Void preserves foreign MX records, but `domain add` refuses apexes that have MX records

Abierto
#509 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
58/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

  1. 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.
  2. 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.

Lenguaje dominante
TypeScript
Estrellas
402
Forks
32
Merge medio
11 h 52 min
PR fusionados (30 d)
88

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de voidzero-dev/void

Todos los issues de voidzero-dev/void

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.