SPF vs DKIM vs DMARC: What Each Record Does and Which One to Fix First

Quick answer: SPF vs DKIM vs DMARC

• SPF = which servers may send.
• DKIM = whether this message was signed properly.
• DMARC = if authentication fails, what should the receiver do.

If you cannot receive email, check MX first. If you can send but emails land in spam or fail authentication, check SPF, DKIM, and DMARC.

For a broader troubleshooting path, start with the email DNS checker guide.

Which one should you fix first?

The right first fix depends on the symptom.

For most domains, the safe setup order is:

MX -> SPF -> DKIM -> DMARC

But the safe troubleshooting order depends on the symptom. If your website works but email does not, use the website works but email does not guide before editing authentication records.

SPF, DKIM, and DMARC are not the same thing

A common mistake is treating SPF, DKIM, and DMARC like three versions of the same record. They are not. They answer different questions.

• SPF can pass while DKIM is missing.
• DKIM can pass while DMARC fails.
• DMARC can exist but still only monitor if the policy is p=none.
• MX can be perfect while outgoing email still lands in spam.
• Website DNS can be perfect while email DNS is broken.

If incoming email is the broken part, read the MX record checker guide first.

What is SPF?

SPF stands for Sender Policy Framework.

SPF is a DNS TXT record that lists the servers and services allowed to send email for your domain.

For example, if your domain uses Google Workspace, your SPF record may authorize Google to send email.

A Google Workspace-only SPF record often looks like:

v=spf1 include:_spf.google.com ~all

A Microsoft 365-only SPF record often looks like:

v=spf1 include:spf.protection.outlook.com -all

Do not copy those blindly. Your correct SPF record depends on which services actually send email for your domain.

For SPF-specific cleanup, use the SPF record checker guide.

What SPF actually checks

SPF checks whether the sending server is allowed to send for the envelope sender domain.

That is not always the same as the visible From address that the recipient sees.

A user may see this visible From address:

From: Your Company <hello@example.com>

But the technical return-path may be:

bounce@emailservice.com

SPF may pass for emailservice.com, but that does not necessarily mean SPF aligns with example.com for DMARC.

Do not assume SPF pass always means DMARC pass. Alignment matters.

SPF record location

SPF is usually published as a TXT record at the root domain.

For example.com, the SPF record usually lives at example.com. In DNS dashboards, the host/name is usually @.

If you send from a subdomain, that subdomain may need its own SPF record. For example, news.example.com may have a separate SPF record from example.com.

The biggest SPF mistake: duplicate SPF records

A domain should not have multiple SPF records at the same name.

Wrong:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com -all

This does not mean both Google and Microsoft are safely authorized. It creates duplicate SPF records.

Correct if both providers genuinely send email for the domain:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Only include a provider if that provider actually sends email for your domain. Legitimate senders should be merged into one SPF record.

SPF strengths and weaknesses

SPF is important, but it is not enough by itself.

What is DKIM?

DKIM stands for DomainKeys Identified Mail.

DKIM lets your email provider sign outgoing messages using a private key. Receiving mail servers then check a public key in DNS to verify the signature.

DKIM proves that the message was signed by a domain-authorized system and was not changed in a way that breaks the signature.

A DKIM record might look like this:

google._domainkey.example.com

or:

selector1._domainkey.example.com

The exact DKIM record depends on your email provider. For selector-specific help, use the DKIM record checker guide.

What DKIM actually checks

DKIM checks a cryptographic signature in the email headers.

A DKIM-signed message contains a header similar to:

DKIM-Signature: v=1; d=example.com; s=google; ...

Two parts are especially important:

If d=example.com and s=google, the receiver checks the DKIM record at:

google._domainkey.example.com

That is why DKIM is selector-based.

DKIM record location

DKIM records are usually published at:

selector._domainkey.example.com

Common examples include:

google._domainkey.example.com
selector1._domainkey.example.com
k1._domainkey.news.example.com

In Cloudflare, the Name field may be google._domainkey or selector1._domainkey because Cloudflare appends the root domain automatically.

Checking only the root domain is not enough for DKIM.

DKIM can be TXT or CNAME

Different providers use different DKIM record types.

Do not guess. Use the exact DKIM record type and value given by your provider.

Google Workspace commonly uses TXT DKIM generated in Google Admin. Microsoft 365 custom-domain DKIM uses CNAME selectors.

DKIM strengths and weaknesses

Do not assume DKIM pass always means DMARC pass. Alignment still matters.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.

DMARC tells receiving mail servers what to do when a message claiming to be from your domain fails authentication and alignment checks.

DMARC depends on SPF and DKIM.

A basic DMARC record looks like:

v=DMARC1; p=none;

It is published at:

_dmarc.example.com

In many DNS dashboards, the Name field is _dmarc.

For policy rollout details, use the DMARC record checker guide.

DMARC policy levels

DMARC has three common policy levels:

A safe rollout usually looks like:

p=none -> p=quarantine -> p=reject

Do not jump straight to p=reject if you are unsure whether all legitimate senders are authenticated.

What DMARC actually checks

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain.

The visible From domain is what users see in the email client.

From: Your Company <hello@example.com>

The visible From domain is example.com.

For DMARC to pass, the message usually needs either SPF pass with alignment or DKIM pass with alignment. It does not always need both.

Having both SPF and DKIM correctly configured is better, but either one can satisfy DMARC if it aligns.

DMARC alignment explained simply

Alignment means the authenticated domain matches or is related to the visible From domain.

DKIM alignment example

Good:

Visible From: hello@example.com
DKIM signing domain: example.com

Problem:

Visible From: hello@example.com
DKIM signing domain: emailservice.com

DKIM may pass for emailservice.com, but it may not help example.com pass DMARC.

SPF alignment example

Good:

Visible From: hello@example.com
Return-path: bounce@example.com

Problem:

Visible From: hello@example.com
Return-path: bounce.thirdpartyservice.com

SPF may pass for thirdpartyservice.com, but it may not align with example.com. This is why third-party email platforms often ask you to authenticate your domain.

DMARC strengths and weaknesses

DMARC is powerful, but it should be rolled out carefully.

SPF vs DKIM vs DMARC comparison table

SPF, DKIM, and DMARC setup order

For a new business domain, a sensible setup order is:

1. MX - make sure incoming email routes to the right provider.
2. SPF - authorize the main sending provider.
3. DKIM - enable signing for the main sending provider.
4. DMARC - publish a monitoring policy.
5. Third-party senders - authenticate CRMs, newsletter tools, forms, and transactional senders.
6. DMARC enforcement - move gradually toward quarantine or reject.

A basic safe DMARC starting point is:

v=DMARC1; p=none;

Do not enforce strict DMARC until you know your legitimate senders are passing SPF or DKIM alignment.

Which one matters most?

If you cannot receive email

SPF, DKIM, and DMARC are not the first place to look. Check nameservers, MX records, mailbox or alias setup, provider verification, and provider activation.

Read the MX record checker guide if receiving is broken.

If your sent emails go to spam

Check SPF, DKIM, DMARC, third-party sender authentication, domain reputation, email content, and sending volume.

Authentication helps, but it does not guarantee inbox placement by itself.

If DMARC fails

Check whether SPF passed, whether DKIM passed, whether SPF aligned with the visible From domain, whether DKIM aligned with the visible From domain, whether the sender is a third-party platform, and whether DMARC is valid at _dmarc.

DMARC failure is often an alignment issue, not just a missing DNS record.

If SPF fails

Check whether SPF exists, whether there is only one SPF record, whether SPF includes the real sending provider, whether old providers were removed too early, whether the SPF record is too long, and whether forwarding is involved.

If DKIM fails

Check whether DKIM is enabled in the provider admin, whether the selector is correct, whether the DNS record type is TXT or CNAME as required, whether the public key or CNAME target was copied correctly, whether DNS propagated, and whether the message was modified after signing.

The email DNS propagation guide can help when records were recently changed but still look wrong.

Common scanner result combinations

Passing SPF, DKIM, and DMARC does not guarantee inbox placement. Reputation, content, volume, bounces, and complaints also matter.

SPF vs DKIM vs DMARC for Google Workspace

For Google Workspace, a clean setup usually includes:

• Google SPF is added in DNS, not generated in Google Admin.
• Google DKIM should be generated in Google Admin.
• DKIM must be started or activated after DNS is published.
• DMARC should be added after SPF and/or DKIM are working.
• Third-party senders need separate authentication.

Read the Google Workspace and Cloudflare guide for a Google + Cloudflare checklist.

SPF vs DKIM vs DMARC for Microsoft 365

For Microsoft 365, a clean setup usually includes:

• Microsoft MX is domain-specific.
• Microsoft DKIM values are tenant/domain-specific.
• Microsoft 365 custom-domain DKIM uses CNAME records, not TXT records.
• DKIM CNAME records should be DNS-only in Cloudflare.
• Third-party senders may need separate SPF/DKIM setup.

Read the Microsoft 365 and Cloudflare guide for a Microsoft + Cloudflare checklist.

SPF, DKIM, and DMARC for third-party senders

Many businesses send email from more than one place.

• Google Workspace
• Microsoft 365
• Website contact forms
• CRMs
• Email marketing tools
• Helpdesk systems
• Ecommerce platforms
• Booking platforms
• Invoicing tools
• Transactional email providers
• Cold email tools

Important rule

One DKIM record for Google Workspace does not authenticate your newsletter platform. One Microsoft SPF record does not automatically authenticate your website form. One DMARC record does not magically fix every sender.

You need to identify every platform that sends email using your domain and authenticate each one properly.

Example: normal mailbox plus newsletter tool

You may need:

If Google emails pass authentication but newsletters fail DMARC, the newsletter platform may not be authenticated with your domain.

Example: Microsoft 365 plus website contact form

You may need:

If Microsoft emails pass but contact form emails fail, the contact form sender probably needs separate authentication.

Common misconceptions

Safe rollout checklist

1. Confirm active nameservers.
2. Confirm where DNS is managed.
3. Check MX records.
4. Confirm mailboxes and aliases exist.
5. Add one clean SPF record.
6. Include only legitimate senders in SPF.
7. Enable DKIM for the main email provider.
8. Add DKIM for third-party senders.
9. Add DMARC at _dmarc.
10. Start DMARC with p=none if unsure.
11. Send test emails from each platform.
12. Check SPF, DKIM, and DMARC results.
13. Fix alignment issues.
14. Move to p=quarantine only after testing.
15. Move to p=reject only when confident.

Troubleshooting order by symptom

Symptom: I cannot receive email

1. Nameservers
2. MX records
3. Old MX records
4. Mailbox or alias
5. Provider verification
6. Provider activation

SPF, DKIM, and DMARC are not the first fix for receiving failures.

Symptom: My sent email goes to spam

1. SPF
2. DKIM
3. DMARC
4. Third-party sender authentication
5. Domain age and reputation
6. Email content
7. Sending volume

Authentication is necessary, but not always sufficient.

Symptom: My domain can be spoofed

1. SPF exists and is clean.
2. DKIM is enabled.
3. DMARC exists.
4. DMARC policy is not only monitoring forever.
5. Legitimate senders pass before enforcement.
6. Move gradually toward quarantine or reject.

DMARC enforcement is the major step for stronger spoofing protection.

What not to do

• Do not change website A/CNAME records when the problem is email authentication.
• Do not create multiple SPF records.
• Do not guess DKIM selectors.
• Do not create Microsoft DKIM as TXT records.
• Do not assume DKIM exists just because SPF exists.
• Do not add DMARC at the root domain.
• Do not start with p=reject before testing senders.
• Do not assume passing SPF/DKIM guarantees inbox placement.
• Do not forget third-party platforms.
• Do not remove old sender records during an active migration without checking.
• Do not ignore alignment when diagnosing DMARC.
• Do not fix DMARC before understanding SPF and DKIM.

Final recommendation

SPF, DKIM, and DMARC work best together.

A good setup should have:

• One clean SPF record
• DKIM enabled for each real sending platform
• DMARC published at _dmarc
• A safe DMARC rollout path
• Test emails from every important sender
• Authentication results checked in real message headers

The simplest mental model is:

SPF = allowed senders
DKIM = signed messages
DMARC = policy and alignment

Fix MX first if email is not being received. Fix SPF and DKIM first if outgoing authentication is weak. Add DMARC carefully, starting with monitoring if unsure, then move toward enforcement only after legitimate mail passes.

Run an SPF, DKIM, and DMARC check

Use Domain Email Doctor to scan your domain's public email DNS records before changing anything.

The scan can help show whether SPF is missing or duplicated, whether DKIM may be missing, whether DMARC exists, and whether MX or nameserver issues are actually the first problem to solve.

Do not guess. Check the records first, then fix the record that matches the symptom.