Hello Customer email surveys use hellocustomer.email by default. You can customize the part of the invitation address before the @ sign. That does not turn it into your own domain, and adding a record to your company's DNS does not authenticate Hello Customer's domain. For a different sending domain, Hello Customer directs you to its support team or your customer success manager. [1]
This guide covers the documented default-domain route: choosing the invitation identity, distinguishing conversation replies from system notifications, and checking the messages you actually receive. It is not a custom-domain SPF/DKIM provisioning guide. The public documentation reviewed here does not provide a complete custom-domain DNS record issuance and signing-activation procedure. Do not copy a generic SendGrid include or generate a DKIM key to fill that gap.
This is a review of provider documentation and relevant email standards, not a logged-in account test, DNS deployment or delivered-message test.
Which Hello Customer email are you configuring?
A touchpoint is a configured feedback collection channel, such as an email survey. Several different kinds of mail can exist in the same account. Check the actual message category before changing anything.
| Message category | Documented sender behavior | What to check |
|---|---|---|
| Email survey invitation | Default domain is hellocustomer.email; the part before @ is customizable. |
Invitation e-mail settings for the intended touchpoint. |
| Conversation reply | Default is feedback@hellocustomer.email. A custom domain configured on the platform and selected in touchpoint settings changes the reply address to feedback@ that domain. |
Reply feature activation and the selected touchpoint, not just the invitation display name. |
| Alerts, scheduled reports and new-user invitations | The provider identifies system@hellocustomer.email as their sender. |
Notification category and report configuration, rather than assuming survey-domain settings control these messages. |
| Auto-responder after survey completion | A separate message flow; the reviewed manual does not establish an exact universal sender address for it. | Test this flow separately. Invitation tests do not exercise it. |
Sources: invitation and auto-responder manual [1], Conversations overview [2], reporting guide [3]. These are documented defaults, not measurements of your account. Do not infer an envelope sender or DKIM signing domain from this table.
Before you start
Use an authorized Hello Customer administrator for creating a touchpoint. Have a controlled test mailbox whose received-message headers your mail administrator can inspect. Use synthetic test responses rather than real customer feedback when possible.
Record the touchpoint name, current sender address and display name, selected language, whether reminders or auto-responders are enabled, and any existing custom-domain arrangement. Keep existing production settings available so a mistaken edit can be restored. Do not upload a production participant list merely to test authentication.
If your account already uses a custom domain, do not switch it back to the default as a shortcut. Confirm its approved configuration with the service owner and Hello Customer first. No DNS change is required merely to inspect the documented default-domain behavior.
Configure the default invitation identity
- As an administrator, use Create touchpoint on the home screen or the link at the top of Touchpoint settings. Select E-mail touchpoint. For an existing touchpoint, work in its settings rather than creating a duplicate production survey.
- In the touchpoint wizard, open Questions & text > Invitation e-mail. Choose the display name and permitted sender address. For the default route, customize the portion before
@hellocustomer.email, not the domain after it. - Set the subject and introduction text in the appropriate language. A recognizable display name helps people understand the message, but is not proof of domain authentication.
- Review the Reminder tab if it is available. The manual says it appears when a reminder period has been selected under Settings > Anti-spam. Check reminder content separately instead of assuming an invitation test covers it.
- Use Save as draft while preparing a new touchpoint. Do not publish or add participants until the intended audience, timing and message content are approved. The provider's publish step becomes available once required setup is complete; that is not an SPF, DKIM or DMARC test. [1]
Changing an address's local part does not create a new authentication domain. For example, two permitted invitation addresses ending in @hellocustomer.email still share that visible From domain. Do not assume those addresses are monitored reply inboxes; confirm the reply experience with a controlled test and the provider.
Check conversation replies and system mail separately
Open Conversations, select the correct touchpoint and open the relevant controlled test conversation. The Reply feature must be activated in the environment; Hello Customer directs customers to their customer success manager for that activation. The respondent's email address must be stored as metadata. [2]
In the reply dialog, the subject and message are required. Optional controls can include the logo and the participant's answer and score. Leave sensitive feedback out of a test message. A visible “sent” indication records the platform action; it does not prove inbox delivery or authentication.
The provider documents feedback@hellocustomer.email as the default reply sender. If a configured custom domain is selected on the touchpoint, check the corresponding custom feedback@ address instead. Conversations less than one year old can be replied to; when an auto-responder is active, the manual says the reply button is unavailable until it has been sent. A Google-review response is different: it does not send an email to the reviewer. [2]
For reports, an administrator can inspect existing schedules through Settings > Notifications > Reports. Check whether a report is active, its scheduled time and recipients, and whether data exists for the period. Do not create an unnecessary recurring report just to troubleshoot an invitation. The reporting guide identifies system@hellocustomer.email for alerts, reports and new-user invitations. [3]
Verify SPF, DKIM and DMARC on received messages
Use the wizard's Send test section to select the language, controlled recipient address, and whether to send the test invitation or test reminder. The manual explicitly distinguishes these choices. [1] Also obtain controlled samples of the other flows you actually use, with appropriate permission.
For each received message, save the message category, timestamp and message identifier alongside the following checks. Do not publish raw headers containing addresses or customer data.
| Check | Meaning and acceptance criterion |
|---|---|
| Visible From | Confirm the complete address, not just the display name. It should match the intended category and configured route. |
| SPF | Inspect the trusted receiver's result and the actual SMTP MAIL FROM domain; for a null reverse path, HELO is the relevant SPF identity. SPF does not directly authenticate the visible From address. |
| DKIM | Inspect the trusted receiver's result for the intended signature, its d= signing domain and s= selector. A signature's presence is not proof that it passed. |
| DMARC | Require a trusted receiver DMARC pass for the actual visible From domain. DMARC needs a passing SPF or DKIM result with the appropriate domain alignment. |
| DKIM-specific verification | If checking DKIM, require that the intended DKIM signature itself passes and aligns with From under the applicable adkim mode. An SPF-only DMARC pass does not establish that DKIM is working. |
With relaxed alignment, the relevant authenticated domain and From domain share the same Organizational Domain. Strict alignment requires the exact same domain. SPF uses the applicable aspf mode; DKIM uses adkim. Do not assume an unrelated passing signature aligns. Read raw DKIM results versus aligned DKIM policy results for the distinction. [4][5]
Trust only authentication results established by the receiving system your mail administrator trusts. Sender-supplied Authentication-Results headers can be forged. A familiar authserv-id or a header's position alone does not establish that trust; the receiving system's handling of externally supplied headers matters. [6]
Distinguish SPF outcomes even when DKIM supplies a DMARC pass. For fail, investigate whether the actual source IP is authorized for the evaluated envelope identity. For temperror, investigate a temporary DNS or receiver problem and recheck after it resolves. For permerror, ask the responsible mail administrator or provider to investigate malformed or duplicate SPF policies and evaluated DNS-dependent-term limits. On a provider-owned default domain, route these findings to Hello Customer; do not try to repair its policy in your company DNS or weaken DMARC.
No universal default Return-Path, DKIM selector, public key or measured pass result is asserted here. Inspect the actual received sample. A valid public DNS record alone does not prove that the service used it to sign that message, and a pass does not guarantee inbox placement or safe content.
Auto-responders need a different test
Hello Customer says Send test cannot test auto-responders, because it does not create an answer record. Its documented approach is to add yourself as a participant and complete the survey. [1] Use an approved isolated test touchpoint and synthetic answers, review the publication/participant consequences first, and then inspect the resulting message separately. The provider says customers cannot reply to the auto-responder; include an appropriate contact address in its text if needed. Do not automatically delete test answers or use a production respondent record as cleanup.
Do I need to add Hello Customer SPF or DKIM records?
Not to authenticate the provider-owned default domain in your own DNS. SPF is evaluated at its actual envelope identity; DKIM key discovery uses the signature's selector and signing domain. A TXT record at your company domain cannot repair another organization's signing domain.
Do not copy Hello Customer's corporate SPF record, infer customer values from its underlying email supplier, or generate an independent DKIM key and assume Hello Customer will sign with it. Provider-owned DNS or signing failures require provider investigation. Preserve your existing SPF, DKIM and DMARC records while diagnosing the default route.
If you want branded-domain sending, contact Hello Customer support or your customer success manager as its manual instructs. Ask for a current, product-specific setup packet covering:
- Eligibility and any plan or permission requirements for your environment.
- Which categories it covers: invitations, reminders, conversation replies, auto-responders and system notifications.
- The intended visible From, actual MAIL FROM behavior, and DKIM signing domain.
- Exact DNS owner names, record types and complete public values, with instructions for obtaining and publishing them.
- Provider validation, signing activation, rollback and a delivered-message acceptance test.
This is a request checklist, not confirmation that all those options are available. Keep the custom route unconfigured until its actual procedure is established. Never send passwords or private DKIM keys in a support ticket.
If a future approved packet calls for DNS changes, preserve one SPF policy per evaluated owner and existing authorizations, keep within the ten evaluated DNS-dependent-term limit including nested evaluation, and do not lower an existing DMARC enforcement policy. DNS changes, new reporting destinations or inbound mail-routing changes need their own approved plan. There is no generic DNS recipe in this guide. [4][5]
Troubleshooting by symptom
| Symptom | Useful next step |
|---|---|
Invitation still shows hellocustomer.email |
Confirm whether you only changed the local part/display name. A different domain is a separate support/CSM discussion. |
| Conversation reply shows an unexpected address | Check the selected touchpoint and whether its configured custom domain is selected; do not infer reply identity from a report email. |
| No Reply button | Check feature activation, respondent email metadata, conversation age and auto-responder state before treating it as DNS failure. |
| Report is missing | Check active state, schedule, intended team/administrator and period data; then inspect receiver quarantine and logs. |
| SPF or DKIM fails on the default route | Preserve DNS. Give support the category, time, message ID and minimally necessary sanitized receiver diagnostics. |
| Authentication passes but mail goes to spam | Inspect content, recipient expectations and receiver policy. A DNS change is not automatically the answer. |
| Preview looks correct but received mail differs | Test the actual invitation/reminder. The provider warns that email-client rendering can differ from preview. |
| Auto-responder does not arrive after Send test | Use the separately approved participant-and-response test; Send test does not trigger this flow. |
The provider suggests allowlisting system@hellocustomer.email when system notifications are missing. Do not translate this into blanket bypasses of spam, phishing or authentication checks. Have the recipient administrator investigate the actual block and approve any narrowly justified exception. [3]
Sources and scope
- Hello Customer: Manual – Create a new touchpoint. Relevant operative sections reviewed: administrator creation, wizard draft behavior, invitation/reminder controls, auto-responders and Send test.
- Hello Customer: Conversations – Overview. Relevant operative reply, identity and permission sections reviewed.
- Hello Customer: Reports – Schedule a dashboard as a report. Operative reporting body reviewed, including sender and recipient scope.
- RFC 7208: SPF. SPF identities and DNS-dependent evaluation limits.
- RFC 9989: DMARC. Identifier alignment and policy evaluation.
- RFC 8601: Authentication-Results. Authentication-result reporting and trust boundaries.
The cited provider pages do not establish the complete custom-domain issuance and activation workflow. That limitation is retained deliberately rather than replaced with guessed records or another platform's instructions.