Email authentication is not one mechanism but three that work together. SPF says which servers may send for your domain. DKIM signs each message cryptographically. DMARC ties the two together and tells receivers what to do when they disagree. Understanding the division of labour is the difference between a deliverability problem you can diagnose and one you cannot.
SPF: the allowed-senders list
SPF (Sender Policy Framework) is a TXT record on your domain that lists the IP addresses and hosts authorised to send mail from it. When a receiving server gets a message claiming to be from you, it checks whether the connecting IP matches your SPF record. If it does, the message passes SPF; if not, it fails.
The catch is the 10-lookup limit. SPF allows include mechanisms and redirects, each of which triggers another DNS lookup. If your record chains through too many third-party senders, receivers stop evaluating after 10 lookups and return PermError. Count your lookups — every include, a, mx, and ptr counts — and trim the record when you approach the limit.
DKIM: the per-message signature
DKIM (DomainKeys Identified Mail) works differently. Your sending mail server adds a cryptographic signature to the message header, computed over selected headers and the body. The public key used to verify that signature is published as a TXT record under a selector name, for example s1._domainkey.example.org.
Because the signature is per-message, DKIM survives forwarding in a way SPF often does not — a forwarder that rewrites the envelope sender breaks SPF but preserves a valid DKIM signature. The selector design also lets you rotate keys without downtime: publish a new selector, start signing with it, then retire the old one once receivers have caught up.
DMARC: the policy layer
DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM and adds two things they lack: alignment and policy. Alignment requires that the domain the recipient sees (the From header) matches the domain that passed SPF or DKIM. Policy tells receivers what to do when authentication fails: none (monitor only), quarantine (send to spam), or reject (drop it).
The standard rollout is to start with p=none and a rua reporting address, collect aggregate reports for a week or two to see which legitimate senders are failing, fix them, then step up to quarantine and finally reject. Jumping straight to p=reject without monitoring is how legitimate mail ends up in the void.
Verifying all three
Each mechanism has its own failure mode, so verify each independently. An SPF check parses your record, counts lookups, and flags syntax problems. A DKIM check retrieves the public key for a given selector and confirms it matches a real signature. A DMARC check reviews the policy, alignment requirements, and reporting address. Run all three before you blame deliverability on anything else.
When all three are correctly configured and aligned, receivers have strong, machine-checkable evidence that a message is genuinely from you. That evidence is what lands your mail in the inbox instead of the spam folder.