Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Billing and invoices, payment, financing, fraud prevention, and subscriptions use [email protected], [email protected], [email protected], [email protected], and [email protected] respectively.
- AWS marks updates to allowlists, email filters, and forwarding rules as Action required. The official page does not provide a universal migration start or completion date or a per-account switching sequence.
- Default email recipients include the root, operations, billing, and security contact addresses. Additional email, mobile, and Amazon Q Developer chat channels require separate configuration in User Notifications.
- Sensitive billing events are not sent to additional chat or mobile push channels by default. Enabling them requires the relevant IAM permissions; broadening forwarding must not replace permission review.
- Retain old rules during migration, add @aws.com and the five exact sender addresses, and verify actual delivery and downstream tickets before deciding whether to restrict the old rules.
- PRODUCT_FIT=NONE: this is a notification governance and email routing issue. Changing the egress IP cannot fix sender allowlists, account contacts, or sensitive-event permissions.
What changed: billing notifications now use AWS User Notifications
As directly verified on September 21, 2026, official AWS Billing and Cost Management documentation lists billing and invoices, payment, financing, fraud prevention, and subscriptions as five categories of managed notifications. Notifications can appear in the Console Notification Center and be sent to account email addresses, additional email addresses, the AWS Console Mobile Application, and Amazon Q Developer integrations with Slack or Microsoft Teams.
The official documentation does not give a release date when all accounts switch simultaneously, nor say how long old and new sender addresses will coexist. This article therefore treats the new addresses as delivery paths that must currently be supported, without claiming that every historical template, email header, or account migrated at the same moment.
Allow each of the five sender addresses; do not rely on a vague rule
AWS lists the following mapping: Billing and Invoices uses [email protected], Payment uses [email protected], Financing uses [email protected], Fraud Prevention uses [email protected], and Subscriptions uses [email protected]. Rules that previously matched only [email protected] may miss these emails.
The general User Notifications documentation also says aggregated notifications may come from [email protected] and recommends that organizations using an email allow list add the @aws.com domain. Security teams should decide, based on their email gateway capabilities, whether to use a controlled domain rule or the five exact addresses plus the aggregation address. Migration is not a reason to bypass SPF, DKIM, DMARC, anti-phishing checks, or attachment policies.
Recipients are not one list: separate account contacts, additional channels, and subscriptions
Billing and Cost Management sends email by default to existing account contacts: root user, operations, billing, and security. In User Notifications under AWS managed notifications subscriptions, administrators can select contacts for each of the five subcategories and add verified email, mobile, or chat channels.
A newly added email address receives a verification email, and the recipient must sign in to the AWS account where it was added to complete verification. AWS also combines multiple addresses for the same subcategory into one email's To/CC fields and deduplicates plus addressing at account level. Downstream parsers should therefore not mistake a change in recipient count for missing notifications.
Sensitive-event defaults: subscribing does not guarantee visibility in chat or mobile
Some billing notifications contain sensitive information such as payment and contact details. AWS excludes sensitive events from additional chat and mobile push channels by default. To include them in a particular channel, enable Include sensitive events in that channel's configuration.
Viewing sensitive events requires notifications:AccessSensitiveEvents, while associating them with a delivery channel requires notifications:SubscribeSensitiveEvents. First establish the business need, minimum recipient scope, chat-space membership, and retention rules. Do not expand sensitive-event permissions across every channel merely to fix one missing email.
A six-step migration: allow both paths first, then verify each category
First, inventory all email gateways, SaaS filters, shared mailboxes, forwarding rules, SIEM rules, ticketing rules, and financial parsers that match [email protected]. Second, identify their owners and the five business categories. Third, add the five exact addresses and, according to policy, @aws.com or [email protected]. Fourth, retain the old rules. Fifth, check the contacts and additional channels for each category in User Notifications. Sixth, use actual authorized notifications received to verify email, ticketing, chat, and audit delivery end to end.
If no official general-purpose test email can demonstrate success for all five business categories, do not treat one verification email as complete acceptance. At minimum, retain the sender address, category, receipt time, destination mailbox, gateway result, downstream ticket ID, and reviewer. Do not record sensitive payment or contact data from the message body.
Rollback and stop conditions: do not remove old rules prematurely
Keeping old allow-list entries provides a fallback for this change. Stop removing old rules if the new addresses have not yet appeared in real notifications, a category has no contacts, an additional email address is still unverified, chat-channel membership is unclear, or automatic parsing depends on the old template. Improve observability and close those gaps instead.
AWS says the email body content remains unchanged while the visual styling is updated, but this does not guarantee compatibility with every custom parser. If parsing depends on HTML structure, the From field, To/CC count, or a fixed footer, replay redacted samples in tests. After confirming continuous coverage of billing cycles and high-risk notifications, let the email and finance owners decide whether to restrict the old addresses.
Troubleshooting: separate delivery, subscriptions, permissions, and networking
If nothing arrives, first inspect email gateway logs, quarantine, and the allow list. If only one category is missing, inspect that subcategory's contacts and subscriptions. For a missing additional-email delivery, check verification status. For sensitive events absent from chat or mobile, check Include sensitive events and the two IAM permissions. For duplicates or fewer recipients, inspect To/CC consolidation and plus-address deduplication.
Use this site's “Systematic proxy connection troubleshooting checklist” only when the Console or API itself shows DNS, TLS, 407, or timeout errors. Restoring connectivity does not replace fixes to allowlists, subscriptions, email verification, or IAM. If fraud or payment notifications repeatedly go missing, stop automated changes and have the account, security, and finance owners handle the issue together.
Sources
Frequently Asked Questions
Which addresses now send AWS billing emails?
The official documentation lists [email protected], [email protected], [email protected], [email protected], and [email protected]. Aggregated User Notifications may also come from [email protected].
Is allowing the entire @aws.com domain enough?
That depends on your organization's email security policy. AWS recommends adding @aws.com, but security teams should retain anti-phishing verification and may choose narrower rules using the five exact addresses plus the aggregation address.
Can the old [email protected] rule be removed immediately?
That is not recommended. AWS has not published a universal switching date or an end date for overlap with old addresses. Retain both paths first, then decide after verifying real delivery and downstream processing for every category.
Which account contacts receive notifications by default?
AWS documentation lists root user, operations, billing, and security contact addresses. Check the actual subscriptions by subcategory in User Notifications.
Why are sensitive billing events missing from chat or mobile?
Sensitive events are excluded from additional chat and mobile push channels by default. Enabling them also requires Include sensitive events and the AccessSensitiveEvents and SubscribeSensitiveEvents permissions.
Can changing proxies or using a fixed IP fix missing billing emails?
No. First check the allow list, subscriptions, contacts, email verification, and IAM. Investigate the egress path only when the Console or API has an explicit network error.