Privacy Policy

Last updated: 2026-07-11

This Privacy Policy describes how Emerge Mail (the "Service") handles information while assisting a WordPress site administrator in authorizing the Emerge Mail WordPress plugin to send email on their behalf. The plugin supports seven email providers; this Service is only involved in the OAuth authorization handshake for the two OAuth-based providers — Gmail and Microsoft 365.

1. Role of the Service

The Service is an OAuth broker. It receives an authorization code from Google or Microsoft after the user grants consent, exchanges that code for tokens, and returns the tokens directly to the requesting WordPress site. The Service does not act as a controller of the user's email data.

The plugin also supports five additional providers — SendGrid, Mailgun, Amazon SES, Brevo, and Generic SMTP — where the user supplies an API key or SMTP credentials directly. Those providers are out of scope for this Service: credentials are entered into the WordPress site and used by the plugin to talk directly to the provider. No part of the request transits this Service.

2. Data we process

During an OAuth authorization flow the Service briefly handles the following:

• The OAuth authorization code returned by Google or Microsoft.
• The PKCE verifier and state value generated by the WordPress site.
• The resulting access token, refresh token, the stable Google account identifier (the OpenID Connect sub claim) where applicable, and the primary email address of the connected mailbox, solely to forward them to the WordPress site that initiated the flow.

The Service may also process standard request metadata (such as IP address and user-agent) for the duration of an HTTP request for the purposes of security, rate limiting, and abuse prevention.

3. Data we do not store

• We do not persist OAuth access or refresh tokens.
• We do not persist authorization codes or PKCE state after the exchange completes.
• We do not maintain a database of users, mailboxes, or sites.
• We do not read, transmit, or retain the contents of any email message.
• We do not receive or process API keys or SMTP credentials supplied for the bring-your-own-key providers.

All tokens issued through this Service are stored exclusively in the database of the WordPress site that requested them, encrypted with a key generated by that site. From the point of token delivery onward, communication with Gmail or Microsoft Graph occurs directly between that WordPress site and the email provider — the Service is not in the request path.

4. Google user data and OAuth scopes

When a site administrator authorizes the Emerge Mail WordPress plugin to send email through Gmail, we request only the minimum OAuth scopes required for that single feature. The sections below describe each scope, the specific Google user data it grants access to, and exactly how that data is used, stored, and shared.

openid

Google's description: Associate you with your personal info on Google.

Data accessed: A stable Google account identifier (the OpenID Connect sub claim returned in the ID token), along with the standard claims Google issues in the ID token (issuer, audience, issued-at and expiry timestamps).

How we use it: Solely to identify the authenticated Google account during the OAuth handshake so the resulting tokens can be matched to the correct mailbox on the WordPress side. The identifier is forwarded to the WordPress site that initiated the flow as part of the OAuth response and is not retained by the Service.

How we store and share it: Not stored on our servers. Not shared with any third party. Stored only inside the user's own WordPress database alongside the corresponding mailbox record.

https://www.googleapis.com/auth/userinfo.email

Google's description: See your primary Google Account email address.

Data accessed: The primary email address of the authenticated Google account, and the boolean flag indicating whether Google has verified that address.

How we use it: The email address is returned to the WordPress site so the plugin can label the connected mailbox in its admin UI (for example, "Connected: alice@example.com") and so the plugin can use it as the From address when later calling Gmail's users.messages.send endpoint. The Service does not log, store, or share this email address beyond passing it through the OAuth response to the WordPress site that initiated the flow.

How we store and share it: Not stored on our servers. Not shared with any third party. Stored only inside the user's own WordPress database, encrypted at rest using a key generated by that WordPress site.

https://www.googleapis.com/auth/gmail.send

Google's description: Send email on your behalf.

Data accessed: Permission to invoke the Gmail API method users.messages.send as the authenticated user. This scope does not grant access to read existing messages, drafts, labels, threads, mailbox settings, contacts, or any other Gmail data; it is write-only and limited to creating new outbound messages.

How we use it: The Service itself never calls the Gmail API. It performs the OAuth authorization code exchange and returns the access token and refresh token that carry this scope to the WordPress site that initiated the flow. From that point on, the WordPress plugin running on the user's own WordPress server calls users.messages.send directly, using only those locally stored tokens, to deliver outbound messages that the WordPress site itself has composed — password resets, comment notifications, WooCommerce order receipts, contact-form submissions, and any other wp_mail() call. The Service is never in the request path for any individual email. We do not call gmail.readonly, gmail.compose, gmail.modify, gmail.metadata, or any other Gmail scope, and we do not request any additional Google API scope of any kind.

How we store and share it: The tokens that carry this scope are not stored on our servers. They are returned to the requesting WordPress site, where they are stored encrypted at rest in that site's own database. They are not shared with any third party.

Limited Use compliance

The Service's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• Google user data is used only to provide and improve the user-facing feature of authorizing the WordPress plugin to send mail on the user's behalf, as described above.
• We do not use Google user data to serve advertisements, including retargeted, personalized, or interest-based advertising.
• We do not allow humans to read Google user data, except (a) with the user's affirmative consent, (b) where necessary for security purposes (such as investigating abuse), or (c) to comply with applicable law.
• We do not transfer Google user data to third parties except as necessary to provide or improve the feature described above, to comply with applicable law, or as part of a merger, acquisition, or sale of assets where the user has been notified.
• Google user data is not used or transferred for any purpose unrelated to the single user-facing feature described above.
• We do not sell Google user data under any circumstance.
• We do not use Google user data to train, fine-tune, or evaluate any machine-learning or AI model — generalized or personalized.

5. Use of Microsoft account data

Where the user authorizes via Microsoft, the same principles apply: tokens are returned to the WordPress site and not retained by the Service, and no Microsoft account data is read or used for any purpose other than completing the OAuth handshake.

6. Bring-your-own-key providers

The plugin supports five additional providers where authentication is by an API key or SMTP credentials supplied directly by the user: SendGrid, Mailgun, Amazon SES, Brevo, and Generic SMTP. For these providers:

• The credentials are entered into the WordPress admin UI and stored encrypted in the WordPress site's own database, using a key generated by that site on first activation.
• The WordPress site sends messages directly to the provider's API or SMTP endpoint. The Service is never involved in the request path.
• The Service does not see, process, or retain those credentials, and never has access to messages sent through them.
• Each provider's own privacy policy and terms govern that provider's handling of the messages your site submits to it.

7. Cookies and tracking

The Service does not set marketing or analytics cookies. It does not track users across sites.

8. Data retention

Authorization codes, PKCE verifiers, and tokens transit the Service in memory only and are discarded once the response is returned. Standard server access logs may be retained for a short period for operational and security purposes.

9. Revoking access

Because the Service does not store tokens, the user can revoke access at any time by:

• Disconnecting the mailbox inside the WordPress plugin's settings page (which deletes the locally stored tokens or credentials), and
• For OAuth providers, revoking the application from Google Account permissions or Microsoft account permissions.
• For API-key providers, rotating or revoking the credential in the corresponding provider dashboard (SendGrid, Mailgun, Amazon SES IAM, Brevo).

10. Security

The Service uses HTTPS in transit, PKCE for the OAuth authorization code flow, and standard hardening of its HTTP responses. No system is perfectly secure; users are responsible for keeping their WordPress installation up to date and protecting the credentials of administrator accounts.

11. Children

The Service is intended for use by site administrators and is not directed to children under 13.

12. Changes to this policy

We may update this policy from time to time. Material changes will be reflected by updating the "Last updated" date at the top of this page.

13. Contact

Questions about this policy can be sent to support@redigit.net.