The three email authentication mechanisms are described in hundreds of guides, and yet a typical rollout looks like this: the administrator publishes an SPF record with a hard fail, enables DMARC with a reject policy, and the next day learns that the invoicing system, the newsletter tool and the printer sending scans have stopped reaching recipients. The problem is not in the mechanisms but in the order.
What each mechanism does
SPF publishes in DNS a list of addresses allowed to send mail on behalf of the domain. The recipient checks the address of the server that connects to it.
DKIM signs the message with the sending server’s private key; the public key is in DNS. The recipient verifies that the content was not altered and comes from an authorised system. The signature survives forwarding, which SPF does not.
DMARC ties the two together: it requires the domain in the sender address visible to the user to align with the domain that passed SPF or DKIM, and tells the recipient what to do when it does not: nothing, quarantine, or reject. It also asks for reports on who sends mail on behalf of the domain.
Step 1: reports before tightening anything
The first DMARC record has a none policy and an address for aggregate reports. It changes nothing in delivery, but over a few weeks it collects information on which addresses send mail with the domain in the sender field. The list always surprises: the HR system, an alerting application, a survey provider, the scanner at reception, a partner sending on the company’s behalf. Without that list every policy is guesswork.
Four to six weeks of reports is the minimum to catch monthly sends.
Step 2: SPF with the full list
The SPF record includes every source from the reports: own servers, the cloud mail service, providers sending on behalf of the domain. Two technical constraints:
- a limit of ten DNS lookups across the whole record, nested ones included; exceeding it is a permanent error and a rejection by some recipients,
- one SPF record per domain; two records is an error.
The record initially ends with ~all (soft fail). The hard -all comes last, once DMARC reports no longer show legitimate sources outside the list.
Step 3: DKIM for every source
Every system sending mail signs it with its own key under its own selector. The cloud mail service has one, the newsletter tool one, the internal relay one. Keys of at least 2048 bits, rotated on the provider’s schedule. Subdomains used by external providers are configured so that the signature aligns with the main domain, otherwise DMARC will not accept them.
Once DKIM is on, the reports show which sources sign and which do not. Sources that cannot sign are candidates for routing through an internal relay.
Step 4: DMARC gradually
When the reports show that all legitimate mail passes SPF or DKIM with domain alignment, the policy changes to quarantine with pct=10: ten percent of non-compliant mail goes to the recipient’s spam folder. After a week without complaints, pct rises to 50, then 100. Then reject, again through pct. At every stage the reports are reviewed, and user complaints about undelivered mail are checked for alignment failures.
Subdomains are a separate decision: the subdomain policy can be stricter than the main one, because subdomains that send no mail can go straight to reject.
Step 5: hard SPF and ongoing monitoring
After reaching reject, the SPF record changes its ending to -all. DMARC reports are still collected and reviewed monthly: a new provider added by the marketing department without IT’s knowledge will show up in the reports before customers call.
Summary
The order: DMARC reports with a none policy, then SPF with the full list and a soft ending, then DKIM for every source, then tightening DMARC by percentages, and hard SPF last. Every step is verified by reports, not by assumption. The rollout takes two to three months, and during that time no legitimate message is lost. A one-day rollout takes one day and several weeks of repairs.