Fix SNS Email Subscription Stuck in "Pending Confirmation": Spam Filters, Missing Emails & Manual Confirmation Steps

An Amazon SNS email subscription only leaves "Pending confirmation" when the person you subscribed clicks the "Confirm subscription" link inside the email SNS sent them — nothing else does it, not a console button, not a topic policy, not time alone. But here's the part almost nobody warns you about: a subscription that was confirmed and delivering fine for months can silently drop back into Pending Confirmation on its own, with no one touching Unsubscribe, because Amazon SNS enforces a hard 10-messages-per-second ceiling per email endpoint and automatically suspends any subscription that crosses it.

Jake sells and repairs phones out of a single storefront, and about eight months ago he let a freelancer wire up a small order system for him — an Amazon SQS queue that holds incoming orders so nothing gets lost if his laptop is closed, plus an Amazon SNS topic that fans out to that same queue and to Jake's own email, so he gets pinged the second a payment fails. The queue side kept working perfectly. The email side never did.

He didn't notice for three weeks, because the queue was still quietly catching everything and nothing looked broken from where he sat. Then a regular customer called asking why her trade-in credit never showed up — her payment had failed twice, the queue had the failure sitting in it the whole time, and the email that was supposed to tell Jake to look never once reached him. That's a real, costed mistake: a trade-in he had to honor anyway, an afternoon spent explaining himself, and a customer who now double-checks everything he tells her.

Which of these is actually happening to you?

"Stuck pending confirmation" is really seven or eight different problems wearing the same status label. Before you go digging into IAM policies or filing an AWS Support ticket, figure out which bucket you're actually in — the fix is completely different depending on the answer, and guessing wrong just burns an afternoon.

Confirming a subscription without waiting on email at all

Every SNS confirmation email carries a one-time web address called the SubscribeURL, and buried in it is a short-lived value called a token — think of it like the one-time code a bank texts you before letting you reset a password. As long as you can get your hands on that token, you don't need to click anything in an email client at all; you can hand it straight to SNS yourself, which is faster and side-steps whatever is blocking the message.

Option 1: Confirm from the console

1. Open the Amazon SNS console and choose Subscriptions in the left-hand menu.
2. Click into the subscription that's stuck at Pending confirmation.
3. Open the confirmation email (check spam) and copy the full SubscribeURL — a long link starting with your region's SNS endpoint, something like https://sns.us-east-1.amazonaws.com/?Action=ConfirmSubscription&TopicArn=...&Token=....
4. Back in the console, choose Confirm subscription, paste that URL into the box, and submit.

If the email genuinely never arrived but you know the subscription exists and is sitting in Pending Confirmation, select it and look for Request confirmation among the actions on that subscription — it tells SNS to resend the confirmation message to the same endpoint without deleting and recreating anything, which is worth trying before you assume the subscription itself is broken.

Option 2: Confirm from the AWS CLI

This is the fastest path if you're comfortable in a terminal — a text-only window where you type commands instead of clicking buttons — and the AWS CLI is Amazon's own command-line tool for talking to AWS services from it.

1. Subscribe the address: aws sns subscribe --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic --protocol email --notification-endpoint you@example.com. AWS immediately returns {"SubscriptionArn": "pending confirmation"} — that literal text, not an error, is the expected response for any email or HTTP(S) subscription, so don't panic when you see it.
2. Once you have the token — from the email, or forwarded to you by whoever's mailbox received it — run aws sns confirm-subscription --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic --token THE_TOKEN_VALUE.
3. A successful response returns the finished SubscriptionArn, a long ARN string instead of the word "pending," which means the endpoint is now live and will start receiving messages on the next publish.

Cause 1: The confirmation email never arrived in the first place

This is the boring one, and it's also the most common one by a wide margin — so rule it out before anything else. Every SNS confirmation message comes from no-reply@sns.amazonaws.com. Personal Gmail, Outlook.com and Yahoo accounts almost never block it outright, but they'll sometimes route it into Spam or Promotions on the first message from a sender they've never seen, simply because the message body is short, link-heavy, and machine-generated — structurally exactly what a phishing email looks like to an automated filter.

Locked-down corporate mail systems are a different problem. If your company routes mail through a security gateway — Mimecast, Proofpoint, and Microsoft Defender for Office 365 all do this — that gateway inspects every inbound link before your inbox ever sees the message, and a raw AWS confirmation link pointing at sns.{region}.amazonaws.com can get quarantined purely because it's an unfamiliar, auto-generated link from a domain your IT team has never explicitly allowed. Whitelisting the sender address alone frequently isn't enough here, because the block often happens at the link-scanning layer rather than the sender-reputation layer — some administrators have added both the sender address and the amazonaws.com domain to their allow list and still never seen the message land.

Cause 2: You subscribed a group inbox or distribution list

An individual mailbox almost always gets the confirmation email right away. A shared team address — a Google Group, a Microsoft 365 mail-enabled group, an alerts@yourcompany.com distribution list — is a different animal, because those systems often reject or silently drop mail from senders outside your organization by default, and AWS is, from that group's point of view, an outside sender.

A supplier of Jake's ran into exactly this, on a bigger scale than Jake's own single-inbox setup. They'd wired a low-stock alert topic to email their whole warehouse team through a Microsoft 365 distribution list — warehouse-alerts@theirdomain.com — and it sat in Pending Confirmation for two weeks while three different people insisted they'd checked their spam folders. Nobody had, because there was nothing to check: their tenant's default mail flow rules were quietly rejecting the message from AWS before it ever reached a mailbox, with no bounce sent back and nothing for anyone to notice.

Ethan's take on this one is blunt: "Group addresses are convenient right up until the first message you actually need gets eaten silently. Half the 'SNS never sends the confirmation' threads out there turn out to be a group set to reject external mail, and nobody thinks to check because there's no error to point at." If your endpoint is a group address, check these before assuming AWS is at fault:

• Google Groups: in the group's settings, confirm "Anyone on the web" (or at least external senders) is allowed to post, and in the Google Workspace Admin Console, confirm the group allows incoming email from outside the organization.
• Microsoft 365: confirm the distribution list is mail-enabled and explicitly allows senders outside your tenant — by default, many M365 groups silently reject external senders with no bounce back to AWS at all, which is exactly why the confirmation email can vanish without a trace on either end.

Even after fixing the settings, the original pending subscription won't magically confirm itself — you'll need to trigger a fresh confirmation email (the console's Request confirmation action, or a brand-new Subscribe call) once the group can actually receive external mail.

Cause 3: A subscription that WAS working just silently un-confirmed itself

This is the counterintuitive one from the top of this page, and it catches experienced AWS users off guard just as often as beginners, because there's a real reflex to assume "it was working, so the setup must still be fine." Amazon SNS caps email and email-json delivery at exactly 10 messages per second per subscription, and this is a hard limit — it cannot be raised with a quota increase request, unlike almost every other SNS limit. If your topic ever bursts past that rate — a bad deploy that retries in a tight loop, a monitoring alarm that fires once per failed health check across dozens of instances, a batch job that publishes a thousand failure notifications in a few seconds — SNS doesn't queue the overflow or drop it quietly. It automatically suspends the subscription, and the console shows exactly the same status as a subscription that was never confirmed at all: Pending Confirmation.

The fix isn't really "reconfirm and move on," because if the publish rate is still spiking, you'll just get suspended again within minutes of reconfirming. The real fix is to stop pointing high-volume, bursty publishing straight at an email endpoint. Route the noisy traffic to an SQS queue instead — SQS has no per-message-rate ceiling anywhere close to 10/second — and either process it there or have a small piece of code batch and summarize before it ever emails a human. Reserve the direct email subscription for genuinely low-volume, "a person needs to see this" alerts. That's exactly the pattern Jake's shop should have used for payment-failure notices from the start: one alert per genuine failure, not one per retry attempt on a webhook that was quietly hammering the topic every few seconds while it tried to recover.

Cause 4: You deleted and recreated the SNS topic

If you deleted a topic and stood up a new one with the same friendly name — common when you're tearing down and rebuilding infrastructure with Terraform or CloudFormation — the old subscription doesn't get cleanly cleaned up on its own. It's tied to the old topic's ARN, which no longer exists, and clicking the confirmation link from an old email against that dead topic will show something like "Subscription not confirmed" in the browser, because SNS can't find the topic to attach it to anymore.

You genuinely can't manually delete a subscription while it's sitting in Pending Confirmation or Deleted status — the Delete button in the console is grayed out for exactly that reason. Amazon SNS automatically removes subscriptions left in either state after two days on its own; there's no faster manual path for the topic owner. If two days pass and it's still hanging around, that's the point to open a support case rather than keep waiting.

The practical fix in the meantime: create a brand-new subscription against the new topic's ARN and confirm that one. Don't try to reuse the old confirmation link — it's pointed at an ARN that no longer resolves to anything, and no amount of retrying will make it work. If you're rebuilding topics through infrastructure-as-code on a regular cadence, this is worth designing around from the start (more on that in the automation section further down).

Cause 5: Your own mail provider is auto-clicking the unsubscribe link

Here's a genuinely strange one that trips people up because it looks like an AWS bug when it isn't. You confirm a subscription, it works, and then — with nobody touching anything — it silently goes back to unconfirmed, over and over, every time you re-add it. Some webmail providers, most notably Gmail, run automated link-scanning on incoming messages for security purposes, and that scanner sometimes pre-fetches every link in an email, including the one-click unsubscribe link SNS includes at the bottom of every notification. The scanner isn't trying to unsubscribe anyone; it's just following the link to check it's safe, but SNS can't tell the difference between a security scanner and a human clicking "unsubscribe."

The workaround is to skip the email-hosted links entirely for the initial confirmation and use the console's manual "paste the SubscribeURL" flow described earlier, rather than clicking anything inside the email client itself. If unwanted unsubscribes keep happening on an ongoing basis after the topic is confirmed and live, look at setting up an email subscription that requires authentication to unsubscribe — it adds a login step before an unsubscribe request is honored, which a passive link scanner can't complete, so the subscription stays put no matter how many automated crawlers visit that link.

Cause 6: The address bounced once and is now suppressed

If a subscribed address results in a bounce — mailbox full, typo in the address, receiving server temporarily rejecting mail — Amazon SNS suppresses that address from receiving further deliveries for seven days. This is technically a different mechanism from Pending Confirmation as a status, but it produces the same symptom from where you're sitting: nothing arrives, at all. The confirmation email itself can bounce just as easily as any other notification, and if it does, you'll be locked out of receiving anything else at that address — including a resent confirmation — until the suppression window passes.

The fix that actually matters is resolving the underlying reason for the bounce first: an overflowing mailbox, an autoresponder rejecting automated senders, a typo in the address you subscribed. Subscribing the same broken address again just produces another bounce and restarts the clock rather than clearing it. If seven days genuinely can't wait, resolving the issue and then contacting AWS through the Support Center is the path to lift the suppression early; there's no self-service button for it in the console.

Cause 7: It's not pending at all — the Subscribe call is failing outright

Worth separating out clearly, because it's easy to conflate with everything above: if the subscription doesn't even show up in the list — no row, no Pending Confirmation, nothing — you're not looking at a confirmation problem at all. You're looking at a permissions problem, and the fix is entirely different.

This shows up most often in two situations. First, an IAM user or role trying to run Subscribe without the sns:Subscribe permission on that specific topic gets an access-denied error back immediately, before any email is ever generated. Second — and this is the one that trips up cross-account setups specifically — subscribing an endpoint that belongs to a different AWS account (an SQS queue, a Lambda function, or an email address managed under another account's tooling) requires the topic's own access policy to explicitly allow that account to subscribe, on top of the identity-based permission. HTTP(S) endpoints, email addresses, and AWS resources in other AWS accounts all require confirmation before they can receive messages — but before confirmation is even possible, the account attempting the Subscribe call needs permission to call it in the first place.

A minimal identity-based policy granting the calling entity permission to subscribe looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "SNSSubscribePermission",
    "Effect": "Allow",
    "Action": "sns:Subscribe",
    "Resource": "arn:aws:sns:us-east-1:111122223333:my-topic"
  }]
}

For a cross-account resource, the topic's own resource-based access policy also needs a matching statement that names the other account as a trusted principal for the Subscribe action, added either through AddPermission or by editing the topic's policy directly with SetTopicAttributes. Miss either half and the Subscribe call fails outright — you'll never even reach a pending confirmation state to troubleshoot, so if nothing shows up in the subscriptions list at all, this is where to look before assuming email delivery is the problem.

Why you can't do this on a FIFO topic at all

One more thing worth ruling out early if your topic name ends in .fifo: Amazon SNS states plainly that directly subscribing email endpoints is supported for standard topics only. A FIFO topic — one that guarantees messages arrive in the exact order they were published, which matters for things like sequential order-processing steps — simply doesn't offer email or email-json as a protocol option in the console, and a Subscribe call attempting it from the CLI will fail. If you need strict ordering upstream and a human alerted downstream, the usual pattern is a FIFO topic feeding an SQS queue, with a small function reading that queue and sending the actual email itself — not subscribing an email address directly to the FIFO topic, because that option isn't there to begin with.

Checking exactly what state a subscription is in

Before you spend time chasing spam filters or group-mail settings, confirm what SNS itself believes is happening. The console's Subscriptions page shows a Status column directly, but if you're managing more than a handful of subscriptions — or automating this — the CLI is faster and scriptable:

1. Run aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic.
2. Look at the SubscriptionArn field for each entry. A confirmed subscription shows a full ARN. An unconfirmed one — whether it's brand new, has never been clicked, or was auto-suspended by the 10-messages-per-second throttle — shows the literal string PendingConfirmation instead of an ARN.
3. If you can't tell whether a confirmation email was even generated on AWS's side, check the NumberOfNotificationsDelivered metric for the topic in CloudWatch. Requesting a fresh confirmation on a pending email subscription increments that metric each time SNS sends one — publishing an ordinary message to the topic does not, which lets you tell the two apart.

That third point matters more than it looks. Without it, you're stuck guessing whether SNS tried to send anything at all versus your mailbox silently eating it. With it, you at least know whether the problem lives on Amazon's side of the wire or yours — which saves you from escalating a support case for something that was actually a spam filter the whole time, or vice versa.

Why the SQS side of your fan-out never has this problem

This is the piece that confuses people building exactly the setup Jake has: one SNS topic fanning out to both an SQS queue and an email address. The queue side "just works" the moment you subscribe it, no clicking anything, while the email side sits there pending. That's not inconsistent behavior — it's SNS following its own documented rule precisely. It in one sentence: HTTP(S) endpoints, email addresses, and AWS resources in other AWS accounts require confirmation before they can receive messages. An SQS queue you own, in the same account, isn't on that list — SNS treats a same-account subscription as something you've already proven you control, because you needed IAM permissions on both the topic and the queue to create the subscription in the first place. An email address proves nothing about who controls it until someone with access to that inbox clicks a link.

For Jake's setup specifically, this explains why his queue never showed a problem while his inbox sat empty: the queue side of the fan-out had already been silently confirming itself since day one, and the only piece that ever needed a human to click something was the email leg — which nobody told him about until orders had already started slipping through unnoticed.

The deadlines and limits nobody reads until they're stuck

A handful of numbers explain almost every "why did this just disappear" question people ask about SNS subscriptions. Keep this table nearby if you're managing a topic with more than a couple of subscribers.

That last row matters most for anyone scripting subscriptions in bulk. A CI pipeline that re-creates a topic and its subscriptions on every deploy can quietly build up thousands of orphaned pending subscriptions over months if old ones are never confirmed or cleaned up, and eventually every new Subscribe call in that account starts failing for a reason that has nothing to do with the specific topic you're working on that particular day — which is a genuinely confusing thing to debug if you don't already know this quota exists.

If you're managing this at any real scale, script it

Checking one subscription by hand in the console is fine for Jake's shop. It stops being fine the moment you're responsible for a topic with dozens of subscribers, or a pipeline that recreates topics on every deploy. Two habits save real time here.

Auditing pending subscriptions across a topic. Rather than clicking through the console entry by entry, pull the full list and filter for the ones still stuck:

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic \
  --query "Subscriptions[?SubscriptionArn=='PendingConfirmation']"

That single command hands back every subscription on the topic still waiting on a click, which is the fastest way to find the three stragglers on a list of forty subscribers before they age out and quietly disappear at the 48-hour mark.

The adjacent task: migrating subscribers when you rebuild a topic. This is the thing you'll need thirty seconds after fixing today's problem, because it's the same underlying cause as the "deleted and recreated topic" section above. If infrastructure-as-code is going to tear down and rebuild an SNS topic regularly, don't ask every human subscriber to re-click a confirmation link each time. Instead, keep the topic itself stable across deploys — give it a fixed logical name in CloudFormation or Terraform so its ARN doesn't change — and reserve full delete-and-recreate cycles for the resources feeding into it (the SQS queues, the Lambda targets), which reconfirm themselves automatically in the same account with no human involved at all. Email addresses should be the one thing that almost never needs to be re-subscribed once it's confirmed.

Setting this up so it doesn't happen again

A few habits catch almost every cause on this page before it turns into a support ticket:

• Never point a high-volume publisher straight at an email endpoint. If a Lambda function or a monitoring system could plausibly fire more than 10 times a second, put an SQS queue or a filtering step in front of the email subscription, not behind it.
• Use a subscription filter policy so a noisy topic only emails a human about the message types that actually need a human — filtering out routine "succeeded" events and forwarding only failures cuts your effective send rate dramatically without touching the underlying publisher.
• Set up authenticated unsubscribe for any topic with more than one or two subscribers, specifically to stop the accidental-click and scanner-click problem from taking out subscriptions you didn't mean to lose.
• Confirm new subscriptions the same day you create them. Waiting even a week risks running into the 48-hour auto-delete window on anything that isn't the throttle-suspension case, and you'll be starting over from a fresh Subscribe call.
• If you're scripting subscription creation, log and periodically clean up anything still sitting at PendingConfirmation after a day or two, rather than letting them accumulate toward the 5,000-per-account quota.
• Before subscribing a group address, confirm with whoever owns that mailbox that external senders are actually allowed in — five minutes of asking beats two weeks of a topic owner blaming AWS for something a mail-flow rule was doing the whole time.

What you genuinely can't work around

Ethan is the one who insists on saying this part plainly, because too many guides skip it: there is no supported way to make an email subscription skip confirmation. Not a topic policy, not an IAM permission, not a hidden CLI flag. "People ask if there's a setting that just marks it confirmed on creation," he says. "There isn't, and there shouldn't be — that setting would turn every SNS topic into a way to spam any address you can guess." The 10-messages-per-second ceiling is the same story: it's described as a hard limit precisely because AWS won't raise it even on a quota increase request, so redesigning the traffic pattern around it is the only real option, not asking Support to lift it.

Similarly, if you don't control the mailbox — a client's shared support inbox, a vendor's alerts address — you can't force their spam filter or their group settings to behave from your side of the fence. The most you can do is hand them the exact SubscribeURL and walk them through the console's manual confirm step yourself, since asking "did you get our email?" repeatedly rarely moves faster than just doing it for them once, with them on the line.

Frequently asked questions

How long does an unconfirmed SNS email subscription stay pending before AWS deletes it?

Two days (48 hours) for a subscription that has simply never been confirmed. If the subscription was previously confirmed and got auto-suspended for exceeding the 10-messages-per-second email limit, it gets a longer grace window of 30 days before deletion.

Can I manually confirm an SNS email subscription without clicking the link?

Yes. Paste the SubscribeURL from the confirmation email into the console's Confirm subscription dialog, or run aws sns confirm-subscription with the topic ARN and the token from that URL. Both do exactly what clicking the link does.

Why did my SNS email subscription flip back to Pending Confirmation after weeks of working fine?

Almost always the 10-messages-per-second delivery limit for email endpoints. Something upstream started publishing faster than that rate to the topic, and SNS automatically suspended the subscription rather than dropping or queuing the overflow.

Does AWS ever resend the SNS confirmation email automatically?

Not on its own schedule, no. You have to trigger it — either by choosing Request confirmation on the pending subscription in the console, or by calling Subscribe again for the same endpoint and protocol.

Can I use a shared mailbox or distribution list as an SNS email endpoint?

Yes, but check that the group explicitly allows mail from outside senders first. Google Groups and Microsoft 365 distribution lists both reject external mail by default in many configurations, and AWS counts as external, which means the confirmation email can be silently dropped before it ever reaches anyone's inbox.

Why isn't the SNS confirmation email showing up even after whitelisting amazonaws.com?

Corporate mail security gateways often scan and quarantine links independently of sender whitelisting, so allowing the sending domain doesn't always stop the message from being held. If your admin can't clear it quickly, confirm the subscription manually with the CLI instead of waiting on the mail team.

What's the difference between "email" and "email-json" protocol for SNS?

Email delivers a plain, human-readable message. Email-json delivers the same notification wrapped in raw JSON, which is meant for a mailbox that's actually read by a script or a legacy system rather than a person. Both protocols share the same 10-messages-per-second limit and the same confirmation requirement, and neither is available on a FIFO topic.

Can I subscribe an SQS queue and an email address to the same SNS topic?

Yes, this is a standard fan-out pattern. Just remember they behave differently: a same-account SQS queue subscription doesn't require confirmation at all, while the email leg always does, regardless of how the queue side is set up.

Why is the Delete button grayed out on my pending subscription?

Subscriptions in Pending Confirmation or Deleted status can't be manually removed by the topic owner. SNS clears them out automatically after two days; if two days pass and it's still there, contact AWS Support.

I deleted my SNS topic and recreated it with the same name — why is the old subscription broken?

The old subscription is tied to the deleted topic's original ARN, which no longer exists, so its confirmation link can't resolve to anything. Create a fresh subscription against the new topic's ARN instead of trying to reuse the old link.

Does clicking Unsubscribe in the confirmation email itself count as confirming?

No — Unsubscribe and Confirm are two separate links in the same message, and clicking Unsubscribe removes the subscription rather than activating it. This distinction matters because automated link scanners in some webmail providers sometimes follow both links without a human choosing to.

How many pending subscriptions can I have before AWS blocks new ones?

5,000 pending subscriptions per AWS account. Past that, new Subscribe calls start failing until existing pending subscriptions confirm, get deleted where possible, or age out on their own.

Can I confirm someone else's email subscription on their behalf using the CLI?

Yes, as long as you have the SubscribeURL or token that was sent to their inbox. This is a common shortcut when you're helping a colleague or client whose mailbox is blocking the message — get them to forward you the confirmation email, then run the confirm-subscription command yourself.

Why does Gmail seem to auto-unsubscribe my SNS email endpoint?

Gmail's automated link-scanning can pre-fetch every link in an incoming message, including SNS's built-in unsubscribe link, before a human ever opens it. Confirming through the console's manual SubscribeURL entry instead of clicking links in the email client avoids this, and enabling authenticated unsubscribe stops it from recurring.

My subscribed email bounced once — how long until it can receive messages again?

Seven days from the bounce, unless you resolve the underlying issue with the address and contact AWS Support through the Support Center to have the suppression lifted early. Simply re-subscribing the same broken address restarts the seven days rather than skipping it.

Is there a way to see who confirmed and who didn't across a large distribution list?

Run aws sns list-subscriptions-by-topic against your topic and check each entry's SubscriptionArn field — a real ARN means confirmed, and the literal text "PendingConfirmation" means it isn't. Filtering that same call with a JMESPath query surfaces just the stragglers without reading the whole list by eye.

Revision note. Written September 2026. This will need a revisit if AWS ever changes the 10-messages-per-second email throttle or the 48-hour/30-day expiry windows, so treat those specific numbers as worth a quick re-check if this page is more than a year old when you read it. If you've been staring at "Pending Confirmation" for an hour wondering what you broke — you probably didn't break anything at all, and you're closer to fixed than it feels right now.