diff --git a/docs/docs/documentation/getting-started/authentication/oidc-v2.md b/docs/docs/documentation/getting-started/authentication/oidc-v2.md
index ccfef3f91..d63ce757c 100644
--- a/docs/docs/documentation/getting-started/authentication/oidc-v2.md
+++ b/docs/docs/documentation/getting-started/authentication/oidc-v2.md
@@ -20,6 +20,21 @@ Signing in with OAuth will automatically find your account in Mealie and link to
 
 If a user previously accessed Mealie via credentials and you want to no longer allow users to log in with `LDAP` or `Mealie` credentials, then you can set the user's *Authentication Method* to `OIDC`. Conversely, if a user's auth method is not `OIDC`, then they can still log in with whatever their auth method is as well as OIDC.
 
+### Email Verification
+
+:octicons-tag-24: v3.21.0
+
+!!! warning "Breaking change in v3.21.0"
+    Mealie now requires your IdP to assert that the user's email address is verified. If your IdP does not emit the `email_verified` claim, logins will fail until you either configure the claim or set `OIDC_REQUIRES_EMAIL_VERIFICATION=false`.
+
+Because Mealie links an OIDC login to an existing account by matching on a claim (`OIDC_USER_CLAIM`, `email` by default), an IdP that lets a user self-assert an arbitrary, unverified email address would allow that user to log into someone else's Mealie account simply by claiming their email. To prevent this, Mealie requires the `email_verified` claim to be present and `true` before authenticating.
+
+Most identity providers (Authentik, Authelia, Keycloak, Google, Entra ID, ...) emit this claim as part of the `email` scope, and require no changes. If a login is rejected for this reason, the following is written to the server logs:
+
+    [OIDC] email_verified claim is missing or false; refusing to authenticate
+
+If your IdP cannot emit the claim, you can opt out by setting `OIDC_REQUIRES_EMAIL_VERIFICATION` to `false`. Only do this if you trust your IdP to not allow users to set an arbitrary email address on their own.
+
 ## Provider Setup
 
 Before you can start using OIDC Authentication, you must first configure a new client application in your identity provider. Your identity provider must support the OAuth **Authorization Code flow with PKCE**. The steps will vary by provider, but generally, the steps are as follows.
@@ -50,6 +65,8 @@ Before you can start using OIDC Authentication, you must first configure a new c
 
     The scopes required are `openid profile email`
 
+    The `email` scope is also what grants the `email_verified` claim required for [email verification](#email-verification)
+
     If you plan to use the [groups](#groups) to configure access within Mealie, you will need to also add the scope defined by the `OIDC_GROUPS_CLAIM` environment variable. The default claim is `groups`
 
 ## Mealie Setup
diff --git a/docs/docs/documentation/getting-started/installation/backend-config.md b/docs/docs/documentation/getting-started/installation/backend-config.md
index 7a8650127..4318a3b86 100644
--- a/docs/docs/documentation/getting-started/installation/backend-config.md
+++ b/docs/docs/documentation/getting-started/installation/backend-config.md
@@ -101,7 +101,7 @@ For usage, see [Usage - OpenID Connect](../authentication/oidc-v2.md)
 | ----------------------------------------------------------------------------------- | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | OIDC_AUTH_ENABLED                                                                   |  False  | Enables authentication via OpenID Connect                                                                                                                                                                                                                                                              |
 | OIDC_SIGNUP_ENABLED                                                                 |  True   | Enables new users to be created when signing in for the first time with OIDC                                                                                                                                                                                                                           |
-| OIDC_REQUIRES_EMAIL_VERIFICATION                                                    |  True   | Requires the `email_verified` claim to be true before a user can sign in. This prevents an unverified email from being used to match an existing account. Only disable this if your identity provider does not emit the `email_verified` claim.                                                          |
+| OIDC_REQUIRES_EMAIL_VERIFICATION <br/> :octicons-tag-24: v3.21.0                    |  True   | Requires the `email_verified` claim to be true before a user can sign in. This prevents an unverified email from being used to match an existing account. Only disable this if your identity provider does not emit the `email_verified` claim. For more information see [this page](../authentication/oidc-v2.md#email-verification)                    |
 | OIDC_CONFIGURATION_URL<super>[&dagger;][secrets]</super>                            |  None   | The URL to the OIDC configuration of your provider. This is usually something like https://auth.example.com/.well-known/openid-configuration                                                                                                                                                           |
 | OIDC_CLIENT_ID<super>[&dagger;][secrets]</super>                                    |  None   | The client id of your configured client in your provider                                                                                                                                                                                                                                               |
 | OIDC_CLIENT_SECRET<super>[&dagger;][secrets]</super> <br/> :octicons-tag-24: v2.0.0 |  None   | The client secret of your configured client in your provider                                                                                                                                                                                                                                           |
diff --git a/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_1_oidc-email-verification.vue b/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_1_oidc-email-verification.vue
new file mode 100644
index 000000000..dfbfd2f88
--- /dev/null
+++ b/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_1_oidc-email-verification.vue
@@ -0,0 +1,64 @@
+<template>
+  <div>
+    <p>
+      If your server signs users in with an external identity provider (OIDC), Mealie now requires that
+      provider to confirm the user's email address before allowing the login.
+    </p>
+    <p>
+      This prevents an unverified, self-asserted email address from being used to match (and sign in) to
+      an existing Mealie account.
+    </p>
+    <div v-if="user?.admin">
+      <hr class="mt-2 mb-4">
+      <p>
+        As an admin, be aware that this is a <strong>breaking change</strong> for identity providers that do
+        not emit the <code>email_verified</code> claim. Those logins now fail, and
+        <code>[OIDC] email_verified claim is missing or false</code> is written to the server logs.
+      </p>
+      <div class="mb-2">
+        You have two options:
+        <ul class="ml-6">
+          <li>Configure your identity provider to include the <code>email_verified</code> claim (recommended)</li>
+          <li>Set <code>OIDC_REQUIRES_EMAIL_VERIFICATION=false</code> to restore the previous behavior</li>
+        </ul>
+      </div>
+      <p>
+        Most providers (Authentik, Authelia, Keycloak, Google, Entra ID, ...) send this claim already and are
+        unaffected. See the OIDC docs for details:
+        <br>
+        <v-btn
+          class="mt-2"
+          color="primary"
+          href="https://docs.mealie.io/documentation/getting-started/authentication/oidc-v2/#email-verification"
+          target="_blank"
+        >
+          OpenID Connect (OIDC)
+        </v-btn>
+      </p>
+    </div>
+    <div v-else>
+      <p>
+        If you can no longer sign in with your external account, contact your server admin. They may need to
+        update the server's OIDC configuration.
+      </p>
+    </div>
+  </div>
+</template>
+
+<script setup lang="ts">
+import type { AnnouncementMeta } from "~/composables/use-announcements";
+
+const { user } = useMealieAuth();
+</script>
+
+<script lang="ts">
+export const meta: AnnouncementMeta = {
+  title: "OIDC logins now require a verified email",
+};
+</script>
+
+<style scoped lang="css">
+p {
+  padding-bottom: 8px;
+}
+</style>
diff --git a/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_2_scraper-proxy-flaresolverr.vue b/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_2_scraper-proxy-flaresolverr.vue
new file mode 100644
index 000000000..9ea063236
--- /dev/null
+++ b/frontend/app/components/Domain/Announcement/Announcements/2026-07-27_2_scraper-proxy-flaresolverr.vue
@@ -0,0 +1,71 @@
+<template>
+  <div>
+    <p>
+      Importing recipes from a URL is now more reliable. Mealie does a better job of looking like a real
+      browser, rotates between several browser signatures, and retries more intelligently when a site
+      pushes back. This works out of the box, with no configuration.
+    </p>
+    <p>
+      Some sites sit behind bot protection (such as Cloudflare) that blocks requests made by a server, no
+      matter how they're made. For those, Mealie can now optionally fall back to two extra layers.
+    </p>
+    <div class="mb-2">
+      <ul class="ml-6">
+        <li>
+          <strong>Proxy support</strong>, which routes recipe and image requests through a proxy. This
+          helps with sites that block your server's IP address.
+        </li>
+        <li>
+          <strong>FlareSolverr support</strong>, which hands the page to a real headless browser as a last
+          resort. This helps with challenges that Mealie can't get past on its own.
+        </li>
+      </ul>
+    </div>
+    <div v-if="user?.admin">
+      <hr class="mt-2 mb-4">
+      <p>
+        Both are optional and off by default, so nothing changes unless you configure them. Mealie
+        escalates only as far as it needs to for each import: a direct fetch first, then the proxy (if
+        set), then FlareSolverr (if set, and only when the page is still blocked).
+      </p>
+      <p>
+        Both are enabled with environment variables. Mealie does not ship or manage either one. You supply
+        the proxy, and host FlareSolverr yourself (it runs nicely as a sidecar container). See the
+        configuration docs for the settings, setup details, and an example compose file:
+        <br>
+        <v-btn
+          class="mt-2"
+          color="primary"
+          href="https://docs.mealie.io/documentation/getting-started/installation/backend-config/#recipe-scraper"
+          target="_blank"
+        >
+          Backend Configuration
+        </v-btn>
+      </p>
+    </div>
+    <div v-else>
+      <p>
+        If a recipe URL still refuses to import, let your server admin know. They can enable these extra
+        options on the server.
+      </p>
+    </div>
+  </div>
+</template>
+
+<script setup lang="ts">
+import type { AnnouncementMeta } from "~/composables/use-announcements";
+
+const { user } = useMealieAuth();
+</script>
+
+<script lang="ts">
+export const meta: AnnouncementMeta = {
+  title: "Better recipe imports, with proxy and FlareSolverr support",
+};
+</script>
+
+<style scoped lang="css">
+p {
+  padding-bottom: 8px;
+}
+</style>