GitHub Retires Repository Push Email Alerts Over Spam Abuse: Replace Them With Actions

For veteran developers and enterprise administrators who have relied on repository-level email alerts since the early days of hosted Git, it is the end of a very old habit. Historically, GitHub's documentation noted that people with admin permissions in a repository could enable email notifications for pushes, with each message listing the new commits and linking to a diff containing just those commits. Why pull the plug now? It comes down to a classic internet tragedy: we can't have nice, unverified things because spammers ruin them.

Why GitHub Pulled the Plug on Push Emails​

GitHub's Changelog entry is refreshingly blunt about why the feature had to go. The company shut down repository push email notifications to prevent spam and abuse. Because recipients did not have to consent before receiving those emails, bad actors could misuse the feature to blast unwanted messages to arbitrary addresses directly through GitHub's trusted email infrastructure.

From an IT security and mail-deliverability standpoint, an unverified outbound notification hook is an open invitation for abuse. When a major platform's domain gets hijacked to relay unsolicited messages, everyone suffers—from the unwilling recipients to the legitimate engineering teams whose actual security advisories and pull-request alerts risk getting caught in enterprise spam traps.

It is also important to keep the scope of this retirement in perspective:

• What is gone: Built-in email notifications triggered specifically by repository push events.
• What remains untouched: Standard GitHub account notifications—such as issue updates, pull request reviews, and @mentions —as well as GitHub Actions and webhooks are not retired by this announcement.

In short, GitHub isn't abandoning email; it is getting out of the business of acting as an unconsented SMTP relay for raw repository pushes.

Shifting to GitHub Actions: How to Rebuild Push Alerts​

If your team, compliance pipeline, or release manager still relies on an inbox alert whenever code lands in a repository, you aren't out of luck—you just have to bring your own mail carrier. GitHub recommends replacing the retired feature with a GitHub Actions workflow triggered by push events that sends email through your own SMTP server or email provider.

While having to maintain a YAML file for something that used to be a simple repository setting might feel like extra homework, moving this logic into GitHub Actions actually gives administrators far better control over noise and security.

1. Scope Your Triggers So You Don't Spam Yourself​

According to GitHub Docs on workflow syntax, a workflow file stored in .github/workflows using a bare on: push trigger will run whenever a push is made to any branch in the repository. In an active project, emailing a distribution list on every feature-branch typo fix is a great way to guarantee your team sets up an inbox rule to delete your alerts.

Instead, GitHub Docs notes that you can apply branches, branches-ignore, tags, or paths filters to on.push. For example, you can restrict the workflow so it only fires when commits are pushed to main or to release branches matching releases/**, while ignoring alpha branches or documentation-only path changes.

2. Lock Down Your SMTP and API Credentials​

Because GitHub is no longer sending these messages on your behalf, your workflow needs credentials for an external SMTP server or transactional email API. Never hardcode those credentials into your .yml workflow file.

As detailed in GitHub Docs on using secrets in GitHub Actions, you can store sensitive values at the repository, environment, or organization level:

• Repository secrets: Navigate to your repository's Settings, select Secrets and variables under the Security section, click Actions, and choose New repository secret (or run gh secret set SECRET_NAME via the GitHub CLI).
• Organization secrets: Organization owners can manage shared outbound mail credentials under organization Settings -> Secrets and variables -> Actions, applying access policies so only specific or private repositories can use them.
• Workflow reference: Pass the stored values into your mail step via the secrets context (for example, ${{ secrets.SMTP_PASSWORD }}).

3. Mind the Security and Policy Guardrails​

Before rolling out a replacement notification workflow across an enterprise organization, keep several documented GitHub Actions security boundaries in mind:

• Write access equals secret access: GitHub's secure-use reference warns that any user with write access to a repository effectively has read access to all secrets configured in that repository. Use a dedicated, least-privilege mail account or API key scoped strictly to sending notifications—never your primary corporate Exchange or Microsoft 365 admin credentials.
• Avoid structured secret blobs: GitHub Docs advises against storing JSON, XML, or YAML blobs inside a single secret because structured data can cause automatic log redaction to fail. Create separate secrets for your SMTP username, password, and host, and manually inspect your workflow run logs after testing both valid and invalid inputs to verify nothing leaks to STDOUT or STDERR.
• Fork and Dependabot limitations: With the exception of GITHUB_TOKEN, secrets are not passed to workflow runners when a workflow is triggered from a forked repository, nor are they available to workflows triggered by Dependabot events.
• Action allowlists and SHA pinning: Repository and organization administrators can disable GitHub Actions altogether or restrict which third-party actions are allowed to run. If you use a community-maintained SMTP action from the GitHub Marketplace rather than a custom script, GitHub's security documentation recommends auditing the action's source code and locking workflow dependencies with a lockfile or pinning the action to a full-length commit SHA rather than a mutable tag.

Summary Checklist for Repository Admins​

Retiring legacy features is rarely glamorous, and it inevitably breaks a few decade-old scripts and habits. Still, shutting down an unverified email relay is a sensible move for platform hygiene. Take ten minutes this week to check whether any of your team's repositories were still counting on native push emails, set up a scoped GitHub Actions workflow if you still need them, and enjoy knowing one more avenue for inbox spam has been welded shut.