Resources · Feature guides

Branded confirmation emails

Make every ticket confirmation arrive from your business, look like it came from your business, and land reliably in the inbox. Covers sender identity, deliverability, and what the customer actually sees.

  • You'll need: Site Calendar Pro 1.1.2+ and Lite 1.1.1.10+ for brand-colour matching (older versions use the legacy palette), a working SMTP setup, access to your domain DNS
  • Estimated time: 10 minutes for sender settings, 30 minutes if SMTP and DNS need configuring from scratch
  • Difficulty: Intermediate — DNS records and email authentication are involved

Why this matters

The ticket confirmation email is the single most important interaction your customer has with your site after paying. If it arrives from a generic wordpress@ address, lands in spam, or looks like a system-generated text dump, you lose trust at the exact moment the customer should feel reassured.

Site Calendar Pro sends a polished HTML confirmation by default — event card, QR code, ICS calendar attachment, ticket details — but the sender identity and deliverability are entirely down to your configuration. This guide walks through the four things that need to be right.

Important — emails won't send at all without SMTP. By default WordPress uses your hosting server's PHP mail() function, which most hosts either disable or rate-limit aggressively. Even when it works, those emails almost always land in spam because the sending IP has no authentication. Configure WP Mail SMTP (or an equivalent) before anything else in this guide.

Step 1 — Install and configure WP Mail SMTP

If you haven't already, install WP Mail SMTP from the WordPress plugins directory. The free version is sufficient for transactional email; the paid tiers add email logging and provider-specific integrations.

Pick a transactional email provider — these are services purpose-built for ticket confirmations, welcome emails, and order receipts. Three solid options:

  • Postmark — fast, simple, great deliverability. Free tier covers 100 emails/month, then £10–£15/month for higher volumes. Recommended for most sites.
  • Brevo (formerly Sendinblue) — free up to 300 emails/day, generous limits.
  • SendGrid — free up to 100 emails/day, widely supported by WP Mail SMTP.

Avoid using Gmail or Outlook personal accounts for transactional sending — both rate-limit aggressively and will start bouncing emails once your event sells more than a handful of tickets.

Sign up for your chosen provider, follow WP Mail SMTP's setup wizard to connect it. The wizard walks through API key entry and runs a deliverability test.

Step 2 — Configure SPF and DKIM on your domain

This is the step that determines whether your emails land in the inbox or spam folder. SPF and DKIM are DNS records that tell receiving mail servers "yes, this email really did come from getsitecalendar.com" — without them, Gmail and Outlook silently route your tickets to junk.

Both records are provider-specific. Postmark, Brevo, and SendGrid each give you copy-paste values in their dashboards after signup. Add them through your DNS provider's control panel:

  • SPF — a TXT record on your root domain (e.g., getsitecalendar.com) authorising the provider's mail servers to send on your behalf. Format: v=spf1 include:spf.postmark.io ~all (varies by provider).
  • DKIM — usually two CNAME records on a subdomain like 20231201._domainkey.getsitecalendar.com pointing to provider-supplied targets. These let receivers cryptographically verify the email's signature.

Wait 15 minutes to 24 hours for DNS propagation, then verify both records show green in your provider's dashboard. Use mxtoolbox.com as an independent check.

Skip SPF/DKIM and emails will land in spam. Stripe customer charges + WP Mail SMTP + missing DNS authentication is the most common cause of "I bought a ticket but didn't get a confirmation" complaints. There is no software-only fix — you have to add the records to your DNS.

Step 3 — Set the sender identity in Site Calendar Pro

In WordPress admin, go to Site Calendar → Settings → Tickets and scroll to the email section. Three fields control how the email appears in the customer's inbox:

  • From name — the display name shown in the inbox. Default: your site name. Use your trading name as customers recognise it (e.g., "Athletic RFC", not "WordPress").
  • From email — the sender address. Default: your WordPress admin email. Critical: this should use a domain you control and that has SPF/DKIM set up. A bookings@yourdomain.com or events@yourdomain.com address works well.
  • Reply-To address — where customer replies are routed. Useful when From is a noreply@ address but you still want a monitored mailbox to receive replies. Leave blank to default to the From email.

Click Save Settings.

If you see a domain mismatch warning after entering the From email — Site Calendar Pro flags this when the email's domain doesn't match the site's domain — that's the plugin warning you about future deliverability issues. Either move your transactional email to your site's own domain, or set up SPF/DKIM for the different domain you're using.

Step 4 — What the customer actually receives

With the settings above configured, here's what arrives in the customer's inbox after a successful ticket purchase:

  • A polished HTML email with a "Registration confirmed" header bar in your brand's primary colour
  • The customer's name and a one-line summary (e.g., "Your registration is confirmed: 2 × Standard entry for Bedfordshire v Hunts")
  • An event card showing the date, time, and venue with address
  • A QR code (220 × 220 px) the customer can scan at the door
  • An 8-character backup confirmation code for manual lookup if the QR fails
  • "View my ticket" and "Event page" buttons linking back to your site
  • An ICS calendar attachment that adds the event to Google Calendar, Outlook, or Apple Calendar with one click

The plain-text version is sent in parallel so customers on legacy email clients still get readable content.

The email matches your brand colours automatically. From Site Calendar Pro 1.1.2 (paired with Lite 1.1.1.10), the HTML email's header bar, accent rules and QR-code box use the Primary and Accent colours you've set under Site Calendar → Settings → Appearance. Change one in Appearance and the next confirmation email picks it up automatically. Older versions used a fixed dark-green / amber palette — that's now the fallback when no custom colours are set.

Step 5 — Send a test purchase and verify the result

Real-world testing beats checklists. Buy a £1 test ticket on your own site using a personal email address. Then check four things:

  1. The email arrives in the inbox, not spam. If it lands in spam, SPF or DKIM isn't set up correctly. Re-check Step 2.
  2. The sender display name is correct. Should match what you set in Step 3, not "WordPress" or your admin email's username.
  3. The QR code is visible in the email body, not blocked or rendered as an attachment. Some corporate email gateways strip inline images — if customers report blank QRs, the 8-character backup code is still in plain text below.
  4. The ICS attachment opens in your calendar app. Click it on your phone; should offer to add the event to Google Calendar or Apple Calendar.
If all four checks pass, you're done. Every future ticket purchase will get the same branded experience.

Resending a confirmation email

Customers misplace ticket emails. They reach inbox-zero too aggressively, archive without reading, or simply don't recognise the sender on a busy day. Site Calendar Pro 1.1.4 added a one-click resend tool so support staff can recover the situation in seconds without digging through email logs.

Where to find it: WordPress admin → Site Calendar → Events → [the event] → Attendees. Each attendee row shows a Resend email button alongside the existing Remove action.

What it does:

  • Sends a fresh copy of the original branded confirmation email, including the QR code, ICS attachment, and ticket details — exactly what the customer received originally.
  • Records a timestamp, the admin user who triggered the resend, and a counter against the attendee record (_pcal_last_resent_at, _pcal_last_resent_by, _pcal_resend_count).
  • Displays a count badge on the button after the first resend (e.g. a small "2" if the email has been resent twice) so multi-staff teams can see prior support actions at a glance.
  • Shows the last-resent timestamp on hover via the button's tooltip.

Rate limit: 30 seconds per attendee. If a second resend is attempted within that window, an amber "Wait a moment before resending again" notice appears and the duplicate send is suppressed. This prevents accidental double-clicks from spamming the customer's inbox.

What it does NOT do:

  • It does not regenerate the QR code or backup confirmation code — the customer's existing QR remains valid (resends are about delivery, not security rotation).
  • It does not modify the attendee record in any way other than the audit metadata above.
  • It does not bypass your SMTP or transactional email setup — if the original send failed because of deliverability problems, the resend will fail the same way. Use the resend as a first response to "I didn't get it", then check the email log if that doesn't help.

Troubleshooting

"Customer didn't receive the confirmation email"

First, resend it. Site Calendar Pro 1.1.4+ adds a one-click resend button to every attendee row, so before you start diagnosing SMTP you can immediately get a fresh copy of the email into the customer's inbox. Go to Site Calendar → Events → [event] → Attendees, find the customer's row, and click Resend email. The button shows a count badge if the email has been resent before — useful for support reps to see at a glance whether they've already tried.

A 30-second cooldown prevents accidental double-clicks. An audit trail records who resent the email and when (visible on hover via the button's tooltip), so multi-staff teams can track support actions cleanly.

If the resend also fails to arrive, the underlying problem isn't the original send — it's deliverability. Continue with the diagnostic steps below.

Diagnostic flow when resend doesn't help:

Check WP Mail SMTP → Email Log (paid feature) or your transactional provider's activity dashboard. You'll see one of three states for the resent email:

  • Sent + delivered: the email left your site and reached the customer's mail server — it's almost certainly in spam. Ask the customer to check their junk / promotions folder and add your sending address to their contacts.
  • Sent + bounced: the recipient's address is invalid or their mailbox is full. Confirm the email address on the attendee record matches what the customer expected, and ask the customer to double-check for typos at booking.
  • Failed to send: your SMTP setup has an issue — usually an expired API key, a rate limit, or a quota exceeded. The error message in the log identifies the cause. Renew the API key in WP Mail SMTP or upgrade your sending provider's plan.

Important: if Site Calendar Pro shows a red "could not be sent" notice next to the Resend button but the customer reports actually receiving the email, you're on Pro 1.1.4 (a false-positive bug). Upgrade to Pro 1.1.4.1 or later — the resend handler now correctly reports success.

"The email arrived but the QR code is missing"

Some corporate Outlook gateways block inline images by default. The customer can still check in using the 8-character backup confirmation code shown below the QR. Door scanner staff can type the code into the manual entry field on the check-in screen.

"From name shows 'WordPress' instead of my business name"

You haven't saved a custom From name in Site Calendar → Settings → Tickets, or WP Mail SMTP's "Force From Name" is overriding it with a different value. If WP Mail SMTP's Force From Name is ON, it overrides every plugin's preference. Either turn off Force From Name in WP Mail SMTP, or set the WP Mail SMTP value to match what you want.

"Emails arrive but always land in Gmail Promotions or Spam"

Deliverability. The fix is always the same three things: (1) SPF record on your domain authorising your transactional provider, (2) DKIM record signed by the provider, (3) Domain matches between WP Mail SMTP's Force From Email, Site Calendar's From email, and the domain with SPF/DKIM set up. Mismatch in any of those three triggers spam filtering.

"I want to change the email's colour scheme to match my brand"

From Pro 1.1.2 onwards: go to Site Calendar → Settings → Appearance and update the Primary and Accent colour pickers. The next confirmation email sent will use those colours for the header bar, section labels and QR-code box tint. The change is instant — no clearing caches, no re-saving events. Logo upload in the email header is still on the roadmap; for now the strongest brand signal beyond colour is the From name and From email, both of which appear before the customer opens the message.

"The ICS attachment isn't working — calendar app says 'invalid file'"

Two known causes. Some email security gateways rewrite or strip ICS attachments — try sending to a personal Gmail or iCloud account to confirm the attachment itself is valid. If the file is reaching the recipient but their calendar app rejects it, the event's start/end time fields may be malformed; check the event in Site Calendar → Events and re-save.

"I get the customer email but no admin notification"

By default Site Calendar Pro doesn't send admin copies of every ticket sale (would flood your inbox during busy events). To monitor in real time, use the WooCommerce or Stripe dashboards — both send their own notification on order completion. For attendee-level visibility, watch Site Calendar → Events → [event] → Attendees.

What's next

Stuck? Email support@getsitecalendar.com and we'll help directly. Pro licence holders get priority response.