Email domain

Overview

Organisers can customize the email domain that will be used for platform emails.

This can be configured in the admin panel at /admin/general/settings, section "Emails Domain". The desired email domain should be pasted here and the email domain should be verified on AWS (Amazon Web Services).

No emails will be sent out until the email domain has been verified

Basic Verification Steps to Follow

ExpoPlatform uses AWS (Amazon Web Services) technology to power the platform, so there are some steps that involve letting AWS know about the connection between your custom domain(s) and ExpoPlatform.

The easy to follow set up steps are below and this first AWS article and second AWS article have additional technical details and explanations if you'd like to learn more.

In domain hosting service account:
1. Log in to the hosting service that is used for this email domain.
2. In the SPF section, follow the instructions for adding a new SPF record. You will need to indicate that the new SPF record is for Amazon and will see "include:amazonses.com" included in the SPF record that is then generated. And when you are done you should see something like: "v=spf1 include:spf.protection.amazonses.com -all"
3. Be sure to confirm and save (depending on which domain service you are using, you may be asked to confirm, save, or do both).
In ExpoPlatform:
1. To set up the custom email domain for the event, navigate to Admin Panel → Event Set up → General → Settings → Scroll down to Email Domain → Plug in your domain → Click Save
TAM validates the set up:
1. ExpoPlatform will handle the domain verification process in AWS and provide you with the necessary CNAME records. These records need to be updated in your email domain management console.
2. After the organizer updates the email domain in their console, ExpoPlatform will validate it in AWS. Once validated, the email domain will become operational and can be used for sending system emails from your company's domain.

If the organiser's email domain is not fully verified in AWS (SPF, DKIM, DMARC records missing or misconfigured), AWS will block outgoing emails silently from the platform's perspective.

Important items to check:

Navigate to Admin Panel → General Settings → Email Domain. Confirm the domain is saved.
Client should verify that their DNS records include:
- SPF record containing: include:spf.protection.amazonses.com
- DKIM CNAME records (provided by ExpoPlatform after domain is added)
- DMARC record (recommended for delivery reliability)
TAM should check whether the domain is in AWS SES sandbox mode — in sandbox, emails can only be sent to verified addresses. Production use requires sandbox exit approval.

Additonal Steps to Ensure Reliable Email Delivery

Customers who completed the original domain setup above may not have these additional records in place. Adding these additional records will help with email deliverability, particularly among recipients using Outlook, Hotmal or Microsoft 365.

Your TAM will confirm which domains are in scope and provide the exact record values once the setup has been completed on the ExpoPlatform side.

What needs to be added

Your DNS administrator needs to add or update the following records. All values will be provided by your TAM.

DKIM records — 3 × CNAME

Three CNAME records that verify emails are genuinely sent from your domain and have not been altered in transit. Names and values provided by your TAM.

MAIL FROM subdomain records — 1 × MX + 1 × TXT

Sets a dedicated sending subdomain (e.g. noreply.yourdomain.com) to align your sending identity and improve sender reputation. Both the MX record name/value and the TXT (SPF) record name/value will be provided by your TAM.

DMARC record — 1 × TXT

Record name: _dmarc.yourdomain.com
Record value: v=DMARC1; p=quarantine;
Important: The policy must be set to quarantine or reject. A value of p=none will not satisfy Microsoft's filters and emails may still be blocked or filtered by Outlook and Microsoft 365.

SPF record — update existing apex TXT

Add include:amazonses.com to your existing SPF record on the apex domain.
Important: Merge this into your existing SPF record — do not create a second SPF TXT record on the same domain. Only the first SPF record will be read, and duplicate records cause delivery failures.
If you already have many include: entries in your SPF record, let your TAM know before making changes, as too many entries can cause SPF lookup limit errors.

If you use other email services (e.g. Microsoft 365, SendGrid, Mailgun)

Your SPF record must include all authorised senders in a single TXT record on the apex domain. Check with your TAM if you are unsure how to merge the new entry with your existing record.

Propagation

DNS changes typically propagate within a few hours but can take up to 72 hours in some cases. Your TAM will verify that all records are correctly in place once changes have been applied.

Quick checklist

☐ 3 × CNAME records added for DKIM (values from your TAM)
☐ MX record added for MAIL FROM subdomain (value from your TAM)
☐ TXT (SPF) record added for MAIL FROM subdomain (value from your TAM)
☐ DMARC TXT record added at _dmarc.yourdomain.com with p=quarantine or p=reject
☐ Apex SPF TXT record updated to include include:amazonses.com (merged, not replaced)
☐ TAM notified that changes have been applied