Business email stopped, messages stuck in queue, or nobody can send or receive?
We investigate Exim, Postfix, Dovecot, SMTP, IMAP, POP3, SPF, DKIM, DMARC, reverse DNS and TLS — plus the DNS, firewall, disk, resources and Linux layer underneath them — to find where mail flow actually broke.
Sending, receiving, mailbox access, or everything?
Very different symptoms have very different causes — the first step is narrowing down which one you’re in.
Users can’t send, SMTP connections fail, mail rejected by remote servers.
Incoming mail never arrives, some domains affected, others not.
IMAP fails, webmail down, authentication or certificate errors.
Nothing works — sending, receiving and mailbox access all affected.
Exim, Postfix or Dovecot
Config error, disk full, certificate problem, DNS, firewall, high load or a failed update. We check main/reject/panic logs — repeatedly restarting can hide the clue.
Mail logs, SMTP connectivity, queue status, relay config, TLS and recent changes — local to Postfix, or elsewhere in the stack.
Can send but can’t read mail — IMAP refused, webmail login failures, SSL errors, mailbox permissions.
SMTP down, port 587/465 blocked, auth failure, TLS problem, wrong client config, or the IP itself blocked. We test the SMTP service and find whether failure is before or after authentication.
Wrong MX records, port 25 blocked, DNS problem, rejected incoming messages, or disk full. We check both external DNS and the mail server itself.
Growing queue, or messages stuck?
An important warning sign — remote rejections, DNS problems, rate limits, reputation issues, or a compromised account sending spam. We review queue size, senders, recipients and SMTP responses before touching anything.
Often temporary — timeouts, greylisting, rate limiting, or the remote mailbox being unavailable. We check delivery logs to tell local from remote.
Why remote servers reject your mail
Missing server IP, duplicate records, syntax errors, or a third-party sender not included.
Missing DNS record, wrong selector, key mismatch, or domain mismatch.
SPF/DKIM alignment failing, third-party services misconfigured, or policy set too strict too soon.
Missing PTR, wrong hostname, or HELO/EHLO mismatch — usually configured through the provider.
Gmail, Microsoft and Yahoo run their own anti-abuse systems — instead of guessing, we read the exact SMTP rejection response.
Disk, inodes, memory and CPU
New mail rejected, mailboxes unavailable, queue growth. We find what’s consuming space before removing anything.
Free space can show while inodes run out — common on servers with lots of small mail files. Looks just like a full disk.
Exim/Postfix/Dovecot, spam filtering or webmail can all get killed under memory pressure.
Large queues, spam filtering, antivirus scanning, or a compromised account generating volume.
SMTP, submission and mailbox ports
Server-to-server delivery. Some providers restrict outbound 25 on new servers or certain accounts — may need provider intervention.
Authenticated sending. If blocked, users can’t send even while server-to-server SMTP still works.
Ports 143/993/110/995. Dovecot, firewall, SSL, authentication or mailbox permissions.
Expiry, wrong hostname, chain issues affecting SMTP/IMAP/POP3/webmail and mail clients.
Password, Dovecot auth, Fail2Ban block, disabled account, or quota — we find where the attempt is rejected.
Quota reached blocks new mail; a broken Roundcube (PHP, DB, SSL) doesn’t necessarily mean IMAP itself is down.
When email failure is actually a compromise
Huge queue, spam volume, unknown users, abuse notifications, blacklisting.
One stolen password can generate huge spam — credential change, session termination, queue cleanup.
The mail server itself may be clean — a hacked WordPress site sends through PHP. Fixing only the queue lets it come back.
Removal only makes sense after the actual abuse source is confirmed stopped.
One recipient, all recipients, one domain, or every domain?
Likely the remote server, not you — filtering, temporary rejection, or their reputation policy.
More likely Exim/Postfix, DNS, firewall, port 25, hostname or the server IP itself.
On a multi-domain server, usually domain-level: DNS, MX, quota, DKIM, SSL or account config.
Shared infrastructure — Exim/Postfix/Dovecot, firewall, DNS service, disk, memory, or the server itself.
MX, A, AAAA, PTR, SPF, DKIM, DMARC — changed carefully, since email depends on all of them together. IPv6 adds its own trap: AAAA records existing while IPv6 connectivity or reverse DNS is broken, or firewall rules that differ from IPv4.
Ports 25, 465, 587, 110, 143, 993, 995 across UFW, iptables, nftables, CSF and the provider firewall — only what’s actually needed stays open. Fail2Ban protects against brute force but can occasionally block legitimate users; we restore access without disabling useful protection.
HestiaCP, DirectAdmin, cPanel & WHM, VestaCP — we check the actual Exim/Dovecot service, not just the panel status. Sometimes the cause is provider-side: SMTP restrictions, IP blocks, abuse suspension or an infrastructure outage.
After a migration: wrong MX, stale DNS, missing mailboxes, missing DKIM/PTR, different hostname. Recovering from backup means restoring carefully so newer mail isn’t overwritten by older backup data.
Restoring flow is the first step, not the last
A restart can bring mail back temporarily without fixing the actual cause.
Bounce messages and exact SMTP errors matter most
A complete email outage normally qualifies as Emergency Support
Emergency Support, for critical email and Linux server incidents.
Out-of-Hours Emergency Support — evenings, weekends, holidays.
Both subject to administrator availability — no guaranteed 24/7 coverage unless separately agreed. Full pricing →
Yes, even when your email is down
Contact us from any working external address — bounce messages and SMTP responses usually contain the exact reason for failure, and they’re easier to act on in writing.
help@direktsupport.euInclude the affected domain and the exact error message. Phone support is primarily for customers with an active monthly management plan.
More than 22 years of practical experience with Linux servers, hosting infrastructure, Exim, Postfix, Dovecot, DNS, backups and production environments. Our objective isn’t simply to restart the mail service.
We identify whether it’s the mail server, DNS, networking, security or Linux underneath — and restore mail flow as safely as possible.