Main Header

Email for SignalPress

Updated on July 30, 2026

Use Settings to configure delivery thresholds and payload options, Routing to set recipients, subjects, event filters, and message templates, Logs to inspect delivery history, and Help for this guide. Routing requires Tier 1; Tier 2 adds request rules and Message templates. Log visibility, payload previews, and deletion can be delegated separately with Tier 2 role permissions.

Send signals to Email when your team should receive an HTML alert in their inbox.

Email is a free SignalPress service that sends HTML event alerts through WordPress wp_mail().

Hub service ID: email. Index: Integrations Overview. Target from PHP: Service Targeting.

SignalPress does not manage SMTP or provider credentials. WordPress uses the web server's mail transport by default; an SMTP or transactional-mail plugin can replace that transport without any SignalPress changes.

Setup

  1. Configure and test WordPress email delivery, preferably with an SMTP or transactional-mail plugin.
  2. Activate Email on the SignalPress Integrations page.
  3. Open the Email page and go to Routing. Recipients default to the WordPress site admin email until you change them.
  4. Select a severity threshold on Settings and whether to include the formatted payload.
  5. Enable the service, save, and send a test signal.

wp_mail() returning success means WordPress accepted the message for delivery. It does not guarantee inbox delivery.

Settings

FieldPurpose
Minimum LevelService-level gate inside delivery. Default: warning.
Signal payloadInclude formatted JSON in the email body. Default: on.

Delivery thresholds

SignalPress applies two independent level checks for Email:

  1. Routing → Routing Minimum Level (Tier 1+) — filters events before they are offered to Email.
  2. Settings → Minimum Level — final gate inside the Email service (also applies to Single Message fallback when using message templates).

An event must pass both before SignalPress sends the signal. In Message templates mode, per-template event filters and request rules run instead of the global routing evaluator for matched rows.

Improve deliverability with DNS authentication

Messages sent directly by a web server are commonly filtered when the visible From domain is not authenticated. For dependable delivery, use an SMTP or transactional-mail provider and publish the DNS records that provider gives you. SignalPress uses wp_mail(), so an SMTP plugin can improve transport and authentication without changing SignalPress.

The important records are:

  • SPF authorizes the servers allowed to send mail for the envelope-sender domain. Publish the exact TXT value supplied by your host or mail provider. A schematic example is shown below; do not copy its placeholder:

“`dns

@ TXT “v=spf1 include:YOUR-MAIL-PROVIDER.example -all”

“`

A domain should have one SPF policy. If one already exists, merge the provider's authorized sender into that policy instead of adding a second v=spf1 record. Include every legitimate sender for the domain, such as the website mail service, help desk, newsletter system, and business mailbox provider.

  • DKIM lets the sending service cryptographically sign messages. The provider normally supplies a selector and either a TXT record containing its public key or a CNAME pointing to a provider-managed key. For example:

“`dns

selector1._domainkey CNAME selector1.your-account.mail-provider.example.

“`

The selector and destination are provider-specific. DKIM cannot be enabled by inventing this record; the sending service must possess and use the corresponding private key.

  • DMARC tells receiving systems how to evaluate messages that fail aligned SPF and DKIM checks and can send aggregate reports. A cautious starting record is:

“`dns

_dmarc TXT “v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r”

“`

Replace the reporting mailbox with one prepared to receive DMARC XML reports. Start with p=none, review reports, correct every legitimate sender, and then consider moving gradually to p=quarantine and p=reject. Publishing a strict enforcement policy before all senders are aligned can block valid mail.

DMARC passes when at least one successful SPF or DKIM identity aligns with the domain in the visible From address. Authentication that passes for an unrelated hosting or provider domain may still fail DMARC alignment. Configure the SMTP provider and WordPress From address to use a domain the provider has verified, rather than an arbitrary address such as a personal Gmail account.

If mail is sent directly from the site's IP address rather than through an SMTP provider, ask the hosting company to configure valid forward and reverse DNS (PTR) for the mail host. PTR records are controlled by the IP owner and usually cannot be added in the website's normal DNS zone. The server should also identify itself with a matching hostname and use TLS. Shared web-hosting IP reputation can still cause filtering even when the records are technically correct.

After changing DNS, send a fresh test message and inspect its raw headers for spf=pass, dkim=pass, and dmarc=pass. DNS authentication improves identity and reputation signals but does not guarantee inbox placement; content, complaint rates, sending history, IP reputation, and recipient behavior also matter.

References: [WordPress wp_mail() documentation](https://developer.wordpress.org/reference/functions/wp_mail/), [DMARC specification](https://www.rfc-editor.org/rfc/rfc9989.html), [SPF specification](https://www.rfc-editor.org/rfc/rfc7208.html), [DKIM specification](https://www.rfc-editor.org/rfc/rfc6376.html), and [Google's email sender guidelines](https://support.google.com/mail/answer/81126).

Send a signal

PHP

sp_capture(
    'backup_failed',
	[
        'message' => 'The nightly database backup failed.',
        'level'   => 'error',
	],
	[ 'source' => 'backup-worker', 'services' => [ 'email' ] ]
);

Recognized levels are debug, info, warning, error, and critical. Missing or invalid levels are treated as info.

Emails contain a compact event summary and, when enabled, an escaped 

 block with pretty-printed JSON. Keys resembling passwords, tokens, secrets, API keys, authorization values, or cookies are redacted. Rendered payloads are limited to 20,000 characters.





Filters: signalpress/email/subject, signalpress/email/html, and signalpress/email/payload.





Routing





The Routing tab controls which events Email sends and, on Tier 2, how each message is composed. Tier 1 adds event filters. Tier 2 adds request rules and a choice between Single Message and Message templates.





Routing method (Tier 2)





Tier 2 sites select one active method. Both configurations are saved; only the selected method runs at delivery time. Switching methods does not delete the other configuration.





  • Single Message -- one shared recipients field, subject, delivery conditions, and built-in layout for every email.
  • Message templates -- unlimited conditional rows evaluated top to bottom. Each row has its own event filters, request rules, recipients, subject, and custom HTML body with tokens.





Sites below Tier 2 use Single Message only and see a locked preview of message templates with an upgrade call to action.





Single Message





When Single Message is selected, configure on the Routing tab:





  • Recipients and Subject -- who receives the email and what appears in the subject line. Leave Subject blank to use the event name. Insert tokens such as {{ event_label }} or {{ level }}.
  • Delivery conditions -- event filters (Tier 1+) and request rules (Tier 2)





All signals that pass these conditions use the built-in email layout configured under Settings (minimum level and payload options).





Message templates (Tier 2)





When Message templates is selected:





  • Add unlimited template rows. Each row has four tabs: Event Filters, Rules, Subject, and Message.
  • Subject tab -- optional recipients and subject for that template. Blank recipients use the Single Message recipients. Blank subject uses the event name.
  • Drag rows to reorder them. Order matters when First matching template is selected.
  • Insert message tokens such as {{ user_display_name }}, {{ summary_table }}, and {{ payload_json }} using the token picker on the Message tab.
  • Choose First matching template (one email per event) or All matching templates (one email per matching row).
  • Enable Send a Single Message when no template matches to fall back to the Single Message recipients, subject, delivery conditions, and built-in layout instead of skipping the email.
  • If no template matches and fallback is disabled, no email is sent.





Message token list is filterable via signalpress/template_tokens. Subject token list is filterable via signalpress/subject_tokens.





Match behavior





  • First matching template -- evaluates rows from top to bottom and sends one email using the first row that matches.
  • All matching templates -- sends one email for every row that matches the event.