Start with the Contact Email that defines the sending domain
ControlShift's official Sender Authentication Configuration guide, updated May 20, 2025, ties its platform sending identity to the organization's Contact Email. The guide says this address is used for platform mail to supporters taking action and administrators subscribed to notifications. Confirm that the configured address belongs to the intended organizational domain before creating authentication records. A typo or an obsolete brand domain at this first step can produce a technically consistent configuration for the wrong identity.
The documented path is the administrator homepage, Settings, Contact, where the address is entered and saved. Treat changing that address as a communication configuration change, not merely an authentication repair. Identify affected message categories, reply expectations and responsible staff before saving. This article does not change an address, contact a supporter or send a platform notification. Current account applicability and the actual route used by representative messages remain open.
Use Deliverability settings to obtain account-specific records
After setting the Contact Email, the guide directs the administrator to Settings, Deliverability. The displayed Domain Name is derived from the Contact Email. If it is wrong, correct the Contact Email first rather than publishing records for an unintended domain. Enter the organization's technical-contact email in the provided field and save through an authorized account workflow. A technical-contact address should be supplied only with appropriate permission and kept current as staff responsibilities change.
After saving, the page presents three CNAME records. Publish the exact issued owners and targets through the organization's authoritative DNS provider. The guide explains the direction of the mapping: the name on the left points to the target on the right. Do not reverse those fields, substitute a record copied from another organization, or replace the issued configuration with a generic SendGrid example. ControlShift's account-generated values are the implementation input for this workflow.
Before editing, compare each complete owner name with the DNS editor's suffix handling and existing zone data. A relative label may be sufficient in one panel while another expects a fully qualified name. Preserve the current records and record the approved changes. The three CNAMEs represent dependencies that should remain attributable to this platform configuration so they can be reviewed during future migrations, domain changes or offboarding.
Check DNS visibility before interpreting Verify
The guide says Cloudflare users should keep the email-deliverability records unproxied. This is specific guidance for those authentication records, not a reason to disable proxying or security controls across an entire website. If the DNS host offers proxy features, review the relevant record setting with the authorized DNS owner and confirm that the issued alias is exposed as required. No DNS setting is changed by this article.
After creating the records, return to Deliverability and choose Verify. The documented success message indicates that ControlShift's DNS check passed. Retain that observation separately from the submitted change and the actual public record. A provider check does not prove that all future messages are signed correctly or that the visible author domain aligns. If verification fails, inspect the exact owner, target, authoritative zone and relevant record settings before repeatedly waiting or rebuilding the configuration.
The provider's brief propagation estimate should not be treated as a universal deadline. An incorrect record owner or a proxied alias is not repaired by elapsed time alone. Record what changed, when it changed and what the provider observed. Leave uncertainty explicit if the authoritative answer and the provider's latest status have not yet been reconciled.
Resolve selector collisions without overwriting another sender
ControlShift specifically warns that organizations already using SendGrid, directly or through another tool, may have s1._domainkey and s2._domainkey records. The guide offers a custom DKIM selector through Advanced Settings to avoid such collisions. It describes checking Use custom DKIM selector, entering a selector of up to three characters and saving so that the generated CNAMEs reflect the choice. Confirm the present interface's accepted value before implementation; this is a product-specific limit, not a universal DKIM selector-length rule.
Do not overwrite an existing selector simply to make the new page's default records fit. Identify the service that owns each existing record and whether it still signs mail. If the configuration has already progressed to issued records, the guide describes removing it and starting again to select the custom option. That is a change to an existing authentication configuration and needs an impact review, especially if production mail already depends on it.
The source adds an important warning: after removing and recreating the configuration, the first CNAME will likely change as well. Review the entire newly issued set, not only the two names that visibly contain the selector. An acceptance checklist that updates the DKIM-looking records but preserves an obsolete first alias can leave a hidden mismatch. Keep old and new values distinguishable in the change record and do not delete unrelated dependencies.
Treat a new Contact Email domain as a configuration migration
The guide distinguishes changing the local part of the Contact Email from changing its domain. A same-domain address change does not require changes to Deliverability settings according to the documented workflow. A different domain does: the guide describes removing the old Deliverability configuration, updating the Contact Email and completing the setup again. That sequence should be planned as a migration with an explicit owner and rollback decision, not a casual cosmetic edit.
Confirm that the new domain is controlled by the organization and that its DNS owner can publish the issued records. Review the timing of scheduled notifications and the evidence needed before resuming normal use. The fact that the previous domain passed Verify does not transfer that result to the new one. Preserve the previous configuration's acceptance record for context while clearly marking the new identity as unverified until the appropriate checks are complete.
Verify message identity without promising delivery
A separately authorized acceptance exercise should inspect harmless representative messages and trusted receiver results. Record the visible author domain, signature domain and selector, envelope identity and actual platform route. RFC 6376, section 3.5 defines the DKIM signature fields, and RFC 9989, section 4.4 explains alignment. A successful DNS check is not a substitute for that message-level relationship.
The retained setup guide provides three CNAMEs rather than a universal SPF include to add at every organizational root. Do not invent an include or add a second SPF policy merely because a generic checklist asks for SPF. If a separate SPF change is genuinely required by the actual route, review it under RFC 7208, sections 3.2 and 4.6.4 with the responsible operator. Authentication can address identity checks; it does not guarantee inbox placement, supporter engagement or the safety of every linked request.
Fictional diagnosis and blank acceptance worksheet
A fictional community organization, Riverbank Neighbours, already has SendGrid selectors for another platform. Its administrator chooses a custom selector in ControlShift but updates only the two selector-related CNAMEs after recreating the configuration. The review finds that the first issued record also changed. The proposed correction is to compare the full new set against the authoritative zone, preserve the other platform's selectors and obtain fresh verification evidence. This scenario is fictional and contains no actual DNS observation, supporter information or executed action.
- Current Contact Email domain and affected message categories: ______
- Deliverability Domain Name and authorized technical contact: ______
- Complete three-record owner/target set and issue time: ______
- Existing selector owners and custom-selector decision: ______
- All changed records after any recreation, including the first: ______
- Authoritative DNS and relevant proxy-setting review: ______
- Verify result and trusted received-message identity evidence: ______
- Domain-migration timing, rollback owner and release decision: ______
Original implementation evidence, human subject-matter review, current source applicability, production-route testing, visual accessibility and owner release remain open. No contact address, authentication configuration or DNS record was changed, and no message was sent. The broader catalogue implementation requirement remains subject to actual authorized account and message evidence.