When you send an email from your CRM site or when a system notification email is sent out, the email will show your email address to the recipient.
However, since the email is actually sent from a Merchant Central server, behind the scenes the email will still show the sender domain to be "iriscrm.com".
Because there is a difference between the sending server domain and the sender's email address domain, email systems can potentially reject the message or mark it as spam mail.
In order to avoid this potential issue, you can add SPF, DKIM, and DMARC records in your domain's DNS settings which indicate that the iriscrm.com mail server is authorized to send messages from you.
When the sending server domain is different from the sender's email address domain, the email systems will look for the SPF, DKIM, and DMARC records in the sender's email domain to confirm that the incoming email is authentic and that it came via an authorized domain.
You can use the CRM's Email Domain Checker to automatically check on the health of the email addresses using in the system.
We also recommend that you can use the Email Metrics page to monitor your email delivery rates and bounce rates.
Below we provide more information on the SPF, DKIM, and DMARC records and how to configure them in your DNS.
What is SPF?
Sender Policy Framework or SPF is a type of email authentication that defines the mail servers or applications that are allowed to send from your domain.
SPF is implemented via SPF records. An SPF record is a text file that is published in the DNS (Domain Name Service) which contains a list of email servers that are authorized to send emails on behalf of your domain.
If the sending server domain used by your email application or system is listed within your SPF record, then your email will be properly authenticated. This will increase the likelihood of your message reaching your customer’s inbox.
How does it work?
Here is an example of the SPF authentication that takes place when you send an email from Merchant Central to your client:
- Using Merchant Central, you send an email FROM jim@yourdomain.com TO bill@clientdomain.com.
- Clientdomain.com's mail server checks the DNS records at yourdomain.com for a valid SPF record.
- If an SPF record exists, then clientdomain.com checks to see if iriscrm.com is included in the SPF record.
- If iriscrm.com is included in the record, then SPF will pass and the email will be properly authenticated.
- If iriscrm.com is not included in the SPF record (or the SPF record is not published) then SPF will fail and the email will not be properly authenticated.
Adding an SPF Record
To add an SPF record, find the TXT record in your DNS settings that have a value starting with "v=spf" and edit that value.
There can only be one record with SPF information in it. If none exists, it can be created. The only change needed is to add "include:_spf.iriscrm.com" in the record.
Here's an example, where the bold part is added to show Merchant Central is allowed to send messages using your email address:
Type: TXT
Current Value: v=spf1 +a +mx ~all
New Value: v=spf1 +a +mx include:_spf.iriscrm.com ~all
TTL: 1 hour / 3600
SPF Record Check
To confirm that your SPF record is configured correctly, you can use an online tool such as MX Toolbox.
- Go to https://mxtoolbox.com/spf.aspx
- Enter your Domain name and click SPF Record Lookup
- Your SPF record along with diagnostic information is now displayed on the page as shown in the below example (soft fails are fine):
What is DKIM?
Domain Keys Identified Mail or DKIM is another type of email authentication technique that allows the receiver to confirm that an email was indeed sent and authorized by the owner of that domain.
In addition to SPF, DKIM provides a second layer of email authentication used to protect your domain from being spoofed.
All major providers like Google, Microsoft, and Yahoo check your email for a valid DKIM signature.
How does it work?
DKIM adds a digital signature in the email header which is secured with public-key cryptography. The signature can be used to easily verify that an email has originated from a specific domain, by decrypting the signature using the public key which is retrieved from your DNS records.
In general terms, the process works like this:
- A domain owner publishes a cryptographic public key as a specially-formatted TXT record in the domain’s overall DNS records.
- When an inbound mail server receives an incoming email, it looks up the sender’s public DKIM key in DNS. The inbound server uses this key to decrypt the signature and compare it against a freshly computed version.
- If the two values match, the message can be proved authentic and unaltered in transit.
Adding a DKIM Record
DKIM authentication is already configured on Merchant Central's server so that you only need to create a new record in your DNS to point to the correct server.
Create two new records in your DNS with the following info:
Type: CNAME
Host: iris._domainkey
Points to: dkim.iriscrm.com
TTL: 1 hour / 3600
Type: CNAME
Host: iris1._domainkey
Points to: dkim1.iriscrm.com
TTL: 1 hour / 3600
Note - It is very important that both records get created to your DNS configuration.
DKIM Record Check
To confirm that your DKIM record is configured correctly, you can use an online tool such as MX Toolbox.
- Go to https://mxtoolbox.com/dkim.aspx
- Enter your Domain name and selector 'iris' (eg. yourdomain.com:iris) and click DKIM Lookup
- Your DKIM record along with diagnostic information is now displayed on the page as shown in the below example (soft fails are fine):
The following table includes links to documentation for common providers.
Provider |
SPF |
DKIM |
|
||
Outlook |
Use DKIM to validate outbound emails sent from your custom domain |
|
Yandex |
||
Yahoo |
||
GoDaddy |
||
Bluehost |
||
Amazon SES |
These are external links and may be broken if the provider made an update. Please let us know about any broken links by sending an email to support@iriscrm.com.
What is DMARC?
Domain-based Message Authentication, Reporting & Conformance, or DMARC, is a protocol that uses Sender Policy Framework, (SPF) and DomainKeys identified mail (DKIM) to determine the authenticity of an email message.
DMARC makes it easier for Internet Service Providers (ISPs) to prevent malicious email practices, such as domain spoofing in order to phish for recipients’ personal information.
Essentially, it allows email senders to specify how to handle emails that were not authenticated using SPF or DKIM. Senders can opt to send those emails to the junk folder or have them blocked altogether. By doing so, ISPs can better identify spammers and prevent malicious emails from invading consumer inboxes while minimizing false positives and providing better authentication reporting for greater transparency in the marketplace.
Your DMARC record is published alongside your DNS records and includes including:
- SPF
- A-record
- CNAME
- (DKIM)
It is important to note that not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do and implementation is growing.
What are the benefits of DMARC?
There are a few key reasons that you would want to implement DMARC:
- ReputationPublishing a DMARC record protects your brand by preventing unauthenticated parties from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
- VisibilityDMARC reports increase visibility into your email program by letting you know who is sending emails from your domain.
- SecurityDMARC helps the email community establish a consistent policy for dealing with messages that fail to authenticate. This helps the email ecosystem as a whole become more secure and more trustworthy.
Adding a DMARC Record
To receive DMARC reports from the client's custom domain it must have DMARC policy added.
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@iriscrm.com; ruf=mailto:dmarc-reports@iriscrm.com; fo=1
TTL: 1 hour / 3600
Related Blogs:
Email and Your CRM: Best Practices for Successful Outgoing Email Management
Email and Your CRM: Best Practices for Successful Outgoing Email Management - Part 2