Notifications: Default email notification integration SNOWFLAKE$DEFAULT_EMAIL granted to SNOWFLAKE.PUBLIC (Pending)¶

To send an email notification from an alert, task, or stored procedure, a user must have the USAGE privilege on an email notification integration. Today, only an administrator can create that integration, so users who can create alerts often can’t send notifications from them until an administrator sets one up.

This change adds a Snowflake-managed email notification integration named SNOWFLAKE$DEFAULT_EMAIL to every account and grants USAGE on it to the SNOWFLAKE.PUBLIC application role. Account users inherit that application role through the account-level PUBLIC role. Users can then send email notifications to verified email addresses of users in the same account without waiting for an administrator.

SNOWFLAKE.PUBLIC is an application role on the SNOWFLAKE database. It isn’t the account-level PUBLIC role.

Note

This change isn’t part of a behavior change bundle, so you can’t enable it in advance for testing. Customer-visible sending begins on November 30, 2026, and continues gradually, so the date on which a given account can send through the integration can vary. Dates are subject to change.

Behavior change¶

Before the change:

An account has an email notification integration only if an administrator creates one. If no administrator has created a notification integration, SHOW NOTIFICATION INTEGRATIONS returns no rows, and users can’t send email notifications. Users who don’t have privileges on an existing notification integration can’t see or use it.

After the change:

Snowflake provisions an email notification integration named SNOWFLAKE$DEFAULT_EMAIL in every account, even if an administrator has never created a notification integration. Provisioning the integration and allowing it to send are separate. The integration can exist in the account before customer-visible sending begins on November 30, 2026.

New accounts receive the integration when they’re created.
Existing accounts receive it through a one-time backfill.

The integration appears in the output of SHOW NOTIFICATION INTEGRATIONS with type set to EMAIL. USAGE is granted to the SNOWFLAKE.PUBLIC application role, not to the account-level PUBLIC role. To confirm the grant, run:

SHOW GRANTS TO APPLICATION ROLE SNOWFLAKE.PUBLIC;

Sending also depends on the ENABLE_DEFAULT_EMAIL_NOTIFICATION account parameter and the integration’s ENABLED property. Snowflake checks both each time it sends. The integration sends email only when the parameter isn’t set to FALSE and ENABLED is TRUE. When both allow sending, any role that inherits SNOWFLAKE.PUBLIC can send email notifications, for example from an alert:

CREATE ALERT my_alert
  WAREHOUSE = my_wh
  SCHEDULE = '60 MINUTE'
  IF (EXISTS (SELECT 1 FROM credit_usage WHERE credits > 50))
  THEN CALL SYSTEM$SEND_SNOWFLAKE_NOTIFICATION(
    SNOWFLAKE.NOTIFICATION.TEXT_PLAIN(
      'Credit usage exceeded 50 credits.'),
    SNOWFLAKE.NOTIFICATION.EMAIL_INTEGRATION_CONFIG(
      'SNOWFLAKE$DEFAULT_EMAIL',
      'Credit spike alert',
      ARRAY_CONSTRUCT('oncall@example.com')
    )
  );

The alert creation dialog in Snowsight uses SNOWFLAKE$DEFAULT_EMAIL as the default email integration.

What doesn’t change¶

Allowed targets are limited to verified email addresses of users in the sending account. The default integration can only send to the verified email addresses of users in the sending account. It can’t send to unverified addresses, or to addresses that don’t belong to a Snowflake user.
Your existing integrations and alerts are unaffected. Email notification integrations that you created, and the alerts, tasks, and procedures that use them, continue to work as before. Nothing is migrated.
The backfill doesn’t overwrite your settings. If SNOWFLAKE$DEFAULT_EMAIL already exists in an account, the backfill skips that account, so changes you’ve made are kept.
Notifications are auditable. Emails sent through the default integration are logged in the NOTIFICATION_HISTORY table function, the same as emails sent through other integrations.

Decisions for administrators¶

Choose one of the following options (you can combine options 2 and 3):

Option 1: Keep the default

No action is required. Roles that inherit SNOWFLAKE.PUBLIC can send email notifications to verified email addresses of users in the account when the integration is allowed to send.

Option 2: Stop sending, or limit which roles can send

ENABLE_DEFAULT_EMAIL_NOTIFICATION is available starting October 27, 2026. Set it to FALSE to stop SNOWFLAKE$DEFAULT_EMAIL from sending. Snowflake checks this parameter on every send, so the change applies whether or not the integration already exists. This doesn’t remove the USAGE grant from SNOWFLAKE.PUBLIC.

ALTER ACCOUNT SET ENABLE_DEFAULT_EMAIL_NOTIFICATION = FALSE;

To limit which roles can send while the parameter allows sending, remove the grant from SNOWFLAKE.PUBLIC, then grant USAGE to the roles you choose. REVOKE USAGE ON INTEGRATION SNOWFLAKE$DEFAULT_EMAIL FROM ROLE PUBLIC doesn’t remove the SNOWFLAKE.PUBLIC grant. An ACCOUNTADMIN removes that grant by calling:

CALL SNOWFLAKE.LOCAL.REVOKE_FROM_PUBLIC_APPLICATION_ROLE('APP_ROLE', 'DEFAULT_EMAIL_USAGE');

To restore the grant, call:

CALL SNOWFLAKE.LOCAL.GRANT_TO_PUBLIC_APPLICATION_ROLE('APP_ROLE', 'DEFAULT_EMAIL_USAGE');

After the SNOWFLAKE.PUBLIC grant is removed, grant USAGE to specific roles:

GRANT USAGE ON INTEGRATION SNOWFLAKE$DEFAULT_EMAIL TO ROLE <role>;

Option 3: Limit who can receive email

Restrict the integration to a list of approved recipients. Each address must be a verified email address of a user in the account:

ALTER NOTIFICATION INTEGRATION SNOWFLAKE$DEFAULT_EMAIL
  SET ALLOWED_RECIPIENTS = ('oncall@example.com', 'secops@example.com');

To go back to allowing any verified email address of a user in the account, run ALTER NOTIFICATION INTEGRATION SNOWFLAKE$DEFAULT_EMAIL UNSET ALLOWED_RECIPIENTS.

Option 4: Turn off the integration object

Set ENABLED to FALSE to stop all email notifications sent through the integration, for all roles:

ALTER NOTIFICATION INTEGRATION SNOWFLAKE$DEFAULT_EMAIL SET ENABLED = FALSE;

Setting ENABLED back to TRUE resumes sending only when ENABLE_DEFAULT_EMAIL_NOTIFICATION isn’t set to FALSE. Snowflake checks both on every send.

Important

If you set ENABLE_DEFAULT_EMAIL_NOTIFICATION to FALSE, remove the SNOWFLAKE.PUBLIC grant, or disable the integration after users have started using it, their alerts, tasks, and procedures that send email through SNOWFLAKE$DEFAULT_EMAIL stop delivering notifications. Check NOTIFICATION_HISTORY for recent use of the integration before you change it.

Managing the default integration¶

SNOWFLAKE$DEFAULT_EMAIL is a Snowflake-managed object. The following table lists the operations you can and can’t run on it:

Operation	Supported
`SET ENABLED = { TRUE \| FALSE }`	Yes
`SET ALLOWED_RECIPIENTS` and `UNSET ALLOWED_RECIPIENTS`	Yes
`SET COMMENT` and `UNSET COMMENT`	Yes
`GRANT USAGE` and `REVOKE USAGE`	Yes
`SET DEFAULT_RECIPIENTS` or `SET DEFAULT_SUBJECT`	No
`RENAME TO`	No
`DROP NOTIFICATION INTEGRATION`	No

GRANT USAGE and REVOKE USAGE in this table apply to grants you make to specific roles. They don’t replace SNOWFLAKE.LOCAL.REVOKE_FROM_PUBLIC_APPLICATION_ROLE for the grant to SNOWFLAKE.PUBLIC.

Because the integration has no default recipients or default subject, every call that uses it must specify the recipients and the subject.

Replication and failover¶

SNOWFLAKE$DEFAULT_EMAIL isn’t replicated or cloned. Each account, including each primary and secondary account in a replication or failover group, has its own copy of the integration. Settings such as ENABLED, ALLOWED_RECIPIENTS, the ENABLE_DEFAULT_EMAIL_NOTIFICATION parameter, and grants of USAGE apply only to the account where you make them. If you change these settings in a primary account, make the same changes in each secondary account so that behavior is consistent after a failover.