Email authentication with SPF, DKIM and DMARC

What it is

SPF is a TXT record on the domain name that starts with v=spf1 and lists the hosts allowed to send, for example v=spf1 include:mail.example.net -all. RFC 7208 limits the number of terms that trigger DNS lookups (include, a, mx, ptr, exists, redirect) to ten per check; beyond that, the check returns "permerror". DKIM adds a DKIM-Signature header to each message; the public key is published at selektor._domainkey.example.ch, so several services can sign side by side, each with its own selector. DMARC publishes a policy (p=none, p=quarantine or p=reject) at _dmarc.example.ch. The policy applies when neither SPF nor DKIM matches the visible sender domain ("alignment"), and rua= specifies an address for aggregate reports.

Why it matters

According to widespread reports, large receivers increasingly make acceptance of mail depend on these records, and attackers forge unprotected sender domains for phishing. Conversely, a careless DNS change, such as an overwritten TXT record or a deleted selector, silently breaks delivery: the messages leave the server and are then rejected or filtered out at the receiver.

How to apply

• Identify all legitimate sending services (your own mail server, newsletters, transactional mail, CRM) and merge them into exactly one SPF record. Start with ~all and switch to -all once you have checked the reports. The ten lookups include the include chains of the services.
• Enable DKIM for each service and publish its selector record. When rotating keys, create a new selector instead of overwriting the old one, so that mail still in transit remains verifiable.
• Start DMARC with p=none and a reporting address, review the reports for a few weeks, then move to quarantine and finally reject. Use the sp tag to set a separate policy for subdomains that never send mail.
• Before any DNS change (switching providers, a new website), export the TXT, MX and CAA records and compare them afterwards.

Pitfalls

Two SPF records on the same name are invalid, not additive. Forwarding breaks SPF because the forwarding server is not listed in the record; DKIM survives forwarding, which is why you need both. Mailing lists that modify the subject or footer break DKIM signatures. Subdomains do not inherit an SPF record. Sending reports to an address in a different domain requires an authorization record there (RFC 7489, "Verifying External Destinations"). DMARC reports are XML and stay unread without an analysis tool.

~all or -all under DMARC

Once DMARC is in force with p=quarantine or p=reject, switching from ~all to -all gains nothing: DMARC only distinguishes "SPF pass" from "not pass", softfail and hardfail lead to the same result, and the p= policy decides how the message is handled. -all, however, costs you forwarded mail, because receivers that already reject on SPF hardfail during the SMTP dialog do so before they have checked the DKIM signature, which is the very signature that would otherwise save the forwarded message. Recommendation: use ~all permanently for domains that send, and control strictness through the DMARC policy; use v=spf1 -all together with p=reject only for domains and subdomains that never send mail.