feat(dns): retire coilysiren.me mail as a non-sending domain #918

Merged

coilyco-ops merged 1 commit from ops/retire-coilysiren-me-mail into main

2026-08-25 02:02:33 +00:00

coilyco-ops commented

2026-08-25 02:00:56 +00:00

Member

Google Workspace routed mail for coilysiren.me and is now down. Kai confirmed nothing recovers through kai@coilysiren.me, so the domain is being retired as a mail domain rather than restored.

Why nothing breaks

Grepped the fleet for every @coilysiren.me address and every mailer config:

coilyco-ops@coilysiren.me - 7 hits, all git commit-identity strings plus the Forgejo account field. A commit author address never receives mail.
cert-manager / Let's Encrypt - deploy/cert_manager.yml:9,30 registers coilysiren@gmail.com. Certificate expiry notices are unaffected.
Forgejo - deploy/forgejo.yml:267 sets FORGEJO__mailer__ENABLED: "false". It sends nothing.
No SES, SendGrid, or any other sender anywhere in the estate.

The only consumer was the DMARC rua added in #911 a few hours ago.

Why not just leave it

DNS currently advertises a healthy mail domain. MX is 1 smtp.google.com. and SPF authorizes Google to send. Mail to the domain fails silently while every external sender sees a working mail host. Silent and externally invisible is the combination worth fixing.

The change

MX      1 smtp.google.com.                   ->  0 .
SPF     v=spf1 include:_spf.google.com ~all  ->  v=spf1 -all
DMARC   v=DMARC1; p=none; rua=...            ->  v=DMARC1; p=reject; sp=reject

Null MX rather than deleting the record. With no MX at all, senders fall back to the implicit MX at the apex A record, which is Netlify's load balancer and runs no SMTP. Mail would hang and retry for days before failing. 0 . (RFC 7505) rejects at once.

Straight to p=reject, no monitoring period. #911 used softfail ~all and p=none because breaking a legitimate sender was the risk, and only rua reports could rule that out. There is no legitimate sender now, so there is nothing to review first. sp=reject covers subdomains, none of which send either; a subdomain that ever needs to send publishes its own _dmarc and overrides it.

The result is stricter than the domain ever was while Workspace ran it.

Both google-site-verification tokens stay. The apex is still a Netlify-hosted site that may need Search Console, and DNS cannot say which product issued which token. Unchanged in the plan.

Verification

terraform validate passes, fmt -check clean, pre-commit run --all-files green.

Targeted plan:

Plan: 0 to add, 3 to change, 0 to destroy.

Three in-place updates, no adds, no destroys. The apex TXT diff swaps only the SPF string and reports # (2 unchanged elements hidden) for the two tokens.

Apply

Stays targeted, for the same reason as #911: this module carries unrelated drift that would destroy three live A records on an untargeted apply. See #914.

terraform -chdir=terraform/aws-inventory plan \
  -target='aws_route53_record.txt["@"]' \
  -target='aws_route53_record.dmarc' \
  -target='aws_route53_record.mx' \
  -out=retire-mail.tfplan
terraform -chdir=terraform/aws-inventory apply retire-mail.tfplan

Follow-on

#915 largely dissolves. DKIM is unnecessary for a non-sending domain and the DMARC hardening it deferred is done here. Bing verification is the only piece that survives, and it was never about mail. Will trim that issue once this applies.

Reverting is a single commit if mail ever returns.

🤖 Generated with Claude Code

Google Workspace routed mail for `coilysiren.me` and is now down. Kai confirmed nothing recovers through `kai@coilysiren.me`, so the domain is being retired as a mail domain rather than restored. ## Why nothing breaks Grepped the fleet for every `@coilysiren.me` address and every mailer config: * `coilyco-ops@coilysiren.me` - 7 hits, all git commit-identity strings plus the Forgejo account field. A commit author address never receives mail. * cert-manager / Let's Encrypt - `deploy/cert_manager.yml:9,30` registers `coilysiren@gmail.com`. Certificate expiry notices are unaffected. * Forgejo - `deploy/forgejo.yml:267` sets `FORGEJO__mailer__ENABLED: "false"`. It sends nothing. * No SES, SendGrid, or any other sender anywhere in the estate. The only consumer was the DMARC `rua` added in #911 a few hours ago. ## Why not just leave it DNS currently advertises a healthy mail domain. `MX` is `1 smtp.google.com.` and SPF authorizes Google to send. Mail to the domain fails silently while every external sender sees a working mail host. Silent and externally invisible is the combination worth fixing. ## The change ``` MX 1 smtp.google.com. -> 0 . SPF v=spf1 include:_spf.google.com ~all -> v=spf1 -all DMARC v=DMARC1; p=none; rua=... -> v=DMARC1; p=reject; sp=reject ``` **Null MX rather than deleting the record.** With no `MX` at all, senders fall back to the implicit MX at the apex `A` record, which is Netlify's load balancer and runs no SMTP. Mail would hang and retry for days before failing. `0 .` (RFC 7505) rejects at once. **Straight to `p=reject`, no monitoring period.** #911 used softfail `~all` and `p=none` because breaking a legitimate sender was the risk, and only `rua` reports could rule that out. There is no legitimate sender now, so there is nothing to review first. `sp=reject` covers subdomains, none of which send either; a subdomain that ever needs to send publishes its own `_dmarc` and overrides it. The result is stricter than the domain ever was while Workspace ran it. **Both `google-site-verification` tokens stay.** The apex is still a Netlify-hosted site that may need Search Console, and DNS cannot say which product issued which token. Unchanged in the plan. ## Verification `terraform validate` passes, `fmt -check` clean, `pre-commit run --all-files` green. Targeted plan: ``` Plan: 0 to add, 3 to change, 0 to destroy. ``` Three in-place updates, no adds, no destroys. The apex `TXT` diff swaps only the SPF string and reports `# (2 unchanged elements hidden)` for the two tokens. ## Apply Stays targeted, for the same reason as #911: this module carries unrelated drift that would destroy three live A records on an untargeted apply. See #914. ``` terraform -chdir=terraform/aws-inventory plan \ -target='aws_route53_record.txt["@"]' \ -target='aws_route53_record.dmarc' \ -target='aws_route53_record.mx' \ -out=retire-mail.tfplan terraform -chdir=terraform/aws-inventory apply retire-mail.tfplan ``` ## Follow-on #915 largely dissolves. DKIM is unnecessary for a non-sending domain and the DMARC hardening it deferred is done here. Bing verification is the only piece that survives, and it was never about mail. Will trim that issue once this applies. Reverting is a single commit if mail ever returns. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-25 02:00:56 +00:00

feat(dns): retire coilysiren.me mail as a non-sending domain

CI / lint (pull_request) Successful in 42s

Details

TruffleHog / Scan for secrets (pull_request) Successful in 4s

Details

9fa6b989c6

Google Workspace routed mail for kai@coilysiren.me and is gone. Nothing
in the estate depended on it: cert-manager registers Let's Encrypt
against coilysiren@gmail.com, Forgejo's mailer is disabled, and
coilyco-ops@coilysiren.me is a git commit-identity string that never
receives anything. The only consumer was the DMARC rua added hours ago
in #911.

Left alone, DNS advertises a healthy mail domain that silently drops
everything sent to it. Configure the domain as what it now is:

  MX      0 .                             (RFC 7505 null MX)
  SPF     v=spf1 -all
  DMARC   v=DMARC1; p=reject; sp=reject   (no rua)

Deleting the MX outright would be worse than the null MX. Senders would
fall back to the implicit MX at the apex A record, which is Netlify's
load balancer and runs no SMTP, so mail hangs and retries for days
before failing rather than rejecting at once.

This is stricter than the domain ever was under Workspace, and it skips
the monitor-then-harden sequence #911 needed. That caution existed to
avoid breaking a legitimate sender. There is no longer one, so p=reject
is safe immediately and no reporting loop is required to get there.

Both google-site-verification tokens stay. The apex is still a
Netlify-hosted site that may need Search Console, and DNS cannot say
which product issued which token.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Agent-Role: sysadmin