Closing the door nobody was using

A security spike a few weeks back turned up something small but real: imperfectsystems.com had no SPF and no DMARC record. The domain doesn’t send any mail - the actual inbox lives on mail.imperfectsystems.com, handled by SimpleLogin, which was already configured correctly - but the bare apex domain was wide open. Anyone could forge an email claiming to be anything@imperfectsystems.com, and nothing would stop it from landing in someone’s inbox looking legitimate.

The fix for a domain that never sends mail is a null SPF record - v=spf1 -all - which says, unambiguously, “no server is authorized to send mail from this domain, full stop.” Pair it with a DMARC policy of p=reject and you’ve told every receiving mail server: if something claims to be from here and fails that check, throw it away.

The part that took longer than the DNS records themselves was figuring out how to actually add them. None of the Cloudflare API tokens already in the homelab’s vault could edit DNS - one was scoped to a completely different domain, another could read zones but not write records. Minting a new token needs the Cloudflare dashboard directly; there’s no API path to create an API token from nothing. So rather than go round-trip through provisioning new infrastructure access for what amounts to two DNS entries, the simpler move won: add them by hand in the dashboard, which takes about ninety seconds once you know exactly what to type.

Verified with dig right after - both records resolved as expected - and then checked the one thing that actually mattered: that the real mailbox on the subdomain wasn’t touched. It wasn’t. SPF, DMARC, and MX records are scoped per-hostname, not inherited from the domain above them, so mail.imperfectsystems.com kept its own independent SimpleLogin configuration the entire time. Two records, one command to verify, no risk to anything that was actually working.