FAQs

Q1. What causes an email to soft bounce or hard bounce?

A soft bounce means the email address is valid, but delivery fails due to temporary issues, such as a full inbox or an inaccessible mail server.

A hard bounce occurs when there is a permanent issue, like a blocked or invalid email address, a non-existent recipient, server problems, an over-quota mailbox, or DNS configuration issues.

Q2. Why do emails end up in the spam folder?

Emails can be marked as spam by popular inbox providers like Gmail, Yahoo! Mail, Outlook, and Apple Mail due to various reasons, including sending bulk emails too frequently, incorrect DKIM and SPF settings, or failing to warm up the domain IP before sending emails.

Q3. Why might an email notification fail to be delivered?

There are several reasons your email notifications may not be delivered:

• Frequency Caps: If the frequency cap limit is reached, the email may not be sent. These caps are set based on daily, weekly, monthly, or lifetime parameters. Users exceeding the frequency cap won't receive the email. To learn more about frequency caps, click here.
• Personalization Failure: This happens when the system can't replace personalized parameters with the correct user data. For example, if a user in a segment doesn’t have a registered "premium amount" and the email contains a macro for this value, the email won’t be sent to that user.
• Hard Bounce: If the email results in a hard bounce, the email address is either invalid or the recipient has blocked the sender. This will mark the address as unreachable for future communications.
• Dropped: Emails may be dropped by the ESP if the user unsubscribes or is on a blacklist.
• Soft Bounce: Soft bounces are temporary delivery failures, often due to issues like a full inbox. These are tracked separately by ESPs in web-hooks.
• Insufficient Credits: If the ESP's credit limit is reached or there are not enough credits available, the email won’t be delivered.
• Vendor Failure: This category covers all other reasons for email delivery failure that are reported by the vendor, beyond those previously mentioned. Backend systems will store raw logs of the responses received for further analysis if requested by the client. In the future, specific vendor failure reasons will be displayed in the UI. Logs will be retained for two years.
• Non-2xx Response: This failure occurs when the vendor logs an error not included in the standard failure categories. Any response that is not a 2xx status code will be captured here.
• Pending Status from Vendor: This failure applies when the communication was sent to the vendor, but the vendor did not send a corresponding web-hook response for the specific message ID.
• Others: This includes all other reasons for non-delivery, such as system failures, server crashes, or campaign issues.