Business Email Not Sending or Receiving? Common Causes & Fixes

Business email almost never fails for one reason. What looks like "email is broken" is usually two separate problems wearing the same disguise: mail that won't go out, and mail that won't come in. They have different causes, different fixes, and mixing them up is the single biggest reason people spend hours chasing the wrong setting.

If you can't send, the fault is usually on your side of the connection: a broken authentication record, a maxed-out sending limit, or a receiving server that's rejecting your domain outright. If you can't receive, the fault is usually upstream: a wrong MX record, a full mailbox, or a spam filter that quietly swallowed the message without ever telling you it did.

Work out which one you're actually dealing with before you change anything. That single step will save you more time than every other fix in this guide combined.

Sending Problem or Receiving Problem? Tell Them Apart First

The trap in that second row is the one worth remembering. If a spam filter on the recipient's server quietly drops your message into their junk folder, your server never gets a bounce because, as far as your server is concerned, the message was accepted. It just never surfaces where the recipient can see it. That's a receiving-side spam filter doing its job, not a sending failure on your end, and no amount of fiddling with your own settings will fix it.

Why Business Email Isn't Sending

1. Your account got logged out of SMTP authentication

This is the most common cause and the most overlooked, because it's boring. If your business uses an app-specific password (common with Google Workspace and Microsoft 365 when two-factor authentication is on) and that password was reset, revoked, or expired, your desktop mail client or old scanner/printer will fail silently or throw a generic "can't connect to server" error. Check the account settings on the device, not just the webmail login - they're often not the same credentials.

2. Your network is blocking outbound port 25

This mostly hits businesses running their own mail server, a legacy on-premise Exchange box, or a website contact form that relays mail through hosting rather than through a proper transactional email service. Major residential and business ISPs, Comcast/Xfinity, Verizon, and AT&T among them, block outbound SMTP on port 25 by default specifically to stop compromised machines from being used to send spam. The fix is almost always to switch outbound submission to port 587 with STARTTLS authentication rather than trying to get port 25 unblocked, which most ISPs won't do for a residential or standard business line anyway.

3. Your SPF record has quietly broken

SPF records are only allowed ten DNS lookups before the check fails - this is a hard limit defined in the SPF specification (RFC 7208), not a guideline. Every time you add a third-party sender (an invoicing tool, a CRM, a marketing platform, your web host), it can add another lookup. Cross ten and the entire SPF record returns a "permerror," even if it looks perfectly valid when you read it. The frustrating part is that this doesn't throw an error anywhere in your inbox - it just makes your outbound mail progressively less trustworthy to receiving servers until one day a chunk of it starts landing in spam or bouncing outright, with no obvious trigger. If you've added a new SaaS tool in the last few months and delivery has quietly gotten worse since, this is the first thing to check.

SPF only answers one question: who's allowed to send for this domain, so it's not the whole picture on its own. Gmail and Yahoo's inbox placement now leans just as heavily on DKIM (a cryptographic signature proving the message wasn't altered in transit) and DMARC (the policy that tells receiving servers what to do when SPF or DKIM fails). A domain with a perfect SPF record but no DKIM or DMARC still gets dropped silently by receivers that require alignment across all three.

4. The receiving server is rejecting you - read the bounce code

Every bounce-back has a three-digit code buried in it. Learn to read the first digit and you've cut your diagnosis time in half:

The 550 code trap: both of the codes below start with 550, and it's the second half that actually matters

• 550 5.1.1 = an address problem. The inbox literally doesn't exist. Check for a typo and move on.
• 550 5.7.1 = a trust problem. The inbox exists, but the receiving server doesn't trust your domain's reputation - usually an SPF, DKIM, or DMARC failure, sometimes a blacklisting.

Treating a 5.7.1 like a typo and just retrying wastes time and fixes nothing - the message will keep failing until the underlying trust issue is resolved.

5. You've hit a sending limit

Business email platforms cap how many recipients you can reach in a rolling 24-hour window, and hitting the ceiling looks exactly like a broken account from the inside:

Neither platform sends you a clear "you've hit your limit" pop-up - you'll just find that new outgoing mail stalls or fails until the rolling window resets, typically within 24 hours. If your business recently ran a bulk mailout, an event invite blast, or a mail-merge campaign through a normal Workspace or 365 mailbox rather than a dedicated sending platform, this is very likely your cause, and it will resolve itself once the window clears — no support ticket needed.

6. Attachments are triggering a filter

Executable file types (.exe, .bat) and some archive formats get blocked outright by most business mail filters regardless of size. Beyond content type, total message size matters too, and this is the one that catches people out because there's rarely a bounce to explain it:

• Microsoft 365: 35MB combined limit for message + attachments by default (an admin can raise this to around 150MB)
• Gmail: anything over 25MB gets auto-converted into a Google Drive link instead of sending as a true attachment

If a message with a large PDF or design file "just disappears" with no bounce, check the size before anything else.

Why Business Email Isn't Receiving (Or Arriving)

1. MX records still point at the old server

This is the single most common cause after a hosting move, a domain transfer, or switching from one email provider to another. MX record changes don't take effect instantly - DNS propagation typically takes anywhere from a few hours up to 48 hours, and in rarer cases up to 72 hours, depending on the TTL (time-to-live) that was set on the old record. During that window, mail doesn't vanish; it splits. Some senders' DNS resolvers will pick up your new MX record quickly - others will keep delivering to the old server until their cached copy expires. That's why "some emails are arriving and some aren't" right after a migration is normal, expected behaviour, not a fault.

Practical tip: if you know a migration is coming, drop your MX record's TTL to something short (300 seconds is common) a day or two beforehand. It won't make the cutover instant, but it dramatically shortens the propagation window because caches refresh far more often.

2. Spam filtering is doing its job silently

Covered above in the diagnostic section, but worth repeating because it's the one that generates the most confused support calls: if mail is being filtered as spam on the receiving end, the sender gets no error at all. From your side, it looks identical to a message that was never sent. The only way to confirm this is to ask the sender to check their own sent folder - if it shows as sent successfully, the problem is filtering on your end, not a delivery failure on theirs.

3. The mailbox is full

Storage limits vary meaningfully by plan, and hitting them causes new mail to bounce back to the sender with a 552 error rather than simply queuing:

• Google Workspace Business Starter: 30GB per user, pooled across Gmail, Drive, and Photos
• Google Workspace Business Standard/Plus: 2TB–5TB per user
• Microsoft 365 Business Basic/Standard/Premium: 50GB per mailbox as the long-standing default, with Microsoft's 2026 packaging update extending eligible Business plans to 100GB

The Google Workspace figure catches people out because it's shared storage - a user who's hoarding files in Drive can push their mailbox over the limit without a single large email involved.

4. An old inbox rule is silently redirecting mail

This one has no error message at all, which makes it the hardest to spot. A forwarding rule set up years ago for a former employee, an auto-archive rule that files anything from a certain sender straight into a folder nobody checks, or a "vacation responder" left switched on can all make legitimate email seem to vanish. Check the account's rules and forwarding settings before assuming it's a server-side fault - this takes two minutes and rules out a surprisingly common cause.

5. Greylisting is delaying (not blocking) delivery

Some receiving mail servers use greylisting: they temporarily reject a first-time message from an unfamiliar sending server with a soft 4xx code, on the theory that legitimate mail servers retry automatically while spam bots usually don't. If you're waiting on an email from a sender using a brand-new mail server or a freshly migrated domain, a delay of anywhere from a few minutes to an hour before it arrives isn't a fault - it's the system working as designed. It only becomes a real problem if the sending server isn't configured to retry, which is worth flagging to the sender if delays become a pattern.

6. Shared hosting reputation dragged the domain down

If your business email runs on a cheap shared hosting package rather than a dedicated business email platform, you're sharing an outbound IP address with hundreds of other domains you've never heard of. If even one of them starts sending spam, the entire IP can get added to a blacklist, and legitimate mail from your domain gets deferred or rejected along with it, through no fault of your own. This is one of the more frustrating causes precisely because nothing on your account is actually broken. Checking your sending IP against a blacklist checker (Spamhaus and MXToolbox both offer free lookups) takes thirty seconds and rules this in or out immediately.

Platform Quirks Worth Knowing

Google Workspace

• Storage is pooled across Gmail, Drive, and Photos on Basic/Business Starter plans - a mailbox can "fill up" from files that have nothing to do with email at all.
• Google Postmaster Tools shows your domain's aggregate spam rate, which Google expects to stay well below 0.30% for bulk senders - worth checking before assuming a problem is one-off.

Microsoft 365 / Outlook

• The 30-messages-per-minute rate limit trips up automated systems more often than the 10,000/day ceiling does.
• A burst send an order-confirmation flow, an event-invite blast, can hit this rate limit and start queuing even though the mailbox is nowhere near its daily total.

Website contact forms and shared hosting email

• These typically skip proper SMTP authentication and rely instead on the hosting server's local mail function.
• If that server's IP has a poor reputation (see the shared-hosting point above), contact-form submissions are usually the first thing to start silently failing, because they're unauthenticated and easy for a receiving filter to distrust.

A Troubleshooting Pattern Worth Recognising

One combination comes up again and again with businesses that have recently switched web host or email provider, and it's worth walking through because it explains why sending and receiving problems so often appear to happen at once, even though they're unrelated underneath.

The pattern looks like this: a business moves hosting providers and updates its DNS. Internal mail, colleague to colleague, same platform keeps working perfectly, because it never leaves the platform's own servers. External mail to clients starts getting deferred or bouncing with 550 5.7.1 errors. On the surface, it looks like one big outage. In reality it's usually two separate, coincidental faults: the MX record change is still propagating (a receiving-side, temporary issue that resolves on its own within 48 hours), and the SPF record wasn't updated to include the new host's outbound servers (a sending-side, permanent issue that won't resolve on its own and needs a DNS edit). Because both symptoms showed up in the same week, they get treated as one problem, and the SPF fix gets missed while everyone waits for "propagation" to finish, even though propagation was never going to fix it.

The lesson: after any hosting, domain, or provider migration, check MX propagation and your SPF/DKIM/DMARC records as two separate tasks, not one.

Step-by-Step Diagnostic Checklist

1. Confirm which problem you have: sending, receiving, or both using the table near the top of this guide.
2. If sending: check for a bounce-back and read the code (4xx vs 5xx) before doing anything else.
3. If sending fails with no bounce at all: check whether you've hit a daily sending limit (Google Workspace: 2,000/day; Microsoft 365: 10,000/day, 30/minute).
4. If receiving: ask the sender to confirm the message shows as sent on their end. If it does, the problem is filtering, not delivery.
5. Check MX records with a free lookup tool (MXToolbox is the standard) if anything changed hosting, domain, or provider in the last 72 hours.
6. Check SPF, DKIM, and DMARC for your domain using a free checker - specifically look for an SPF "permerror," which signals the 10-lookup limit has been exceeded.
7. Check mailbox storage for the affected account.
8. Check inbox rules and forwarding settings on the affected account.
9. Run a blacklist check on your sending IP (Spamhaus or MXToolbox) if the issue affects mail to multiple different domains at once.
10. If everything above checks out clean: the fault is likely on the recipient's server, not yours - ask them to check their own logs.

When to Bring In a Professional

Most of the causes above are a five-minute DNS check or a settings fix. Bring in someone with hands-on DNS and mail server experience if:

• It's been more than 72 hours since a migration and mail is still splitting between old and new servers
• You've confirmed a blacklisting and don't know how to request delisting from the specific blacklist involved
• Your SPF record has exceeded the 10-lookup limit and needs restructuring with nested includes or flattening
• You're planning a DMARC rollout to p=reject and want to avoid blocking your own legitimate mail in the process
• The issue is intermittent and affects some recipients but not others, which usually means a reputation issue rather than a simple misconfiguration

Related Guides

Why Are Business Emails Going to Spam? (SPF, DKIM & DMARC Explained) - a closer look at the authentication trio behind most of the sending causes above

Domain Related Problems - for DNS delays, missing verification, and email setup errors tied to your domain

Hosting Related Issues - if shared hosting or IP reputation looks like the root cause

Professional Email / Business Email Issues - for hands-on help fixing SPF, DKIM, DMARC, and delivery problems directly