Why Your Business Emails Are Being Blocked or Delayed (UK SME Guide)

When email goes wrong, most people assume “it’s in spam”. In reality, modern mail systems often reject or delay messages long before the recipient ever sees them. For UK SMEs this can silently break enquiries, quotes, invoices and purchase orders.

Common symptoms

• Emails “send” but the recipient never receives them (and you get no obvious error).
• Some recipients get emails instantly, others see delays of 10–60+ minutes.
• Emails to Microsoft 365 / Outlook.com are inconsistent (works one day, fails the next).
• Web forms and scanners fail while Outlook works (or vice versa).
• You receive “Undeliverable” / “Rejected” bounces with confusing technical codes.

Why this happens

Most blocking and delays fall into a few repeat categories. The trick is identifying which one you’re hitting.

• Authentication issues (SPF/DKIM/DMARC) causing rejection or policy-based failures.
• Reputation issues (shared server IP, previously abused IP range, or unusual sending patterns).
• DNS mismatches (missing reverse DNS / rDNS, incorrect hostnames, stale records).
• TLS/handshake problems (old ciphers, certificate/name mismatch, outbound relay issues).
• Rate limiting / greylisting (recipient servers intentionally delay mail to deter spam).
• Misconfigured apps (websites, printers, CRMs) sending “from” addresses they aren’t allowed to use.

Typical bounce messages (plain English)

You don’t need to memorise SMTP codes, but recognising these patterns saves hours.

Message / code you might see	What it usually means	Typical fix
550 / 5.7.1 rejected	Recipient server is refusing the message (policy/auth/reputation).	Check SPF/DKIM/DMARC alignment; confirm sending IP/domain reputation.
451 / 4.7.1 try again later	Temporary deferral (greylisting or rate limiting).	Warm sending pattern; reduce bursts; ensure correct HELO/rDNS; monitor queue.
SPF fail / not permitted	Sender isn’t authorised to send for that domain.	Fix SPF record; ensure apps send via the correct relay.
DMARC fail	DMARC policy is rejecting because From: doesn’t align with authenticated identity.	Fix DKIM signing and alignment; correct From: usage in apps; review DMARC policy.
TLS negotiation failed	Encryption handshake/ciphers/cert mismatch between servers.	Update mail stack; ensure correct hostname/cert; avoid legacy TLS settings.

Quick checks you can do (without specialist tools)

• Send a test to multiple providers (Gmail, Outlook, Yahoo) and note who fails.
• Check your From address matches your domain (avoid random From domains in apps).
• Look for bounces in Sent Items, server logs, or the sending mailbox (they often land there).
• Ask the recipient for the exact bounce (screenshots or copy/paste helps).
• Check your DNS is consistent (SPF record exists, DKIM exists, DMARC exists).

Fixes that usually work

• Make SPF correct and minimal (authorise only what you actually use; avoid multiple SPF records).
• Enable DKIM everywhere (especially if you use Microsoft 365 or a third-party relay).
• Set a sensible DMARC policy (start with monitoring, then tighten once aligned).
• Use an authenticated SMTP relay for apps (websites, scanners, CRMs) rather than direct sending.
• Fix reverse DNS (rDNS) on dedicated mail servers (HELO name should match PTR).
• Monitor and manage reputation (shared IP pools can be risky; consider dedicated outbound where appropriate).

When to escalate (and what to ask for)

If the issue is intermittent, affects only certain domains (often Microsoft), or involves server-level reputation, you’ll want proper diagnostics. When escalating to your IT provider, ask for:

• SMTP logs showing the exact rejection/deferral response
• Confirmation of SPF/DKIM/DMARC alignment
• Confirmation of sending IP and whether it’s shared or dedicated
• Confirmation of rDNS/PTR and HELO hostname
• A plan for app relay (web forms/scanners) so they don’t break when policies tighten