Auto forward your emails to Vtiger Managing User Profiles Automate Outgoing Emails in Email Settings Automation - Assignment Rules Set up Multi-path Workflows Creating a Scheduled Workflow Automation - Workflow Scheduler Workflows in Vtiger CRM Vtiger Webforms Set up a Workflow Action to Create Event Set up a Workflow Action to Create Records Set up a Workflow Action to Create Task Set up a Workflow Action to Invoke Custom Function Set up a Workflow Action to Create an SMS Task Setting Up a Workflow Action to Send Emails Workflow Action to Update Fields Automation - Webhook Workflow Automation - Expressions Workflow Configuring Business Hours Configuration - Company Details Configuration - Consents Configuring the Customer Portal Maps in Vtiger CRM Configuration - Usage Details Configuring Encrypted Data Fields in Vtiger CRM Configure Picklist Dependencies Considerations for Deactivating Vtiger Users Configuring Field and Record Displays Create Reminders for Records and Inbox Creating a Grid Field Type Dealing with Currencies and Taxes Enable Desktop Notifications on Chrome Web Browsers Vtiger CRM Add-ons IMAP Configuration - 2-way sync between Vtiger and IMAP providers Setting up Autopay & Payment Gateways Inventory - Tax Management Inventory - Terms and Conditions Login to Vtiger on SSO SAML using ADFS Mailroom Functionality for Different Scenarios Manage Multiple Currencies Marketing and Sales - Deal to Project Mapping Lead Conversion Data Mapping Marketing and Sales - Profile Scoring Using the Module Label Editor Configuring Module Numbering Configure My Preferences Feature My Preferences - Calendar Settings Tags in Vtiger My Preferences - Notification Preferences SAML Support in Vtiger CRM Vtiger Mailroom Configuring a Relationship Between Modules Settings - Left Menu Configuring Global Picklists in Vtiger Settings - Set up your Support Team Settings - Start Up Page Configuring Picklist Values Configuring Modules Using Module Builder SLA Policies in Vtiger Troubleshooting Login Issues Add-Edit Unsubscribe Links in your Email Template 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 Setting Up Websense Trackers Vtiger Websense Widgets Creating Custom Modules in Vtiger CRM Configuring Dependent Fields and Blocks for Modules Formula Fields Configuring App Passwords for Gmail Outgoing Server and Yahoo Mail Customizing Module Layouts Configuring Module Layouts & Fields Auto forward Emails from Microsoft Office 365 Automation - SMS Reply Actions Duplicate Record Prevention in Vtiger CRM Generate and Manage Third-party App Passwords in Yahoo Configuration - Storage Guard Customizing your Self-Service Portal Theme Using CSS Styles Adding Hidden Fields to a Webform Login Page Customization Creating Custom Filters Adding a local DNS Entry

Introduction

Email is one of the easiest and most effective ways to reach your customers. But at the same time, it’s also a common target for problems like spam, fake senders, and phishing attacks. To protect against these risks, email providers and internet standards groups created special security checks called email authentication protocols.

These checks help confirm whether an email really comes from the domain (or website address) it claims to be sent from.

The three most common authentication methods are:

• SPF (Sender Policy Framework): Confirms which servers are allowed to send emails for your domain.
• DKIM (DomainKeys Identified Mail): Ensures that your email content hasn’t been changed along the way.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Defines how receiving servers should handle emails that fail SPF or DKIM checks and provides reports to the domain owner.

When these methods are set up, they make it much harder for fake emails to get through, keep your domain reputation safe, and improve the chances that your messages land in your customer’s inbox instead of the spam folder. 

Now we’ll take a closer look at how each one works.

Sender Policy Framework (SPF)

SPF is an email authentication protocol that allows a domain owner to specify which mail servers are authorized to send emails on behalf of their domain.

How does it work?

The domain owner publishes an SPF record in their DNS, listing authorized servers or IP addresses.

• When an email is received, the recipient server checks the sending server’s IP against the SPF record.
• If it matches, the email passes SPF authentication; otherwise, it fails.

To learn more about creating a SPF record, click here.

To learn more about creating a CNAME record, click here.

Example: Grasspods, a company using Vtiger, adds vtiger.com as an authorized sender in its DNS records. When John (a Grasspods user) sends an email, Gmail checks the DNS for grasspods.com and sees that Vtiger is authorized. Gmail then marks the email as Passed SPF.

  

Why it matters:

• Reduces the risk of phishing attacks using your domain.
• Improves deliverability by signaling to ISPs that your emails are legitimate.
• Prevents legitimate messages from being blacklisted as spam.

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.
 

SPF record example: v=spf1 include:vtigermails.com -al

Adding Vtiger to the SPF Record for Your Domain

To authorize Vtiger to send emails on behalf of your domain, you’ll need to update your domain’s DNS settings and add an SPF record. The steps vary depending on your domain hosting provider.

• Bluehost: Edit DNS records
• Cloudflare: Manage SPF records
• GoDaddy: Add an SPF record, Add an SPF record to my domain
• Google Domains: Edit DNS records
• HostGator: Edit DNS records
• HostMonster: Edit DNS records
• Hover: Edit DNS records
• Namecheap: Configure SPF records
• Squarespace: Edit DNS records

  

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is an email authentication method designed to prove that an email really came from the claimed sender and that it hasn’t been changed along the way. It works by attaching a digital signature to each email. This signature is unique to the sending domain and allows the receiving server to verify the message’s authenticity.

Think of it as a tamper-proof seal for emails. If the seal is intact, the receiver knows the message is genuine and unchanged. If the seal is broken, the system flags it as suspicious.

To learn more about DKIM, click here.

How does DKIM work?

The DKIM process can be broken down into three key steps:

Step 1: Selecting which parts of the email to sign

• The sending domain decides which elements of the email should be protected.
• These elements could include parts of the header (like the From field, Subject, or Date) or even the body of the email.

Whatever is selected must remain unchanged during transit—if any of the signed elements are altered, DKIM validation will fail.

Step 2: Creating a digital signature

• Once the parts are chosen, the sending system creates a cryptographic hash (a unique fingerprint) of that information.
• This hash is then encrypted using a private key that belongs to the domain.
• Only the domain owner has access to this private key, which ensures that no outsider can forge a valid signature.
• The encrypted hash (the DKIM signature) is added to the email header before the message is sent.

Step 3: Validation by the recipient server

• When the recipient’s mail server receives the email, it notices the DKIM signature in the header.
• It then performs a DNS lookup to retrieve the public key published by the sending domain.
• Using this public key, it decrypts the DKIM signature back into the original hash.
• The server then generates its own hash of the signed elements and compares it with the decrypted hash.
  • If they match, the message is confirmed to be authentic and unaltered.
  • If they don’t match, it means the message was tampered with or the signature was invalid.

Example

Imagine Yahoo forwards an email to Grasspods. If Yahoo modifies the body of the email, for example, by adding a line such as forwarded by Yahoo Mail then the body no longer matches the original hash. If the body were part of the signed elements, the DKIM check would fail.

However, if only the From field (in the header) were included in the DKIM signature, the validation would still pass because the modified body was not part of the signed content.

This flexibility allows domain owners to choose what is most important to protect, while still allowing for legitimate forwarding or minor changes in transit.

Why does DKIM matter?

• Protects integrity: Ensures that emails haven’t been tampered with during transit.
• Builds trust: Adds credibility to your domain and helps prevent bad actors from spoofing it.
• Improves deliverability: Mailbox providers (like Gmail, Yahoo, and Outlook) are more likely to place DKIM-signed emails in the inbox instead of the spam folder.
• Works well with other protocols: DKIM is often used together with SPF and DMARC to create a strong, layered defense against email fraud.

Limitations of DKIM

• Implementation can be complex, requiring key generation, DNS setup, and email server configuration.
• Adoption is slower compared to SPF due to the technical setup.
• DKIM results are not visible to end-users and rely on email providers for validation.
• Does not fully prevent spoofing on its own and works best with SPF and DMARC

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM.

It allows domain owners to:

• Specify who is authorized to send emails on behalf of their domain.
• Instruct receiving servers on how to handle emails that fail authentication.
• Receive reports about email activity related to their domain.

A DMARC record is published in your domain’s DNS as a TXT record. It helps receiving servers verify whether an email claiming to come from your domain is legitimate.

By implementing DMARC:

• You reduce phishing and spoofing attempts.
• You improve email deliverability.
• You strengthen trust in your brand’s communication.

How DMARC Works with SPF and DKIM

DMARC works in combination with:

• SPF, which verifies that the sending server is authorized.
• DKIM, which ensures that the message content has not been altered.

If an email fails SPF or DKIM checks, DMARC determines how the receiving server should handle it based on the policy you define.

The receiving server may:

• Accept the email
• Move it to spam
• Reject it entirely

Sample DMARC Record

A DMARC record is added to your DNS as a TXT record. A sample record looks like this:

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; sp=none; aspf=r;

Tag Explanation

• v=DMARC1 – Specifies the DMARC version.
• p=none – Defines the policy (monitoring only, no enforcement).
• pct=100 – Applies the policy to 100% of messages.
• rua=mailto:[email protected] – Email address to receive aggregate reports.
• sp=none – Subdomain policy.
• aspf=r – SPF alignment mode.

DMARC Policies

DMARC provides three policy options to define how failed emails should be handled:

• None: Emails are monitored only. No enforcement is applied.
• Quarantine: Emails that fail validation are typically sent to the spam folder.
• Reject: Emails that fail validation are rejected completely and not delivered.

Note: The domain owner can request a policy, but the final decision to enforce it is made by the receiving mail server.

DMARC Requirements and Authentication

Major email providers such as Google and Yahoo require domains to have a DMARC policy configured.

To ensure successful email delivery:

• The domain used in the From address must be authenticated.
• SPF, DKIM, and DMARC records must be properly configured in DNS.

You can configure the DMARC policy for your domain from the Email Settings page under the DMARC Security Authentication section

DMARC Record Verification in the CRM

The CRM checks whether your sending domain has a valid DMARC record configured.

• If no DMARC record exists, a warning message is displayed when adding an email address in the Compose Email window.
• You can navigate to User Menu > Settings > Email Settings.
• Under Sender Authentication Domains, select the domain.
• The DMARC Records block displays the current status.

If a DMARC policy exists, the system shows that a policy is configured. If not, the CRM will display the recommended DMARC record (including Host and TXT values) to help you configure it correctly.

Verifying DMARC Configuration for Your Domain

You can verify whether DMARC is configured for your domain using an external lookup tool.

Follow these steps to verify:

1. Go to the MXToolbox DMARC Lookup page.
2. Enter your domain name (e.g., example.com).
3. Click DMARC Lookup.
4. Review the displayed DMARC record.

If no DMARC record is found, you must create one in your DNS. You may begin with a basic monitoring policy, such as:

p=none

Once verified, you can gradually move to stricter policies such as quarantine or reject.