Deliverability Monitoring

Joryio includes a built-in deliverability monitoring dashboard that helps you track delivery health per channel, DNS authentication status, blocklist exposure, and set up automated alerts for delivery issues.

Dashboard Overview

Navigate to Analytics > Deliverability to access the monitoring dashboard. A left rail picks the channel you are reporting on: Email, WhatsApp, SMS, Push, Viber. Each channel shows only the metrics it genuinely emits - a number a channel cannot produce is left out rather than drawn as a confident 0%.

KPI Cards

The cards come from the channel's own metric set, so their number and identity change with the channel:

Metric	Description	Channels
Delivery Rate	Delivered / sent	All five
Bounce Rate	Bounced / sent - healthy below 5%	Email
Complaint Rate	Marked as spam / sent - healthy below 0.1%	Email
Open Rate	Unique openers / delivered - healthy above 20%	Email
Read Rate	Read receipts (the blue tick) / delivered	WhatsApp
Click Rate	Unique clickers / delivered	All five
Unsubscribe Rate	Unsubscribes / sent	Email, SMS
Failure Rate	Failed / attempted, where attempted is sent + failed	WhatsApp, SMS, Push, Viber

Failure rate is over attempted, not sent. A send the provider rejects outright never emits a sent event, so dividing failures by sent compared a number against a denominator that excluded it - push, which reports per device, could read 160%. The card names its own denominator: "N of M attempted".

Delivery, bounce, complaint and failure cards are colour-coded against their healthy threshold. Open, read, click and unsubscribe have no universal target, so they are shown neutral.

Each channel's report also states its caveat in place - Apple Mail Privacy Protection makes email opens an upper bound; WhatsApp read receipts and iOS push deliveries are lower bounds; SMS clicks are counted only for links Joryio shortened.

Opens and clicks are counted once per person per message - the same as the dashboard and campaign pages - so a reader who opens two campaigns is two opened messages beside two delivered ones, and bots and link scanners are left out. A click on an email counts as an open, because it proves the email was opened.

The date range

The range picker at the top right offers Today, Yesterday, Last 7 days, Last 30 days, This month, Last month and All time, plus a custom range. It is measured in your workspace timezone and includes the whole of the end day, so "Today" and "Yesterday" return data rather than an empty report.

Skipped before sending

Beside the delivery figures sits a count of messages skipped before sending - stopped by quiet hours, a frequency cap, a suppression list or a consent gate. It counts operational skips only: a contact held back as an A/B control or in the global holdout was never meant to receive the message, so counting them here made a healthy send look throttled.

DNS Authentication

This section, the bounce breakdown and the blocklist matrix appear on the Email report only - the other channels have no DNS to authenticate and no blocklists to sit on.

Proper DNS authentication is critical for email deliverability. The Domain Health section displays the authentication status for each of your connected sending domains.

Dedicated IPs

On platform-managed email, dedicated sending IPs are available on request for high, steady volumes. Joryio attaches them per sending domain, so a marketing subdomain and a transactional subdomain can share one set of IPs or use their own. Ask your Joryio contact; there is nothing to configure on your side.

Which domains appear here

Domain Health is read-only: it lists the sending domains attached to this workspace and shows their live authentication status. A domain appears when it is either:

• attached by Joryio support (org-wide or scoped to this workspace), or
• the domain of a configured sender for this workspace or organization.

Attaching and removing a sending domain is done by Joryio support - it's an infrastructure step (verifying SPF/DKIM for the domain); you add the DNS records they send you. On this page you can only Check Now to refresh a domain's status. If a domain you expect is missing, contact Joryio support to attach it.

Authentication Records

Record	Purpose
SPF (Sender Policy Framework)	Specifies which mail servers are authorized to send email on behalf of your domain
DKIM (DomainKeys Identified Mail)	Adds a digital signature to outgoing emails to verify they haven't been tampered with
DMARC (Domain-based Message Authentication)	Tells receiving servers what to do with emails that fail SPF or DKIM checks
Bounce MX	On managed email, the MX record on your bounce domain e.<sending domain>, pointing at Amazon SES (feedback-smtp.<region>.amazonses.com). Bounces and complaints come back through it. Shown gray as not applicable for a domain that sends through your own email provider.

MX on the sending domain itself is not part of the check: it only decides whether replies to an address on that domain reach an inbox. When the domain has none, Domain Health shows a gray note - "No inbox on <domain> - replies need a Reply-To" - which never turns the domain red or changes its status dot.

Each record shows one of three statuses:

• Pass (green): Correctly configured
• Fail (red): Configuration error detected
• Missing (gray): Record not found in DNS

Click Check Now on any domain card to trigger a fresh DNS lookup.

tip

Ensure SPF, DKIM and DMARC - and Bounce MX on managed email - show "Pass" for optimal deliverability. Missing or misconfigured DMARC records are the most common cause of emails landing in spam folders.

Sign in with Apple users

If your app or website offers Sign in with Apple, people who choose Hide My Email give you a relay address (@privaterelay.appleid.com or @private.icloud.com). Apple only forwards mail to those addresses from domains you have registered in your Apple Developer account, and only when DKIM or SPF matches the way Apple requires. See Apple Private Email Relay.

Sender identities & custom From

Once a sending domain has both SPF and DKIM passing, you can build sender identities on it yourself under Settings → Email Configuration - choose a display name and a local part (e.g. news); the domain is locked to your verified sending domains. The same locked-domain picker powers the custom From sender in campaigns and journey email steps. The platform refuses to send from a domain that is not SPF+DKIM verified for this workspace.

Reading the Dashboard

Delivery Trends Chart

The chart shows daily volumes over the selected period as stacked bars: delivered against bounced on email, and delivered against failed on every other channel. Opens (or reads) and clicks are lines you can toggle on over the top.

A healthy chart shows a dominant delivered bar with a thin band of bounces or failures on it. Days are drawn in your workspace timezone, so the bars line up with the cards above them.

Bounce Breakdown

Bounces are categorized into two types:

• Hard Bounces: Permanent delivery failures caused by invalid email addresses, non-existent domains, or blocked recipients. These addresses should be removed from your lists.
• Soft Bounces: Temporary delivery failures caused by full mailboxes, server downtime, or message size limits. These typically resolve on their own.

Important

A hard bounce rate above 2% can severely damage your sender reputation. Regularly clean your email lists and use double opt-in to minimize hard bounces.

Bounce reasons

Each bounce type lists its most common reasons, with the status code the receiving mail server reported - for example Mailbox does not exist (5.1.1) or Mailbox full (4.2.2). On managed email, Joryio reads the actual bounce message the receiving server sent back, so the reason is the server's own, not a guess. Bounces with no known reason are counted in the type but not listed.

Auto-replies are not bounces

When someone has an out-of-office or other automatic reply switched on, their mailbox answers your email. Amazon SES reports many of these answers as a soft bounce ("Transient / General"), which made delivered emails look bounced.

On managed email, Joryio receives the reply itself and recognizes an automatic reply from its standard markers. An automatic reply:

• is not counted as a bounce anywhere - not in this report, campaign statistics, journey statistics, alerts or billing;
• never counts towards a contact's soft-bounce limit and never suppresses the address;
• shows on the contact's timeline as Auto-reply (out of office), recorded as the message.auto_replied event.

Joryio keeps only what the reply means (auto-reply, bounce and its status code), never the reply's text. The returned messages themselves are deleted after three days.

A soft bounce after the email was opened

Sometimes a soft bounce arrives after the email was already delivered and opened - for example when the recipient's mail system forwards a copy and that copy fails, such as a forwarding loop reported as "5.4.14 Hop count exceeded - possible mail loop". The original reached the person, so there is nothing to fix on your side.

In a campaign's Recipients list, the person's timeline marks such a bounce with a short note when it follows a delivery, a real open or a real click of the same send, and names the mail loop when the bounce reports one. Bot-flagged opens and clicks never count as an open here. The bounce is still recorded as a soft bounce and counts towards the contact's soft-bounce limit. Because the message was delivered, it is not in the Bounced figure or the bounce rate - see the next section.

Soft bounces that are delivered later

A soft bounce means the receiving server said "not now" - the message is tried again and often arrives. Joryio counts a message as bounced only if it was never delivered:

• a hard bounce always counts as bounced;
• a soft bounce counts as bounced only while that message has no delivery. If a later attempt is delivered, the message counts as delivered, not bounced.

The same rule applies everywhere a bounce is counted: the campaign page and its Recipients list, the campaigns list, this report, the dashboard and bounce-rate alerts. On a campaign page, the line under Bounced says how many soft bounces were delivered on a retry.

Delivered, Bounced and No final status yet add up to Sent. No final status yet is the messages the receiving server has not answered for yet - neither a delivery nor a bounce. It usually resolves within hours.

By mailbox provider

Deliverability is not one number. Gmail, Outlook and Yahoo each run their own reputation system, and a problem is nearly always concentrated in one of them rather than spread evenly. A workspace-wide bounce rate averages that away, so a Gmail block reads as a mild dip until it is most of your list.

The Email report breaks the funnel down by the recipient's mailbox provider: how many you sent, how many were delivered, the bounce rate and the open rate for each.

Four things about how it is calculated, because each one changes what the number means:

• Rates appear only above a volume floor. Below it you still see the counts, but not a percentage - a bounce rate from thirty sends moves by whole points on a single bounce, and a plausible-looking figure from almost no data is worse than no figure. Those rows read "not enough data".
• Open rate is out of delivered, not sent. A bounced message was never there to open. Dividing by sent would understate every provider in proportion to how badly it bounced, which would make the worst-delivering provider look like the worst-engaging one too.
• Grouping is by the recipient's domain. A company running Google Workspace on its own domain is Gmail in every way that matters to deliverability, but its address does not say so, and it counts under Other domains. So "Other" means everything unmatched, not "small providers".
• Opens and clicks are attributed through the send. Only the send carries the recipient's address - a tracking pixel and a click redirect fire with a message reference, not an address - so each person is matched to a provider from the mail you sent them, and their engagement counted there. Anything we cannot match, such as an open from someone with no send in the range, is reported as unattributed rather than dropped, because a missing open lowers a rate instead of emptying a column and is the harder kind of gap to notice.

Opens are unique people with bots excluded, the same as everywhere else on this page, and the note under the table says how many automated opens were set aside. Campaign analytics can show bot activity; this report deliberately cannot, so the count is there to explain why the two disagree. Apple Mail Privacy Protection still inflates opens for Apple addresses more than for others, so compare Apple's open rate against itself over time rather than against Gmail's.

Filtering by sending domain

Deliverability problems belong to the sender, not the audience: authentication, reputation and blocklisting are all properties of the domain a message was sent from. So on the Email report you can narrow every number to one sending domain - useful the moment you send from more than one, because a problem on a new domain is invisible in a workspace-wide average dominated by an established one.

The picker offers only domains this workspace actually sent from in the chosen date range, with how many sends each carried, so a filter can never come back empty because of a typo.

Some sends carry no sender address at all - anything sent before we started recording it. Those belong to no domain and are therefore outside a filtered view. When that applies, the report says how many, so a filtered number is never mistaken for the whole picture.

The filter is offered on Email only. The other channels have a sender, but not a domain: an SMS has a number and a push has an app.

The alerts below are deliberately not affected by this filter. They watch the whole workspace, because an alert scoped to one domain is an alert that stays quiet while another one burns.

Blocklist Monitoring

The Blocklist status card (email only) is a matrix: one row per sending domain, one column per blocklist provider, plus a Checked column with the time of the last lookup. A cell reads clear or listed. An Only problems toggle hides the rows that are clean everywhere.

Click Check all now to run a fresh check against all configured blocklist providers.

If any of your domains are listed, you should:

1. Investigate the cause (high bounce rates, spam complaints, compromised accounts)
2. Fix the underlying issue
3. Submit a delisting request to the blocklist provider

Alerts

Deliverability alerts are now part of the unified alert engine in Settings → Logs & Monitoring, alongside your API, webhook, and event alerts - one place to create, manage, and review every alert, with one history and one notification feed.

To create a deliverability alert:

1. Go to Settings → Logs & Monitoring → Alerts → New alert.
2. In Step 1, choose the Deliverability direction and pick a metric (Bounce rate, Complaint rate, Hard/Soft bounce rate, Unsubscribe rate, or Delivery rate).
3. In Step 2, set the threshold (a percentage), the operator (Above / Below), and the lookback window (1h / 4h / 24h / 7d).
4. In Step 3, choose how you're notified (email or webhook) and the cooldown.

Recommended alerts

Set up at minimum:

• Bounce rate above 5% to catch list-quality issues early.
• Complaint rate above 0.1% to stay below ISP complaint thresholds.

Existing alerts migrated automatically

If you had deliverability alerts before this change, they were migrated into Monitoring as Deliverability alerts (absolute mode, 24h window) - no action needed.

See the Monitoring guide for the full metric reference.

Google Postmaster Tools Integration

Google Postmaster Tools provides Gmail-specific delivery insights that help you understand how Gmail views your sending domain.

Connecting Google Postmaster

1. Go to Analytics → Deliverability
2. Scroll to the Gmail Insights section
3. Click Connect Google Postmaster
4. Sign in with your Google account and grant access
5. Your verified domains will be synced automatically

What Data is Available

• Domain Reputation: How Gmail rates your sending domain (HIGH, MEDIUM, LOW, BAD)
• Spam Rate: Percentage of your emails marked as spam by Gmail users (should stay below 0.1%)
• Authentication Success Rates: DKIM, SPF, and DMARC pass rates for your emails
• Delivery Errors: Types of delivery failures and their frequency
• Encryption Rate: Percentage of emails sent over TLS

Data Sync

• Data is synced automatically every day at 8:00 AM
• Use the Sync Now button for an on-demand refresh
• Google Postmaster data is typically delayed by 24-48 hours

Prerequisites

• Your sending domain must be verified in Google Postmaster Tools (https://postmaster.google.com)
• You need a Google account with access to the domain's Postmaster data
• Sufficient email volume - Google only reports data when there's enough traffic from your domain