Email delivery & DKIM

Why deliverability matters

Anyone who has ever lost a sales lead to the spam folder knows: sending an email is easy, getting it to the inbox is hard. Modern mailbox providers (Gmail, Outlook, Apple Mail) decide what reaches the inbox based on the authentication signals attached to the message:

• SPF — does the sending IP belong to a list the domain has authorized?
• DKIM — is the message cryptographically signed by the sending domain?
• DMARC — does the domain owner instruct receivers what to do if SPF and DKIM fail?

If all three align, the message goes to the inbox. If they don’t, it gets spam-foldered or rejected outright. SecureSMTP handles all of this for you on our domain by default; if you want your own domain in the From: header, you set DKIM up once and we handle it from there.

Default: send via SecureSMTP (zero setup)

Out of the box, notifications come from [email protected], with Reply-To set to the visitor’s email. SPF, DKIM, and DMARC are all configured on our sending domain — Gmail and Outlook accept us cleanly. No DNS changes on your side.

Trade-off: the From: address says [email protected]. If you reply from your inbox it still reaches the visitor (Reply-To handles that), but the visitor sees “SecureSMTP” as the sender of the original notification, not your brand. For most internal inbox notifications that’s fine; if you want stronger branding, set up a custom domain.

Custom domain via DKIM

Adding a custom domain lets SecureSMTP send From: [email protected] while keeping all the deliverability guarantees of the default setup. You give us authorization to sign on behalf of your domain via a DKIM DNS record; we never get your inbox or your mail credentials.

1. In SecureSMTP dashboard: /app/forms/email → Add sending domain.
2. Enter your domain (e.g. yourbrand.com) and click Generate records.
3. SecureSMTP shows you 3 DNS records to add (DKIM, SPF, DMARC) — see the next section.
4. Add the records in your DNS provider (Cloudflare, GoDaddy, Route 53, etc.).
5. Back in SecureSMTP, click Verify. Verification typically completes in 30 seconds — DNS providers occasionally take a few minutes.
6. Once verified, set the new domain as your default sender. Notifications start coming From: your domain on the next submission.

The three DNS records

SecureSMTP generates these for your specific domain on the sending-domain page using Resend as the email infrastructure. The shape is always the same — Resend will give you the exact selector name and host values to copy. The example below shows the general structure; the actual selector you'll paste comes from your sending-domain dashboard, not from this example.

• Already have an SPF record? Don’t add a second one — merge by inserting include:_spf.securessmtp.com into the existing record. Two SPF records on the same name invalidate each other.
• Already have a DMARC record? Leave it alone — adding SecureSMTP-aligned DKIM and SPF is enough. We honour whatever policy you’ve set.
• TTL doesn’t matter — set whatever your DNS provider defaults to. Verification checks DNS once, then we cache the result.

In-WP status panel

The plugin includes a live status panel that shows whether each piece of the delivery stack is healthy on your site.

Find it at QCS Forms → Email Delivery. The panel shows:

• Sending domain — which domain SecureSMTP will use to send (securessmtp.com or your custom one).
• SPF / DKIM / DMARC — three small checkboxes, green when the DNS records resolve correctly.
• Recent delivery — the last 10 outbound messages with status (Delivered, Soft bounce, Hard bounce, Complained).
• Bounce rate — rolling 7-day percentage. Anything above 5% is worth investigating.

If a record breaks (TTL expires, you accidentally remove a CNAME), the corresponding checkbox turns red and the panel surfaces a one-line explanation of how to fix it.