Email sending

Request emails are sent through your own email provider. You connect an account you already have with an API key, and every request email of the site leaves through it: from your own address, with replies coming to you.

Privatus Analytics never sends a request email from an address of its own. Until a provider is connected, nothing is sent.

It is under Testimonials in the site's sidebar, then Settings, then Email sending. It needs the sites.manage permission and the Business plan. Sharing a form's link, embedding it, the popup and the QR code work on every plan and need no email provider.

What you need#

• An account with one of the five providers below, with a sender address or a sending domain that the provider has verified.
• An API key of that account. Each provider's section says where to find it and which permissions it needs.
• A postal address. It is shown in the footer of every email, because email laws such as CAN-SPAM ask a sender to give one.

Connect a provider#

Connect a provider opens one form.

Check and connect asks your provider whether the key works and, where the provider can tell us, whether the From address is verified. No email is sent for this. If the provider refuses the key, the page says what it said and nothing is stored.

The key is stored encrypted. It is never shown again: the page shows its last four characters only. To change it, choose Edit and paste a new one. Leaving the key field empty keeps the stored key.

Connecting is done in the web app only. There is no API operation and no MCP tool for it, and an API token cannot connect, change, test or disconnect a provider.

The page#

• Send a test sends one short email through your provider to your own address, and to nobody else. It shows the From, the reply address and the footer as every request email will have them.
• Check again asks the provider whether the connection works.
• Edit changes the sender details or the key.
• Disconnect deletes the stored key for good. Request emails that are queued or scheduled wait until a provider is connected again. Nobody is dropped.

What is sent and what is read#

Your email provider works for you, under your own agreement with it. It is not a subprocessor of Privatus Analytics.

Open and click tracking of the provider is switched off for these emails where the provider lets a sender do so (Postmark, SendGrid, Mailgun). Opens are counted by our own small image, which records no IP address and no device. See what the open counter records.

The monthly limit#

Each site can send 10,000 request emails a month through its provider. Every request email counts, first emails and follow-ups. A test does not.

At the limit, sending for the site waits until the 1st of the next month and then continues by itself. Nobody is dropped. The Requests tab and this page say so, with the date.

The limit is set by us for each site, and you can see it on this page. To raise it, write to [email protected].

Your provider has limits of its own. When it says an email cannot be taken right now (a rate limit, a daily quota), that email is tried again later.

Bounces and spam complaints#

We ask your provider for recent hard bounces and spam complaints about every 15 minutes, with the same key, and only while the site has sent request emails lately.

A bounce or complaint about a request email does what it has always done: the person is marked Bounced and gets no further email, and after a hard bounce or a complaint the address goes on the opt-out list for every workspace. See Bounces.

A key that can send and cannot read bounces still works. The page then says "This key cannot read bounces", and a bounce is not seen here. Use a key with the permissions listed for your provider to avoid that.

When the connection stops working#

A connection is paused when your provider says that nothing will get through until someone acts:

• the key is refused (deleted, replaced or not active),
• the key is no longer allowed to send,
• the From address or its domain is no longer verified,
• the provider closed or suspended the account, or has not approved it.

While it is paused, nothing is attempted through it. The site's request emails wait. They are not sent from another address, and nobody is dropped. The member who connected the provider and the workspace's owner get an email saying which site, which provider and why.

Fix it with your provider, or paste a new key under Edit, then press Check again. The emails that waited go out, within the monthly limit.

These do not pause a connection: a rate limit, a provider outage, and one address the provider will not send to. The first two are tried again later. The last is recorded on that one email.

Amazon SES#

Use an IAM user made for this, in the AWS region you send from.

The policy the user needs. These are the actions used, and no other:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ses:SendEmail",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ses:GetAccount",
        "ses:GetEmailIdentity",
        "ses:ListSuppressedDestinations"
      ],
      "Resource": "*"
    }
  ]
}

• ses:SendEmail sends. AWS documents it together with ses:SendRawEmail without saying whether this kind of email needs both. If AWS refuses to send with this policy, add ses:SendRawEmail to the first statement.
• ses:GetAccount and ses:GetEmailIdentity are how the key and the From address are checked without sending.
• ses:ListSuppressedDestinations reads bounces and complaints. Without it emails are still sent, and bounces are not seen.

Amazon SES has no list of bounces. We read your account-level suppression list, which holds the addresses that hard bounced or complained. It must be enabled: in the SES console, under Configuration, Suppression list, Account-level settings, with both reasons ticked. Accounts opened after November 25, 2019 have it on by default. Gmail does not report spam complaints to Amazon SES, so those are not seen.

An account still in the SES sandbox can only send to verified addresses. Such a recipient is recorded as not sent, and the connection keeps working.

Postmark#

Postmark has one kind of server token, which sends and reads bounces. There is no send-only token. Use a server of its own for request emails if you want to keep them apart from your other mail.

The From address must be a confirmed Sender Signature, or at a domain you verified in Postmark.

SendGrid#

Choose Custom Access and switch on:

• Mail Send (the scope mail.send), to send,
• Suppressions (the scopes suppression.bounces.read, suppression.blocks.read and suppression.spam_reports.read), to read bounces and complaints.

A key with only Mail Send works, and bounces are then not seen.

The From address must match a verified Sender Identity or an authenticated domain.

Mailgun#

Use an account API key, or on plans with roles a key with the Developer role. A Domain Sending Key does not work here: it can only send, so it cannot be checked when you connect and cannot read bounces.

The From address should be at the sending domain, and the domain must be active in Mailgun.

Resend#

Choose Full access so bounces and complaints can be read. A key with Sending access works, and bounces are then not seen.

The From address must be at a domain you verified in Resend.

Good to know#

• One provider per site. Another site of the workspace has its own connection and its own monthly limit.
• On a plan without email sending a connection is kept and not used. Request emails wait, and the page says so.
• The unsubscribe link and the opt-out list are ours and work the same with every provider. An address on the opt-out list is never sent to, through any provider.
• A purchase connection asks buyers with request emails, so it needs a provider connected here too.