THE CONNECTIONS BEHIND YOUR BUSINESS
SPF, DKIM and DMARC Explained
Learn how sending authorization, message signatures and domain alignment work together, with safe read-only checks.
Email authentication answers three different questions. It does not promise inbox placement, prove a message is harmless or encrypt its contents.
Start here: three checks, different jobs
| Check | What it tests | Important limit |
|---|---|---|
| SPF | Whether a connecting sender is authorized for the envelope domain | Forwarding can change the connecting server |
| DKIM | A signature associated with a signing domain | Changes to signed content can invalidate it |
| DMARC | Alignment with the visible From domain using passing SPF or DKIM | Authentication can pass for an unrelated domain |
The envelope sender used during SMTP can differ from the From address a reader sees. DMARC needs a passing, aligned SPF result or a passing, aligned DKIM result. Both do not have to pass; ordinary relaxed alignment can match organizational domains. Do not judge alignment from display names.
1. Inventory legitimate senders before editing
List your mailbox service, website forms, invoicing tools and marketing platforms. For each, record its documented sending domain, SPF guidance and DKIM setup. Receiving mail through one provider does not mean every outgoing message uses it. Preserve current DNS records before changes.
SPF is a TXT record beginning with v=spf1. Publish one SPF policy per name, not a separate policy for each vendor. Its DNS-querying terms have a limit; merging includes without evaluating that limit can break authentication. RFC 7208 defines SPF evaluation.
2. Inspect DNS and one real received message
These Windows queries only read DNS. Replace the DKIM selector with the selector shown in the message’s DKIM-Signature or your sender’s documentation; selector is not a universal fixed name.
Resolve-DnsName your-domain.example -Type TXT
Resolve-DnsName _dmarc.your-domain.example -Type TXT
Resolve-DnsName selector._domainkey.your-domain.example -Type TXTA provider may publish DKIM through a CNAME instead. Query that type when documented. A public key in DNS proves publication, not that your outgoing service is actually signing.
At a trusted receiving mailbox, inspect Authentication-Results and DKIM-Signature. Compare the receiver’s SPF result/domain, DKIM result/signing domain, and DMARC result/visible From domain. Ignore authentication text inserted by an untrusted sender. Keep personal addresses, message bodies and IDs out of public support posts.
3. Introduce policy carefully
A DMARC monitoring policy such as p=none requests reporting without requesting quarantine/rejection. Reports require a working, authorized destination and may contain sensitive sender metadata. It is not an enforcement policy. Inventory and fix legitimate senders before a staged move toward quarantine or reject; check subdomain coverage separately. RFC 7489 defines policy and alignment; RFC 6376 describes DKIM signatures.
If a legitimate sender fails
Stop policy escalation. Preserve the evidence, identify the actual sending system and correct its documented authorization/signing setup. Do not add another SPF record, allow every IP or disable spam protection. For Microsoft-specific configuration, use Microsoft 365 authentication records.
Official references
Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.