Email Going to Spam: DNS Records to Check Before Blaming Your Email Provider

Quick answer: what should you check first?

If your email is going to spam, check these in order:

SPF, DKIM, and DMARC are necessary for trust, but they do not guarantee inbox placement.

If you want the broader DNS checklist first, start with the email DNS checker guide.

DNS can cause spam placement, but it is not the only cause

Email deliverability is not controlled by one DNS record.

Spam filtering can consider many signals, including:

• SPF result
• DKIM result
• DMARC result
• Domain reputation
• IP reputation
• Spam complaint rate
• Bounce rate
• Sending volume
• Sending history
• Email content
• Link reputation
• Recipient engagement
• Whether recipients expected the email
• Whether unsubscribe is easy for marketing emails
• Whether the message looks like phishing or impersonation

DNS is the right place to start because it is objective and fixable.

But if SPF, DKIM, and DMARC all pass and emails still go to spam, the next issue is likely reputation, content, list quality, or sending behavior.

For a plain-English comparison of the three authentication records, use the SPF vs DKIM vs DMARC guide.

First: check a real email header

Do not rely only on your DNS dashboard.

A DNS record can exist, but your actual sent email may still fail authentication.

• SPF record exists, but the actual sender is not included.
• DKIM record exists, but the provider is not signing.
• DKIM passes, but it signs with the provider's domain instead of yours.
• DMARC exists, but SPF/DKIM do not align with the visible From domain.
• Google Workspace passes, but your newsletter tool fails.

The best first step is to send a test email to an external mailbox and inspect the message headers.

What to look for

In the message headers, look for something like:

Authentication-Results:
spf=pass
dkim=pass
dmarc=pass

A strong result may look like:

Authentication-Results: mx.google.com;
       spf=pass;
       dkim=pass header.i=@example.com;
       dmarc=pass

If you see this, you likely have an authentication problem to fix:

spf=fail
dkim=none
dmarc=fail

SPF: check whether your sending service is authorized

SPF stands for Sender Policy Framework.

SPF tells receiving mail servers which services are allowed to send email for your domain. SPF authorizes sending services and should usually be one TXT record at the root domain.

A simple Google Workspace-only SPF record often looks like:

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

A simple Microsoft 365-only SPF record often looks like:

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

Do not copy these blindly unless they match your actual sender.

For a detailed SPF cleanup walkthrough, use the SPF record checker guide.

The biggest SPF spam problem: third-party senders

Many businesses set up SPF for their main mailbox provider but forget other sending platforms.

If these tools send email using your domain but are not authenticated, messages from those platforms may go to spam even if normal staff email is fine.

Practical rule

Check every system that sends from addresses like:

hello@example.com
support@example.com
billing@example.com
news@example.com

Each one may need SPF, DKIM, or both.

Duplicate SPF records can hurt authentication

A domain should not publish multiple SPF records at the same hostname.

Wrong:

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

This does not mean both providers are safely authorized. It creates duplicate SPF records.

Correct if both Google and Microsoft genuinely send email for the domain:

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

Only include both if both really send email. If you fully moved from Google Workspace to Microsoft 365, you may not need Google in SPF anymore. If you fully moved from Microsoft 365 to Google Workspace, you may not need Microsoft in SPF anymore.

DKIM: check whether messages are signed

DKIM stands for DomainKeys Identified Mail.

DKIM lets your email provider sign outgoing messages. Receiving servers can verify that signature using a DNS record.

For deliverability, DKIM is often more important than people realize because it helps prove that the message was signed by an authorized domain key.

DKIM is selector-based

DKIM records do not usually live at the root domain. They live at:

selector._domainkey.example.com

Examples:

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

If you check the wrong selector, DKIM may appear missing even when it exists.

DNS record existence is different from an actual sent email showing dkim=pass. For selector troubleshooting, use the DKIM record checker guide.

Google Workspace DKIM issues

For Google Workspace, DKIM usually requires:

1. Generate a DKIM key in Google Admin.
2. Add the DKIM TXT record in DNS.
3. Return to Google Admin.
4. Start authentication.
5. Send a test email.
6. Check that DKIM passes.

A typical Google selector is:

google._domainkey

The full DKIM value must come from Google Admin.

For the full provider checklist, use the Google Workspace Cloudflare DNS guide.

Microsoft 365 DKIM issues

For Microsoft 365 custom domains, DKIM usually uses two CNAME records:

selector1._domainkey
selector2._domainkey

The targets must come from Microsoft 365 or Microsoft Defender.

Do not guess Microsoft DKIM values. Use the exact values Microsoft gives you.

For the full provider checklist, use the Microsoft 365 Cloudflare DNS guide.

DMARC: check whether authentication aligns with your From domain

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

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

A basic DMARC record is published at:

_dmarc.example.com

A safe starting value is:

v=DMARC1; p=none;

DMARC should be published at _dmarc, not the root domain.

If emails are going to spam, missing DMARC or failing DMARC is a major signal to check. For policy rollout help, use the DMARC record checker guide.

DMARC alignment is the part most people miss

SPF or DKIM can pass, but DMARC can still fail. DMARC depends on SPF or DKIM alignment with the visible From domain.

Good DKIM alignment

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

This aligns.

Bad DKIM alignment

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.

Good SPF alignment

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

This aligns.

Bad SPF alignment

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 sending platforms often require domain authentication, custom DKIM, and sometimes custom return-path setup.

DMARC exists, but p=none: is that bad?

Not necessarily.

This record is valid:

v=DMARC1; p=none;

It means monitoring only. For a new or messy domain, p=none is usually a safe starting point.

But p=none does not ask receivers to quarantine or reject failing messages. If your long-term goal is stronger spoofing protection, you may eventually move to:

v=DMARC1; p=quarantine;

and later:

v=DMARC1; p=reject;

Only do this after you confirm legitimate senders pass SPF or DKIM alignment.

DNS records to check when emails go to spam

If DNS was recently updated and still looks wrong, check the email DNS propagation guide before making repeated changes.

PTR and reverse DNS: when it matters

PTR, also called reverse DNS, maps an IP address back to a hostname.

This matters most if you send email from your own mail server, a VPS, a dedicated SMTP server, a dedicated sending IP, or some transactional email setups.

If you use Google Workspace or Microsoft 365, they usually manage the sending infrastructure. You usually do not set PTR for Google or Microsoft IPs yourself.

For most small business users, this is provider-managed. But if you self-host email, it becomes critical.

MX records are not usually the spam fix

MX controls where incoming email is delivered.

If your problem is I cannot receive email, then check MX first. If your problem is My sent email goes to spam, then MX is usually not the main fix.

However, MX can still matter indirectly because a domain with incomplete or messy DNS may look poorly maintained. More importantly, if replies cannot reach you, users may disengage or mark messages as suspicious.

Check MX if

• Recipients say replies bounce.
• Your domain cannot receive email.
• Your email provider setup says MX is incomplete.
• You recently migrated providers.
• Your website works but email receiving fails.

Use the MX record checker guide when receiving or reply routing is broken. If your website works but email receiving fails, use the website works but email does not guide.

Third-party sending platforms need their own authentication

This is one of the biggest causes of some emails go to spam, but others are fine.

This often happens because Google Workspace or Microsoft 365 is authenticated, but the other tools are not.

What to do for each sender

1. Is the platform still used?
2. Does it send using your domain in the From address?
3. Does the platform provide SPF instructions?
4. Does the platform provide DKIM instructions?
5. Does it require a custom return-path or bounce domain?
6. Does it show the domain as verified?
7. Does a test email from that platform pass SPF, DKIM, and DMARC?
8. Does the DKIM signing domain align with your visible From domain?

One authenticated email provider does not automatically authenticate every other tool.

Check the visible From domain

Spam filters and DMARC care a lot about the visible From domain.

From: Your Company <hello@example.com>

The visible From domain is example.com. For better authentication, SPF or DKIM should align with that domain.

Common problem

Your newsletter shows:

From: Your Company <hello@example.com>

But the message authenticates as:

emailservice.com

That may pass SPF or DKIM for the service, but not necessarily pass DMARC for your domain.

Fix

Authenticate your domain inside the newsletter or sending platform. This usually means adding provider-specific DKIM CNAME or TXT records.

Check the return-path or bounce domain

The return-path is the technical address used for bounces.

It may look like:

bounce@example.com

or:

bounce.emailservice.com

SPF alignment depends on the domain used in the return-path. If you want SPF to help DMARC pass, the return-path domain should align with the visible From domain.

Many platforms call this custom return-path, custom bounce domain, MAIL FROM domain, envelope sender domain, or SPF alignment domain.

Not every platform requires this if DKIM alignment is working, but it is worth checking for marketing and transactional email platforms.

Check branded tracking links

Marketing platforms often rewrite links for click tracking.

For example, your email may show links that redirect through a tracking domain. If the tracking domain is a generic shared tracking domain, it may look less trustworthy than a branded domain.

Some platforms allow a branded tracking domain such as:

click.example.com

This usually uses a CNAME record.

Branded tracking links can help consistency, but they do not replace SPF, DKIM, or DMARC.

Tracking domains can develop their own reputation. Do not use tracking to hide spammy links or misleading destinations.

Check whether your domain is new

A new domain can go to spam even with perfect DNS.

• No sending history
• Low domain reputation
• Sudden sending volume
• Little recipient engagement
• No established trust with inbox providers

Safer sending pattern for new domains

• Send low volume first.
• Send to people who expect the email.
• Avoid cold bulk outreach.
• Keep complaint rates very low.
• Do not suddenly send thousands of messages.
• Use consistent From names and domains.
• Make unsubscribe easy for marketing emails.
• Monitor bounce and spam reports.

DNS authentication is necessary, but reputation still takes time.

Check domain reputation and IP reputation

If DNS authentication passes but email still goes to spam, reputation may be the issue.

For Gmail recipients, Google Postmaster Tools can help show domain reputation, IP reputation, spam rate, authentication, encryption, and delivery errors if you have enough volume.

Check spam complaint rate

Spam complaints are extremely important. A user complaint means someone clicked Report spam or similar.

Even if your DNS is correct, high complaints can push future email to spam.

Common causes of high complaint rates

• People did not expect the email.
• List was purchased or scraped.
• Opt-in was unclear.
• Emails are too frequent.
• Content is too sales-heavy.
• Unsubscribe is hard to find.
• The brand name is unfamiliar.
• The subject line feels misleading.
• The recipient cannot remember signing up.

For marketing emails, reduce complaints before increasing volume.

Check unsubscribe setup for marketing emails

For marketing or subscribed email, unsubscribe matters.

Even though unsubscribe is not a DNS record, it affects deliverability.

• Clear unsubscribe link in the email body
• One-click unsubscribe support if required by the sending platform or inbox provider
• Unsubscribes are honored quickly
• No login required just to unsubscribe
• No misleading preference page
• Suppression lists are respected

If people cannot unsubscribe easily, they may click Report spam instead. That hurts reputation.

Check email content before blaming DNS

Even with SPF, DKIM, and DMARC passing, content can still send an email to spam.

• Misleading subject lines
• Excessive capitalization
• Too many links
• Suspicious URLs
• Link shorteners
• Attachments recipients did not request
• Heavy image-only emails
• Broken HTML
• Poor plain-text version
• Aggressive sales language
• Phishing-like wording
• Mismatch between From name and domain
• No physical address in marketing emails where required
• Unclear unsubscribe path

DNS helps prove identity. Content still affects trust.

Check sending volume and warming

Sudden sending spikes can cause spam placement.

That jump can look suspicious, especially for a new domain or new sender.

Better approach

• Increase volume gradually.
• Start with engaged recipients.
• Avoid sending to old or unverified lists.
• Remove hard bounces.
• Remove repeated non-openers.
• Segment by engagement.
• Monitor complaint rate.
• Pause campaigns if spam complaints rise.

Authentication does not override poor sending behavior.

Google Workspace email going to spam

If Google Workspace email goes to spam, check:

A basic Google Workspace SPF record is often:

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

If you also use third-party senders, merge them into one SPF record.

Microsoft 365 email going to spam

If Microsoft 365 email goes to spam, check:

A Microsoft 365-only SPF record is often:

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

If other services send email for the same domain, merge legitimate senders into one SPF record.

Website contact form emails going to spam

Website forms often fail because they send email badly.

Common bad setup:

From: hello@example.com
Sent by: unauthenticated web server

Better setup:

• Use a proper SMTP or transactional email provider.
• Authenticate the sending domain.
• Add required SPF or DKIM records.
• Use a consistent From address.
• Use a real reply-to address.
• Avoid sending directly from the web host's unauthenticated mail function.

Newsletter emails going to spam

Newsletter emails need more than basic mailbox authentication.

• Sending domain is verified in the newsletter platform.
• DKIM records are added.
• SPF or return-path setup is complete if required.
• DMARC passes.
• Branded tracking domain is configured if appropriate.
• Unsubscribe is visible.
• One-click unsubscribe is enabled where required.
• List was opted in.
• Bounce rate is low.
• Complaint rate is low.
• Sending volume is reasonable.
• Subject line is not misleading.

Newsletter deliverability is heavily affected by engagement and complaint rate.

Invoice or transactional emails going to spam

Transactional emails include receipts, invoices, password resets, booking confirmations, account notifications, support updates, and login links.

These should be especially reliable.

If transactional emails go to spam, fix authentication and content quickly because these messages directly affect customers.

Cold email going to spam

Cold outreach is especially difficult. Even perfect DNS does not make cold email safe from spam filtering.

• Recipients did not ask for the email.
• Complaint rates can rise quickly.
• New domains have no reputation.
• Cold templates often look similar across senders.
• Sending volume ramps too quickly.
• Links and tracking can look suspicious.
• Recipients ignore or delete the messages.

Practical warning

Do not treat SPF, DKIM, and DMARC as a way to force cold emails into inboxes. They only prove identity and policy. They do not make unwanted email wanted.

Common spam-related authentication results

Safe troubleshooting workflow

Use this workflow when email goes to spam:

1. Send a test email to an external mailbox.
2. Inspect message headers.
3. Check SPF result.
4. Check DKIM result.
5. Check DMARC result.
6. Check alignment with the visible From domain.
7. Identify the actual sending platform.
8. Check DNS records at the active DNS host.
9. Fix SPF duplication or missing includes.
10. Enable DKIM for the sender.
11. Add DMARC if missing.
12. Authenticate every third-party platform.
13. Check domain and IP reputation.
14. Review email content.
15. Review complaint and bounce rates.
16. Reduce volume if sending is too aggressive.
17. Test again with a new message.

Do not keep changing DNS randomly. Use the real message header as evidence.

What not to do

• Do not assume your email provider is the problem before checking headers.
• Do not create multiple SPF records.
• Do not guess DKIM values.
• Do not check DKIM without knowing the selector.
• Do not add DMARC at the root domain.
• Do not jump to p=reject before testing legitimate senders.
• Do not assume DNS authentication guarantees inbox placement.
• Do not ignore third-party senders.
• Do not send large campaigns from a brand-new domain.
• Do not use purchased or scraped lists.
• Do not make unsubscribe difficult.
• Do not hide spammy links behind tracking domains.
• Do not change MX records when the problem is outbound spam placement.
• Do not send the same test email repeatedly without changing the underlying issue.

Final checklist: DNS records to check before blaming your provider

Before blaming Google, Microsoft, your newsletter tool, or your web host, check:

• Active nameservers
• SPF exists
• Only one SPF record exists
• SPF includes the real sender
• DKIM exists for the sender
• DKIM is enabled, not just published
• DMARC exists at _dmarc
• DMARC passes on real email
• SPF or DKIM aligns with visible From domain
• Third-party senders are authenticated
• Return-path or bounce domain is configured if needed
• PTR/reverse DNS is correct if you control the sending IP
• Domain reputation is not poor
• IP reputation is not poor
• Spam complaints are low
• Bounce rate is low
• Email content does not look spammy
• Sending volume is not suddenly too high

The best deliverability setup is not one record. It is a combination of correct authentication, good sending behavior, clean lists, and trustworthy content.

Run an email spam DNS check

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

A scan can help show whether SPF is missing or duplicated, DKIM may be missing, DMARC is absent, MX is misconfigured, or nameservers point somewhere unexpected.

Start with DNS authentication, then inspect real email headers, then move on to reputation, content, and sending behavior.