Articles in this section
Auto-forwarding your emails to Vtiger Automate Outgoing Emails in Email Settings Automation - Approvals Automation - Assignment Rules Automation - Multi-path Workflows Automation - Scheduled Workflows Automation - Scheduler Automation - Standard Workflows Automation - Webforms Automation - Workflow Action - Create Event Automation - Workflow Action - Create Records Automation - Workflow Action - Create Task Automation - Workflow Action - Invoke Custom Function Automation - Workflow Action - SMS Task Automation - Workflow Action - Send Mail Automation - Workflow Action - Update Fields Automation - Workflow Action - Webhook Automation - Workflows - Vtiger Expressions Configuration - Business Hours Configuration - Company Details Configuration - Consents Configuration - Customer Portal Configuration - Maps Configuration - Usage Details Configure Encrypted data fields in Vtiger CRM Configure Picklist Dependencies Considerations for Deactivating Vtiger Users Control Fields and Record Displays using Configuration Editor Create Reminders for Records and Inbox Create a field of a Grid type Customize your self-service portal theme using CSS styles Dealing with Currencies and Taxes Enable Desktop Notifications on Chrome Web Browsers Extensions - Extension Store IMAP Configuration - 2-way sync between Vtiger and IMAP providers Inventory - Payments and Subscriptions Inventory - Tax Management Inventory - Terms and Conditions Login to Vtiger on SSO SAML using ADFS Mailroom Functionality in Different Scenarios Manage Multiple Currencies Marketing & Sales - Forecast and Quota Settings Marketing & Sales - Pipelines and Stages Marketing and Sales - Deal to Project Mapping Marketing and Sales - Lead Conversion Data Mapping Marketing and Sales - Profile Scoring Module Management - Labels Editor Module Management - Module Numbering My Preferences My Preferences - Calendar Settings My Preferences - My Tags My Preferences - Notification Preferences SAML Support in Vtiger CRM Set up Mailroom Settings - Configure Module Settings Settings - Create Dynamic Fields and Layouts Module Management - Creating a Relationship Between Modules Settings - Customize Records and Fields for your Business Settings - How to set email autoresponder to Webform submission? Settings - Left Menu Settings - Manage Global Picklists in Vtiger Settings - Set up your Support Team Settings - Start Up Page Settings - Working with Picklist Values Module Management - Module Builder Support - SLA Policies Troubleshooting Login Issues Unsubscribe your Email User Management - Authentication User Management - Encrypted Field Access Logs User Management - Groups User Management - Login History User Management - Profiles User Management - Roles User Management - Settings Log User Management - Sharing Rules User Management - Users User Management - Vtiger Support Access Vtiger Buzz - Chrome Extension for Notifications Vtiger Implementation wizard Vtiger Language Support Websense - Trackers Websense - Widgets Configuration - Storage Guard Adding a local DNS Entry Adding Additional Hidden Fields to a Webform Configuring Dependent Fields and Blocks for Modules Duplicate Prevention in Modules Module Management - Modules Module Management - Module Layouts & Fields

Authenticate Emails with SPF, DKIM, and SenderID

Bindu Rekha Babu
1 Jun, 2021 - Updated 3 months ago



Authenticate your emails with SPF, DKIM and Sender ID


SPF (Sender Policy Framework)


SPF is an email authentication protocol that allows the owner of a domain to authorize other email servers to send email on behalf of this domain.


How does SPF authentication works?


DNS Administrator should add SPF record in the Domain Name System (DNS) listing the domains or IP addresses that are authorized to send email on behalf of this domain.


During an SPF check, recipient email server looks up the SPF record by looking up the domain name listed in the “envelope from” address (also referred to as return-path address). If the IP address / domain name of the server sending email isn’t listed in that SPF record, the message fails SPF authentication.


For example, Grasspods is using Vtiger. Grasspods administrator added as an authorized sender in DNS record.


John, one of the users in Grasspods, sends an email to a contact from Vtiger. Contact’s email server is Gmail.

When the email is received by Gmail, it will query the DNS records for, and will find that the IP addresses used by Vtiger are indeed authorized to send messages on behalf of, and will mark that email as ‘Passed’.


Let’s take a look at an SPF policy in action and see how the process unfolds.



Who uses SPF authentication?


SPF – or Sender Policy Framework (see the Wikipedia article) – is being used to authenticate emails by large providers such as Charter, Comcast, Earthlink, Juno/Netzero, Gmail, RoadRunner, Verizon, and others.


Why does SPF authentication matter?


An SPF-protected domain is less attractive to phishers, and is therefore less likely to be blacklisted by spam filters, ensuring legitimate email from that domain is delivered.


If SPF check fails, Emails might be put into Spam folder instead of Inbox of your prospect. Having an SPF policy provides an additional trust signal to ISPs so you can increase the likelihood that your emails arrive in the inbox.


v=spf1 ~all


How much does the SPF authentication cost?


There is no charge. The changes to the DNS settings, typically performed by your hosting company or network administrator, only require a few minutes.


How to add vtiger to the SPF record for your domain?


DKIM (DomainKeys Identified Mail)


DKIM is an email security standard designed to ensure that messages aren’t altered in transit between the sending and recipient servers.


How does it work?


There are a lot of steps. But, we’ll break it down into manageable sections for you.



Step 1: Identifying what parts of a message are to be signed using DKIM signature


First, a sender decides which elements of the email they want to include during the signing process. They can choose to include the whole message (header and body) or just focus on one or more fields of the email header. The elements they wish to include in their DKIM signing process must remain unchanged in transit, or the DKIM signature will fail authentication.


For example, if an email is forwarded from Yahoo! to grasspods, Yahoo! may add a line of text at the top of the email (e.g. “forwarded by Yahoo! mail”). At that point, the body of the email has been changed and, if the body were included in the DKIM signing process, the DKIM authentication would fail for the forwarded email.


However, if only an element of the header, such as the “from” field were included in the DKIM signature, and the message was forwarded from Yahoo! to grasspods, the DKIM authentication would pass. Since, the part of the message that was changed, was not signed by DKIM.


Step 2: The encryption process


So how does this signing process sounds? Cryptography is at the center of it.


The sender will configure their email platform to automatically create a hash of the parts of the email they want to sign. Hashing is the process that converts readable text into a unique textual string.


For example:


From: Sender
Subject: DKIM>


maps to the following unique hash string: 2s9krlv9pabwqldvirgamlgqytqal


Before sending the email, that hash string is encrypted using a private key. The private key is assigned to a unique combination of domain and selector; Only the sender has access to the private key. After the encryption process is complete, the email will be sent.


Step 3: Validating the DKIM signature with a public key


The email provider receiving the email sees that it has a DKIM signature, which reveals which “domain/selector” combination signed the encryption process. To validate the signature, the mailbox provider will run a DNS query to find the public key for that domain/selector combination.


This public key has the unique characteristic that it is the only match for the private key that signed the email, also known as a “key pair match.” The key pair match enables the email provider to decrypt the DKIM signature back to the original hash string.


The email provider then takes the elements of the email signed by DKIM and generates its hash of these elements. Finally, the mailbox provider compares the hash it generated with the decrypted hash from the DKIM signature. If they match, we know that

  • The DKIM domain really does “own” the email otherwise, the decryption process wouldn’t have worked in the first place.
  • The elements of the email signed by DKIM were not changed in transit (if they were changed, the hashes would not match).


Why it matters?


Email providers who validate DKIM signatures can use information about the signer as part of a program to limit spam, spoofing, and phishing, although DKIM does not tell receivers to take any specific actions. Depending on the implementation, DKIM can also ensure that the message has not been modified or tampered with in transit.


The problem with DKIM is that because it’s more difficult to implement, fewer senders have adopted it. This spotty adoption means that the absence of a DKIM signature does not necessarily indicate the email is fraudulent. Therefore, DKIM alone is not a universally reliable way of authenticating the identity of a sender. In addition, the DKIM domain is not visible to the non-technical end user, and does nothing to prevent the spoofing of the visible “header from” domain.


Sender ID


Sender ID is an email authentication protocol. It was developed by Microsoft to prevent against domain spoofing and phishing exploits by verifying the domain name from which e-mail messages are sent.


Sender ID validates the origin of e-mail messages by verifying the IP address of the sender against the legitimate owner of sending domain.




Exchange uses Sender ID for validation. By using Sender ID, you will ensure that your email is delivered to recipients that use Exchange


How it Works?


The process of extracting domain using sender ID check is as follows

  1. When an e-mail message is received by the inbound mail server it will check for Sender field.
    • If Sender field exists, then use the domain in this field.
    • If it doesn’t exist, then use the domain in the From field.



Using domain in the From field recipient server looks up From domain’s published DNS record and determines whether the sending server’s IP address matches the one on in the record. If the record matches, the e-mail is authenticated and delivered to the recipient. Otherwise, the message is either discarded or returned to the sender as a bounce e-mail.


In the below example, since there is no Sender field, the domain is using the From field. Here, the From field is SenderID next checks the SenderID record in DNS. If it does not exist, it falls back to the SPF record.




Subject: Special offer
From: John>


Say the sending email server IP is - and when it does a SenderID lookup on the From domain, it will result in the below record.


v=spf2.0/pra ~all


The “include” says to do a SenderID lookup for


v=spf1 ip4: ~all


Here SenderID looks for the spf2.0 syntax. Since it doesn’t find spf2.0, it falls back to spf1 syntax. Then it compares against, and finds that the IP is in the range. Later passes the SenderID check.

Home Privacy Policy Terms of Service Security Center Policy & Legal Center Contact Us
© Copyright 2021 Vtiger. All rights reserved.
Powered by Vtiger
Facebook Twitter Linkedin Youtube