Newsletter delivery (add-on)

The addresses this store will never mail again, whatever any list or import says about them, with why each one is here and when. The audience of every campaign is checked against this table before a single row is written. A row whose address reads as erased belonged to somebody who asked to be forgotten: the hash stays so the address is still never mailed.

Tell the store never to mail an address again, for somebody who asked directly rather than through a link. The subscriber's own status is written at the same time, so the screens and the sender cannot disagree. The reason has to be "manual" or "invalid" — a bounce and a complaint are facts a mail provider reports and the store records them itself, and typing one by hand would be writing evidence that never arrived.

Remove one suppression, addressed by the SHA-256 of the address — which is how the row is keyed, because that is the half that survives an erasure. Only do this when you know why the address landed there: mailing one that complained is how a store loses its sending reputation. The subscriber's own status is left alone on purpose, so removing a suppression does not quietly resubscribe anybody.

Nine checks over the store's sending setup, each with a status, a sentence saying what is true and a sentence saying what to do about it. The domain group is SPF, DKIM, DMARC and the from address, read live from DNS; the transport group is whether a campaign carries a plain-text part, whether the one-click unsubscribe headers survive the transport in use, whether the sending throttle is sane and whether the provider's webhook is configured and has been heard from; the list group is the bounce and complaint rates over the last thirty days against the thresholds Gmail publishes. Run this when a merchant says their mail lands in spam, when a campaign's delivered count looks wrong, or before a store sends its first real campaign. Answers are cached for ten minutes; anything reported as still checking means a lookup had not come back, and asking again a moment later returns it.

Throw away the cached DNS answers and look everything up again. Use it after a merchant has changed a DNS record — an SPF include added, a DKIM selector published, a DMARC policy moved off none — because the ordinary read would otherwise answer with what was true up to ten minutes ago. It makes real DNS queries and, on a store whose transport can be asked, one API call to that provider, so it is not something to run in a loop.

Mints a fresh random path secret for one of the seven email providers (smtp2go, ses, postmark, mailgun, sendgrid, resend or mailersend), writes it into the plugin's configuration, and answers the whole webhook URL to paste into that provider's dashboard. The secret is what tells a genuine event from a stranger who guessed the address, and on SMTP2GO, which signs nothing, it is the only thing that does. Generating a new one silently stops the old URL working, so a provider already pointed at the previous secret has to be updated or its events are dropped.

Registers this store's webhook URL with the provider through its own API, for the delivered, bounce, spam complaint, open and click events, using the API key already in that provider's transport settings, so a merchant does not have to find the right screen in somebody else's dashboard. Whether a provider can is its own answer: SMTP2GO, SendGrid, Mailgun, Resend, MailerSend and Amazon SES (ses) can with the key on file, and Postmark can once its server token is in. One that cannot answers with a refusal naming the manual steps instead. Generate a secret first, because there is no URL to register without one. When it works, and the provider is the one the site sends through, one test message goes out through the site's own transport (to the provider's own test address where it has one, otherwise to the store's From address, never to a subscriber), and the answer's test says where it went; the Settings card then shows whether its event came back.

Sends one small test message through the site's own transport to check that the provider's webhook reports back, the same as the Send a test button on the provider's Settings card. It goes to the provider's own test address where its plugin names one (which nobody receives), otherwise to the store's From address, never to a subscriber. Only the provider the site sends through can be tested, there must be a webhook secret, and one test a minute per provider. The answer's test says where it went and starts as waiting; ask get_provider_webhook_test for what came back.