The Perimeter You Can Actually Feel
Most of the security layers in this series are invisible: key checks inside the gate, taint tracking in the pipeline, scope geometry in the keys. The email and DNS perimeter is the opposite. It is the one part of the sovereign stack that external mail servers, DNS resolvers, and spam filters inspect on every interaction. When it is misconfigured, the failure is immediate and public: mail lands in spam, lookups fail, spoofers pass. When it is right, the fleet’s identity is verifiable from the outside — no inside knowledge required.
This article is the practical checklist behind the S7.8 email-perimeter work: what the fleet actually hardened, why each layer matters, and how the checks hold up against the most common attack patterns.
The DNS layer: where identity starts
DNS is the phone book of the internet, and the phone book must be tamper-evident. The first hardening step is DNSSEC: cryptographic signatures on DNS records so that a resolver can verify that the answers it receives really came from the zone’s authoritative server. Without DNSSEC, a poisoned cache or a malicious resolver can redirect traffic, and neither the sender nor the receiver can tell. With it, the zone’s records are signed and the signature chain is checked by the resolver.
The practical setup: the zone is signed at the registrar level, DS records are published, and the Cloudflare-managed DNS serves signed answers. The verification is external — dig +dnssec shows the chain. The audit layer records the check as part of the periodic perimeter verification, so the fleet does not rely on the setup being correct once; it relies on the setup being verified on a schedule.
The email layer: SPF, DKIM, and DMARC
Email authentication answers three questions about every message: is the sender’s server allowed to send for this domain (SPF), does the message carry a verifiable signature from the domain’s key (DKIM), and what should receivers do with messages that fail both (DMARC).
- SPF publishes the list of servers authorized to send mail for the domain. A mail server receiving a message checks the sending IP against the SPF record. Simple, but spoofable in the gap between SPF and the visible “From” address — which is why SPF alone is not enough.
- DKIM signs the message with a domain key. The signature covers the message body and selected headers, so the receiver can verify both that the message came from the domain and that it was not altered in transit. DKIM survives forwarding, which SPF does not.
- DMARC tells receivers what to do with messages that fail SPF and DKIM: none (monitor only), quarantine, or reject. The fleet publishes a strict DMARC policy — reject — and a reporting address so that authentication failures are visible in aggregate reports.
The three mechanisms close each other’s gaps. SPF covers the sending server, DKIM covers the message, and DMARC covers the policy. A fleet that publishes all three with a reject policy makes it structurally hard for an attacker to send mail that looks like it comes from the domain — the mail will fail authentication and be rejected by policy.
What the perimeter actually blocks
Concrete attack patterns and how the layers stop them:
- Domain spoofing. An attacker sends mail with the fleet’s domain in the “From” header. Without SPF/DKIM/DMARC, receivers may accept it. With the full stack, the mail fails SPF (wrong server), fails DKIM (no valid signature), and DMARC says reject. The attack is blocked by policy, not by vigilance.
- Cache poisoning. An attacker tries to redirect the domain’s traffic by poisoning a resolver. DNSSEC’s signature chain makes the forged answer fail validation. The attack is blocked by cryptography, not by luck.
- Lookalike takeover. An attacker registers a similar domain and tries to harvest mail sent to the real one. DNSSEC and email authentication cannot stop the registration, but the fleet’s own mail and DNS are verifiable, so the lookalike cannot pass the checks the real domain passes. The attacker’s messages fail, and the fleet’s own outbound mail is provably genuine.
The verification loop
Configuration is not the same as protection. The perimeter is checked on a schedule, and the checks are recorded in the audit layer (S7.7): DNSKEY/DS presence, SPF record validity, DKIM key rotation and publication, DMARC policy strength and aggregate reports. A drift — a missing DS record after a registrar change, a DKIM key about to expire, a DMARC policy accidentally downgraded — shows up in the ledger as a security event, not as a surprise during an incident.
The perimeter also participates in the recovery discipline (S7.11): the DNS and email configuration is part of the verified state that gets restored and re-verified after an incident. A compromised zone is rebuilt from the signed, known-good configuration — never hand-edited in a panic.
Why the perimeter belongs in the sovereign stack
For the S6 series, the email and DNS perimeter is the first thing a customer’s own systems check when interacting with the fleet. Mail from the fleet passes SPF, DKIM, and DMARC — not because a human remembered to configure it, but because the configuration is part of the stack’s verified state. DNS lookups validate against a signed chain. This is sovereignty in the small: the fleet’s identity on the open internet is under the fleet’s own control, verifiable by anyone, without renting trust from a third party.
The checklist is short and mechanical. It is also the layer where “we hardened it” has the most direct, checkable meaning: any mail server in the world can verify it, right now, without asking permission.
Grounded in wiki concepts dnssec, spf, dmarc, email-authentication, domain-verification, zone-management, entity cloudflare, and the S7 security series. Design notes on a running system.
