SPF vs DKIM vs DMARC: How Email Authentication Actually Works

Three separate DNS-based mechanisms decide whether an email claiming to be from your domain reaches an inbox, and each does a different job. SPF (Sender Policy Framework, RFC 7208) is a TXT record listing which mail servers are authorized to send on the domain's behalf, ending in a qualifier that tells receivers what to do about everyone else: -all rejects unauthorized senders outright, ~all marks them as suspicious without blocking, ?all takes no position, and +all explicitly authorizes any server — a serious misconfiguration rather than a relaxed policy. DKIM (DomainKeys Identified Mail, RFC 6376) works differently: the sending server cryptographically signs each outgoing message, and the public key is published at a <selector>._domainkey.<domain> TXT record, so a receiving server can verify the message wasn't altered in transit and genuinely came from a server holding the matching private key. DMARC (RFC 7489), published at _dmarc.<domain>, is the record that actually enforces something: it requires SPF or DKIM to pass and align with the visible From: header, then applies a policy — p=none only monitors and reports, p=quarantine sends failures to spam, p=reject blocks them outright — with rua= specifying where aggregate failure reports get sent. SPF and DKIM alone don't stop spoofing; without a DMARC policy enforcing them, a message that fails both can still land in an inbox.

Reading all three correctly means parsing an SPF record's mechanisms and qualifier, finding and decoding the _dmarc TXT record's policy and reporting tags, and knowing what each combination actually means for deliverability and spoofing risk. The DNS Inspector does this automatically: enter any domain and it parses the SPF qualifier into a plain Strict/Moderate/Wide-Open verdict, decodes the DMARC policy into Protected/Monitoring/Unprotected, and shows both alongside every other DNS record for the domain in one scan.