Email Domain Setup and Authentication
Best Practices and what to expect when configuring a new email domain.
Email authentication is an absolute must in today's email ecosystem. It gives inbox providers (Gmail, Microsoft, Yahoo, etc.) confidence that emails being sent to their users are being sent by validated, genuine sources and not bad actors, who may be trying to spam or scam customers. The more confidence that an inbox provider has that the email is legitimate, the more likely they are to deliver it to the inbox, instead of the spam folder.
A quick rundown on the benefits of implementing SPF, DKIM, and DMARC:
- Stops email spoofing/phishing from your domain.
- Provides important information about the emails you send, which can be used to get all legitimate emails properly authenticated.
- Improves sender reputation and email deliverability; your legitimate emails are more likely to reach the inbox.
In order to do this, Webex Campaign customers will need to configure some DNS records, generated by our Amazon SES email gateway, on their chosen email subdomain.
Domain Verification Record
This is a TXT record inserted into the DNS to verify with Amazon SES that you own the domain that you will be sending from.
Name | Type | Example Value |
---|---|---|
_amazonses.subdomain.domain.com | TXT | examplerecord+123= |
subdomain.domain.com | TXT | amazonses:examplerecord+123= |
SPF
SPF (Sender Policy Framework) is a form of email authentication that defines a process to validate an email message that has been sent from an authorized mail server in order to detect forgery and prevent spam. The owner of a domain can identify exactly which mail servers they are able to send from with SPF protocols. This takes the form of a TXT record inserted into the DNS.
Name | Type | Example Value |
---|---|---|
subdomain.domain.com | TXT | "v=spf1 include:amazonses.com -all" |
This example creates an SPF record that allows IP addresses from Amazon SES (our email gateway) to send emails from your subdomain and pass inbox provider SPF checks.
If you want to specify individual IP addresses, you can amend the record as follows:
Name | Type | Example Value |
---|---|---|
subdomain.domain.com | TXT | "v=spf1 ip4:192.168.0.1 -all" |
Having your SPF record configured like this means that only emails sent from servers with the specified IP addresses will pass inbox providers' SPF checks.
DKIM
DKIM, which stands for DomainKeys Identified Mail, is an email authentication method designed to detect forged header fields and content in emails. DKIM enables the receiver to check if email headers and content have been altered in transit.
A good analogy is that of a postal envelope seal. Think of a DKIM signature in the email header as an envelope seal: the sending server "seals" an email message on its way out by affixing a signature to the message; anyone who attempts to tamper with the email in transit, must break the seal to do so, which is detectable by the inbox providers.
We will provide you with 3 CNAME records to configure in the DNS of your subdomain.
Name | Type | Example Value |
---|---|---|
example1._domainkey.subdomain.domain.com | CNAME | example1.dkim.amazonses.com |
example2._domainkey.subdomain.domain.com | CNAME | example2.dkim.amazonses.com |
example3._domainkey.subdomain.domain.com | CNAME | example3.dkim.amazonses.com |
DMARC
DMARC, (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to detect email spoofing. In order to comply with DMARC, messages must be authenticated through either SPF or DKIM, or both.
Setting up the DMARC policy on your domain
Once you have published a DMARC record for your email domain in the DNS; whenever an email that claims to have originated from your domain is received, the email service provider fetches the DMARC record and checks the email message for it. Depending on the result, the email is either delivered, quarantined, or rejected
Name | Type | Example Value |
---|---|---|
_dmarc.subdomain.domain.com | TXT | "v=DMARC1;p=reject" |
DMARC Policies
In this example, the "p" (policy) value has been set to "reject". There are 3 policies that can be applied depending on your preference.
- p=none: This tells inbox providers to take no specific action on emails that fail authentication. They will most likely be delivered unless it is very obviously spam. A p=none DMARC policy leaves the decision up to inbox providers.
- p=quarantine: This policy informs inbox providers to send emails that fail authentication to spam or junk folders. These messages may also be blocked.
- p=reject: This is the strongest DMARC policy value. If a message fails DMARC when set to “reject” will, it not be delivered at all.
Complying with DMARC through DKIM
For an email to comply with DMARC based on DKIM, both of the following conditions must be met:
- The message must have a valid DKIM signature.
- The From address in the email header must align with the domain in the DKIM signature.
- If the domain's DMARC policy specifies strict alignment for DKIM, these domains must match exactly. This is our standard setup.
- If the domain's DMARC policy specifies relaxed alignment for DKIM, the domain can be a subdomain of the From domain.
To comply with these requirements, complete the following steps:
- Set up DKIM by completing the steps in the DKIM guide.
Complying with DMARC through SPF
For an email to comply with DMARC based on SPF, both of the following conditions must be met:
- The email must pass an SPF check.
- The domain in the From address of the email header must align with the MAIL FROM domain that the sending mail server specifies to the receiving mail server.
- If the domain's DMARC policy for SPF specifies strict alignment, the From and MAIL FROM domains must match exactly.
- If the domain's DMARC policy for SPF specifies relaxed alignment, the MAIL FROM domain can be a subdomain of the domain in the From header. This is our recommended setup.
To comply with these requirements, complete the following steps:
- Set up a custom MAIL FROM domain by completing the steps in the custom MAIL FROM domain guide.
- Ensure that your sending domain uses a relaxed policy for SPF. If you haven't changed your domain's policy alignment, it uses a relaxed policy by default.
Custom MAIL FROM Domain
Messages that are sent through our gateway, Amazon SES, automatically use a subdomain of amazonses.com as the default MAIL FROM domain. Sender Policy Framework (SPF) authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES.
If you don't want to have the SES default MAIL FROM domain, and would rather use a subdomain of a domain that you own, this is referred to in SES as using a custom MAIL FROM domain. You will also need to do this to pass DMARC authentication via SPF alignment. We do recommend this as a best practice.
To do this, it requires you to publish your own SPF record for your custom MAIL FROM domain. In addition, SES also requires you to set up an MX record so that your domain can receive the bounce and complaint notifications that email providers send you.
Name | Type | Example Value |
---|---|---|
custommailfromsubdomain.subdomain.domain.com | MX | 10 feedback-smtp.eu-west-2.amazonses.com |
custommailfromsubdomain.subdomain.domain.com | TXT | "v=spf1 include:amazonses.com -all" |
Custom MAIL FROM domain requirements
The subdomain you use for your MAIL FROM domain has to meet the following requirements:
- The MAIL FROM domain has to be a subdomain of the verified identity (email address or domain) that you send email from. For example, mail.example.com is a valid MAIL FROM domain for the domain example.com. Similarly, custom.mail.example.com is a valid MAIL FROM domain for the subdomain mail.example.com.
- The MAIL FROM domain shouldn't be a domain that you send email from. If you have to use the MAIL FROM domain in a From address, there are some additional considerations and you will need to speak to us.
- The MAIL FROM domain shouldn't be a domain that you use to receive email.
MX Record
The number 10 listed along with the MX value is the preference order for the mail server and will need to be entered into a separate value field as specified by your DNS provider's GUI
Gmail and Yahoo large sender requirements
Starting February 2024, Gmail and Yahoo will require the following for senders who send 5,000 or more messages a day to their customers accounts:
- Authenticate outgoing email
- Make it easy for recipients to unsubscribe (one-click/list unsubscribe)
- Avoid sending unwanted or unsolicited email
- Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.
Both of these major inbox providers have shared this enforcement timeline:
In February 2024, bulk senders who don’t meet sender requirements will start getting temporary errors (with error codes) on a small percentage of their non-compliant email traffic. These temporary errors are meant to help senders identify email traffic that doesn’t meet our guidelines so that senders can resolve issues that result in non-compliance.
In April 2024, we’ll start rejecting a percentage of non-compliant email traffic, and we’ll gradually increase the rejection rate. For example, if 75% of a sender’s traffic meets our requirements, we’ll start rejecting a percentage of the remaining 25% of traffic that isn’t compliant.
Bulk senders have until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages.
Click to see Gmail and Yahoo's documentation on this.
Authenticate outgoing email
We will help ensure you meet all authentication requirements as per the above guidance in this article. The key things to know are that Gmail and Yahoo require the following:
- Set up SPF and DKIM email authentication for your sending domain.
- Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.
- DMARC must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
- For DMARC to be aligned with the SPF domain, you will also need to set up a custom MAIL FROM domain.
- As a best practice, our recommendation is to align DMARC to both the SPF and DKIM domain.
Monitoring Spam Rates
Gmail and Yahoo stipulate that you must "keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.". Whilst we don't have any tools to manage spam rate monitoring in Webex Campaign, we recommend signing up to the inbox provider tools, where you'll need to authenticate your identity and ownership of the email domain to start seeing this data.
Updated about 2 months ago