Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#509 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
58/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
documentation

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
402
フォーク
32
平均マージ
11時間 52分
マージ済み PR（30日）
88

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

voidzero-dev/void のほかの issue

voidzero-dev/void の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。