To use email masking

1. Review Important to know about email masking, below.

2. Prepare for email masking by getting approvals, identifying the subdomain name, and setting up a custom domain on the instance.

3. Configure a company domain for email masking.

4. Configure and validate email masking

Important to know about email masking

• Use of email masking requires approval from both Medallia and the client company.

• The setup and configuration process for email masking takes from 6 to 8 weeks to complete.

  • The configuration and validation steps must be done on the production instance; they cannot be done in a sandbox instance.

• Email masking requires coordination between Medallia Support and the company IT group.

  • Medallia maintains the SPF, DMARC, and DKIM standards.
  • The company maintains the DNS and MX configurations.

• Auto reply emails are not available when using Email masking because those email must be routed through a *.medallia.com domain.

• To improve DMARC reputation — and avoid being identified as SPAM — the email address should

  • use a company subdomain (such as feedback.example.com),
  • should not use the main root or home domain (such as example.com), and
  • should not be shared with another service (such as marketing or Support).

• Email masking is related to but different from SMTP relaying. Configuring SMTP relaying is out of scope for this document and requires advanced setup between the Medallia operations team and the company's IT organization. For more information, contact your Medallia expert.

Email delivery components

Email masking uses DMARC, DKIM, SPF, and MX which are industry-standards for ensuring sure deliverability of email messages. Setting up email masking requires coordination between Medallia and the company's email administration to properly comply with the standards. Email transport systems and applications use email header values to detect deceptive or fraudulent email. Much of the work in setting up Email masking is to ensure these header values are valid so messages are delivered correctly.

When Medallia sends a masked email on behalf of a company:

1. The email includes an encrypted DKIM signature; From and Reply-to addresses that point to the Company mail server; and a Return-path that points to the Medallia mail server.

2. When the recipients mail server receives the email, it asks the company server for the IP address of the sending server. The company server's DNS record redirects the lookup to the Medallia SPF record, which identifies the address.

3. To verify the message was not altered in transit, the recipient asks for the Medallia DKIM public key, which it then uses to verify the integrity of the message.

4. The recipient uses the Medallia DMARC policy to approve or reject the message.

5. The approved message is delivered to the user.

SPF

Sender Policy Framework (SPF) identifies the IP addresses of the servers allowed to send messages from an Medallia subdomain. These addresses are stored as a TXT record in the Domain Name Service (DNS) for the subdomain. Mail transfer agents query DNS to learn the address, and they may reject messages as spam when not provided.

To avoid being classified as SPAM, the Return-path header field in the outgoing email must point to the originating Medallia email server. As such, SPF records are fully managed by Medallia, Inc.

DKIM

Email spam senders have been known to intercept valid email messages and inject their own message into the body of the email. To ensure the integrity of the message, Medallia Experience Cloud email servers inject DomainKeys Identified Mail (DKIM) signatures into the email header. The receiving email server then compares the signature against a public key included with the subdomain DNS TXT record, similar to this record:

;; ANSWER SECTION:
default._domainkey.feedback.example.com. 300 IN	TXT	"v=DKIM1\; k=rsa\; p=***_PUBLIC-KEY_***"

If the signature and key do not cryptographically compare to be from the same source, the agent may reject the email as spam.

DKIM for Medallia-managed email domains are fully managed by Medallia, Inc. as part of our data center infrastructure. Medallia retains ownership and management of DKIM and clients using email masking must create a CNAME record with a specific value that corresponds to the key.

DMARC — Enforcement

DMARC is a mechanism that Internet hosts publish to specify "who to contact" when there is a problem or question with SPF or DKIM validation, and what to do about the questionable message. For more information, see DMARC.

Clients establish a DMARC policy record, which may be any of the available three levels: none, quarantine, and reject. The policy directive tells the receiving system how to treat your email that fails the DMARC test.

Warning: During email masking implementation, you might set the policy to none for monitoring purposes. However, for production, masked domains that are assigned only to Medallia (such as feedback.example.com) must have a DMARC policy of reject (preferred) or quarantine (minimum allowed) with a pct=100 setting.

Masked domains that are shared with other senders (such as example.com) must have a DMARC policy of reject (preferred), quarantine, or none. Note that Google, Yahoo, and other email service providers require an explicit DMARC policy.

This example DNS TXT record identifies postmaster@example.com as the DMARC contact and the email rejection policy is set to quarantine (p=quarantine) with a pct=100:

;; ANSWER SECTION:
_dmarc.example.com.	300	IN	TXT	"v=DMARC1\; p=quarantine\; rua=mailto:postmaster@example.com\; ruf=mailto:postmaster@example.com\; pct=100"

DMARC for Medallia email domains are fully managed by Medallia, Inc. as part of the data center infrastructure.

MX (Mail Exchange)

A mail exchange is a client-managed service connected to the Internet that receives messages for a domain. When using Reply-To or an email masked domain for From, the client IT must set up a mail exchange and the associated DNS record(s), and ensure that the mailboxes specified in the email addresses are valid.

This example DNS record creates a mail exchange for a client-owned domain:

feedback.example.com. 300 IN MX 10 inbound-mail1.example.com
feedback.example.com. 300 IN MX 10 inbound-mail2.example.com

Important: Ensuring that an email address does not bounce is critical for keeping the reputation of an email masking domain high.

BIMI (Branding integrity)

Brand Indicators for Message Identification (BIMI) is an emerging email standard for tagging emails with your brand's logo and showing an "authenticated" checkmark to give recipients a sense of integrity for the message. Clients who implement BIMI may see an increase in engagement with survey emails.

BIMI is only available on email-masked domains, requires a DMARC policy of reject or quarantine and a pct=100 setting, and is implemented fully by the client's IT team. For more information, see BIMI.