Email DNS Checker: What to Check When Domain Email Breaks

Quick answer: what should an email DNS checker check?

A useful email DNS checker should check at least these record groups:

The most important idea is this: website DNS and email DNS are related, but they are not the same thing. Your website can work perfectly while email is broken.

Why domain email breaks even when the website works

Many domain owners assume that if the website loads, DNS must be correct. That is not true.

A domain can use different providers for different jobs:

• Vercel, Netlify, Wix, Shopify, WordPress, or Squarespace for the website
• Cloudflare, Namecheap, GoDaddy, Route 53, or another provider for DNS hosting
• Google Workspace, Microsoft 365, Zoho, Proton Mail, or another provider for email

Your website usually depends on A, AAAA, or CNAME records. Your email receiving depends mainly on MX records. Email authentication depends on TXT and provider-specific DKIM records.

So when your website works but email does not, do not start by changing your website A record or CNAME. Check the email records first.

Step 1: Check the active nameservers first

Before fixing MX, SPF, DKIM, or DMARC, confirm where DNS is actually controlled.

Nameservers tell you which DNS provider is authoritative for the domain. For example, if your domain uses Cloudflare nameservers, then changes made inside Namecheap DNS may not affect the live domain records. Namecheap might still be your registrar, but Cloudflare is the DNS host.

This is one of the most common causes of confusion.

What to check

Look for the domain's active nameservers:

• Are they Cloudflare nameservers?
• Are they Namecheap nameservers?
• Are they GoDaddy nameservers?
• Are they the web host's nameservers?
• Are they from another DNS platform?

Common mistake

You bought the domain at Namecheap, so you add Google Workspace MX records inside Namecheap. But the domain is actually using Cloudflare nameservers. Result: the records you added are not live, and email still does not work.

Fix

Edit DNS records only at the active DNS host shown by the nameservers.

Step 2: Check MX records for receiving email

MX records tell the internet where to deliver incoming email for your domain.

If someone sends an email to hello@example.com, the sender's mail server looks up the MX records for example.com. Those MX records point to the email provider responsible for receiving mail.

What good MX results should show

Your MX records should match your actual email provider.

Common MX problems

What to fix first

If receiving email is broken, MX is usually the first record family to check.

Ask:

1. Which provider should receive mail for this domain?
2. Do the live MX records match that provider?
3. Are there old MX records from a previous provider?
4. Are the priorities correct?
5. Have the mailboxes or aliases been created inside the email provider?

DNS only tells the internet where to send mail. It does not automatically create the mailbox. If hello@example.com does not exist inside your email provider, mail can still fail even if MX is correct.

Step 3: Check SPF for sending authorization

SPF stands for Sender Policy Framework. It is an email authentication record published as a TXT record on the root domain.

SPF tells receiving mail servers which services are allowed to send email for your domain.

For example, if you use Google Workspace, your SPF record needs to authorize Google. If you also use a newsletter tool, CRM, invoicing system, or cold-email platform, SPF may need to include those services too.

What an SPF record looks like

A typical SPF record looks like this:

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

For Microsoft 365, a typical SPF record looks like this:

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

Do not copy these blindly unless they match your provider. Your correct SPF record depends on the services that send email for your domain.

The biggest SPF rule: only one SPF record

A domain should not have multiple separate SPF records.

This is wrong:

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

If your domain sends through both Google and Microsoft, you do not publish two SPF records. You merge the allowed senders into one SPF record:

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

Only use a merged record if both services genuinely send email for the domain.

Common SPF problems

Safe SPF troubleshooting process

1. List every service that sends email using your domain.
2. Keep only one SPF record at the root domain.
3. Add the correct include: mechanism for each legitimate sending service.
4. Remove old services you no longer use.
5. Avoid blindly copying SPF examples from old setup guides.
6. Recheck after DNS propagation.

Step 4: Check DKIM for signed outgoing email

DKIM stands for DomainKeys Identified Mail. It lets your email provider sign outgoing messages using a private key. Receivers can then check a public key in DNS to confirm that the message was authorized and not modified in transit.

DKIM is important because it helps prove that outgoing email is genuinely connected to your domain.

Why DKIM is different from SPF

SPF is usually one TXT record at the root domain.

DKIM is usually provider-specific and selector-based. The DNS record might live at a name such as:

google._domainkey.example.com

or:

selector1._domainkey.example.com
selector2._domainkey.example.com

The exact selector depends on your email provider.

Common DKIM problems

Important DKIM note

A checker cannot always prove that DKIM is completely absent unless it knows the exact selector your provider uses. A missing common selector is a clue, not always final proof.

The best workflow is:

1. Open your email provider's admin panel.
2. Find the DKIM setup page.
3. Copy the exact selector and record value from the provider.
4. Add the record at your active DNS host.
5. Go back to the provider and enable or verify DKIM.
6. Send a test email and inspect the authentication results.

Step 5: Check DMARC for domain-level policy

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It tells receiving mail servers what to do when messages claiming to be from your domain fail authentication and alignment checks.

DMARC is published as a TXT record at:

_dmarc.example.com

A basic DMARC record looks like this:

v=DMARC1; p=none;

A stronger DMARC policy might look like this:

v=DMARC1; p=quarantine;

or:

v=DMARC1; p=reject;

DMARC policy levels

Why even p=none is useful

A basic DMARC record is better than having no DMARC at all because it establishes a domain-level authentication policy. It also prepares the domain for future reporting and stricter enforcement.

However, p=none is not the final security goal. It is usually the starting point. Once you confirm that legitimate sending sources pass SPF or DKIM alignment, you can consider moving toward quarantine and eventually reject.

Common DMARC problems

Safe DMARC rollout

A practical rollout looks like this:

1. Start with p=none.
2. Confirm all legitimate sending services.
3. Make sure either SPF or DKIM aligns for those services.
4. Fix failing legitimate senders.
5. Move to p=quarantine when confident.
6. Move to p=reject only after testing.

Do not jump straight to p=reject if you are unsure which platforms send email for your domain.

Step 6: Check whether DNS was changed in the wrong place

This is especially common when the domain registrar, DNS host, website host, and email provider are different companies.

Example setup:

In this setup, you would normally edit DNS records in Cloudflare, not Namecheap, Vercel, or Google. Google gives you the values, but Cloudflare is where the live DNS records are managed.

Symptoms of editing DNS in the wrong place

• You added MX records but the checker still says MX is missing
• Google or Microsoft still cannot verify the domain
• The website works, but email still bounces
• You see different DNS results in different tools
• You changed records at the registrar but the nameservers point somewhere else

Fix

Find the active nameservers. Then edit records only inside the DNS provider shown by those nameservers.

Step 7: Understand DNS propagation

After you change DNS records, the result may not update everywhere immediately. DNS records use TTL values, which tell resolvers how long they can cache the old answer.

In many cases, changes appear within minutes. Sometimes they can take longer, especially if the old records had long TTL values or the previous DNS provider cached results.

What to do after changing records

1. Save the record.
2. Wait a few minutes.
3. Run the email DNS check again.
4. If results still show old records, wait longer and retest.
5. Confirm you edited the active DNS host.
6. Check for typos in the name/host field.

Do not keep changing multiple records every few minutes. That makes troubleshooting harder.

Common symptoms and what to check first

I can send email, but I cannot receive email

Check:

1. MX records
2. Whether the mailbox or alias exists
3. Whether old MX records are still present
4. Whether the email provider has completed domain verification

Likely issue: receiving/routing problem.

I can receive email, but my emails go to spam

Check:

1. SPF
2. DKIM
3. DMARC
4. Whether the sending platform is authorized
5. Whether the domain is new or has low sending reputation

Likely issue: authentication or reputation problem.

Google Workspace says my domain is not verified

Check:

1. Active nameservers
2. TXT verification record
3. Whether you added the record at the correct DNS host
4. Whether the host/name field was entered correctly

Likely issue: verification TXT record is missing or added in the wrong place.

Microsoft 365 email does not work after setup

Check:

1. MX record
2. Microsoft SPF include
3. DKIM CNAME records
4. DMARC record
5. Whether users/mailboxes exist in Microsoft 365

Likely issue: incomplete DNS setup or mailbox setup.

My website works but email stopped working

Check:

1. Nameservers
2. MX records
3. Whether the website migration changed DNS hosting
4. Whether old email records were removed accidentally

Likely issue: DNS migration affected email records.

My SPF checker says duplicate SPF records

Check all TXT records at the root domain and find records starting with:

v=spf1

There should be only one.

Fix by merging legitimate sending services into a single SPF record and deleting the duplicates.

Safe order of fixing email DNS

When email breaks, fix records in this order:

1. Nameservers - confirm where DNS is managed.
2. MX - fix receiving mail first.
3. SPF - authorize legitimate sending services.
4. DKIM - enable signing from your email provider.
5. DMARC - publish a safe starting policy.
6. Provider verification - confirm setup inside Google, Microsoft, or your mail provider.
7. Test email - send and inspect authentication results.

This order prevents unnecessary changes to website records and reduces the chance of breaking something that was already working.

What not to do when email DNS breaks

Avoid these common mistakes:

• Do not delete website records just because email is broken.
• Do not add multiple SPF records.
• Do not copy random SPF/DKIM/DMARC records without matching them to your provider.
• Do not change nameservers unless you understand what DNS records will move.
• Do not jump to DMARC p=reject before verifying SPF and DKIM.
• Do not assume the registrar is always where DNS is managed.
• Do not assume a working website means email DNS is correct.
• Do not remove old MX records until you know which provider should receive mail.

Example: Google Workspace domain email checklist

If your domain uses Google Workspace, check:

• Active DNS host is correct
• Google Workspace MX records are present
• Old MX records are removed
• SPF includes Google
• DKIM is generated and enabled in Google Admin
• DMARC exists at _dmarc
• The mailbox or alias exists in Google Workspace
• The domain is verified in Google Admin

A simple Google Workspace SPF record often looks like:

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

But if you also send email from other platforms, they may need to be added to the same SPF record.

Example: Microsoft 365 domain email checklist

If your domain uses Microsoft 365, check:

• Active DNS host is correct
• Microsoft 365 MX record is present
• Old MX records are removed
• SPF includes Microsoft 365
• DKIM CNAME records are added
• DKIM is enabled in the Microsoft admin/security area
• DMARC exists at _dmarc
• Users and mailboxes exist in Microsoft 365

A simple Microsoft 365 SPF record often looks like:

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

Again, only use this alone if Microsoft 365 is your only sending service.

Example: Cloudflare DNS and email setup

If your domain uses Cloudflare DNS, remember:

• MX records are for email receiving.
• TXT records are used for SPF, DMARC, and verification.
• DKIM may be TXT or CNAME depending on provider.
• MX and TXT records are DNS-only; they are not proxied through Cloudflare.
• The orange cloud proxy setting applies to website-related A, AAAA, and CNAME records, not MX or TXT records.

For most email DNS fixes in Cloudflare, you are adding or editing records in the DNS table, not changing website proxy settings.

Email DNS checklist before asking for help

Before contacting your email provider, developer, or IT support, collect this information:

1. Your domain name
2. Your email provider
3. Your DNS host
4. Your website host
5. Whether sending, receiving, or both are broken
6. The current MX records
7. The current SPF record
8. Whether DKIM is enabled
9. The current DMARC record
10. Any recent DNS, website, or email migration

This makes troubleshooting much faster.