This article introduces the different domains used in Dialog Insight for email delivery, interaction tracking, and landing page hosting. You will learn about the role of each domain and discover the email authentication mechanisms, including SPF, DKIM, and DMARC.
Domains Used for Email
Several domains may be involved in email delivery, depending on their purpose. Some identify the sender to the recipient, while others are used for the technical handling of email delivery. Understanding their roles helps explain how email authentication works.
The sender domain is the part of the email address that follows the @ symbol in the address displayed as the sender of the message. For example, if the sender's email address is info@example.com, the sender domain is example.com.
The Mail-From domain is the domain used to receive notifications when an email cannot be delivered. This address is used for email delivery management and is generally invisible to the recipient. With Dialog Insight, the Mail-From domain is created by adding the in-mta prefix to the sender domain. This configuration aligns the domains used for email authentication.
Example:
- Sender domain: example.com
- Mail-From domain: in-mta.example.com
The Mail-From domain allows the recipient's mail server to verify sending authorization using SPF. For this verification to contribute to DMARC compliance, the Mail-From domain must also align with the sender domain according to DMARC alignment rules.
Email Authentication Mechanisms
Email authentication allows email services to verify certain aspects of a message's origin and the sender's identity. Properly configuring these mechanisms helps protect your sender identity and improve email deliverability, although it does not guarantee that your emails will reach the inbox.
Three complementary mechanisms are used: SPF, DKIM, and DMARC. Each plays a distinct role in email verification.
- SPF (Sender Policy Framework) allows the receiving mail server to verify whether the IP address of the server sending the email is authorized to send email on behalf of the Mail-From domain.
- DKIM (DomainKeys Identified Mail) verifies the message's digital signature and the integrity of the content covered by that signature. It involves a signing domain, which may differ from the From and Mail-From domains.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) verifies whether the SPF or DKIM authentication result aligns with the sender domain.
For a message to pass DMARC, at least one of the two mechanisms, SPF or DKIM, must pass authentication and meet the alignment requirements for the From domain.
When setting up your account, if you choose subdomain delegation, our team will configure SPF, DKIM, and DMARC for you.
SPF (Sender Policy Framework) allows the recipient's mail server to verify whether the server sending the email is authorized to send messages for the Mail-From domain. To do this, the mail server checks the SPF record (a TXT record) published in the DNS for that domain. This record specifies which IP addresses or servers are authorized to send emails for the domain.
The Mail-From domain is part of the technical information exchanged between servers to deliver the email. This information forms the SMTP envelope, which is separate from the message content. You can compare this envelope to a mailing envelope: the return address on the envelope may differ from the sender's address indicated in the letter it contains. In an email, the latter corresponds to the address displayed as the sender of the message.
The following diagram illustrates how SPF works:.png)
DKIM (DomainKeys Identified Mail) adds a digital signature to your emails. This signature allows the recipient's mail service to verify that the message was signed by an authorized source for the signing domain and that the parts of the message covered by the signature were not altered during transmission.
This mechanism relies on two complementary keys:
- A private key, held by Dialog Insight, which is used to sign your emails.
- A public key, published in the DNS records for the signing domain, which allows mail services to verify the signature.
When the email is received, the mail service retrieves the public key and uses it to verify the signature. If verification succeeds, the DKIM signature is considered valid.
The following diagram illustrates how DKIM works: 
For more information, visit http://www.dkim.org/
DMARC (Domain-based Message Authentication, Reporting and Conformance) allows the recipient's mail server to verify whether an email meets the authentication and alignment requirements for the sender domain.
For a message to pass DMARC, at least one of the following conditions must be met:
- SPF passes and the Mail-From domain aligns with the sender domain.
- DKIM passes and the signing domain aligns with the sender domain.
Alignment means that the domains match according to the rules defined in DMARC. With Dialog Insight, the Mail-From domain is created by adding the in-mta subdomain to the sender domain. The DKIM signing domain is verified independently of the Mail-From domain.
Do you send 5,000 or more emails per day to personal Gmail accounts? Senders who send 5,000 or more emails per day to personal Gmail accounts must configure SPF, DKIM, and DMARC, among other requirements. A DMARC policy with p=none is acceptable for meeting this requirement. For more information, see https://dmarc.org/resources/deployment-tools/. |
Domains Used for Tracking and Web Content
Other domains complement those used for email delivery and authentication. They are used to customize tracking links included in communications and the web addresses of landing pages hosted in Dialog Insight. Using domains associated with your organization helps maintain consistency with your brand identity and build trust with recipients when they click your links or visit your pages.
Dialog Insight collects statistics on links clicked in your communications and also automatically displays certain forms to your contacts, including unsubscribe forms and options for viewing a message online. The links you include in your communications are replaced with links pointing to the platform's servers.
When a contact clicks a link, they are first directed to Dialog Insight's servers, where the click is recorded, and then redirected to the final destination, such as a page on your website. By default, these links use a domain associated with the platform (for example: app.dialoginsight.com).
However, your contacts may find these links suspicious. Why does a link in a communication direct them to app.dialoginsight.com when they do not recognize this site and are unlikely to associate it with your company? To reassure recipients and reduce potential phishing complaints, it is important to configure a domain that will be used to customize tracking links.
If you used domain delegation, a tracking link domain should already be configured in your account. To view your tracking links, go to the Tracking Links section under Account Management.
By default, this address uses a domain provided by Dialog Insight. You can instead configure a custom subdomain so that your landing page URLs use a domain associated with your organization.
Configuring a custom domain for landing pages is optional. It involves adding and validating the subdomain, as well as configuring the DNS settings and SSL certificate.
For more information, see Using a Custom Domain for Landing Pages.