Distinguish system mail from marketing mail
Spektrix's System Email Authentication documentation covers operational messages such as order confirmations, print-at-home tickets, password resets and membership notices. It distinguishes these from marketing email handled by Dotdigital. A marketing domain being authenticated is therefore not sufficient evidence that system notifications use the intended identity.
Inventory the Spektrix system, message categories, intended sender and responsible team. Include scheduled reports or lists only where they are part of the actual scope; do not assume every possible feature is enabled for the organization. The customer-support and box-office teams should agree which visible address recipients will see and which mailbox will receive replies.
The documentation supports a configuration plan, not an assertion that a tenant has been configured. This manuscript performs no support communication, DNS query, record change or test send. The original implementation and account-applicability requirements remain open. System Email Authentication
Choose the dedicated sending subdomain deliberately
Spektrix instructs clients to use a subdomain for system mail and place the relevant configuration there rather than at the root. It also advises against using the same subdomain as a Spektrix custom-domain web integration. Record the chosen boundary and check whether that name already serves another purpose.
A dedicated subdomain can help separate operational dependencies, but it is not a guarantee that reputation or security effects can never reach the wider organization. The practical benefit is clearer ownership and reduced overlap with root-domain infrastructure. Preserve that distinction rather than promising complete isolation.
Before proposing records, identify the existing authoritative zone, current MX use and inherited or explicit DMARC policy. A name that appears unused in a spreadsheet may still support a service. Do not replace production website or mailbox records simply to fit a convenient example. Confirm the intended subdomain with the authorized domain owner and Spektrix's documented support workflow. Sending Subdomain
Review SPF, DKIM and MX as different dependencies
The system-email guide names SPF, DKIM and MX records for the selected sending subdomain. Its SPF example includes mailgun.org. If an SPF policy already exists at that name, review one complete policy rather than adding a second record or pasting an entire sample inside the existing value. Preserve legitimate sources and review DNS-dependent evaluation limits.
DKIM is support-assisted: the guide asks clients to confirm the sending domain with Spektrix Support, which helps generate the domain key. It describes 2048-bit keys. Retain the actual issued key name and public value; do not invent a selector or reuse another organization's key.
MX records concern mail routing, not a substitute for a DKIM signature. The guide gives different Mailgun MX destinations for UK/Ireland/Canada and US clients. Use the provider-confirmed account region and full instructions, including any values not established by a copied excerpt. Never change the root domain's existing mail service merely because the system-mail subdomain needs MX configuration. Setting up SPF, DKIM and MX Records; RFC 7208, section 3.2; RFC 7208, section 4.6.4
Keep logging and reply routing separate from authentication
The guide describes an optional email logging dependency using an email label beneath the sending subdomain and a region-appropriate CNAME. It says clients do not directly access the resulting logging and that it helps support investigate delivery. This is not the same thing as a DKIM key or proof that a recipient read a message.
Review tracking or logging features under the organization's privacy and communications requirements before enabling them. This manuscript does not create the tracking record or collect recipient interaction data. A proposed evidence pack can identify whether the feature is in scope without assuming that opens or clicks reliably measure human attention.
The provider also describes setting a Reply-To address through support when the sending address has no monitored mailbox. Review that destination with the box-office team. A reply arriving successfully proves a workflow outcome, not alignment of the original notification. Email Logging; Reply To Address
Preserve parent-domain DMARC intent
Spektrix warns that a basic subdomain DMARC record can conflict with the organization's existing parent-domain configuration. Treat any supplied monitoring policy as a proposed policy decision, not a harmless verification token. Publishing an explicit subdomain policy can change the applicable policy relationship, so the domain owner must review it before approval.
Use current DMARC semantics rather than broad statements that authentication always ensures delivery or that a policy value determines every recipient's outcome. DMARC evaluates alignment with a passing authentication identity, while receivers retain their own handling policies. A fallback sending domain cannot be assumed to authenticate an unrelated author domain merely because mail continues to leave an application.
The proposed final check is an authorized representative system message with its author domain, signing identity, selector, relevant envelope identity and trusted receiver results. Keep marketing-message evidence separate. Do not lower policy to hide an unresolved system route or claim that a green DNS check proves customer receipt of a ticket. DMARC; Conflicts; Fallback domain; RFC 9989, section 4.4; RFC 9989, section 5.3
Acceptance worksheet for box-office and IT teams
Use this original proposed worksheet to coordinate operational mail without replacing evidence with assumptions.
- Message scope: system identifier, operational categories and separate Dotdigital marketing responsibilities.
- Sending boundary: approved subdomain, existing DNS use and distinction from custom web integrations.
- Provider request: support-confirmed region, issued DKIM key details and complete record instructions.
- Policy review: single coherent SPF policy, explicit or inherited DMARC intent and the domain owner's approval.
- Mail routing: subdomain MX configuration and confirmation that root-domain mailbox service remains unaffected.
- Optional features: logging or tracking decision, privacy owner and monitored Reply-To destination.
- Acceptance: provider status where available, authorized received-message identities and trusted authentication results.
- Continuity: rollback owner, scheduled-message dependencies and unresolved production-release questions.
The worksheet is blank. It records no actual customer addresses, ticket purchases, private keys, DNS changes or support actions.
Fictional diagnosis: a marketing domain was mistaken for system mail
A fictional theatre launches an authenticated Dotdigital campaign and assumes its ticket confirmations are covered by the same setup. A later system-message sample shows a different sending path. The box-office team proposes changing the root domain's MX records because the system-mail guide mentions MX.
The proposed review stops that unrelated change. It separates the marketing and operational routes, identifies the dedicated system-mail subdomain, and asks for the correct account-region instructions and support-issued key. The existing corporate mailbox infrastructure is preserved while the new dependency set is reviewed.
The theatre also checks the parent-domain policy before accepting a suggested subdomain record. No success is claimed until appropriate operational evidence exists. This scenario is fictional and does not describe an actual Spektrix incident, customer message or executed test.