> For the complete documentation index, see [llms.txt](https://kasplo.gitbook.io/kasplo-doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kasplo.gitbook.io/kasplo-doc/product-docs/overview/transactional/email-delivery-attempt-statuses.md). # Email Delivery Attempt Statuses ### Overview A delivery attempt represents each instance where Kasplo attempts to deliver an email to a recipient's mail server. Understanding delivery attempt statuses helps you monitor email performance, identify deliverability issues, and maintain sender reputation. This guide explains each status, its impact on your campaigns, and recommended actions to resolve or prevent issues. ### Delivery Attempt Statuses #### Submitted **What it means**\ The email has been accepted by Kasplo and queued for delivery processing. **Impact** * Email is in transit but has not yet reached the recipient server * This is a normal initial state for all outgoing messages * No deliverability issues indicated **Action required**\ None. The status will automatically update once delivery is attempted. #### Sent / Success **What it means**\ The email was successfully delivered to and accepted by the recipient's mail server. **Impact** * Message delivery is complete * The receiving server has confirmed acceptance * No further delivery attempts will be made **Action required**\ None. This indicates successful delivery. #### Deferral **What it means** * Monitor deferral rates by domain * If deferrals are frequent for specific domains, reduce sending rate * Verify sender authentication (SPF, DKIM, DMARC) is properly configured * Maintain consistent sending patterns to build reputation * Avoid sending to stale or low-quality email lists **How to resolve** * Temporary issue, not a permanent failure * Kasplo will automatically retry delivery according to retry policies * Common causes include recipient server load, greylisting, or temporary throttling * May result in delayed delivery times **Impact** What it means\ The recipient's mail server temporarily delayed or refused to accept the email. #### Conn Max Out (Connection Maximum) **What it means**\ The email was not sent because Kasplo reached the maximum connection or rate limit for the recipient domain. **Impact** * Protects sender reputation by preventing domain-level throttling * Email is queued for retry, not permanently rejected * May indicate sending volume exceeds recipient server capacity * Can cause delivery delays during high-volume campaigns **How to resolve** * Reduce concurrent connections to the affected domain * Lower the sending rate for high-volume domains (Gmail, Outlook, Yahoo) * Implement domain-based throttling policies * Distribute sends over a longer time period * Warm up new IP addresses gradually * Separate high-volume domains into dedicated sending pools #### Failed / Failure **What it means**\ The email could not be delivered due to a permanent error. Kasplo will not retry delivery. **Impact** * Message delivery has permanently failed * Common causes include invalid email addresses, non-existent domains, or recipient server rejection * Impacts sender reputation if failure rate is high * May indicate list quality issues **How to resolve** * Review bounce reason codes to identify specific failure causes * Validate email addresses before upload using email verification tools * Remove hard bounces and invalid addresses from your list immediately * Verify DNS configuration (MX, A records) for your sending domain * Check email formatting and header structure for compliance * Monitor authentication failures (SPF, DKIM alignment) #### Failure Too Long **What it means**\ The email was deferred repeatedly over an extended period and has exceeded the maximum retry limit. The message is now marked as failed. **Impact** * Message delivery has been abandoned after multiple retry attempts * Indicates persistent issues with the recipient domain or address * Kasplo has stopped attempting delivery * Suggests deeper deliverability or domain reputation issues **How to resolve** * Identify domains with recurring "Failure Too Long" statuses * Apply stricter rate limiting for problematic domains * Suppress or remove addresses that consistently defer * Investigate recipient domain policies and requirements * Consider removing recipients from this domain if the pattern continues * Review whether the recipient domain may have blocklisted your sending IPs #### Blank Status **What it means**\ No delivery attempt has been recorded yet. **Impact** * Email may still be queued for processing * Campaign may be paused or scheduled for future send * System may still be processing the message **Action required**\ Wait for the status to update. If the status remains blank for an extended period, verify that: * The campaign is active and not paused * Sending quotas have not been exhausted * No system-wide issues are affecting delivery #### Status Summary Reference | Status | Type | Retry Behavior | | ---------------- | ----------- | --------------- | | Submitted | In Progress | N/A - queued | | Sent / Success | Final | No retry needed | | Deferral | Temporary | Automatic retry | | Conn Max Out | Temporary | Automatic retry | | Failed / Failure | Permanent | No retry | | Failure Too Long | Permanent | No retry | | Blank | Pending | N/A | ### Best Practices to Reduce Delivery Issues #### Reducing Connection Maximum (Conn Max Out) * Configure domain-specific sending rate limits * Limit concurrent connections per destination domain * Implement gradual IP warm-up for new sending infrastructure * Avoid sending large volumes to a single domain in short bursts * Separate major providers (Gmail, Outlook, Yahoo) into dedicated sending pools #### Reducing Deferrals * Implement and verify sender authentication (SPF, DKIM, DMARC) * Maintain consistent sending patterns and volumes * Use engaged, opted-in recipient lists * Monitor and maintain list hygiene * Ensure DNS and TLS configurations are properly set up * Avoid sudden spikes in sending volume #### Reducing Permanent Failures * Validate email addresses before importing lists * Implement real-time or batch email verification * Remove hard bounces immediately after detection * Verify sending domain DNS records (MX, SPF, DMARC) * Ensure email formatting follows RFC standards * Monitor and fix authentication failures #### Reducing Failure Too Long * Monitor domains with high deferral rates * Apply aggressive rate limiting to problematic domains * Implement suppression lists for repeatedly deferring addresses * Set appropriate retry limits based on recipient behavior * Consider removing recipients from domains with persistent issues ### Monitoring Recommendations To maintain optimal deliverability, regularly monitor: * Domain-specific deferral rates and patterns * Connection maximum trends by domain and time period * Failure reasons and bounce classifications * Retry attempt distributions * Overall list quality metrics * Sender reputation scores ### Need Help? > If you continue to experience delivery issues after implementing these recommendations, contact the Kasplo Support Team with: > > * Specific affected domains or email addresses > * Time frame of the issues > * Current sending configuration details > * Any error messages or bounce codes received