Email Not Sending or Receiving? A Practical Troubleshooting Guide for Webmail and Business Email

November 7, 2026
Ridoy Hasan
Guide

When a company mailbox stops working, the root cause almost always falls into one of three buckets: DNS records that are missing or wrong (SPF, DKIM, DMARC, MX), mail client settings that do not match the server, or a quota or sending cap that has been reached. This guide walks through each bucket in the order a support engineer would check them, so you can fix most problems yourself and know exactly what to hand over when you cannot.

It helps to picture the two directions separately:

Outgoing mail. Your server hands the message to the recipient’s server over SMTP. The recipient then checks your domain’s SPF, DKIM and DMARC records to decide whether to deliver it to the inbox, send it to spam, or reject it.
Incoming mail. A sender’s server looks up your domain’s MX record to learn which server accepts mail for you, then delivers the message there.

That split is the key to fast diagnosis. Authentication records govern what you send; the MX record and routing settings govern what you receive.

Step One: Is It a Sending Problem or a Receiving Problem?

Before changing anything, pin down which direction is failing. Match what you are seeing to the table below.

What you observe	Direction	Check first
Messages you send land in spam or bounce	Sending	SPF, DKIM, DMARC
Webmail sends fine, but Outlook or a phone app cannot	Sending	SMTP host, port, authentication
Errors such as “relay access denied” or “quota exceeded”	Sending	SMTP login, hourly or daily send limit
Other people write to you, but nothing arrives	Receiving	MX record, email routing
Senders report a bounce when writing to you	Receiving	MX record, mailbox quota, nameservers
Nothing goes in or out	Both	Nameservers and DNS zone, account suspension

Four quick tests

Log in to webmail and send a message to a personal Gmail address. If it arrives, the server can send, and the fault likely sits in your mail client settings.
From that Gmail account, write back to your business address. If it never arrives, you have a receiving problem.
Whenever a bounce comes back, keep the complete text including the numeric code (for example 550 5.7.26). It is the single most useful clue you have.
Confirm the mailbox is not full and the hosting account is active and paid up.

Sending Problems: Repair SPF, DKIM and DMARC

If outgoing messages bounce or end up in spam, start with the three authentication records. Together they let a receiving server confirm that a message really came from your domain.

Why they matter more every year

Gmail expects at least SPF or DKIM from every sender. Once you send roughly 5,000 or more messages a day to personal Gmail accounts, you are treated as a bulk sender and need SPF and DKIM together, a published DMARC record (at minimum p=none), and alignment between the visible From domain and the authenticated domain. Yahoo applies similar rules without publishing a numeric threshold, and Microsoft began enforcing comparable requirements for Outlook.com, Hotmail and Live.com in May 2025. Unauthenticated mail is therefore far more likely to be filtered or refused than it was a few years ago. (Mailreach, DMARCguard, Folderly)

1. SPF (Sender Policy Framework)

SPF is a DNS TXT record listing the servers permitted to send mail for your domain.

Publish only one SPF record per domain. If one exists, edit it rather than adding a second.
Include your hosting server’s IP address, plus an include: entry for every external service that sends on your behalf, such as a newsletter platform.
Stay within the limit of ten DNS lookups. Too many nested include: entries make SPF evaluation fail.
Watch for typos and a missing service, the two most common causes of “not authorized” bounces.

Host:  yourdomain.com
Type:  TXT
Value: v=spf1 +a +mx ip4:YOUR_SERVER_IP ~all

With an outside sending service, the value becomes:

v=spf1 +a +mx ip4:YOUR_SERVER_IP include:spf.provider-domain.com ~all

Use the exact include: hostname published by that service. (Serverman)

2. DKIM (DomainKeys Identified Mail)

DKIM attaches a cryptographic signature to each outgoing message. The recipient fetches your public key from DNS and uses it to confirm the message was signed by your domain and not altered in transit. Valid SPF without DKIM still leaves you more exposed to spam filtering.

On cPanel or Plesk, enabling DKIM normally inserts the public key into the local DNS zone automatically, under a name shaped like selector._domainkey.yourdomain.com.
If your DNS is hosted elsewhere, for instance at Cloudflare or your registrar, copy the TXT record shown in the panel and add it there by hand.
When you generate keys yourself, choose 2048-bit.

3. DMARC

DMARC builds on SPF and DKIM. It tells receiving servers what to do with mail that fails authentication, and it sends you reports about who is using your domain. Publish it as a TXT record at _dmarc.yourdomain.com.

Host:  _dmarc.yourdomain.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]

Policy	Effect on failing mail
`p=none`	Monitor only; nothing is blocked
`p=quarantine`	Failing mail is routed to spam
`p=reject`	Failing mail is refused outright

Begin with p=none, read the reports for a few weeks to confirm all legitimate sources pass, then tighten the policy step by step. A recent scan of about 5.49 million domains found that only around 30% publish DMARC and just 6% enforce p=reject, so a properly staged policy puts you ahead of most senders. (DMARCguard)

Remember alignment: for DMARC to pass, at least one of SPF or DKIM must pass and use a domain that matches the From address. Passing alone is not enough.

Validating Deliverability from the Hosting Panel

Before editing DNS by hand, let the hosting control panel audit the domain. It will usually point to the exact record that is wrong and can often repair it for you.

In cPanel

Sign in and open Email → Email Deliverability.
Find your domain and read the SPF and DKIM status. A problem is flagged with a Repair option that writes the correct record. (BearHost)
If your nameservers are not the hosting provider’s (for example Cloudflare or a registrar’s DNS), the repair cannot take effect locally. Copy the suggested records and add them at the DNS provider that actually serves your domain.
Allow time for propagation, which can range from a few minutes to several hours depending on the record’s TTL.

Confirm the fix

Method	How	A healthy result
Message headers	Send a test to Gmail and choose “Show original”	SPF, DKIM and DMARC all read PASS
Scoring tool	Send a message to the address given by mail-tester.com	A score of about 8/10 or higher
Blacklist lookup	Enter the server IP into a tool such as MXToolbox	The IP appears on no list
DNS query	Run `dig +short TXT yourdomain.com`	Exactly one `v=spf1` record

Other Reasons Outgoing Mail Fails

Even with perfect DNS, mail can still stall for non-DNS reasons.

Wrong SMTP settings or a blocked port. Port 25 is commonly blocked for outbound use on shared hosting. Configure Outlook, Thunderbird and mobile apps to use port 465 (SSL/TLS) or 587 (STARTTLS) with authentication. (UnderHost)

Setting	Value
Outgoing server	mail.yourdomain.com
Port, SSL/TLS	465
Port, STARTTLS	587
Authentication	Required
Username	Full email address
Password	The mailbox password

Send-rate limits. Hosts cap how many messages an account can send per hour or day to protect the shared IP’s reputation. Once the cap is hit, mail queues and errors such as “message quota exceeded” appear. The cap varies by plan.

A full mailbox. A mailbox at its storage limit can disrupt normal operation. Delete old items or raise the quota.

A blacklisted IP. If the server’s IP has been listed for spam, receiving servers will refuse your mail. A bounce that names your IP is a strong hint.

Website forms using PHP mail(). If a contact form is not delivering, switch it to authenticated SMTP, for example through an SMTP plugin on WordPress.

Bulk campaigns. Do not push newsletters through a hosting mailbox. A dedicated delivery service such as Amazon SES, Mailgun or SendGrid protects your server’s reputation.

Reverse DNS (PTR). Google and Yahoo expect a valid PTR record on the sending IP for high-volume senders. Only the hosting provider can set this, so raise it with support if in doubt.

Receiving Problems: Correct the MX Record

When mail is not arriving, check the MX (Mail Exchanger) record first. It is the DNS entry that tells the world which server accepts mail for your domain. If it is missing, mistyped, or aimed at the wrong place, incoming messages never reach your mailbox.

A. Webmail on your hosting: point MX to the hosting hostname

If your mailboxes live on the same hosting server (you read mail through cPanel webmail or Roundcube), the MX destination must be the hosting server’s hostname. Your provider supplies this in the welcome email or the account details. On cPanel the default is mail.yourdomain.tld, and that name must resolve to the server’s IP address.

Host:     yourdomain.com
Type:     MX
Priority: 0 (or 10)
Value:    mail.yourdomain.com  (or the hosting hostname, e.g. server1.hostbrand.com)

Keep three rules in mind:

The value must be a hostname, never a bare IP address.
If you use mail.yourdomain.com, an A record with that name must point to the server’s IP.
A lower priority number means a higher preference, so 0 is tried first.

B. Editing MX in cPanel

Open Domains → Zone Editor.
Click Manage beside the domain and switch to the MX tab.
Edit the incorrect record, set the priority and destination, then choose Save Record.
Delete leftover MX entries from a previous mail provider, otherwise some messages may still be routed there.

C. Make Email Routing agree with the MX record

cPanel keeps a separate Email Routing setting for each domain, and it must match what the MX record says. A mismatch leads to bounced, lost or looping mail.

Option	Use it when
Local Mail Exchanger	Mailboxes are on this hosting server (the normal webmail case)
Remote Mail Exchanger	Mail is handled elsewhere, such as Google Workspace, Microsoft 365 or Zoho
Backup Mail Exchanger	This server should only hold mail while the primary exchanger is unreachable
Automatically Detect	Lets cPanel guess; unreliable while DNS is changing, so choose manually

Find it under Email → Email Routing, pick the domain, select the option and press Change.

A typical failure: MX points to Microsoft 365 but routing is still set to Local, so messages arriving at the hosting server stay there and never reach the Microsoft mailbox. The reverse also hurts: routing set to Remote while MX still names the hosting server makes the message bounce in a loop. (StackHarbor)

D. Are you editing the right DNS?

A frequent trap: the domain’s nameservers belong to Cloudflare or the registrar, yet the MX is changed inside cPanel. That edit changes nothing the outside world sees. Always modify records at the DNS service your nameservers actually point to.

E. Verify the result

Run dig +short MX yourdomain.com or nslookup -type=mx yourdomain.com and confirm the expected hostname appears.
Check that the A record for that hostname returns the hosting server’s IP.
Send a test from an outside address and make sure the mailbox has free space.
Wait a few hours after any change before judging the outcome, since DNS needs time to spread.

If it still fails

When every record is correct and mail still does not arrive, the cause is probably on the server side: a stopped mail service, a firewall blocking inbound port 25, a suspended account, or a domain placed on spam hold. At that point, contact your provider using the checklist in the next section.

Reading Bounce Messages

The code inside a bounce notice usually reveals where the fault lies.

Message	Typical meaning	What to do
550 5.7.26	Message unauthenticated, SPF hard fail, or blocked by DMARC policy	Correct SPF, DKIM, DMARC and alignment
550 5.7.30	DKIM failed permanently	Confirm DKIM is enabled and its DNS record exists
550 5.7.40	Bulk sender has no DMARC record	Publish a `_dmarc` TXT record
550 5.1.1	Recipient address does not exist	Check the address for typos
Relay access denied	Sending without SMTP authentication	Enable authentication in the mail client
Quota exceeded or mailbox full	Storage or send limit reached	Free space or ask for a higher limit
554 denied or spam rejection	Receiving server judged the message to be spam	Keep the headers and check blacklists and authentication

(DMARCguard, Fused)

When to Contact Your Hosting Provider

Some faults can only be solved on the provider’s side. Open a ticket if you see any of the following:

The server IP is blacklisted
Outbound port 25 is blocked, or your send limit must be raised
A PTR (reverse DNS) record needs to be set or corrected
The mail service (Exim or Dovecot) is down, or the queue is stuck
The account is suspended or the domain is on spam hold
MX, SPF and DKIM all look correct, yet mail still fails to arrive or leave

What to include in the ticket

Complete details shorten the time to a fix:

Your domain and the affected mailbox
Whether sending, receiving or both are failing, and since when
The full bounce text with its error code
The other address involved in the test, such as a Gmail account
The channel in use (webmail, Outlook, phone app) and the port configured
Any recent changes to DNS, nameservers, MX or mail settings
The “Show original” headers of a test message, if you can obtain them

Support contact: [insert your hosting brand’s support email, ticket or live chat link here]

Prevention Checklist

Set up SPF, DKIM and DMARC on every domain
Start DMARC at p=none, review reports, then enforce gradually
Use port 465 or 587 with authentication in every mail client
Monitor mailbox quotas regularly
Send website form mail through authenticated SMTP
Use a dedicated delivery service for bulk campaigns
Record your current MX and routing before changing nameservers or DNS
Run a deliverability and blacklist check once a month
Give each mailbox its own strong password

Frequently Asked Questions

Webmail messages reach Gmail, but only in spam. Why? Most often SPF, DKIM or DMARC is missing or not aligned. Open the message in Gmail with “Show original” and confirm all three results say PASS.

My domain has two SPF records. Is that a problem? Yes. Only one SPF record is valid per domain, so merge them into a single entry.

How long until a new MX record works? Usually from a few minutes to a few hours, depending on the TTL. During that window some senders may still deliver to the old destination.

Can an MX record contain an IP address? No. It needs a hostname, and that hostname needs an A record pointing at the server.

What changes if I use Google Workspace or Microsoft 365? Point MX at the servers they specify, set cPanel Email Routing to Remote Mail Exchanger, and add their include: entry to your SPF record.

Is DMARC mandatory? Not for every sender by law, but Gmail, Yahoo and Microsoft expect it from high-volume senders, and it improves protection and inbox placement for everyone else too.

Conclusion

For outgoing problems, repair SPF, DKIM and DMARC and confirm them with the Email Deliverability tool in your hosting panel. For incoming problems, correct the MX record, use the hosting hostname as its destination when you rely on webmail, and make sure Email Routing matches. If the fault persists, send your provider the bounce text and the details above so the server-side cause can be found quickly.