Keep sending with SparkPost. Tatami reads its delivery events and shows you what bounced, what got blocked, and what to fix next.
No DNS changes. No rerouting mail. See the SparkPost setup.
SparkPost
Sending as usual
Event webhook
https://tatamimonitor.com/webhooks/sparkpost/a8f3b2c9
Tatami
Last hour
Outlook deferrals up 4x
451 4.7.650 · 198.51.100.24
Your mail keeps flowing through SparkPost. Tatami only reads the events it reports.
SparkPost delivery events contain clues that an aggregate report can miss: bounce classes, raw rejection reasons, retry details, and transmission identifiers. Connect those events to Tatami to investigate delivery problems with their original context, whether you are reviewing one campaign or traffic across several sending pools and subaccounts.
Review policy_rejection and bounce events with their raw reasons and bounce classes. Identify the receiving domains involved before reviewing authentication, content, or sending practices.
Bring delay events into the same view as delivery outcomes. Inspect retry counts, sending IPs, and routing context when those fields are present in SparkPost's payload.
Retain campaign, transmission, template, and subaccount identifiers supplied by SparkPost. Use the event context to connect an operational issue with the team or campaign responsible.
Tatami explains each bounce, watches your IPs and domains, and tells your team when something breaks.
1,240 Outlook bounces since 9:00, all from 198.51.100.24.
Microsoft is blocking that IP. Gmail and Yahoo look normal.
Also works in Claude Code and Codex through mcp.tatamimonitor.com.
Google, Yahoo, and Microsoft signals for every IP and domain.
Outlook is bouncing mail from 198.51.100.24 with 550 5.7.1 S3150.
Also sent to
Discord
Email
Rules on bounces, blocklists, volume, and throttling.
One filtered link per customer.
Point the SparkPost webhook at Tatami. Your mail keeps sending the same way.
Create a SparkPost source inside your Tatami project and copy the webhook URL. Choose a source name that identifies the account or environment supplying events.
In SparkPost Configuration, create a webhook using the Tatami URL. Select delivery, bounce, delay, policy rejection, and spam complaint events, plus any supported unsubscribe events you need.
Save and validate the webhook, then send a test message through SparkPost. Confirm a delivery outcome appears in Tatami and inspect its campaign or transmission details.
Detail depends on the fields your webhook sends. Opens and clicks are not needed.
Yes. Tatami records policy_rejection as a bounce outcome and preserves SparkPost's event payload, including reason, raw_reason, bounce_class, and error_code when provided. Those details help your team investigate why the receiving system rejected a message.
SparkPost events can carry campaign_id, transmission_id, subaccount_id, template information, sending IP, and IP pool. Tatami retains those supplied fields with the event. The available context depends on the event and the metadata included when sending.
No. A delivery event means the receiving mail server accepted the message. It does not confirm whether it reached the inbox or spam folder. Tatami monitors the delivery events you send, bounce reasons, and sender reputation to help you investigate deliverability issues; it does not measure inbox placement.
Providers are unlimited on every plan. Connect the rest of your email stack the same way.
PostShiba deliverability tool
Amazon SES deliverability tool
Customer.io deliverability tool
Smartico deliverability tool
Bento deliverability tool
$10 per million emails. First 100 IPs free. See pricing
Connect the webhook and watch your first SparkPost events arrive in minutes.