DNS hygiene for small networks
Every service you publish and every mail domain you send from is described by DNS, and DNS is where those descriptions go stale. A record pointing at an address you no longer control sends your visitors to a stranger, and a mail policy nobody reviews leaves room for someone else to send as you. For a small network that sends email, hosts services or does both, the work is mostly about keeping the published answers true and making each one say what it means.
SPF in plain terms
SPF, the Sender Policy Framework, is a DNS record that says which hosts may use your domain in the SMTP envelope. When a receiving server handles a message, it looks up the SPF record for the domain in the MAIL FROM, the envelope sender that mail clients call the return path, and may separately check the HELO or EHLO identity. RFC 7208 recommends checking HELO first when both identities are checked. If the sending host is not listed, the message is more likely to be treated as suspicious.
SPF says nothing about the From header a person reads in their mail client. Closing that gap is the job of alignment, which DMARC applies to the SPF result, so a record that authorises your sending hosts is only one part of the story.
An SPF record is a TXT record published for a domain. It is usually written at the domain you send from, but SPF is evaluated against the domain in the envelope sender, so the record may sit at an envelope subdomain instead of at the apex of the visible domain. Its mechanisms describe the allowed senders: ip4, ip6, a, mx, include and all. Keep the list short and explicit. An evaluation may use at most ten terms that trigger DNS lookups, including terms reached through nested includes and redirects. This is a limit on evaluated terms, not a count of individual DNS packets, so a record that accumulates third-party includes can exceed that limit, which returns a permanent error and stops the record authorising anything at all (RFC 7208). End the record explicitly. -all makes a sender you did not list produce an SPF fail, which a receiver may act on by rejecting the message or by treating it as suspicious, and redirect hands the evaluation to a policy you administer for several domains.
Test SPF changes before publishing them. A misconfigured record can cause legitimate mail to be rejected or to lose alignment, and receivers cache the result for the length of the TTL, so a bad change stays in effect for longer than the change took.
DKIM and message integrity
DKIM, DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages. The signature covers selected headers and a hash of the message body. The receiver checks it against a public key published under a selector name, such as selector1._domainkey.example.com. DKIM applies defined canonicalization rules, so some formatting changes are tolerated. Changes to covered content that alter the canonicalized data cause verification to fail. Unsigned headers are not protected, and an optional body-length limit can leave appended content outside the signature. These limits are described in RFC 6376.
DKIM requires coordination between your mail server and your DNS. The server signs outgoing messages with a private key that never leaves it, and the matching public key is published as a TXT record. Rotate keys on a schedule, and prepare the rotation rather than performing it under pressure: publish the new selector and start signing with it, keep the old selector published until mail signed with it has expired, then remove it.
DMARC as the policy layer
DMARC is where the two checks are brought together with a policy. DMARC extracts the domain visible in the From header and compares it with the identity that authenticated the message. A message passes when either of two things holds: SPF passes and the SPF-authenticated domain is aligned with the From domain, or DKIM passes and the signing domain is aligned with the From domain. A message does not need both checks to pass. If neither provides an aligned pass, DMARC fails. That does not prove forgery: forwarding and message modification can also cause failures, and receivers apply their own handling policies (RFC 7489).
Alignment has two forms. In relaxed mode the two domains share an organisational domain, so mail from sub.example.com aligns with example.com. In strict mode the domains have to match exactly. Relaxed is the usual choice for a small network that sends from subdomains.
The policy value p= takes none, quarantine or reject and applies to mail that fails. Start with none and read the reports. When the reports show only the mail you expect, move to quarantine and watch what it catches. Move to reject after legitimate sending sources are accounted for and the remaining failure cases have been investigated. A percentage value rolls enforcement out gradually, and a separate sp= value controls the treatment of subdomains, which otherwise follow the main policy.
Reports are requested inside the record itself. rua asks for aggregate reports by destination, and ruf asks for per-message failure reports. An aggregate report usually lists the sources that sent mail in your name and the outcome of their alignment checks, but reporting depends on the receiving server and its policy, so a source missing from the reports is not proof that it never sent. Read them, and treat them as operational data, because they describe sending hosts you did not choose.
DNSSEC and trust in the chain
DNSSEC adds cryptographic signatures to DNS records so that a resolver can check that an answer came from the zone and was not altered. It needs support on both sides: the host serving your zone has to be able to sign it, and the registrar has to let you publish a DS record for it. If either is missing, the chain of trust stops there.
Key rotation is part of the ongoing cost. If the signatures expire and are not renewed, validating resolvers can no longer validate the zone and the domain stops resolving for them. Put the rollover date in the same calendar as patching. DNSSEC protects the answers, not the service behind them, so a correctly signed record can still point at a host with problems of its own.
Record hygiene
Keeping the zone clean is the other half of the job. Remove records for services that no longer exist, because a stale address record sends traffic to whoever holds that address now.
TTL values decide how long resolvers and caches keep an answer, so a TTL is a statement about how quickly you want a change to take effect. Short TTLs mean more queries reach your authoritative servers, since every resolver has to ask again soon. Long TTLs mean fewer queries, and a change that takes that long to spread. Match the TTL to how often the record actually changes.
Reverse records live in their own zone rather than in your forward zone. A PTR record maps an IP address to a name in the in-addr.arpa tree for IPv4 and ip6.arpa for IPv6, and whoever holds the IP address normally controls that zone, which for hosted mail is the provider rather than you. RFC 1912 asks that PTR and A records match and that every reachable address has a PTR record. Many receiving systems check that match when mail arrives from your hosts.
Checklist
- Publish one SPF record for the domain you send from, at the apex or at the envelope subdomain, and end it explicitly.
- Keep SPF inside the limit of ten DNS-querying terms, counting nested mechanisms.
- Sign outbound mail with DKIM, publish the selector key, and retire old selectors only after mail signed with them has expired.
- Publish a DMARC record with
p=none, read the aggregate reports, then move toquarantineandreject. - Enable DNSSEC only when the zone host and the registrar both support it, and schedule the key rollover.
- Remove records for services that no longer exist, and set each TTL to match how often that record changes.
- Keep forward and reverse names in step for every address that sends mail.