Category: Monitoring and logs

  • Common Transactional Issues

    This guide helps you diagnose and resolve the most frequent delivery failures, API errors, and authentication problems with transactional emails in Sender.

    Symptoms

    Transactional emails are not arriving in your recipients' inboxes.

    The Logs page under Transactional emails → Logs shows no Emails sent events for recent sends, or events appear with Bounces status.

    Your API requests to https://api.sender.net/v2/message/send return a non-2xx response code such as 401, 422, or 429.

    SMTP connections to smtp.sender.net fail with authentication or timeout errors.

    Possible Causes

    Invalid or missing API token — Your request does not include a valid Authorization: Bearer header, or the token has been deleted from Account settings → API access tokens. This results in a 401 Unauthorized response.

    Malformed API request or missing required fields — The request body is missing required fields such as from, to, or subject, or contains invalid values. The API returns a 422 response with details about which fields failed validation.

    Domain authentication failure — Your sending domain does not have valid SPF, DKIM, or DMARC records. Receiving mail servers may reject or quarantine emails sent from unauthenticated domains.

    SMTP connection or credential errors — The SMTP username, password, server address, or port is incorrect, causing connection refused or authentication failure errors when sending through smtp.sender.net.

    Rate limiting — You are exceeding the allowed number of API requests per minute. The API returns a 429 Too Many Requests response with a Retry-After header indicating when you can send again.

    Steps to Resolve

    Step 1 — Verify Your API Token or SMTP Credentials

    If you are sending via the API, go to Account settings → API access tokens and confirm that the token used in your Authorization: Bearer {token} header exists and has not been revoked. If no tokens are listed, create a new one by clicking Create API token.

    If you are sending via SMTP, go to Transactional emails → Setup instructions → SMTP and confirm your credentials match an active SMTP user. Verify that your application connects to smtp.sender.net on port 25, 2525, or 587 using PLAIN or LOGIN authentication over TLS.

    Step 2 — Check the API Request for Missing or Invalid Fields

    If the API returns a 422 error, inspect the response body for the errors object, which lists each invalid field. Ensure your request includes all required fields: from (with email and name), to (with email), and subject.

    If you are sending with a template, the endpoint is https://api.sender.net/v2/message/{id}/send and requires a valid campaign id and a to object.

    If the API returns 400 Bad Request, review the message field in the response for a description of the problem.

    Step 3 — Verify Domain Authentication Records

    Go to Account settings → Domains. Locate your sending domain and check the Authentication column for three green checkmarks representing SPF, DKIM, and DMARC. If any checkmark is missing or shows a warning, your DNS records are incomplete or misconfigured.

    Click Recheck DNS records after updating your DNS settings. All three records must pass validation for reliable inbox delivery.

    Step 4 — Check for Bounces and Rate Limits in Logs

    Go to Transactional emails → Logs. Use the Event type filter and select Bounces to isolate failed deliveries. Review the Recipient and Subject columns to identify which emails bounced.

    If your API responses include a 429 status code, check the X-RateLimit-Remaining and Retry-After headers to determine how long to wait before retrying. Implement exponential backoff or throttle your send rate to stay within the limit shown in X-RateLimit-Limit.

    Step 5 — Review Metrics for Delivery Trends

    Go to Transactional emails → Metrics. Check the Hard bounces, Soft bounces, and Spam reports counters at the bottom of the page. A rising Hard bounces count indicates invalid recipient addresses in your sends. A rising Spam reports count may signal sender reputation problems that could lead to broader deliverability issues.

    Use the Domain filter to isolate metrics for a specific sending domain if you use more than one.

    How to Verify the Fix

    After applying your fix, send a test transactional email using either the API or SMTP. Go to Transactional emails → Logs and filter by Event type → Emails sent to confirm the test email appears with the correct Recipient, Subject, and Date / time.

    A successful API response returns {"success": true, "message": "Email sent"} along with an emailId. If the email also appears under Event type → Opens after you open it in the recipient inbox, delivery and tracking are working correctly.

    Related Issues

    Emails delivered to spam instead of inbox → This typically results from incomplete domain authentication or poor sender reputation. Check your SPF, DKIM, and DMARC status under Account settings → Domains and review the Spam reports metric under Transactional emails → Metrics.

    Template variables not populating in received emails → If recipients see raw variable placeholders instead of personalized values, verify that the variables object in your API request includes matching key-value pairs for every placeholder used in the template.

    Emails showing as sent in Logs but not received → The email may have been accepted by the recipient's mail server but filtered or delayed. Check with the recipient to review their spam or junk folder, and verify that the sending domain is not listed on any public blocklists.

    FAQs

    I fixed the issue but old emails still show as bounced in Logs. Will they be retried?

    No. Previously bounced emails are not retried automatically. You will need to resend them through a new API request or SMTP send after resolving the underlying issue.

    How do I know if the problem is on my side or on Sender's servers?

    Check the HTTP response code from the API. Codes in the 4xx range indicate a problem with your request, such as invalid authentication or missing fields. Codes in the 5xx range indicate a server-side issue on Sender's end. If you consistently receive 5xx errors, contact Sender support.

    Can I test my API integration without sending a real email?

    There is no sandbox mode for the transactional email API. To test, send a real request to https://api.sender.net/v2/message/send using a recipient address you control. Check Transactional emails → Logs to confirm the email was sent and delivered successfully.

    My SMTP connection keeps timing out. What should I try?

    Verify that your firewall or hosting provider is not blocking outbound connections on port 25, 2525, or 587. Try each port to determine which one your network allows. Confirm the server address is set to smtp.sender.net and that TLS is enabled in your SMTP client configuration.

  • How to Set Up Webhooks for Transactional Email Events

    Webhooks let you receive real-time HTTP POST notifications at your own endpoint whenever specific events occur in your Sender account. You can use webhooks to track bounces, monitor new subscriber activity, and integrate delivery data with your own systems — without polling the API.

    This article walks you through adding a webhook, selecting a topic, securing your endpoint with the signing secret, and monitoring webhook performance.

    Before You Begin

    Confirm the following before setting up a webhook:

    • You have an active endpoint URL that accepts HTTP POST requests (e.g., https://yourdomain.com/webhooks).
    • Your endpoint returns a 2xx status code on successful receipt. Non-2xx responses are logged as failures.
    • You have access to Account settings in your Sender dashboard.

    Step 1: Open the Webhooks Page

    Go to Account settings → Webhooks in the left sidebar. This opens the Webhooks page, which displays a table of all configured webhooks with four columns: Topic, Total deliveries, Total failures, and Response time. If no webhooks exist yet, the table will be empty.

    Step 2: Add a New Webhook

    Click the Add webhook button in the top-right corner. A modal dialog appears with two fields:

    URL — Enter the full endpoint URL where Sender should send POST requests (e.g., https://yourdomain.com/webhooks).

    Topic — Open the Select topic dropdown and choose the event you want to subscribe to.

    The available topics are:

    Topic

    Description

    subscribers/new

    A new subscriber is added to your account

    subscribers/updated

    An existing subscriber's data is modified

    subscribers/unsubscribed

    A subscriber opts out

    groups/new

    A new group is created

    groups/new-subscriber

    A subscriber is added to a group

    groups/unsubscribed

    A subscriber is removed from a group

    campaigns/new

    A new campaign is created

    bounces/new

    A bounce event is recorded

    For transactional email monitoring, the bounces/new topic is particularly useful — it notifies your endpoint whenever a sent email bounces, letting you flag delivery issues in real time.

    After filling in both fields, click Add to save the webhook.

    Step 3: Verify Webhook Delivery

    Once the webhook is created, it appears as a row in the table on the Webhooks page. Monitor the Total deliveries and Total failures columns to confirm your endpoint is receiving and acknowledging payloads correctly. The Response time column shows how quickly your server responded to the most recent delivery.

    If Total failures is incrementing, your endpoint may be returning a non-2xx status code or is unreachable. See Step 5 below to investigate.

    Step 4: Secure Your Webhook With the Signing Secret

    Below the webhook table, the Signing secret section displays a masked secret value. Use this secret to verify that incoming POST requests genuinely originate from Sender.

    Click the eye icon next to the secret field to reveal the full value. Click the copy icon to copy the secret to your clipboard. Use this secret on your server to validate the signature included in each webhook request header.

    If you suspect the secret has been compromised, click Rotate secret to generate a new one. After rotating, update the secret in your application immediately — requests signed with the old secret will no longer validate.

    Step 5: View Error Logs for a Webhook

    To diagnose failed deliveries, click the dropdown arrow (chevron) to the right of the Pause button on the webhook row, then select View error logs. This opens the Webhook logs page, which displays a table with two columns:

    Date / time — The timestamp of the failed delivery attempt.

    Error code — The HTTP status code returned by your endpoint (e.g., 405, 500).

    Click the expand arrow on any log entry to reveal the full response body returned by your server. This is helpful for identifying misconfigured endpoints, incorrect HTTP methods, or server-side errors.

    Managing Existing Webhooks

    Pause a Webhook — Click the Pause button on any webhook row to temporarily stop deliveries without deleting the configuration. This is useful when performing maintenance on your endpoint.

    Edit a Webhook — Click the dropdown arrow next to the Pause button and select Edit. The Edit webhook modal lets you update the URL or change the Topic. Click Add to save your changes.

    Delete a Webhook — From the same dropdown menu, select Delete to permanently remove the webhook. This action cannot be undone.

    Tips for Reliable Webhook Integration

    Respond quickly — Your endpoint should return a 2xx status code within a few seconds. Long-running processing should be handled asynchronously after acknowledging receipt.

    Use the signing secret — Always validate the request signature on your server to ensure payloads are authentic.

    Monitor the Webhooks table — Check Total failures and Response time regularly to catch delivery issues early.

    Combine with Logs — Cross-reference webhook data with the Logs page under Transactional emails → Logs to match bounce notifications with specific recipient email addresses and event details.

    Combine with Metrics — Use the Metrics page under Transactional emails → Metrics and filter by Event type (Bounces, Spam reports) to see aggregate trends alongside your webhook-driven alerts.

  • Monitoring Transactional Delivery

    This guide explains how to track delivery performance, review individual email events, and diagnose issues for your transactional emails in Sender.

    Where to Find This Feature

    In the Sender dashboard, go to: Transactional emails → Metrics.

    This opens the Transactional overview page. At the top, you will see summary cards for Total emails sent, Total delivered, Total opens, Total clicks, Unsubscribes, Hard bounces, Soft bounces, and Spam reports. Below the summary cards is a time-series chart that visualizes sending activity over your selected date range.

    Three filter dropdowns — Event type, Domain, and Campaign — sit above the chart, along with a date range picker and frequency toggles for Hourly, Daily, Weekly, and Monthly views.

    To view individual email events, click Logs in the left sidebar. This opens the Latest events log page, which displays a searchable, filterable table with columns for Event, Recipient, Subject, Template, and Date / time.

    Steps to Monitor Transactional Delivery

    Step 1 — Review Delivery Metrics on the Overview Page

    Go to Transactional emails → Metrics. The summary cards at the top show aggregate counts for the selected period. Check Total emails sent against Total delivered to confirm emails are reaching recipients. Review Hard bounces, Soft bounces, and Spam reports for signs of delivery problems.

    Use the date range picker in the upper-right corner to adjust the reporting period. Choose a preset such as Last 7 days or Last 30 days, or enter a Custom range and click Apply. Switch between Hourly, Daily, Weekly, or Monthly to change the chart granularity.

    Step 2 — Filter Metrics by Event Type, Domain, or Campaign

    Click the Event type dropdown to select or deselect specific events: Emails sent, Opens, Clicks, Bounces, Unsubscribes, or Spam reports. The chart and summary cards update to reflect your selection.

    Click the Domain dropdown and use the Find by domain search field to isolate metrics for a specific recipient domain. Click the Campaign dropdown and use Find by campaign to narrow results to a particular transactional email template.

    Combining these filters helps you pinpoint delivery patterns for specific audiences or message types.

    Step 3 — Investigate Individual Events in the Logs

    Go to Transactional emails → Logs to open the Latest events log. Each row shows the Event type, the Recipient email address, the Subject line, the Template used, and the Date / time the event occurred.

    Use the Search bar to find a specific recipient or subject. Use the Event type, Domain, and Campaign dropdowns to narrow results. To reset all active filters, click Clear filters. Adjust the date range picker to expand or limit the time window. Use the View dropdown at the bottom to change how many rows display per page.

    You can also jump directly from the Metrics page to a filtered log view by clicking the arrow (→) next to any metric card such as Total opens → or Hard bounces →.

    Step 4 — Set Up Webhooks for Real-Time Delivery Notifications

    Go to Account settings → Webhooks and click Add your first webhook (or Add webhook if you already have existing webhooks).

    In the Add webhook dialog, enter your endpoint in the URL field and select a Topic from the dropdown. The bounces/new topic sends a notification to your endpoint whenever a bounce event occurs, allowing your system to react to delivery failures in real time.

    Each webhook is secured with a Signing secret displayed at the bottom of the Webhooks page. Use this secret to verify that incoming webhook payloads originate from Sender.

    Understanding the Data

    Total emails sent — The total number of transactional emails dispatched from your account during the selected period. This count includes all send attempts regardless of outcome.

    Total delivered — The number of emails accepted by the recipient's mail server. A gap between sent and delivered counts indicates bounces or rejections.

    Total opens — The number of times recipients opened your transactional emails. This is tracked via a pixel embedded in the email and may not capture every open (for example, if images are blocked).

    Total clicks — The number of times recipients clicked a tracked link within your transactional emails.

    Hard bounces — Permanent delivery failures, typically caused by an invalid or non-existent email address. Hard-bounced addresses should be removed from future sends.

    Soft bounces — Temporary delivery failures caused by conditions such as a full inbox, a temporarily unavailable server, or message size limits. Sender will typically retry soft-bounced emails.

    Unsubscribes — The number of recipients who opted out of receiving emails via the unsubscribe mechanism included in your messages.

    Spam reports — The number of recipients who marked your email as spam. A rising count here can damage your sender reputation and affect deliverability to other recipients on the same domain.

    Common Issues

    Sent count is higher than delivered count → Some emails bounced or were rejected by the recipient's server. Go to Logs, filter by Event type → Bounces, and review the affected recipients and domains. Check whether the addresses are valid and whether a specific domain is rejecting your messages.

    Open rate appears unusually low → Many email clients block tracking pixels by default, which prevents opens from being recorded. This does not necessarily mean recipients are not reading your emails. Focus on Total clicks as a more reliable engagement signal.

    High number of spam reports → Recipients are marking your transactional emails as spam. Verify that you are only sending expected, transaction-triggered messages to the correct recipients. Review your email content and sending frequency. A high spam rate can harm your domain reputation.

    Bounces concentrated on a single domain → Use the Domain filter on the Metrics or Logs page to isolate the affected domain. Persistent bounces from one provider may indicate a block or configuration issue. Check your sending domain authentication (SPF, DKIM, DMARC) and consider contacting the recipient mail provider if the issue persists.

    Logs show no data for the selected period → Verify that your date range includes the time frame when emails were sent. Click the date range picker and expand the range, or select Last 30 days. If the log is still empty, confirm that your API or SMTP integration is actively sending emails.

    FAQs

    How often are metrics updated on the overview page? Metrics update in near real-time. Refresh the page to see the latest delivery stats. You can switch between Hourly, Daily, Weekly, and Monthly views to change the level of detail shown in the chart.

    Can I view logs for a specific transactional template? Yes. On the Logs page, click the Campaign dropdown and select the template you want to inspect. The table will filter to show only events associated with that template.

    What is the difference between hard bounces and soft bounces? A hard bounce is a permanent failure — the email address does not exist or the domain is invalid. A soft bounce is a temporary failure — the mailbox may be full, or the server is temporarily unavailable. Sender retries soft bounces automatically.

    Can I get notified about delivery events outside the dashboard? Yes. Go to Account settings → Webhooks and add a webhook with the bounces/new topic to receive real-time bounce notifications at your own endpoint. This lets your system respond to delivery failures programmatically.

    How do I jump from a metric to its related log entries? On the Metrics page, click the arrow (→) next to any metric card such as Total opens → or Hard bounces →. This takes you directly to the Logs page pre-filtered to that event type and date range.