Most security conversations start with the application layer. Firewalls, WAFs, input validation, SQL injection — the stuff that makes the OWASP Top 10. But there is a layer beneath the application that most operators never touch: the DNS layer. And beneath DNS, there is a quieter layer still: the email authentication perimeter. When we hardened the lucidhive.com zone in August 2026, we discovered that our email perimeter was not just weak. It was nonexistent.
The audit that revealed the gap
The Cloudflare tunnel audit of August 1st fixed the HTTP 530 errors that had taken down every subdomain. But the tunnel fix was only half the perimeter. The zone audit that followed — a 16-record inventory of every DNS entry in the lucidhive.com zone — exposed the email side: three authentication records, all broken or stale, and zero SPF policy.
The DMARC record was malformed. The spec requires v=DMARC1 as the first tag — RFC 7489 is explicit about this. Our record started with DMARC1; p=reject — missing the v= prefix entirely. The DNS server accepted it. The DMARC validator rejected it. The result: p=reject was not enforced. Any spoofer could send email as @lucidhive.com and the domain’s own authentication layer would nod along.
The DKIM record pointed to a Google Workspace selector — google._domainkey.lucidhive.com — with an RSA key for a Workspace instance that no longer existed. Harmless to leave (unused selectors don’t break anything), but it was dead weight. A stale credential in a zone you control is a liability you chose not to clean.
And SPF? There was none. No TXT record at the apex. Zero authorization policy. The domain had no statement about who was allowed to send email on its behalf. In DNS terms, this is the equivalent of leaving the front door unlocked and the alarm system unplugged.
DNSSEC: the integrity layer most people skip
Before fixing email records, we needed to ensure the DNS layer itself was trustworthy. DNSSEC — DNS Security Extensions — signs DNS records cryptographically so that resolvers can verify the answers they receive haven’t been tampered with in transit.
Cloudflare enables DNSSEC for the zone. When a resolver queries lucidhive.com, it receives not just the answer but a cryptographic signature chain that traces back to the zone’s KSK (Key Signing Key) and ZSK (Zone Signing Key). The resolver verifies the chain. If any record has been modified between the authoritative server and the resolver — by a man-in-the-middle, a cache poisoning attack, or a BGP hijack — the signature fails and the resolver refuses the answer.
DNSSEC does not encrypt DNS traffic. It authenticates it. The distinction matters: DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the channel; DNSSEC signs the payload. You want both, but for different reasons. DNSSEC ensures that the SPF, DMARC, and MX records we publish are the records that resolvers actually use. Without DNSSEC, an attacker could篡改 the DNS response in flight, substituting a permissive SPF record that authorizes their mail servers. With DNSSEC, the signature chain breaks and the forged record is rejected.
This is the foundation that everything else sits on. You cannot build email authentication on a DNS layer that can be spoofed.
SPF: the authorization statement
SPF (Sender Policy Framework) is a TXT record at the domain apex that lists which mail servers are authorized to send email on behalf of the domain. It is the simplest of the three email authentication mechanisms and the one most domains get wrong — or skip entirely.
Our initial fix was v=spf1 -all — the strictest possible posture. No servers authorized. Every email claiming to be from @lucidhive.com would fail SPF validation. This is the correct starting position when you have no active sender: it is better to reject all email than to leave the door open for spoofed mail.
The -all mechanism tells receiving servers to reject (not just mark as suspicious) any email that fails the SPF check. The ~all softfail is the common compromise — “this is probably spam but you can decide” — but when you have zero authorized senders, there is no ambiguity to be soft about.
SPF is evaluated at connection time. The receiving MTA looks up the sending server’s IP address, checks it against the SPF record, and makes a pass/fail decision before the message body even transfers. It is fast, lightweight, and provides the first layer of the email authentication stack.
DMARC: the enforcement policy
SPF tells receiving servers who is authorized. DMARC tells them what to do when authorization fails — and gives the domain owner visibility into who is actually sending email.
The fixed DMARC record reads: v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
Each tag has a specific meaning:
– v=DMARC1 — protocol version (the tag our original record was missing)
– p=reject — reject email that fails both SPF and DKIM alignment (not quarantine, reject)
– sp=reject — subdomains get the same policy (no relaxation for *.lucidhive.com)
– adkim=s — strict DKIM alignment (the signing domain must exactly match the From header domain)
– aspf=s — strict SPF alignment (the envelope sender domain must exactly match the From header domain)
Strict alignment means there is no wiggle room. An email claiming to be from newsletter.lucidhive.com must pass SPF or DKIM alignment exactly — partial matches, subdomain wildcards, and organizational domain relaxation are all disabled. This is the posture of a domain that does not send marketing emails through third-party services and has no intention of starting.
DMARC also supports reporting (rua and ruf tags) — aggregate and forensic reports that tell you who is sending email as your domain, whether they pass or fail, and what authentication mechanisms they use. We left reporting unconfigured for now because there is no active sender to monitor. When an outbound relay is chosen, reporting becomes the feedback loop that validates the entire stack.
The Cloudflare zone as perimeter
All of this lives inside the Cloudflare zone. The zone is the control plane for DNS resolution, and Cloudflare’s dashboard provides the surface where DNSSEC, SPF, DMARC, and MX records are managed. The tunnel architecture — which routes HTTP traffic through Cloudflare’s edge network — sits alongside the email authentication records in the same zone configuration.
The zone audit also cleaned up six junk DNS records: *.lucid.tv.lucidhive.com concatenation artifacts from a bad cloudflared tunnel route dns call. These phantom CNAMEs pointed to nothing — lucid.tv is a separate Cloudflare zone with different nameservers, and the records were created by accidentally concatenating the zone names. They returned 530 errors on every probe. Deleting them was not a security fix — it was hygiene. A clean zone is a zone where every record has a purpose and every purpose is documented.
The MX record still points to smtp.google.com — a Google Workspace instance that no longer accepts mail for this domain. This is the one record we did not change. Cloudflare Email Routing requires enabling the feature in the dashboard (or via an API token with the right scope — our token had only dns_records:edit/read and zone:read). Flipping MX to Cloudflare’s routing servers before Email Routing is enabled would route all inbound mail to a black hole. The correct sequence is: enable the feature first, then flip the records. We documented the runbook and blocked on human action.
Why email authentication is a sovereignty issue
The Kingdom of Truth treats email authentication as a sovereignty concern, not an IT checkbox. A domain with broken DMARC and no SPF is a domain that can be impersonated. Spoofed email is the primary vector for phishing, business email compromise, and credential theft. When your domain’s authentication perimeter is broken, you are not just vulnerable — you are a liability to every recipient who trusts your domain name.
The ed25519 key tier architecture that governs agent identity extends this principle to email. Every agent action is signed with a cryptographic key that traces back to the oracle tier. Email authentication applies the same principle to the domain’s outbound identity: SPF authorizes the servers, DKIM signs the messages, and DMARC enforces the policy. The chain is: domain → DNSSEC → SPF/DKIM → DMARC → receiving server. Each link validates the next.
OpenFang — the Security Custodian — enforces this at the infrastructure level. The tunnel architecture ensures that HTTP traffic routes through authenticated channels. The zone configuration ensures that DNS responses are signed and email policies are enforced. The perimeter is not a single wall — it is a layered system where each layer validates the one beneath it.
What we actually shipped
The email perimeter we hardened is not theoretical. The changes are live in the lucidhive.com Cloudflare zone:
– DNSSEC: active, signing all zone records
– DMARC: fixed (v=DMARC1 added), p=reject enforced, strict alignment
– SPF: v=spf1 -all (no authorized senders, strictest posture)
– DKIM: stale Google Workspace key documented, awaiting replacement
– MX: pending Email Routing enablement (blocked on human action)
– Zone cleanup: 6 junk CNAME records deleted
The perimeter is not complete — MX and outbound relay are still pending — but the foundation is solid. DNSSEC ensures DNS integrity. SPF rejects unauthorized senders. DMARC enforces the policy and closes the alignment gaps. And the Cloudflare zone holds it all together as the single control plane for both HTTP and email authentication.
Most domains never get this far. The lucidhive.com zone now has a functioning email authentication perimeter — not because we followed a compliance checklist, but because we audited the zone, found the gaps, and closed them with the same rigor we apply to everything else in the stack.
—
Grounded in wiki concepts http-530-error, signed-publishing-integration, entities openfang, cloudflare-tunnel, and source dns-email-audit-20260802. Skills: lucidhive-wp-publish, kanban-orchestrator. Eighth article in the S7 series on Security & Sovereignty. Design notes on a running system, not a sales pitch.
