Authenticate your emails with SPF, DKIM, and Sender ID.
Watch these videos to learn more
SPF (Sender Policy Framework)
SPF is an email authentication protocol that allows the owner of a domain to authorize other email servers to send an email on behalf of this domain.
How does SPF authentication work?
DNS Administrator should add an SPF record in the Domain Name System (DNS) listing the domains or IP addresses that are authorized to send an email on behalf of this domain.
During an SPF check, the recipient email server looks up the SPF record by looking up the domain name listed in the 'envelope from' address (also referred to as the 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. The Grasspods administrator added vtiger.com as an authorized sender in the grasspods.com DNS record.
Example
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 the SPF check fails, Emails might be put into the Spam folder instead of the 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 include:vtigermails.com ~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.
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?
The following steps (separated into manageable sections) will tell you how.
Step 1: Identifying what parts of a message are to be signed using the 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 sound? 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 [email protected]>
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.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 challenging 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 is an email authentication protocol. It was developed by Microsoft to prevent 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 the sending domain.
Advantage
Exchange uses Sender ID for validation. By using Sender ID, you will ensure that your email is delivered to recipients who use Exchange.
How does it work?
The process of extracting the domain using the sender ID check is as follows:
Using the domain in the From field, the recipient server looks up the From domain’s published DNS record and determines whether the sending server’s IP address matches the one 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 grasspods.com. SenderID next checks the SenderID record in DNS. If it does not exist, it falls back to the SPF record.
Example
HELO vtigermails.com
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
Subject: Special offer
From: John
QUIT@grasspods.com>
Say the sending email server IP is - 1.2.3.4, and when it does a SenderID lookup on the From domain grasspods.com, it will result in the below record.
v=spf2.0/pra include:vtigermails.com ~all
The “include” says to do a SenderID lookup for vtigermails.com
vtigermails.com
v=spf1 ip4:1.2.3.0/24 ~all
Here, the SenderID looks for the spf2.0 syntax. Since it doesn’t find spf2.0, it falls back to spf1 syntax. Then, it compares 1.2.3.4 against 1.2.3.0/24 and finds that the IP is in the range. Later, it passes the SenderID check.