Email goes to spam: where Postfix configuration breaks
An email leaves the queue without errors, but the recipient does not see it: some messages land in Spam, some are rejected on the recipient side with a 550 refusal, and some drive the IP or domain onto blacklists.
The sender sees the status Delivered, while the client waits for an invoice or login link and never receives them.
The cause is almost always on the sender side.
In Postfix, this is usually an incomplete DKIM signature, an SPF record that does not cover all sending nodes, a PTR that does not match the name in HELO, and a domain without a DMARC policy — the recipient simply has no way to confirm that it is we who have the right to send the email.
Sender reputation is built from these checks long before content filtering, and the email text has almost nothing to do with it.
The cost of such a configuration is higher than it seems: transactional emails — password reset, order confirmation — do not arrive, and support looks for the problem in templates.
Worse, when a provider blocks emails from the domain entirely: regaining trust and getting off blacklists takes weeks, and all that time email is silent.
We explain how this is closed: where to look at the queue and logs, what checks an email passes before the inbox, and what exactly is fixed in Postfix configuration so the recipient sees a verified sender.
What a correct mail server configuration provides
Email deliverability is determined not by one parameter but by a combination: aligned SPF and DMARC records, DKIM email signing, a correct return address, and sending rate limits.
A server on Postfix covers each of these tasks, but the combination only works as a whole — half-configured mechanisms produce a worse result than their complete absence.
TLS connection encryption is enabled in two modes: opportunistic negotiation and mandatory with certificate verification on the recipient side.
The first provides compatibility with almost all mail systems, the second guarantees that the content will not be read at an intermediate node.
The same task is solved by publishing a domain policy for recipients: major services support it and reject emails that arrive outside a secure channel.
Spam filters work on both receipt and sending: node reputation checks, header parsing, content scoring, quarantine instead of irreversible deletion.
This layout separates temporary 4xx delays from 5xx refusals — unavailability of a remote server stops turning into a lost email, and every rejection is visible in the log with a reason.
Measurable effect: the share of emails reaching the Inbox reaches 97–99%, the classes of refusals "no signature" and "does not match domain policy" disappear, and mailings on behalf of the company are blocked at the recipient before they are read.
Separately, the risk that an email with your domain will go to a client from someone else's server is eliminated.
Own server, external service, or hybrid: what to choose
The choice here is not binary. It is worth evaluating along three axes: who is responsible for address reputation, how deeply you need to manage headers and delivery logs, and whether the team has someone ready to sort out a stuck email queue at night.
The key criterion is the nature of the traffic. Transactional emails (password reset, invoice, notification) require immediate delivery and refusal handling, while bulk mailings require address warming and unsubscribe processing. That is why streams are often separated along different paths: this is the hybrid sending scheme.
| Option | When it fits | Limitations |
|---|---|---|
| Own mail server | Full control is needed: your own DKIM keys, filtering rules, delivery logs, correspondence within a closed perimeter | You grow address reputation yourself — reverse zones, SPF, DKIM, DMARC, complaints, and blocklists are on your side |
| Managed mail server | Administration is delegated to an integrator, while the domain and configuration remain yours | Non-standard changes go through the provider's regulations, and response takes longer |
| External mailing service | Bulk and transactional sending where deliverability and reporting are needed without your own team | Weak control over headers and logs, reputation depends on a shared pool of addresses, and terms are tied to sending volume |
| Hybrid sending scheme | Inbound and internal emails on your own server, bulk and transactional — through an external node | The two circuits must be connected: routing, unified authentication, policy synchronization, refusals are handled in two places |
In practice, a hybrid is chosen more often than "pure" schemes: it relieves the load on your own node but retains control over correspondence. Next, we explain how TLS, DKIM, and filtering are configured on each circuit.
Postfix configuration procedure: from audit to handover
Mail server configuration starts not with editing the configuration but with an audit: most often the cause of problems is not in the code but in address reputation, incorrect DNS records, and a queue that accumulates for days.
That is why we work strictly in stages — from measuring the current state to handover for operation.
-
Audit of current sending. We capture mail agent logs: response codes from receiving parties, the share of emails in the queue and its processing time, behavior under peak load. In parallel, we check PTR, SPF, DKIM, DMARC, and whether the address is on blacklists.
-
Solution design. We record which domains and streams we serve, where the boundary between transactional emails and bulk mailings lies, and on which node we enable filtering and signing.
-
Server configuration. We install Postfix with TLS and automatic certificate renewal, generate a DKIM key and publish records, enable anti-spam with greylisting and blocklists, and limit sending rate and the number of parallel connections.
-
Test sends. We send to external mailboxes at different providers and read the headers: the signature must verify, domain alignment must match the scheme, and the email must land in the Inbox, not in spam.
-
Configuration validation. We simulate failure of one of the components, observe how the queue and retries behave, and check whether log rotation, monitoring, and a clear rollback plan are enabled.
-
Handover for operation. We provide access credentials, the stream scheme, the list of DNS records, and instructions for the on-call engineer: what to check when there is a non-delivery complaint and how to quickly roll back a change.
Set of configurations, schemes, and support regulations
A server ready for operation is not yet the result that can be left without us. After handover, your team retains a set of artifacts: configurations with explanations, signing keys, a stream scheme, and procedures for typical situations.
- Working configurations of Postfix and related services in a version control system — with comments explaining why a parameter is set this way and what will break if it is changed.
- DKIM keys and signing records: private ones — with storage location and rotation procedure, public ones — with an exact list of records for changing the DNS provider.
- Mail flow map: inbound and outbound email, relays, at which stage authentication checks and filters trigger, and where an email goes if delivery fails.
- Access policies: who connects to the server and from where, authentication rules, and relay restrictions for internal services and external senders.
- Backups of configuration and keys — with a schedule, retention period, and restore verification on a separate test environment.
- Maintenance procedure: updating filters and databases, key rotation, queue and log analysis, actions when blacklisted.
- Infrastructure documentation: a scheme of SPF, DKIM, and DMARC records, dependencies on external services, failure points, and on-call procedures.
The set is updated as changes occur — the documentation does not diverge from the actual server state.
Project case study: how we restored email deliverability for a store
An online store with its own mailing: invoices, order statuses, access recovery. Complaints of "the email did not arrive" came in waves, and some transactional messages settled in spam at major recipients.
The Postfix configuration had been kept "as it was set up" for years, and the owner did not immediately see the link between the drop in repeat purchases and email.
What the analysis showed
The server sent everything from one address and one reputation: one spike of complaints dragged down the entire domain. There was no DKIM signature, SPF and DMARC were not aligned — recipients cut off some emails even before content checks.
The logs added a second problem: after a short network failure, the queue did not clear on its own and waited for manual intervention.
What we changed and what the result was
We separated the streams: transactional emails went to a separate subdomain and a separate address with a warmed-up sending volume, while bulk mailings went to their own.
We configured SPF, DKIM with a current signing algorithm, and a DMARC policy first in monitoring mode, then in reject mode. The queue received retry limits and automatic return of deferred emails — short failures stopped requiring an on-call engineer.
We tracked deliverability through Postmaster Tools: the share of delivered emails grew from ~60% to 97–99%, we left key blacklists within a couple of weeks, and recovery after a failure takes minutes instead of manual analysis.
What to do if the mail server is already running but emails go to spam?
If Postfix is already deployed but emails go to spam, you need to start with sending diagnostics. We compare queue logs with responses from receiving servers: some addresses accept mail, some respond with a delay or reject at the connection stage. The difference between these groups is the point where the cause should be sought.
Next is checking email signing. We look at whether the DKIM signature is applied to the entire outbound stream or whether emails from website forms and internal modules lose it.
We check domain alignment in SPF and DMARC: if the envelope goes out with one name but the From header specifies another, filters read this as forgery. Forwarding breaks the signature, and the email loses trust.
In parallel, we check blacklists for the domain and address, IP history, and the reverse zone.
A separate case is a shared address with someone else's mailing or a fresh IP without warmed-up reputation: sending volume is increased gradually, otherwise the spike is recorded as a sign of bulk mailing.
When the cause is in the node or address itself, we perform mail server migration without stopping correspondence: the new node is brought up alongside, mailboxes are synchronized, signing and delivery are verified on it, and only then is mail exchange switched over — with rollback still possible. Users continue working in their usual interface.
We change what actually affects delivery: signing, policy, address reputation, queue parameters. We verify the result by the share of emails in the inbox and the number of refusals per hundred sends — not "it got better" but measurable dynamics.
Frequently asked questions about email signing, filters, and limits
Questions usually come down to one thing: how quickly emails will start reaching the recipient and whether the recipient's mail system will block us. Below are the things most often asked before work starts, with technical details rather than general promises.
How long does it take to get out of spam after configuring signing?
The configuration itself — correct SPF, DKIM, and DMARC records, a PTR reverse zone, and a sending host aligned with it — takes effect immediately.
But domain and address reputation is built gradually: at most major recipients, a fresh sender goes through lower trust for the first few days, and some emails go to the Spam folder.
Therefore, we make the first sends with a limited volume and increase it as successful checks appear in DMARC reports.
Stable delivery usually takes from a few days to two or three weeks — the timeframe depends on whether the domain was noticed in past mailings and whether it has a correspondence history.
Are there limits on sending volume?
Yes, and they are not on our side but on the recipients' side: most mail systems limit the number of connections and emails from one sender per unit of time.
We configure the queue so that sending proceeds at a specified rate, and in case of a temporary refusal, the email is not lost but is retried with increasing delay.
We separate bulk and transactional streams: emails from services and requests should not wait while a bulk mailing goes out.
Will the solution be compatible with what we already have?
We install and configure the mail server on your infrastructure; if you already have another agent running, we migrate addresses, aliases, routing rules, and current blocklists, and we perform the switchover with preparation on a test environment.
We verify email delivery across all mailboxes before switchover, so production traffic moves without downtime.
What to do if emails are still cut off by filters?
We analyze recipient reports and headers of rejected emails: most often the issue is a mismatch between the domain in the reverse zone and in the signature, or links and attachments that the anti-spam filter considers suspicious.
Based on the results, we correct the signature, templates, and filtering rules on our side rather than asking the recipient to add you to exceptions.
Next — how this looks in practice and what remains with you after handover: we will review the task and come back with an estimate and a plan.Let's discuss the task: we will come back with an estimate and work plan
To discuss the task substantively, at the start we need a minimum: the domain and access to manage its DNS records, a list of mailboxes and aliases, the current mail server configuration if it is already deployed, and samples of emails that currently go to spam.
This is enough to look at real delivery headers and understand where the sender signature is lost. If you do not yet have your own server — that is also a workable scenario; we start with a clean installation and immediately build the configuration correctly.
In response, we return not general words but a specific package:
- assessment of work by stages — with a clear division of what we do and what remains on the customer's side;
- implementation plan with sequencing: first basic delivery and channel encryption, then email signing, then anti-spam policies;
- scope of work — which records we create in DNS, which keys we issue and where we store them, which inbound email checks we enable;
- placement scheme: what is installed on the current server, and what requires a separate node or external service;
- list of accesses and approval points so as not to stretch the start into correspondence;
- operation procedure: how certificates and keys are updated, where to look in case of delivery failure;
- acceptance criteria — the share of emails passing authentication and a closed open relay.
Then we agree on the work order and start with the area that gives the fastest effect. Describe the task in a few words — domain, number of mailboxes, what is already configured — and we will come back with an estimate and a plan.