Website Works but Email Does Not: DNS Records to Check First

Quick answer: what should you check first?

If your website works but email does not, check DNS in this order:

The most important rule is simple: Do not change website A, AAAA, or CNAME records just because email is broken. Check nameservers and MX records first.

Website DNS and email DNS are different

A domain can have several different services connected to it at the same time.

This is why these two statements can both be true:

• example.com loads correctly in a browser.
• hello@example.com cannot receive email.

A working website proves that the website records are good enough for web traffic. It does not prove that email routing or email authentication is correct.

Common symptoms when website works but email does not

Use the symptom to decide what to check first.

Step 1: Check active nameservers before editing anything

The first question is not where your website is hosted. The first question is where your active DNS records are managed.

Nameservers tell the internet which DNS provider is authoritative for the domain. If your active nameservers are at Cloudflare, then DNS records inside Namecheap, GoDaddy, or your website host may not be live.

Example

You bought the domain at Namecheap. Then you connected the domain to Cloudflare. Then you hosted the website on Vercel.

In this setup:

If the nameservers point to Cloudflare, you must edit MX, SPF, DKIM, and DMARC inside Cloudflare DNS.

Adding records inside Namecheap will not fix live email DNS if Namecheap is no longer the active DNS host.

Step 2: Do not touch website records unless the website is the problem

Website records usually look like:

A
AAAA
CNAME

Email records usually involve:

MX
TXT
CNAME

TXT records can include SPF, DMARC, verification records, and other provider instructions. DKIM can be published as TXT or CNAME depending on the provider.

If only email is broken, avoid changing:

• Root A record
• Root AAAA record
• www CNAME
• Website CNAME records
• Website host connection records
• Vercel, Netlify, Wix, Shopify, or Squarespace website records

Changing website records while troubleshooting email can create a second problem: now both the website and email may break.

Step 3: Check MX records for incoming email

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

If someone emails:

hello@example.com

the sender's mail system checks the MX records for:

example.com

Those MX records should point to the email provider that handles your inbox.

What MX records should match

The exact values depend on the provider. Use the provider's current DNS instructions.

Common MX problems

Step 4: Confirm the mailbox or alias exists

DNS can route mail to your provider, but it does not create the mailbox.

For example, if your MX records correctly point to Google Workspace, Google can receive mail for your domain. But if the address does not exist, mail can still bounce.

Check whether the address exists as one of these:

• A user mailbox
• An alias
• A group address
• A catch-all address
• A forwarding address
• A shared mailbox
• A distribution list

Example

You want:

hello@example.com

to receive email.

You correctly add Google Workspace MX records.

But inside Google Admin, there is no user or alias for:

hello@example.com

Result: DNS may be correct, but the address still does not receive mail.

Step 5: Check whether the domain is verified with the email provider

Many email providers require domain verification before they fully activate email.

This usually means adding a TXT or CNAME record to DNS.

If the provider dashboard says setup is incomplete, check whether the verification record was added at the active DNS host.

Step 6: Check SPF if outgoing email is weak or failing

SPF helps receiving servers identify which systems are allowed to send email for your domain.

A typical Google Workspace SPF record looks like:

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

A typical Microsoft 365 SPF record looks like:

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

Do not copy these blindly unless they match your actual email provider.

Common SPF problems

SPF usually matters more when the issue is outbound trust or spam placement. If you cannot receive email at all, check MX first.

Step 7: Check DKIM for signed outgoing email

DKIM allows your email provider to sign outgoing mail. Receiving mail servers can verify the signature using a public DNS record.

DKIM is often required for strong deliverability and DMARC alignment.

DKIM records may look like this

For some providers, DKIM is a TXT record:

google._domainkey.example.com

For Microsoft 365 and some other platforms, DKIM may use CNAME records such as:

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

The exact selector depends on the provider.

Common DKIM problems

DKIM matters most when outgoing emails land in spam, fail DMARC, or fail provider setup checks.

Step 8: Check DMARC after SPF and DKIM

DMARC tells receiving servers how to handle messages that fail authentication and alignment checks.

A basic DMARC record is published as a TXT record at:

_dmarc.example.com

A safe starting record is:

v=DMARC1; p=none;

Stricter policies include:

v=DMARC1; p=quarantine;

and:

v=DMARC1; p=reject;

Common DMARC problems

If you are unsure, start with p=none, then fix SPF and DKIM before moving to a stricter policy.

Step 9: Check recent changes

Email often breaks after a website or DNS migration.

Ask:

• Did you recently move the website to Vercel, Netlify, Wix, Shopify, or Squarespace?
• Did you recently enable Cloudflare?
• Did you change nameservers?
• Did you delete old DNS records?
• Did you change from Google Workspace to Microsoft 365?
• Did you move from registrar DNS to Cloudflare DNS?
• Did a developer clean up DNS records?
• Did you add a new email marketing or CRM platform?
• Did you change domain forwarding settings?

The timing matters. If email broke right after a website migration, the likely issue is not the website itself. The likely issue is that MX, SPF, DKIM, or DMARC records were not copied into the new active DNS zone.

Scenario 1: Website works, but incoming email bounces

Most likely causes:

• Missing MX records
• Wrong MX records
• MX records point to an old provider
• Mailbox or alias does not exist
• Domain is not verified with the email provider
• DNS changes were made at the wrong DNS host

What to do

1. Check active nameservers.
2. Check MX records.
3. Confirm the email provider is correct.
4. Confirm the mailbox or alias exists.
5. Check the provider dashboard for setup warnings.
6. Send a test email from an external mailbox.

Do not start by changing website A or CNAME records.

Scenario 2: Website works, email receives, but outgoing email lands in spam

Most likely causes:

• Missing SPF
• Duplicate SPF
• DKIM not enabled
• Missing DMARC
• Third-party sender not authenticated
• New domain with little reputation
• Poor email content or sending behavior

What to do

1. Check SPF.
2. Check DKIM.
3. Check DMARC.
4. Send a test email and inspect authentication results.
5. Authenticate third-party senders.
6. Avoid suddenly increasing sending volume.

MX is less likely to be the main issue if receiving works normally.

Scenario 3: Website works, but Google Workspace says setup is incomplete

Most likely causes:

• Google MX records missing
• Google verification TXT record missing
• DNS records added at wrong host
• SPF missing or incorrect
• DKIM not generated or not enabled
• DMARC missing
• Mailbox or alias not created

What to do

1. Confirm active DNS host.
2. Add Google's MX records exactly as instructed.
3. Add Google's verification TXT record if required.
4. Add or fix SPF.
5. Generate and enable DKIM in Google Admin.
6. Add a basic DMARC record.
7. Return to Google Admin and verify setup.

Scenario 4: Website works, but Microsoft 365 email does not

Most likely causes:

• Microsoft 365 domain verification incomplete
• Microsoft MX record missing or wrong
• SPF does not include Microsoft
• DKIM CNAME records missing
• DKIM not enabled
• DMARC missing
• User mailbox not licensed or created
• Old MX records still present

What to do

1. Confirm active DNS host.
2. Check Microsoft 365 domain setup instructions.
3. Add the correct MX record.
4. Add the required TXT verification record.
5. Add or fix SPF.
6. Add Microsoft DKIM CNAME records.
7. Enable DKIM.
8. Add a DMARC record.
9. Confirm the mailbox exists and is licensed.

Scenario 5: Website works after moving to Cloudflare, but email stopped

This is common.

When you move a domain to Cloudflare, you may change the domain's nameservers to Cloudflare. If all old DNS records are not copied into Cloudflare, the website may work but email may fail.

What may have happened

Important Cloudflare note

MX and TXT records are DNS-only. They are not proxied through Cloudflare. You do not need an orange cloud for MX or TXT records.

If email broke after moving to Cloudflare, check whether the email DNS records exist in Cloudflare DNS.

Scenario 6: Website works on Vercel or Netlify, but email fails

This often happens when people think Vercel or Netlify controls all DNS.

There are two different possibilities:

Possibility A: DNS is managed somewhere else

The domain points to Vercel or Netlify using A/CNAME records, but DNS is still managed at Cloudflare, Namecheap, GoDaddy, or another DNS host.

In this case, edit email records at the DNS host, not necessarily inside Vercel or Netlify.

Possibility B: Nameservers were moved

If nameservers were moved to a new provider and old email records were not copied, email can break even if the website was set up correctly.

What to check

1. Active nameservers.
2. MX records.
3. TXT records for SPF and DMARC.
4. DKIM records from the email provider.
5. Provider verification status.

Scenario 7: Website works, but email forwarding does not

Email forwarding still depends on DNS and forwarding rules.

For example, you may want:

hi@example.com

to forward to:

yourname@gmail.com

For this to work, the forwarding provider usually needs:

• Correct MX records
• The forwarding address configured
• Destination mailbox verified
• No conflicting MX records
• Sometimes SPF or sender rewriting support for forwarded mail

Common forwarding mistakes

If the goal is forwarding only, make sure the forwarding service's MX records are the active MX records.

Scenario 8: Website works, but email stopped after changing nameservers

Changing nameservers changes where the internet looks for DNS records.

If you move nameservers from one DNS provider to another, you must copy all important records:

• Website A records
• Website AAAA records
• Website CNAME records
• MX records
• SPF TXT record
• DKIM TXT/CNAME records
• DMARC TXT record
• Verification TXT records
• Any service-specific DNS records

A nameserver change can make the new DNS provider authoritative. If the new DNS zone is missing email records, email can stop immediately or after cached DNS records expire.

Website DNS records explained

These records are usually website-related:

Examples:

example.com      A       76.76.21.21
www.example.com  CNAME   cname.vercel-dns.com

These records help browsers find your website.

They do not tell the internet where to deliver email.

Email DNS records explained

These records are usually email-related:

Examples:

example.com          MX    ASPMX.L.GOOGLE.COM
example.com          TXT   v=spf1 include:_spf.google.com ~all
_dmarc.example.com   TXT   v=DMARC1; p=none;

These records help email systems route and authenticate mail.

What not to do

When email breaks but the website works, avoid these mistakes:

• Do not delete website A records unless the website is the problem.
• Do not delete www CNAME records unless the website is the problem.
• Do not change nameservers without copying all DNS records first.
• Do not add MX records at the registrar if active DNS is managed elsewhere.
• Do not mix MX records from multiple email providers unless explicitly required.
• Do not create multiple SPF records.
• Do not move DMARC straight to p=reject before testing.
• Do not assume Cloudflare proxy settings fix email.
• Do not assume DNS creates mailboxes automatically.
• Do not keep changing records every few minutes without retesting.

Safe troubleshooting workflow

Use this workflow:

1. Identify the exact failure

Ask:

• Can you receive email?
• Can you send email?
• Are messages bouncing?
• Are messages going to spam?
• Is only one address affected?
• Is the whole domain affected?
• Did the problem start after a DNS or website change?

2. Check nameservers

Find where DNS is actually managed. Edit records only at the active DNS host.

3. Check MX

If receiving is broken, MX comes first. Confirm MX records match the intended email provider.

4. Check mailbox or alias

Make sure the email address exists inside the provider.

5. Check provider setup

Look for incomplete verification or setup warnings.

6. Check SPF, DKIM, and DMARC

If sending or deliverability is the issue, authentication records are the next priority.

7. Test carefully

After changing DNS:

• Wait for propagation.
• Send test emails from external accounts.
• Check authentication results.
• Confirm website still loads.
• Confirm email still routes correctly.

Example: Vercel website + Google Workspace email

A common setup:

Website records may include:

example.com      A       76.76.21.21
www.example.com  CNAME   cname.vercel-dns.com

Email records may include:

example.com          MX    Google Workspace MX records
example.com          TXT   v=spf1 include:_spf.google.com ~all
google._domainkey    TXT   Google DKIM value
_dmarc               TXT   v=DMARC1; p=none;

If the website works but email fails, do not change the Vercel A/CNAME records first. Check whether the Google MX and TXT records exist in Cloudflare.

Example: Cloudflare DNS + Microsoft 365 email

A common setup:

Microsoft 365 may require:

• Domain verification TXT record
• MX record for Microsoft 365
• SPF TXT record
• DKIM CNAME records
• DMARC TXT record

If the domain uses Cloudflare nameservers, add those records in Cloudflare DNS.

Do not add them only at Namecheap unless Namecheap is the active DNS host.

Example: Website host email replaced by Google Workspace

Old setup:

New setup:

In this case, the website may still work because A records point to the hosting server.

But email may fail if MX still points to the old cPanel mail server.

Fix:

1. Add Google Workspace MX records.
2. Remove old cPanel MX records if no longer used.
3. Add Google SPF.
4. Enable Google DKIM.
5. Add DMARC.
6. Confirm mailboxes or aliases exist in Google Workspace.

Example: Website migration broke email

Before migration:

After migration, the developer copied only:

Result:

• Website works
• Email fails
• Provider verification fails
• SPF/DKIM/DMARC checks show missing records

Fix: copy the missing email DNS records into the active DNS host.

How to prepare before contacting support

Before contacting your email provider, website host, or developer, collect:

1. Domain name
2. Active nameservers
3. DNS host
4. Website host
5. Email provider
6. Whether receiving is broken
7. Whether sending is broken
8. Whether emails bounce or go to spam
9. Current MX records
10. Current SPF record
11. Whether DKIM is enabled
12. Current DMARC record
13. Recent DNS or website changes
14. Example bounce message, if available

This helps support identify whether the issue is DNS routing, mailbox setup, authentication, or reputation.

Simple decision tree

Use this simple path:

If incoming email does not arrive

Check:

1. Nameservers
2. MX records
3. Mailbox or alias
4. Provider verification

If outgoing email lands in spam

Check:

1. SPF
2. DKIM
3. DMARC
4. Sending reputation
5. Third-party sender authentication

If provider says setup incomplete

Check:

1. DNS host
2. Verification TXT/CNAME
3. MX
4. SPF
5. DKIM
6. DMARC

If email broke after website migration

Check:

1. Whether nameservers changed
2. Whether MX was copied
3. Whether SPF was copied
4. Whether DKIM was copied
5. Whether DMARC was copied
6. Whether verification records were copied

Final checklist

If your website works but email does not, check:

• Active nameservers
• Correct DNS host
• MX records
• Old MX records
• Mailbox or alias setup
• Email provider verification
• SPF record
• Duplicate SPF records
• DKIM records
• DMARC record
• Recent nameserver changes
• Recent website migration
• Whether records were added in the wrong DNS account

The safest rule: Fix email DNS records without touching website records unless the website itself is broken.

Run an email DNS check

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

A scan can help separate website DNS from email DNS, so you know whether the problem is nameservers, MX, SPF, DKIM, DMARC, or provider setup.

Start with the records that affect email. Do not guess and accidentally break the website that is already working.