An invoice bounces, an order notification remains queued, or a password reset never reaches its user. Start by establishing which message stopped at which stage. A 550, 554 or 421 reply helps direct the investigation, but the number alone does not establish the root cause or the correct change.
This guide follows an incident from evidence collection through ownership, a targeted correction and controlled retry verification. For the individual standard reply meanings and the detailed DSN field reference, use the SMTP codes and bounce reference. The examples here are hypothetical, not DCHost customer incidents or completed tests.
1. Record the message and its user impact
Write down the expected result: an invoice arriving, a single recipient receiving an update, or an entire application’s notifications returning to normal. “Sent” in an application may mean only that a submission server accepted the message. Acceptance after the final message-data reply, inbox placement and reading are separate outcomes.
Record the event time and time zone, sending application, SMTP service, affected envelope recipient, queue or provider message identifier and complete error reply. If the user clicked send several times, keep those submissions separate. Correlate application and MTA records before assuming they describe the same message.
- Which command preceded the reply: AUTH, MAIL FROM, RCPT TO, DATA, or the end of message data?
- Which server replied: the application’s submission service or a remote recipient MX?
- Does the incident affect one recipient, one domain, one application or all outbound traffic?
- What changed recently: credentials, account, sending source, DNS, attachment size, software or volume?
- Is this recipient still queued, finally failed, accepted, or in an uncertain state?
Keep the complete raw evidence in restricted storage and prepare a redacted copy for support. Do not share passwords, AUTH payloads, API keys or password-reset links. Limit personal addresses and message content to what the investigation requires, and verify diagnostic links through the provider’s known website.
2. Establish recipient state before resending
A 4xx reply is a temporary failure; an MTA that already accepted the message normally manages retries in its queue. A 5xx is a permanent failure for the command or attempt as made, so do not repeat it unchanged. That distinction does not make every 5xx recipient invalid or promise that every 4xx will clear within minutes.
An SMTP reply and a bounce are different events. Submission can fail directly in the application, while an MTA can generate a later notification after a remote rejection or queue expiry. A DSN goes to the envelope return address, which may differ from the visible From header. The absence of a bounce is not proof of successful delivery.
| Verified state | Immediate decision | Outcome to follow |
|---|---|---|
| Queued after temporary deferral | Identify the queue owner and retry schedule; avoid creating a new application copy. | Acceptance, another deferral, or final failure when the queue lifetime ends. |
| Action: failed | Attempts to this recipient have ended. Investigate Status and the complete diagnostic. | A new tracked submission only if needed, valid and corrected. |
| Success after final message data | This SMTP transfer was accepted. Investigate downstream delivery separately. | Provider delivery evidence, recipient confirmation or a later notification. |
| End of data sent, final reply lost | Acceptance is uncertain. Reconcile sender and, where available, receiver records. | A continuation decision owned by one system with duplicate risk recorded. |
One message can have several recipients with different RCPT TO results. Preserve each result and consider the final DATA response before deciding what was accepted. A failure for one address is not a reason to resend the message to every successful recipient.
From a DSN to an incident decision
This is a hypothetical message/delivery-status excerpt, not a complete MIME email. The message-level field and recipient-level fields are separated by a blank line:
Reporting-MTA: dns; mail.example.com Final-Recipient: rfc822; user@example.net Action: failed Status: 5.1.1 Remote-MTA: dns; mx.example.net Diagnostic-Code: smtp; 550 5.1.1 User unknown
Attempts have ended for the named recipient, and the remote server reported a nonexistent mailbox. Correlate that with your queue record and validate the address. Action: failed alone would not establish an invalid address: a size or policy rejection can also end delivery. DSN fields can be forged, so an unverified report must not silently change your mailing list.
3. Find the system that owns the failed step
An AUTH failure between an application and its submission service is different from a remote MX rejecting a message after submission. The first requires the application’s endpoint, TLS mode and account authorization; the second requires the sending MTA’s outbound delivery record. Do not try your mailbox credentials against an arbitrary recipient MX.
| Stage identified by evidence | Investigation owner | Targeted check |
|---|---|---|
| Application connection or AUTH failure | Application/account administrator and submission provider | Correct endpoint, TLS mode, active account, credentials and permissions. |
| Local MTA reports DNS, storage or filter failure | That MTA’s operator | Effective resolver, storage, filtering service and queue state. |
| Remote MX rejects a recipient or policy condition | Sender operator, with recipient administrator where needed | Full remote reply, recipient record and the actual message identity. |
| SMTP accepted, recipient reports no message | Recipient/mail service and incident owner | Subsequent delivery, quarantine, folders, rules and forwarding. |
After AUTH, 535 5.7.8 indicates invalid or insufficient credentials; check the account and supported authentication method. After AUTH, 454 4.7.0 indicates a temporary server failure, not a reason by itself to change the password. A 454 after STARTTLS has a different TLS context. For “relaying denied,” verify the submission service and relay authorization; the reply alone does not demonstrate an open relay.
The cPanel mail-client setup guide can help compare supported connection settings. Panel delivery reports, queue visibility and SSH rights depend on the service. Ask the provider for missing evidence. Even with your own MTA, PTR and outbound-port permissions may remain under provider control.
Verify the effective logging destination: a Postfix deployment may use /var/log/mail.log, /var/log/maillog or the journal; Exim mainlog/rejectlog paths depend on the installation. Default logs may not contain a full SMTP transcript. Look for queue ID, recipient, time, relay and diagnostic, and avoid enabling broad credential-bearing logging just to fill a gap.
For 530, match the complete reply to the command: the operation may require authentication, or the server may require STARTTLS first. The reference explains the AUTH and STARTTLS contexts of a 530 reply. Verify the correct trusted submission service and TLS mode; establish and validate required TLS before sending credentials.
4. Follow the correction branch supported by evidence
Recipient address or routing
For a verified 550 5.1.1 User unknown, confirm the complete recipient address through an authoritative source. On your own domain, inspect the mailbox, alias, forwarding and local-versus-remote mail-routing setting. Stop automatic sends to a confirmed invalid address until corrected and revalidated; do not treat one address failure as evidence that an entire domain or customer list is invalid.
For destination-domain or connection problems, examine MX records, the selected MX hosts’ A/AAAA records and DNS results seen by the sending system. An apex A/AAAA record is unnecessary when usable MX records exist. Missing MX can invoke the implicit-MX rule; MX 0 . explicitly advertises no mail service. NXDOMAIN, a temporary DNS error and an unreachable MX require different handling.
MX describes inbound routing, not authorization to send from some other server. If a registrar transfer coincided with a nameserver or zone change, investigate the actual change rather than treating the transfer as the cause. Distinguish a destination syntax diagnostic such as 553 5.1.3 from 5.1.2, which concerns the destination system/domain.
Mailbox quota, system storage or message size
“Mailbox full” and “mailbox disabled” are different: X.2.2 describes fullness and X.2.1 a disabled mailbox. System storage is another layer. The standard description of 452 is insufficient system storage, but this code also applies when an implementation’s recipient-count limit is reached during RCPT TO. If local storage exhaustion is confirmed, inspect disk and inode use, log or backup growth and filter queues. Freeing space on your own VPS does not repair a remote server’s full disk.
For a mailbox you administer, adjust capacity or quota with the appropriate retention and verified archive/backup process. For a remote mailbox, contact its administrator through a suitable alternate channel. Do not classify every quota rejection as a permanently invalid address. The email archiving and retention guide explains why indiscriminately deleting old mail is not a general quota remedy.
552 5.3.4 identifies a per-message size limit. Measure the complete encoded message, including headers and MIME overhead, rather than the attachment’s size on disk. Reduce unnecessary signature or embedded-image content, shrink attachments, or use a file-sharing link with recipient authorization and suitable expiry. Do not publish a sensitive document openly to bypass a mail limit.
If the limit belongs to your MTA, evaluate a change against actual capacity; increasing it will not increase a receiver’s limit. Recipient-count limits are separate: preserve accepted recipients and let the product split remaining attempts appropriately. A legacy 552 “too many recipients” reply should be treated as temporary in that specific compatibility context; do not confuse it with 552 5.3.4 size rejection.
Sender identity, policy or reputation
For 550 5.7.1 or a 554 with a policy diagnostic, use the full text and receiver documentation to identify the failed check. 554 alone does not prove spam or an IP blocklist. Likewise, 5.7.26 reports multiple failed message-authentication checks without specifying which mechanisms. The presence of a DNS record does not prove the actual message passed that check.
These are independent illustrative replies, not one SMTP conversation. Their diagnostic text distinguishes a host block, a spam rejection and a temporary volume limit:
550 5.7.1 Service unavailable; Client host blocked 554 5.7.1 Message rejected as spam 421 4.7.0 Too many messages from this IP, try again later
- SPF: establish the actual connecting outbound IP and MAIL FROM identity, or HELO where applicable. The visible From is not the SPF identity. Check one selectable SPF policy for the evaluated identity and the limit of 10 DNS-causing terms, including nested evaluations.
- DKIM: examine the actual verification result, signing domain and selector. A signature header is not a pass, and DKIM does not establish that content is safe.
- DMARC: at least one successful SPF or DKIM identity must align with the visible From domain. Failure of one mechanism does not automatically fail DMARC. Correct the legitimate source and alignment before weakening policy because of a generic 5.7.1.
- PTR/HELO: check the actual connection IP’s reverse and forward DNS, outgoing HELO and receiver requirements. With a relay provider, the IP may differ from your application server’s IP.
Use the cPanel and VPS authentication guide for implementation context and the SPF, DKIM, DMARC and rDNS guide for the identity relationships. Make DNS changes in the authoritative zone; editing an unrelated panel’s copy will not change the receiver’s lookup.
Forwarding can change SPF or DKIM results. SRS rewriting of the envelope sender does not by itself restore DMARC alignment with the visible From. Compare direct and forwarded paths separately. Aggregate reports can help identify legitimate sources and alignment failures, but reports are not guaranteed from every provider, and detailed failure reports may expose personal information.
If a diagnostic identifies a blocklist or provider policy, verify the actually used IP/domain through that specific channel. If a compromised account, form or application is confirmed, contain unauthorized sending and correct access and the underlying defect first. Then follow the relevant removal procedure; removal from one list does not guarantee acceptance elsewhere. The sender reputation recovery guide (in Turkish) covers that separate recovery process.
For an identified content-filter issue, inspect malformed MIME/HTML, unsafe links, malicious attachments or the specific policy violation. A fixed list of “spam words,” switching to plain text or changing IPs cannot guarantee acceptance. On shared outbound infrastructure, other accounts may warrant investigation, but do not assume a neighbor is compromised without evidence. A dedicated IP or new domain is not a way to bypass the receiver’s rejection.
TLS, network or temporary server failure
421 means the service is unavailable and the transmission channel is closing; it is not synonymous with rate limiting. Full 450/451 diagnostics may identify mailbox, policy or processing conditions. Compare affected destinations over the same interval: widespread failures justify checking a common outbound path, resolver, network or local filter, while one destination requires investigation of that particular path and response.
For TLS, identify the failing hop and direction. Replacing your inbound certificate will not repair a remote MX’s certificate or STARTTLS service. For MTA-STS/DANE, inspect the sender’s effective policy and the target validation evidence; for REQUIRETLS, inspect the required forwarding support. Do not disable mandatory TLS to get the message through.
When the reply explicitly identifies rate limits, examine total destination volume, parallel connections and recent campaign bursts. Greylisting is different from volume throttling, and neither promises acceptance after a fixed number of attempts. In Postfix, inspect default_destination_rate_delay, default_destination_concurrency_limit and transport overrides together; the recipient-limit setting can change whether a destination means a domain or an individual recipient.
The outbound mail security and rate-limit guide helps with ongoing control of authorized traffic. A provider’s limit should be interpreted across the relevant traffic, not evaded by spreading the same unwanted or blocked sends across extra IPs.
5. Give one system ownership of retries
An application retry loop and an MTA queue acting independently can produce duplicate email. Record which system is retrying, its queue lifetime and its destination-specific delay. If a provider owns the queue, use its documented behavior instead of borrowing another MTA’s defaults.
RFC 5321 generally describes at least 30 minutes between retries and at least 4–5 days before giving up, with reason-aware variable strategies and shorter limits possible for some notifications. These are not every product’s defaults. A password-reset token’s useful lifetime is a separate application requirement; do not equate it with the SMTP queue lifetime.
- Verify the current result and queue owner for each recipient.
- Correct the evidenced cause, recording the change, affected system and time.
- If the message remains queued, follow the existing MTA attempt; do not broadly force the queue and overload the destination.
- If attempts have ended, check that the content is still needed and valid before a new submission. Exclude already successful recipients.
- If the final DATA reply was lost, record uncertain acceptance. Use provider/application duplicate-prevention features where supported; do not assume that reusing Message-ID guarantees deduplication.
Build volume for a legitimate new sending identity from recipient demand and measured responses. The dedicated-IP warm-up guide applies to a justified architecture, not evasion of an existing rate or policy rejection. No fixed warm-up calendar guarantees acceptance.
Choose a Verified Alternative for a Critical Notification
If an invoice or password-reset notification cannot arrive within its useful lifetime, the incident owner should assess an already authorized and verified alternative channel or an authenticated customer portal the user can access. A general status notification, such as an SMS, need not carry invoice contents or a reset token; keep sensitive material behind the authorized access route. Follow the applicable identity-verification process for account recovery, and do not redirect sensitive contents to an arbitrary new email address.
Link the fallback decision to the same application event. Track the original message’s queue, later delivery and the validity of any link or token; coordinate resend or cancellation with the existing queue owner. A late original message should not trigger duplicate order actions, repeated notifications or conflicting account-recovery steps.
6. Verify the correction on a controlled sending path
Use an authorized test recipient and non-sensitive content through the same sending path. Changing the source IP, relay, From/MAIL FROM or DKIM selector changes what the comparison proves. Correlate the application submission, queue record and remote response; a green status in one panel is insufficient.
- At which stage and with which diagnostic did the original failure occur, and what happened at that stage now?
- Were accepted and deferred recipients recorded separately?
- Did the message reach the intended recipient location, or was there a later notification or quarantine?
- Did queue age and size recover, or did a successful small test hide an ongoing volume problem?
- Did the application event produce an unwanted duplicate notification?
Choose a closure criterion from the business impact: for example, a verified controlled delivery on the affected application path followed by observation of normal traffic without the same failure. Record the interval and recipient scope. One successful test is not a promise of future delivery to every provider.
Hypothetical incident: two WooCommerce notification failures
Suppose a store’s order notifications produce both 550 5.1.1 and, at one destination domain, 421 4.7.0 Temporary rate limit exceeded. These are not proof of a single cause. First correlate order/application records with recipients and queue identifiers, then separate the affected groups.
If an authoritative check confirms an invalid address in the first group, automatic sends stop and the address needs correction. If messages in the second group remain in the provider’s queue, observe its retries and total destination volume instead of creating new order notifications. If the logs do not support those assumptions, change the diagnostic branch; do not declare a successful outcome in advance.
After a correction, test only necessary, authorized recipients and verify both acceptance and recipient outcome. If the evidence instead identifies authentication or TLS failure, rate tuning alone is insufficient. Close the incident with the actual change and measured result, rather than an unsupported story that moving to a “clean IP” solved every code.
7. Reduce recurrence with measured operational controls
Use address verification and double opt-in where applicable. Suppress confirmed invalid recipients before further sends, and keep delivery suppression distinct from a user’s unsubscribe request. Missing open tracking alone does not prove an invalid address or absence of consent; manage permission and preferences from their own records.
Protect credentials and applications, monitor compromised-site or account sending, and use suitable per-account limits to contain unexpected bursts. A limit alone is not an alert or malware diagnosis. Keep secrets protected and record DNS and signing changes. The deliverability checklist supports the broader review when SMTP acceptance and inbox placement diverge.
Separate transactional and marketing queues, priorities and sending sources when justified by actual requirements. Subdomain or IP separation does not guarantee complete reputation isolation. Critical messages also need application-level duplicate prevention, useful lifetime and a clear user-facing state.
Do not monitor only raw error totals. Use recipient attempts within a stated time interval as a denominator, then group by diagnostic, destination and source; repeated attempts can inflate counts. Queue age, final failure, acceptance and complaints are different measures. Track the oldest waiting messages and sudden changes as well as averages.
Compare shared mail, a VPS or a dedicated server against a demonstrated capacity or control need. Confirm MTA operations, port/PTR rights, security, backups and support ownership. A larger server cannot by itself repair an invalid address, unwanted traffic or a remote receiver’s policy.
Finish the support record with event time, impact, replying server and command, full diagnostic, queue state, controlled changes and verified outcome. The next operator should be able to continue from evidence rather than reconstructing the incident from a code alone.
Official Sources
Standard meanings were compared with these documents and registries on 4 November 2026. Verify product- or receiver-specific behavior against its version and complete diagnostic separately.
