SPF, DKIM, and DMARC are often lumped together as “email authentication,” but they do different jobs. SPF asks whether a server is allowed to send. DKIM asks whether a signed message can be verified. DMARC asks whether those authenticated identities align with the From domain people see and tells receivers how to handle failures. A healthy setup uses all three.
The shortest comparison
- SPF: authorized sending infrastructure.
- DKIM: verifiable message signature.
- DMARC: alignment and policy for the visible From domain.
Use a free Beacon domain check to view the public records first. It is better to understand the current state than to replace DNS entries based on a generic example.
SPF: a list of allowed senders
SPF is published as one TXT record. It commonly includes your mailbox provider and other authorized systems. Its limitation is important: SPF normally evaluates a technical return-path identity, which may not match the friendly From address. SPF can also fail if the record causes too many DNS lookups. That is why SPF is useful but not a complete anti-spoofing control.
Before editing it, list all email sources and read how to check an SPF record. Never publish two SPF records; receivers can treat that as an error.
DKIM: a signature that receivers can check
DKIM adds a signature to outgoing mail. The receiving system uses a selector in the message to find the matching public key in DNS. If verification succeeds, it shows that the signed content has not been changed in transit and that the signer controls the relevant key.
DKIM needs to be enabled in each sending platform. Publishing one key does not automatically sign mail from a newsletter or support platform. Send a test from every source and inspect the headers; our DKIM guide gives a non-technical path.
DMARC: the layer that makes the visible domain meaningful
DMARC evaluates SPF and DKIM results for alignment with the visible From domain. Passing either aligned SPF or aligned DKIM can satisfy DMARC. It also publishes a policy: monitoring with p=none, suspicious handling with p=quarantine, or rejection with p=reject.
DMARC is not a switch to flip on a Friday afternoon. Start by discovering legitimate sources, then decide whether stronger enforcement is safe. See the DMARC policy comparison.
Example: why all three matter
A marketing platform sends a campaign with an authorized SPF server but uses its own unrelated return-path domain. SPF may pass, yet it may not align with your visible From domain. If the platform also signs with DKIM using your domain, aligned DKIM can support DMARC. If neither identifier aligns, DMARC can fail even though one technical check looked positive. This is normal behavior, not a reason to weaken DMARC blindly.
What to configure first
- Inventory every legitimate sender.
- Make one complete SPF record.
- Enable DKIM for each service and verify actual test messages.
- Publish DMARC in monitoring mode.
- Use results to correct alignment and unknown senders.
- Consider quarantine or reject only when legitimate mail is protected.
Common confusion
“SPF passes, so I am protected.” Not necessarily; alignment matters. “DKIM is a DNS record only.” No; the provider must also sign messages. “DMARC makes all email inbox.” No; it establishes identity, while list quality, reputation, and content still influence placement.
If mail still goes to spam after authentication is sound, use this deliverability checklist to work through the next factors.
Before you edit DNS
Take a current snapshot and know which service owns each line. A common failure is pasting a new SPF record supplied by a vendor over the company’s existing record, silently removing the mailbox provider. Another is publishing DKIM while leaving the provider setting off. Use the vendor’s own setup instructions, change one system at a time, and test a real message afterward. If a contractor manages DNS, ask them to document both the record and why it is needed.
Remember that technical wording can vary by provider. “Domain authentication,” “custom sending domain,” and “email signing” may all describe parts of the same setup. The important evidence is the authentication result on a sent message and the aligned visible From domain—not the label in a dashboard.
Keep the test message with the change record for future troubleshooting.
Maintain the setup
New vendors and DNS changes are the usual source of drift. Document the owner and purpose of every sending system. Recheck after a platform migration and consider monitoring once the setup is correct so relevant record changes are not invisible.
Frequently asked questions
Does DMARC require SPF and DKIM?
DMARC evaluates SPF and DKIM. A useful implementation normally configures both, although a message can pass DMARC through one aligned result.
Which one should I fix first?
Start with an inventory and current-record check. In practice, a single valid SPF record and working DKIM for every provider make DMARC investigation much safer.