Skip to content
Postfix Insights

Spot a deliverability problem in your Postfix logs

A deliverability problem is not random. When your mail reputation or sending policies are questioned, you will see a cluster of rejections or deferrals concentrated on a specific receiver (one mailbox provider or domain), not scattered across dozens of destinations. This concentrated failure is the signal that separates a reputation issue from normal list churn.

The cluster signal: concentration is the symptom

Section titled “The cluster signal: concentration is the symptom”

Read your mail logs with an eye to density. A few 5.1.1 (user unknown) failures to different providers across a week? Normal. But 200 deferrals in two hours, almost all to one domain, with DSN codes starting in 4.7.x or 5.7.x? That is a reputation or authentication issue showing itself.

Random scatter
low-rate 5.1.1 across many domains: list hygiene, not reputation
Concentrated cluster
a spike to one provider with 4.7.0 / 5.7.x: rate limiting or a policy block
Random failures spread thin across destinations are noise. Failures concentrated on one receiver, with policy or rate codes, are a reputation or authentication problem. Group by domain, then by code.

The most common patterns are:

  • A sudden spike in 4.x.x transient bounces (especially 4.7.x) to one provider, often repeating over hours or days. This usually means rate limiting or throttling; your reputation is warming up or the provider is pushing back.
  • A sharp rise in permanent 5.7.x failures (especially 5.7.1 or 5.7.26) to one domain. This is policy rejection: the provider has blocked your messages due to reputation, SPF/DKIM/DMARC alignment, or an IP-level block.
  • A spike in 5.1.1 (user unknown) spread evenly across many recipients at one domain over a short window. This often signals a list quality problem, not a reputation issue; compare it to your baseline.

Postfix Insights groups bounce and defer rates by destination domain and breaks down DSN codes per destination, so a concentrated spike becomes immediately visible in the delivery health dashboard instead of buried in raw logs.

How to read the codes

Section titled “How to read the codes”

Enhanced status codes (DSN codes) follow RFC 3463. They are three numbers: class.subject.detail, where the first digit tells you permanence.

4.x.x codes are transient. Your mail bounced but could succeed later. Retry is expected. Within the 4.x.x family, 4.7.x is the policy and security class:

  • 4.7.1 (transient security failure) and other 4.7.x codes mean the provider is imposing temporary rate limits, authentication challenges, or reputation delays. This is not a permanent block. Reduce sending rate, ensure authentication (SPF, DKIM, DMARC) is aligned, and give your reputation time to warm.

5.x.x codes are permanent. The message will not be delivered; permanent action is required.

  • 5.7.1 (delivery not authorized, message refused) is the provider’s policy rejection. Common reasons: IP reputation (your sending IP is blocklisted or has poor history), domain reputation (your sending domain has little or no history), or sender verification failure. Check your IP reputation and sending domain reputation with provider postmaster tools.
  • 5.7.26 (multiple authentication checks failed) is defined in RFC 7372 and means DMARC, SPF, or DKIM alignment failed. The provider’s authentication checks found a mismatch: your message was signed by a domain that did not align with the envelope From, or SPF did not pass. This is almost always an authentication configuration issue, not reputation.
  • 5.1.1 (bad destination mailbox) means the recipient user does not exist at that provider. This is a list hygiene issue, not a reputation signal, and should not cluster suddenly unless your list source changed.

For a complete reference, see the DSN Status Codes reference.

Triage: cluster by destination, then by code

Section titled “Triage: cluster by destination, then by code”

Spotting the cluster is the first step. To understand what is happening, group failures by destination domain, then by DSN code within that domain.

If you see a spike of 5.7.1 or 5.7.26 concentrated on one provider:

  1. Check SPF, DKIM, and DMARC alignment. Use your provider’s postmaster tools (Google Postmaster Tools for Gmail, Microsoft SNDS for Outlook) to see rejection reasons. Many providers give feedback on authentication or reputation in real time.
  2. Check your sending IP reputation. Services like Sender Score, Talos Reputation Center, or your provider’s IP reputation tool will show if your IP is listed.
  3. Verify that DKIM signatures are applied to all outgoing mail and are aligned with your domain’s From header. SPF should include your sending IP or mail server.
  4. If blocked at the IP level (common for new IPs), expect the block to lift once reputation warms. Warm up slowly: send a small volume to your own domain or whitelist first, then gradually increase.

If you see a spike of 4.7.x deferrals (transient policy) to one provider:

  1. Reduce your sending rate to that domain. Rate limiting is the provider’s way of saying “slow down.” Backing off for a few hours or days often resolves it.
  2. Ensure authentication is correct. Some providers rate-limit mail that does not have DKIM, SPF, or DMARC alignment, even if not fully rejected.
  3. Monitor reputation warmup metrics. If you are a new sender, expect early deferrals as you build history. After a week or two of low-volume, clean sends, deferrals typically subside.

If you see scattered low-rate 5.1.1 failures across many recipients at one provider:

  1. Check your recipient list. Batch processes sometimes generate outdated or mistyped addresses.
  2. Validate email addresses before sending. Remove unverified addresses.
  3. This is not a reputation issue; reputation issues show in concentrated 5.7.x or 4.7.x spikes, not in user-not-found errors.

If failures scatter across many domains with no concentration:

This is normal churn. Random individual bounces (a user here, another there) are not a signal of a reputation problem.

What to check next

Section titled “What to check next”

Once you have identified a concentrated spike to one provider with policy or transient-policy codes, the next steps are targeted.

Authentication alignment (for 5.7.26 or authentication-related 5.7.1):

  • Verify that your DKIM private key is loaded in Postfix and signs all outgoing mail (check header_checks in your Postfix config).
  • Confirm that your domain’s SPF record includes all IPs or servers authorized to send mail on your behalf.
  • Validate DMARC policy alignment: the domain in your envelope From header must match the domain in the DKIM signature or SPF-authenticated IP.

To check these records against your live DNS from outside the mail server, the Email Authentication Checker grades SPF, DKIM, DMARC, MTA-STS, and more for a domain, and the Email Header Analyzer reports the SPF, DKIM, and DMARC result for a specific message when you paste its headers.

IP and domain reputation (for policy-based 5.7.1 or 4.7.x deferrals):

  • Query your sending IP against major blacklists. Check Sender Score, Barracuda Reputation Block List (BRBL), or your provider’s IP reputation dashboard. The Email Blacklist Checker tests a domain or IP against several public DNS blocklists in one pass.
  • Check reverse DNS (PTR) for your sending IP. It should resolve to a hostname under your control or your mail provider’s hostname.
  • Review your domain reputation. New domains without sending history are often deferred or rate-limited. Sending a small volume of clean mail to your own domain or a test list for a few days builds initial history.

Provider feedback:

  • Most major mailbox providers (Google, Microsoft, Yahoo, etc.) offer postmaster feedback tools. Google Postmaster Tools and Microsoft SNDS provide real-time delivery metrics, authentication failures, and reputation feedback.
  • These tools do not give you a direct “reason” code but show trends in rejections, spam complaints, and authentication errors. Use the trends to guide your next check.

Postfix Insights in your workflow

Section titled “Postfix Insights in your workflow”

Postfix Insights surfaces bounce and defer metrics by destination domain and breaks down DSN codes per domain. When a reputation or policy issue strikes one provider, you will see the spike in the delivery health view immediately, without scrolling through raw logs.

From there, you can:

  1. Click into the affected domain to see the DSN codes.
  2. Group by code to see whether the issue is transient (4.7.x), permanent (5.7.x), or authentication-related (5.7.26).
  3. Cross-reference that domain in your postmaster tools or IP reputation service.

For a walk-through of the dashboard, see the Quick Start guide. For a detailed breakdown of how bounces and deferrals differ in Postfix logs, see Deferred vs. Bounced Mail in Postfix.

To analyze Postfix logs locally or integrate them into your own systems, visit the Postfix Insights GitHub repository.

References

Section titled “References”