TABLE OF CONTENTS




Introduction

This feature is used to create new email senders from inbox authorization or domain authorization methods.


Feature Notes:

  • Green status means the domain or sender is authorized.
  • Yellow status means the domain or sender authorization is still pending.
  • Red status means the domain authorization has been permanently rejected.
  • You will need the support from your IT team to set up the DNS records of your subdomain sender.






Add Domain


Good to know before you start

  • You will need help from your IT team to set up the DNS records for your subdomain email sender.
  • We strongly recommend setting up DKIM, SPF, and DMARC records for better email security and inbox placement. Amazon SES needs you to publish an MX record to receive bounce and complaint notifications from email providers. You also need to publish an SPF (TXT) record to show that Amazon SES is allowed to send emails from your domain. For more details, check this link: Amazon SES Mail From.

  • We suggest using subdomains for different email types. For example, send marketing emails from marketing.example.com and survey invitation emails from feedback.example.com. This way, each subdomain builds its own reputation. If one subdomain's emails are marked as spam, it won't hurt the others.

    For more best practices, check out Amazon's best practices.




How to setup


1. Navigate to Settings → System Admin → System Settings → Survey & Campaigns → Email Senders.



2. Click on +Add Subdomain.



3. Fill in your desired subdomain. 



4. Click on Save.


Important: In order for any sender created based on the subdomain to work, the subdomain needs to be authorized. Your tech team will need the DNS Records in order to authorize the subdomain.




Get DNS Records


1. Navigate to Settings → System Admin → System Settings → Survey & Campaigns → Email Senders.


2. Under Actions click on ⋮ and then on View DNS Records.


3. Add the provided information to your DNS records - this step requires you to get in touch with your tech team.




Verify Authorization Status


Once the information has been added to your domain's DNS records, click on ⋮ under Actions menu and then click on Verify Status.


Please note: it may take a while for your DNS records changes to propagate, if the subdomain status is still pending, try verifying after a couple hours.


Important: You will need to Check Status within 72 hours of adding a subdomain in CustomerGauge.


 




Add New Sender From Authorized Subdomains


Good to know before you start

  • If you don’t want to receive direct replies, you do not need to create an inbox for the email address. However, if you set up an inbox, you can create an automatic reply to let your customers know that the inbox is not being monitored.




How to setup


1. Navigate to Settings → System Admin → System Settings → Survey & Campaigns → Email Senders.


2. Click on +Add Sender.


3. Select From authorized subdomains.



4. Select a subdomain from the dropdown and type the desired From Email.


5. Fill in the desired Reply To email and then click on Save.

Please note: the senders added from subdomains are dependent on that subdomain's authorization. You will need to authorize the subdomain in order for the sender to work properly.






Add New Sender from Email Address


1. Navigate to Settings → System Admin → System Settings → Survey & Campaigns → Email Senders.



2. Click on +Add Sender.


3. Select From email address.



4. Fill in your desired From Email.


5. Amazon will send a verification email to the email provided.


6. After the verification, find the email in the senders list and click on ⋮ under Actions, then click on Verify Status.






CustomerGauge Sender


Important: Although we provide a default sender from our own subdomain, we highly recommend that you use your own subdomain when sending campaigns. Sending from your own subdomain increases the response rate as recipients will recognize your brand.


Direct replies are not supported when using the CustomerGauge default sender.






Understanding the importance of authorized (sub-)domains

While not strictly mandatory, DKIM, SPF, and DMARC play an important role in email authentication. Setting up DKIM, SPF, and DMARC significantly enhances email deliverability for the domain in question.



Impact on Email Performance

Inbox service providers favor DKIM-authenticated emails, as those without DKIM authentication are more prone to bouncing, quarantine, or being labeled as spam. Although quarantined emails may register as delivered in CustomerGauge, they won't be visible to most recipients. So setting up DKIM is highly recommended to improve deliverability.


Note: Some providers like Google and Yahoo demand DMARC, DKIM, and SPF for bulk email-sending domains. Failure to meet these requirements may result in bounced emails categorized as DMARC or Policy bounces, or can otherwise fail inbox placement.



Setting up DKIM

DKIM (DomainKeys Identified Mail) acts as a safeguard against email spoofing. In CustomerGauge, configuring DKIM includes setting up CNAME records in your DNS provider. These records enable receiving mail servers (e.g., Gmail) to verify the email's signature associated with your domain. You can obtain the DKIM records by clicking 'View DNS records' for your domain. 



Setting up SPF

SPF (Sender Policy Framework) verifies the authorization of the sending email server for a specific domain. Adding CustomerGauge's SPF record to your From Address domain enhances authentication by listing IP addresses or domains used for sending emails. You can obtain the SPF record by clicking 'View DNS records' for your domain.



Setting up DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) offers additional protection against email spoofing. Setting up a DMARC record enables inbox providers to handle emails failing SPF and DKIM checks according to specified policies. DMARC causes email servers to verify alignment, ensuring that the domain in SPF or DKIM matches the domain in the email's "From" header. This prevents phishing attempts that falsely claim to be from a different sender. DMARC also provides domain owners with reporting on email authentication and usage. Customizing DMARC policies allows businesses to tailor authentication measures to their requirements.



Explanation of values

DMARC policies can be defined by adding a TXT record in your DNS provider settings, with a value that can include the following semicolon-separated properties:

  • v: the version of DMARC.
  • p:type of policy that dictates how to process emails that do not pass authentication. This can be any of the following:
    • none: used to collect feedback and gain visibility into email streams without impacting existing flows.
    • quarantine: filter emails that do not pass authentication into the recipient's quarantine.
    • reject: bounce emails that do not pass authentication.
  • sp: used to apply a policy to a subdomain of the DMARC record.
  • pct: the percentage of total unique sends that failed authentication to apply this policy to. For example, if your DMARC record included p=reject; pct=25, and 100 emails failed authentication, only 25 of them will be bounced, while the other 75 will be delivered to their recipients.
    • Define this property to slowly ramp up your authentication policy to ensure it's working as expected.
    • This parameter can be ignored by certain inbox service providers.
  • ruf &rua: two optional parameters that specify an email address to send DMARC reporting data to. These must be provided in URI mailto format (e.g., mailto:reporting@example.com). The reporting data that's sent differs based on the parameter: 
    • rua: an aggregate report of all your domain traffic.
    • ruf: failure reporting data that includes redacted copies of individual messages that failed authentication.
  • adkim & aspf: specifies the alignment mode for DKIM and SPF. These should both be set to r (i.e., a relaxed alignment). A relaxed alignment should be the default setting for DMARC for DNS services.



Example use cases



Neutral policy

v=DMARC1; p=none;

This example shows a neutral DMARC policy with no additional parameters. A neutral policy is useful for senders who are just starting to get familiar with DMARC. This is the bare minimum for DMARC to function.



Quarantine policy with failure reporting

v=DMARC1; p=quarantine; pct=25; ruf=mailto:reporting@example.com;

This example shows a policy that will quarantine 25% of emails that fail authentication, while the other 75% of emails that fail authentication will be permitted for delivery. The policy also provides a reporting address where an individual notification email can be sent for each email that fails authentication. This is typically used when working on strengthening your authentication policy.



Strict policy with aggregate reporting

v=DMARC1; p=reject; rua=mailto:reporting@example.com;

This example shows a strict DMARC policy to bounce any emails that fail authentication, and provides an email address to send aggregate reporting data to. This is typically used when you have high confidence in how the domain is used.



Please note: CustomerGauge Support can't assist with DMARC record setup. You should contact your IT team (or the person that handles your DNS settings) for help. You can also use third-party DMARC consulting services for extra support.