AWS SES troubleshooting

Data not appearing in InboxEagle

If your AWS SES campaigns are not showing up in InboxEagle’s deliverability dashboard:

Verify the connection is active — Go to Integrations and check that AWS SES shows “Connected” or “Active”. If it shows “Disconnected”, click to reconnect.
Check that campaigns are being sent — InboxEagle only displays deliverability data for campaigns sent after the connection was established. Verify you’ve sent at least one email through SES since connecting to InboxEagle.
Confirm the correct SES region — InboxEagle monitors one specific AWS region (usually us-east-1 by default). If you’re sending from a different region (e.g., eu-west-1), you may need to configure monitoring for multiple regions. Check your integration settings for the monitored region(s).
Check SES sending limits and quotas — Go to the AWS SES console and verify your account is not in the Sandbox. Sandbox accounts can only send to verified email addresses. If you’re still in Sandbox, request production access from AWS.
Verify SES event publishing — If you use Bot Finder, delivery and engagement events are routed via SNS/SQS. If you don’t use Bot Finder, ensure your SES configuration set publishes events to CloudWatch (or another monitoring destination). Without event publishing, InboxEagle cannot see detailed engagement data.

Campaign sending succeeds but no delivery data appears

If campaigns send successfully but InboxEagle does not show delivery, bounce, complaint, or engagement metrics:

Check event publishing — In the AWS SES console, go to your Configuration Set and verify that event destinations are configured for the event types you care about (delivery, bounce, complaint, open, click).
Missing configuration set — If you have not assigned a configuration set to your sending identity, SES will not publish detailed events. Go to your SES sending identity (e.g., a domain or email address) and ensure a configuration set is selected.
Regional mismatch — SES events are published to the same region as your sending identity. If InboxEagle is configured to monitor a different region, no events will be received. Verify the regions match.

Bot Finder events not arriving

If you have Bot Finder configured but events are not appearing in the Bot Finder dashboard:

The most common causes are:

Configuration set not applied — The ie-config-{ExternalId} configuration set created by the CloudFormation stack is not assigned to your sending identity or account default.
SNS subscription not confirmed — The SQS queue subscribed to the SNS topic has status “PendingConfirmation” instead of “Confirmed” in the AWS SNS console.
IAM permissions missing — The IAM role lacks sqs:ReceiveMessage or sns:Subscribe permissions. Verify the role trust policy allows InboxEagle’s AWS account to assume it.
Resource sync not running — InboxEagle’s resource discovery runs every 5 minutes. Wait at least one cycle after creating the CloudFormation stack or updating the role ARN.

Deliverability scores are zero or missing

If InboxEagle shows zero bounce rate, complaint rate, or other metrics:

Insufficient data — These metrics require at least 100 emails sent to calculate meaningful percentages. If you’ve sent fewer emails, wait for more volume or send a test batch.
Events not published — Verify that your SES configuration set publishes bounce and complaint events to a CloudWatch log group or other destination. Without event data, InboxEagle cannot calculate these metrics.
Timing lag — SES events can be delayed by up to 15 minutes. If you just sent a batch, wait a few minutes before checking InboxEagle.

Authentication records not showing passing

If SPF, DKIM, or DMARC records show as failing in InboxEagle:

Check DNS records — Go to your domain’s DNS provider and verify the actual records match what InboxEagle expects. Use a tool like MXToolbox to validate SPF and DKIM records.
DMARC policy not set — DMARC typically shows as “none” or “missing” if you haven’t published a DMARC record. Start with a p=none policy to collect data, then advance to p=quarantine and p=reject after verifying alignment.
SPF syntax error — Common mistakes include too many DNS lookups (SPF has a 10-lookup limit) or incorrect IP ranges. Check your SPF record for syntax errors.
DKIM selector not verified — In AWS SES, you must verify the DKIM selectors. Go to the SES console, select your domain, and ensure DKIM signing is enabled and all selectors are verified.

Blocklist status not updating

If blocklist detection shows an old status or never updates:

Blocklist check frequency — InboxEagle checks major blocklists (Spamhaus, Barracuda, SURBL, etc.) once per day. If you were recently delisted, wait up to 24 hours for the status to refresh.
No sending history — If you haven’t sent emails from your IP or domain since being listed, the blocklist checker may not prioritize it. Resume sending a small volume to trigger a refresh.
Multiple IPs — If you send from multiple IPs (shared or dedicated), each one is checked separately. Ensure you’re checking the IP you’re actually sending from.

IP reputation is poor but sending hasn’t changed

If your IP reputation suddenly drops without any change in sending practices:

New IP warmup — If you recently switched to a new IP, start with low volume and gradually increase sends over 1–2 weeks. ISPs treat new IPs with skepticism until they see consistent, trusted sending patterns.
List quality — Sudden reputation drops often correlate with list quality issues. Check for:
- High bounce rates (over 5%)
- High complaint rates (over 0.3%)
- Low engagement from stale contacts
Shared IP abuse — If you’re on a shared IP and another sender on the IP has poor practices, your reputation may be affected. Consider a dedicated IP if your volume supports it (typically 100k+ emails/month).

Rate limiting or throttling errors

If you see SES rate limiting errors or delivery attempts are being throttled:

Check sending rate limits — In the AWS SES console, go to Account Dashboard and check your sending rate limit (messages per second). If you’re hitting the limit, requests are throttled.
Request a rate limit increase — AWS allows rate limit increases for verified accounts with good sending practices. Go to the SES console and submit a limit increase request.
Batch and retry — Implement exponential backoff in your application. If you hit rate limits, queue messages and retry with increasing delays (e.g., 1s, 2s, 4s, 8s).

Unsubscribe and complaint handling

If unsubscribe links are not working or complaint rates are not being tracked:

DMARC alignment — Ensure your List-Unsubscribe header is DMARC-aligned (uses your domain, not a third-party URL). ISPs require DMARC alignment for unsubscribe handling.
Complaint events — Verify that your SES configuration set publishes complaint events. If complaint events are not published, InboxEagle cannot track complaints and may show them as unsubscribes instead.
List hygiene — High complaint rates indicate content or list quality issues. Review recent campaigns for content that triggered complaints and remove complainers from future sends.