Three important tools to prevent Spoofing and Validate Email Authenticity
I) Sender Policy Framework (SPF)
This is the email authentication protocol that defines all the senders that are authenticated to send emails on behalf of your domain.
SPF protects a company’s domain from spoofing and improves its sender reputation with MBPs (Mailbox Providers) such as Google, Microsoft, Yahoo etc.
The major threats from unauthenticated email are Spam, Spoofing, Phishing
Spam is unwanted email that promotes scams, gathers information, or attacks the email infrastructure of an organization to disrupt email services.
Phishing is a type of attack through email to manipulate recipients into taking action to accomplish the attacker’s goal.
Spoofing is a cyberattack technique used to convince the recipient that their messages are being sent by someone other than the apparent sender. Email spoofing is a part of BEC (Business Email Compromise) and Whaling Attacks
BEC – Security exploits in which the attacker targets an employee who has access to company funds and convinces the victim to transfer money.
Whaling Attacks – In this type of phishing attack the attacker targets high-profile employees such CEO, CFO to steal sensitive information from the company.
When anyone sends an email to our domain’s email accounts, the receiving server checks the sender’s return-path address and verifies if the domain in use has a valid SPF record.
The SPF authentication works with a special DNS TXT record for a domain. This record list all mail servers authorized to send emails on behalf of a domain.
If SPF passes the email is authenticated and delivered to the recipients’ mailbox. If it fails, the email may be rejected or marked as spam.
Example SPF TXT Record
v=spf1 a ip4:00.00.00.00 ip4:00.00.00.00 ip4:00.00.00.00/26 include:spf.protection.outlook.com include:_spf.domain.net -all
- v (required tag) – at present accepted version is spf1
- all (required tag) – It should be placed at the end of the SPF record. Depending on the qualifiers used ~, +, -, ? (this mechanism indicates how the recipient should treat emails from non-authorized sources)
- a – record tag allows the SPF to validate the sender by the domain name’s IP address (if not specified it takes the value of the current domain)
- ip4 OR ip6 – IPV 4 and 6 addresses that are allowed to send emails on behalf of the domain,
- mx – record tag checks the MX record of the mail server (if not specified it takes the value of the current domain)
- ptr – Not Recommend as it spends too many DNS lookups.
- exists – Checks whether an A record exists or not for the mentioned domain.
- include – List all the sending sources under this tag lets the recipient know that you verify all the added domains/subdomains as legitimate sources.
Note: If your SPF record exceeds the 10-DNS-lookup limit, SPF email authentication returns a permanent error showing “too many DNS lookups”. This error is interpreted in DMARC as a fail. Therefore, when this happens, it has a negative impact on your email deliverability in the “eyes” of spam filters.
II) DomainKeys Identified Mail (DKIM)
This is an email security standard that helps to detect whether messages are altered in transit between sending and receiving mail servers.
- The sending server creates DKIM signature – a body and headers of your message hashed with your private key.
- When the message arrives to the receiving server which check the mail message wasn’t meddled in transit.
- The receiving server runs DNS query to the sending server and retrieves the public key and then it builds its own hashes and compares with the ones received in the message.
- If the key validation fails, the email message may be rejected or go to spam folder. If the key and the signature match the mail will reach the relevant inbox.
The DKIM authentication which uses public key cryptography works with a special DNS TXT record for a domain. This record stores the public key the receiving mail server will use to verify the message signature. The major reasons to use the DKIM.
- To verify the legitimacy of the email message
- To create a reputation for the email domain
Example DKIM TXT Record
v=DKIM1; k=rsa; t=s; s=email; p=MIIBI……GTRYGS
- v specifies DKIM version (DKIM1)
- t indicates the domain is testing DKIM (Value y OR s)
- g granularity of the public key.
- k Cryptosystem key type used default rsa
- p public key
- h indicates which hash algorithms are acceptable. (The default value is to allow for all algorithms but you can specify sha1 and sha256)
- n is a note field intended for administrators, not end users
- s indicates the service type to which this record applies. The default value is a wildcard asterisk (*) which matches all service types. you can mention email.
To create the DKIM for your own Mail server or for the Mail Relay.
- 1. Install Opendkim Package
- 2. Generate Public and Private DKIM Keys
- 3. Configure OpenDKIM
- 4. Configure Postfix/Sendmail with OpenDKIM
- 5. Publish DNS TXT Record
- 6. Test DKIM
II) Domain-Based Message Authentication Reporting and Conformance (DMARC)
Domain-based Message Authentication Reporting and Conformance (DMARC) is an additional method of authenticating email messages. It acts as a gatekeeper to inboxes and, if set up properly, can prevent phishing and malware attacks from landing in the inbox.
A DMARC policy determines what happens to an email after it is checked against SPF and DKIM records. An email either passes or fails SPF and DKIM. The DMARC policy determines if failure results in the email being marked as spam, getting blocked, or being delivered to its intended recipient.
DMARC essentially handles the questions: What should happen to messages that fail authentication tests (SPF and DKIM) – – Should they be Quarantined? Rejected? or, should we let the message through even if it failed to prove its identity?
DMARC policies can contain instructions to send reports about emails that pass or fail DKIM or SPF
Example DMARC TXT Record
v=DMARC1; p=none; rua=mailto:support@domain.com; ruf=mailto:support@domain.com; fo=1;
- v DMARC version (DMARC1)
- p Instructs the receiving mail server what to do with messages that don’t pass authentication
- none — Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the record.
- quarantine — Mark the messages as spam and send it to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages.
- reject —Reject the message. With this option, the receiving server usually sends a bounce message to the sending server.
- rua Email address to receive reports about DMARC activity for your domain.
- ruf Email address to receive the Failure reports are also called forensic reports. (Google not support)
- sp Sets the policy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC policy for your subdomains.
- pct Specifies the percent of unauthenticated messages that are subject to the DMARC policy
- adkim Sets the alignment policy for DKIM, which defines how strictly message information must match DKIM signatures . s means that DKIM checks are “strict.” This can also be set to “relaxed” by changing the s to an r, like adkim=r.
- aspf Sets the alignment policy for SPF, which specifies how strictly message information must match SPF signatures. s is the same as adkim=s, but for SPF.
Note that aspf and adkim are optional settings. The p= attribute is what indicates what email servers should do with emails that fail SPF and DKIM.
Brand Indicators for Message Identification (BIMI)
It is an email standard that lets you add a brand logo to authenticated messages sent from your domain. Email clients that support BIMI display your brand logo next to your messages in the inbox. With BIMI, brand logos and logo ownership are verified with Verified Mark Certificates (VMC), so recipients can be sure logos displayed in their inbox are legitimate.
BIMI notes – If your domain uses BIMI,
- The DMARC p option must be set to quarantine or reject. BIMI doesn’t support DMARC policies with the p option set to none
- The DMARC policy must have a pct value of 100. BIMI doesn’t support DMARC policies with the pct value set to less than 100.
Conclusion – SPF, DKIM, and DMARC are collections of free email authentication methods used to verify that senders are legitimately authorized to send email from a specific domain.