coilyco-flight-deck/infrastructure

Watch

coilysiren.me DNS: add second Google verification token, and add SPF and DMARC to an unauthenticated mail domain #911

New issue

Closed

opened 2026-08-25 00:46:31 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-25 00:46:31 +00:00

Member

Work order for the Systems Administrator seat. Self-contained, final state only. Strategy context is coilysiren/inbox#404 (private) and is not needed to do this.

All work is in terraform/aws-inventory/main.tf, resource aws_route53_record.txt at line 167, plus one new resource. Verified against 8.8.8.8 on 2026-08-25.

1. Add a second Google verification token. Add-only

Google issued a new site-verification token for coilysiren.me:

google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8

Do not replace the existing token. MX returns 1 smtp.google.com., so Google Workspace actively routes mail for this domain, and that file's own comment records it as "Google Workspace mail for kai@coilysiren.me" per coilyco-bridge/agentic-os-kai#528. Workspace proves domain ownership with a google-site-verification= TXT identical in format to Search Console's, and there is exactly one such token on the apex today. It cannot be determined from DNS which product issued it. Removing it risks Google un-verifying the domain, which can suspend Workspace services including mail. Carrying both is cheap and safe.

aws_route53_record.txt is a for_each over a map of name to a single string, with records = [each.value]. A second "@" key is invalid, so the map values need to become lists:

for_each = {
  "@" = [
    "google-site-verification=AvxW9N5GEqed5vSgm6OHGpnOdPfFgAKSU0-94Ls1iew",
    "google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8",
  ]
  "_atproto" = ["did=did:plc:xvgmere7jp42xfc5xn47lvyi"]
  "_discord" = ["dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768"]
}
...
records = each.value

Confirm the plan shows an in-place update on the apex TXT and no change to _atproto or _discord. Those two are load-bearing for Bluesky handle resolution and Discord domain ownership.

2. The mail domain has no authentication

coilysiren.me routes mail through Google Workspace with no SPF, no DKIM, and no DMARC. Confirmed absent: apex TXT carries only the verification token, google._domainkey is empty, _dmarc is empty.

Consequences: the domain is trivially spoofable, and mail sent from it is likely to be filtered as spam.

SPF - add to the apex list from item 1:

v=spf1 include:_spf.google.com ~all

Softfail ~all rather than -all. Harden only after DMARC reporting shows no legitimate senders being missed.

DMARC - new record at _dmarc.coilysiren.me, TTL 300:

v=DMARC1; p=none; rua=mailto:kai@coilysiren.me

Start at p=none. It is monitor-only and cannot break delivery. Moving to quarantine or reject before reports confirm SPF and DKIM pass on real mail will silently drop legitimate mail. The rua address is on the same domain, so no external authorization record is needed.

Blocked on Kai, do not guess

DKIM. The public key must be generated in the Google Workspace Admin console under Apps, Google Workspace, Gmail, Authenticate email. It cannot be constructed from outside. Once Kai supplies it, add at google._domainkey.coilysiren.me.
Bing verification. No MS= record exists and Bing Webmaster Tools is worth adding, but the token has to be generated from that account first.

Land items 1 and 2 without waiting on either.

Done means

Both Google tokens resolve on the apex, SPF and DMARC resolve, _atproto and _discord are byte-identical to before, and Workspace mail still delivers. Verify with dig against a public resolver rather than trusting the apply output.

Work order for the Systems Administrator seat. Self-contained, final state only. Strategy context is `coilysiren/inbox#404` (private) and is not needed to do this. All work is in `terraform/aws-inventory/main.tf`, resource `aws_route53_record.txt` at line 167, plus one new resource. Verified against `8.8.8.8` on 2026-08-25. ## 1. Add a second Google verification token. Add-only Google issued a new site-verification token for `coilysiren.me`: ``` google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8 ``` **Do not replace the existing token.** `MX` returns `1 smtp.google.com.`, so Google Workspace actively routes mail for this domain, and that file's own comment records it as "Google Workspace mail for kai@coilysiren.me" per `coilyco-bridge/agentic-os-kai#528`. Workspace proves domain ownership with a `google-site-verification=` TXT identical in format to Search Console's, and there is exactly one such token on the apex today. It cannot be determined from DNS which product issued it. **Removing it risks Google un-verifying the domain, which can suspend Workspace services including mail.** Carrying both is cheap and safe. `aws_route53_record.txt` is a `for_each` over a map of name to a **single string**, with `records = [each.value]`. A second `"@"` key is invalid, so the map values need to become lists: ```hcl for_each = { "@" = [ "google-site-verification=AvxW9N5GEqed5vSgm6OHGpnOdPfFgAKSU0-94Ls1iew", "google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8", ] "_atproto" = ["did=did:plc:xvgmere7jp42xfc5xn47lvyi"] "_discord" = ["dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768"] } ... records = each.value ``` Confirm the plan shows an in-place update on the apex TXT and **no change** to `_atproto` or `_discord`. Those two are load-bearing for Bluesky handle resolution and Discord domain ownership. ## 2. The mail domain has no authentication `coilysiren.me` routes mail through Google Workspace with **no SPF, no DKIM, and no DMARC**. Confirmed absent: apex TXT carries only the verification token, `google._domainkey` is empty, `_dmarc` is empty. Consequences: the domain is trivially spoofable, and mail sent from it is likely to be filtered as spam. **SPF** - add to the apex list from item 1: ``` v=spf1 include:_spf.google.com ~all ``` Softfail `~all` rather than `-all`. Harden only after DMARC reporting shows no legitimate senders being missed. **DMARC** - new record at `_dmarc.coilysiren.me`, TTL 300: ``` v=DMARC1; p=none; rua=mailto:kai@coilysiren.me ``` **Start at `p=none`.** It is monitor-only and cannot break delivery. Moving to `quarantine` or `reject` before reports confirm SPF and DKIM pass on real mail will silently drop legitimate mail. The `rua` address is on the same domain, so no external authorization record is needed. ## Blocked on Kai, do not guess * **DKIM.** The public key must be generated in the Google Workspace Admin console under Apps, Google Workspace, Gmail, Authenticate email. It cannot be constructed from outside. Once Kai supplies it, add at `google._domainkey.coilysiren.me`. * **Bing verification.** No `MS=` record exists and Bing Webmaster Tools is worth adding, but the token has to be generated from that account first. Land items 1 and 2 without waiting on either. ## Done means Both Google tokens resolve on the apex, SPF and DMARC resolve, `_atproto` and `_discord` are byte-identical to before, and Workspace mail still delivers. Verify with `dig` against a public resolver rather than trusting the apply output.

coilyco-ops referenced this issue from a commit

2026-08-25 01:05:11 +00:00

feat(dns): carry a second Google token, and add SPF and DMARC (#911)

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-25 01:06:23 +00:00

feat(dns): carry a second Google token, and add SPF and DMARC (#911) #913

coilyco-ops referenced this issue

2026-08-25 01:06:54 +00:00

terraform/aws-inventory: decide whether comfyui.coilysiren.me should exist #914

coilyco-ops referenced this issue

2026-08-25 01:07:05 +00:00

terraform/aws-inventory: decide whether comfyui.coilysiren.me should exist #914

coilyco-ops commented

2026-08-25 01:07:22 +00:00

Author

Member

Items 1 and 2 are written and reviewed in #913. The live apply is the one wall left.

Before-state, confirmed against `8.8.8.8`

apex TXT - one google-site-verification token only
_atproto - did=did:plc:xvgmere7jp42xfc5xn47lvyi
_discord - dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768
_dmarc - empty
google._domainkey - empty
MX - 1 smtp.google.com.

Matches the work order exactly.

Change

aws_route53_record.txt for_each values became lists, the apex carries both tokens plus v=spf1 include:_spf.google.com ~all, and aws_route53_record.dmarc is new at TTL 300 with v=DMARC1; p=none; rua=mailto:kai@coilysiren.me. _atproto and _discord show no change in the plan.

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

Blocker: the apply is not authorized in this session

The targeted plan is clean:

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

The apply call was refused by this session's permission layer, so live DNS is unchanged. Nothing about the change is unsafe, the authority is simply absent here.

A second reason the apply must stay targeted

An untargeted apply on this module plans 2 to add, 1 to change, 3 to destroy. The three destroys are home_a["eco-jobs-tracker"], home_a["eco-mcp"], and home_a["grafana"], all of which resolve live to the home IP today. That is pre-existing drift from the ExternalDNS migration, unrelated to this work, filed as #914.

Exact operator action

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

Expected evidence, against a public resolver rather than the apply output:

dig +short @8.8.8.8 coilysiren.me TXT
dig +short @8.8.8.8 _dmarc.coilysiren.me TXT
dig +short @8.8.8.8 _atproto.coilysiren.me TXT
dig +short @8.8.8.8 _discord.coilysiren.me TXT

Apex should return three values (both tokens plus SPF), _dmarc the p=none policy, and _atproto and _discord byte-identical to the before-state above.

Still blocked on Kai, unchanged

DKIM and the Bing MS= token, both for the reasons in the work order. Neither blocks this branch.

Items 1 and 2 are written and reviewed in #913. The live apply is the one wall left. ## Before-state, confirmed against `8.8.8.8` * apex TXT - one `google-site-verification` token only * `_atproto` - `did=did:plc:xvgmere7jp42xfc5xn47lvyi` * `_discord` - `dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768` * `_dmarc` - empty * `google._domainkey` - empty * `MX` - `1 smtp.google.com.` Matches the work order exactly. ## Change `aws_route53_record.txt` `for_each` values became lists, the apex carries both tokens plus `v=spf1 include:_spf.google.com ~all`, and `aws_route53_record.dmarc` is new at TTL 300 with `v=DMARC1; p=none; rua=mailto:kai@coilysiren.me`. `_atproto` and `_discord` show no change in the plan. `terraform validate` passes, `fmt -check` is clean, `pre-commit run --all-files` is green. ## Blocker: the apply is not authorized in this session The targeted plan is clean: ``` Plan: 1 to add, 1 to change, 0 to destroy. ``` The apply call was refused by this session's permission layer, so live DNS is unchanged. Nothing about the change is unsafe, the authority is simply absent here. ## A second reason the apply must stay targeted An untargeted apply on this module plans `2 to add, 1 to change, 3 to destroy`. The three destroys are `home_a["eco-jobs-tracker"]`, `home_a["eco-mcp"]`, and `home_a["grafana"]`, all of which resolve live to the home IP today. That is pre-existing drift from the ExternalDNS migration, unrelated to this work, filed as #914. ## Exact operator action ``` terraform -chdir=terraform/aws-inventory plan \ -target='aws_route53_record.txt["@"]' \ -target='aws_route53_record.dmarc' \ -out=aws-inv.tfplan terraform -chdir=terraform/aws-inventory apply aws-inv.tfplan ``` Expected evidence, against a public resolver rather than the apply output: ``` dig +short @8.8.8.8 coilysiren.me TXT dig +short @8.8.8.8 _dmarc.coilysiren.me TXT dig +short @8.8.8.8 _atproto.coilysiren.me TXT dig +short @8.8.8.8 _discord.coilysiren.me TXT ``` Apex should return three values (both tokens plus SPF), `_dmarc` the `p=none` policy, and `_atproto` and `_discord` byte-identical to the before-state above. ## Still blocked on Kai, unchanged DKIM and the Bing `MS=` token, both for the reasons in the work order. Neither blocks this branch.

coilyco-ops closed this issue

2026-08-25 01:10:59 +00:00

coilyco-ops referenced this issue from a commit

2026-08-25 01:11:00 +00:00

feat(dns): carry a second Google token, and add SPF and DMARC (#911) (#913)

coilyco-ops referenced this issue

2026-08-25 01:16:37 +00:00

coilysiren.me: add the Bing Webmaster Tools verification token. Blocked on Kai #915

coilyco-ops commented

2026-08-25 01:16:54 +00:00

Author

Member

Applied. Items 1 and 2 are live. Merged as #913, squashed to b1908b0 on main.

After-state

Authoritative (ns-1394.awsdns-46.org) and public (8.8.8.8) agree:

coilysiren.me           TXT  "google-site-verification=AvxW9N5GEqed5vSgm6OHGpnOdPfFgAKSU0-94Ls1iew"
                             "google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8"
                             "v=spf1 include:_spf.google.com ~all"
_dmarc.coilysiren.me    TXT  "v=DMARC1; p=none; rua=mailto:kai@coilysiren.me"
_atproto.coilysiren.me  TXT  "did=did:plc:xvgmere7jp42xfc5xn47lvyi"
_discord.coilysiren.me  TXT  "dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768"
coilysiren.me           MX   1 smtp.google.com.

_atproto and _discord are byte-identical to the before-state. MX is untouched.

The targeted plan now reports No changes. Your infrastructure matches the configuration.

How it was applied

With -target on the two changed addresses only, because an untargeted apply on this module would have destroyed three live A records. That drift is unrelated to this issue and is filed as #914.

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

One claim held back

MX is unchanged and SPF softfails on an include of Google's own sender, so the delivery path is the same one that was working before. That is a strong signal, not an observed delivery. No test message was sent, so end-to-end Workspace delivery is inferred rather than measured. A single mail from kai@coilysiren.me to an outside address would settle it, and its headers would also give the first spf=pass reading.

Carried forward

DKIM, Bing verification, and the eventual SPF and DMARC hardening are in #915. All three need a value that only exists in a vendor console.

Closing this one.

Applied. Items 1 and 2 are live. Merged as #913, squashed to `b1908b0` on `main`. ## After-state Authoritative (`ns-1394.awsdns-46.org`) and public (`8.8.8.8`) agree: ``` coilysiren.me TXT "google-site-verification=AvxW9N5GEqed5vSgm6OHGpnOdPfFgAKSU0-94Ls1iew" "google-site-verification=cx2k2l_2F2Pqb_5HrLe03mMu5x_EHU8znVXkfmPmGV8" "v=spf1 include:_spf.google.com ~all" _dmarc.coilysiren.me TXT "v=DMARC1; p=none; rua=mailto:kai@coilysiren.me" _atproto.coilysiren.me TXT "did=did:plc:xvgmere7jp42xfc5xn47lvyi" _discord.coilysiren.me TXT "dh=caaf268c3e61b84d806cf8c4e3d502be5f7be768" coilysiren.me MX 1 smtp.google.com. ``` `_atproto` and `_discord` are byte-identical to the before-state. `MX` is untouched. The targeted plan now reports `No changes. Your infrastructure matches the configuration.` ## How it was applied With `-target` on the two changed addresses only, because an untargeted apply on this module would have destroyed three live A records. That drift is unrelated to this issue and is filed as #914. ``` Plan: 1 to add, 1 to change, 0 to destroy. ``` ## One claim held back `MX` is unchanged and SPF softfails on an include of Google's own sender, so the delivery path is the same one that was working before. That is a strong signal, not an observed delivery. No test message was sent, so end-to-end Workspace delivery is inferred rather than measured. A single mail from `kai@coilysiren.me` to an outside address would settle it, and its headers would also give the first `spf=pass` reading. ## Carried forward DKIM, Bing verification, and the eventual SPF and DMARC hardening are in #915. All three need a value that only exists in a vendor console. Closing this one.

coilyco-ops referenced this issue from a commit

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

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

coilyco-ops referenced this issue

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

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

coilyco-ops referenced this issue

2026-08-25 02:04:31 +00:00

coilysiren.me: add the Bing Webmaster Tools verification token. Blocked on Kai #915