Email Authentication & Deliverability Tools

When an email arrives claiming to be from your domain, the receiving mail server has no built-in way to verify that claim is legitimate — unless you've published an SPF record. An **SPF record explained** simply is a DNS TXT record that tells the world which servers are authorised to send email on your behalf. Without one, anyone can forge your domain in the From address and receiving servers have no mechanism to detect it. With SPF misconfigured — specifically by exceeding the 10-lookup limit or using the wrong qualifier — your legitimate mail fails authentication just as reliably as a spammer's forged message would. This guide covers everything from the mechanism to the syntax to the traps that catch experienced sysadmins.

When a receiving mail server evaluates your SPF record and hits an error that cannot be retried — not a temporary DNS failure, but a permanent structural problem — it returns `permerror`. In the vast majority of cases, **SPF permerror** has exactly one cause: your SPF record requires more than 10 DNS lookups to fully evaluate, violating the hard limit defined in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). The result is that your legitimate outbound mail fails SPF authentication as definitively as a forged message would. This guide covers what permerror means, why the 10-lookup limit exists, how to trace and count your own lookups step by step, and all three realistic fix approaches — from the simple to the operationally demanding.

Most domains that publish a DMARC record never move beyond `p=none`. They enable monitoring, collect reports for a week or two, and then leave the policy at the monitoring stage indefinitely — providing no actual protection against domain spoofing or phishing. A DMARC record at `p=none` is purely informational: it tells receiving servers to report what they see, but instructs them to deliver everything regardless of authentication outcome. **DMARC policy enforcement** — advancing through `p=quarantine` to `p=reject` — is what transforms DMARC from a reporting tool into a genuine anti-spoofing control. Done correctly, this process takes 4–8 weeks and eliminates the vast majority of fraudulent email sent using your domain. Done incorrectly, it silently blocks legitimate mail. This guide is the step-by-step playbook for doing it correctly.

SPF tells receiving servers which IP addresses are permitted to send mail on behalf of your domain. DKIM does something fundamentally different: it cryptographically signs the message itself, allowing the receiver to verify that the content came from an authorised sender and hasn't been modified in transit. A message with a valid **DKIM** signature carries proof of authenticity that survives relaying, forwarding chains, and multiple mail hops. A message without one — or with an invalid signature — gives DMARC nothing to align, degrades your sender reputation, and leaves your domain open to impersonation. This guide covers how DKIM signing and verification work, how the selector DNS record is structured, how to manage multiple selectors across ESPs, and how to rotate keys without disrupting live mail flow.