SPF DKIM and DMARC Explained With ISP Support

Last Updated, 2020-07-17 email-authentication

SPF DKIM and DMARC are simply a set of email authentication methods to prove to ISPs and mail services that senders are truly authorized to send email from a particular domain and, are a way of verifying your email sending server is sending emails through your domain. This is done to prevent someone else from sending emails on behalf of you by using your domain address. No matter how it happens, it is better to prevent this.

Not just that, but verifying your account with these will make you a valid sender in the eyes of the server on the receiving end. These parameters can be easily adjusted in the domain panel and adding TXT records in the domain DNS.

SPF (Sender Policy Framework): SPF authentication works by strictly specifying the number of allowed domain IPs that can send emails from your domain. While setting up SPF, the domain owner can add a file or record on the server which tells the receiving server what domains are actually allowed to send emails.

DKIM (DomainKeys Identified Mail): DKIM authentication similar to SPF the DKIM is added as a TXT record by adding it in your domain panel. It makes sure that none of the emails going from server to server is not tampered by anyone in the middle and email can be clearly identified from the other end.

DMARC(Domain-based Message Authentication): DMARC builds on SPF and DKIM to validate emails further by matching the validity of SPF and DKIM records. This enables you to set policies and get generated reports in case the DMARC validation fails.

FAQ

Difference between the working
ISP Wise Support for email Authentication
ISP recommendations for Email Authentication

Difference between the working

Working on each of these authentication mechanisms differs according to the objective they are trying to achieve. Let us see how the working of each of these validation differs.

SPF

Installation: Txt record in domain DNS needs to be set, this record will contain a bunch of valid server IPs that can send emails through the specific domain.

Structure:

v=spf1 include:54443444.domain.net ~all

Working: Every email you send has a Return-path header associated with it. This return path is the email address to which email delivery notifications are sent regarding email bounce and spam. The domain of that sending server's domain path is extracted, and its DNS record details are fetched.

Now since you have added the SPF credentials in the domain's TXT record. This will contain a list of IP addresses that are allowed to send emails. If the fetched email's server IP is in the SPF record, then everything is passed for the SPF validation.

In the case it doesn't contain the IP of the received email server, then it is up to the service on the email receiving end to decide what actions to take on that email.

What happens when the SPF validation fails is entirely up to the service that is commencing the validation. Still, it is recommended to add SPF validation, just to add an extra layer of validation to your emails.

DKIM:

Installation: First, a public key and you have to specify the private key has to be generated, and the public key hash has to be set in the TXT record, and the email signing has to be enabled to send email signatures.

Structure:

DKIM Set in txt record with the public key

k=rsa; p=MIGfMA0GCksjlkdixcieJDDSFIELDSKFLCBiQKBgQDLMMExLiGRqzJkNdNIjUnLX7JL0wjbwwENDoXgJIBisIsrofLPetZM401dioNU8k//Yw5/iyzhyrWsIyINyyHs77EoDFDDEEFFEKJKLJHLKifLN51IIvwIDAQABQp6nIyi5oioyZh+1jDXoCDDFDSFEEDSFSEFE85N7b76aTtHmy2wTgR2LFS

DKIM Signature in email with the private key

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=fnc; d=env.etransmail.com; h=To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Content-Transfer-Encoding:List-Unsubscribe:Date;
bh =DEEFSFDSFWEEEfdfgdsgeERFSFMps774=; b=oDQdtCY85ckhjSDFSDFEdsfsdfdsfasedf9+sVkuMD5bpevJB4SB3+HEP0pikyDQpeLEWOeC2rwyrhDucDYctVYRr6DSFDFEdsfsdfdsfasedf9+s
afasdfawessfF8DFEdsfsdfdsfasedf9+sVkuMD5bpevJB4SB3+HEP0pikyDQpeLEWOeC2rwyrhDucDYctVYRr6DSF

Working: Even though DKIM and SPF have a similar step of implementation of adding a txt record in the DNS, we still have to generate a public key and a private key in case of DKIM implementation.

The private key which is hidden on your email server side is used to encrypt the email signature. This encrypted signature is then sent as a header in each and every email sent from the email server.

The public key hash is then stored in a DNS TXT record. This key with the private key received int the email signature is then used to decrypt and verify the email signature by the email receiving server.

Where bh = Email signature, b = The Encrypted key and, d = Signing domain. These values are validated and tested for verification against the credentials in the DKIM text record that is in the email headers. The action that needs to be taken after the validation failure depends upon the policy of the email service doing the DKIM verification.

This is a sample of DKIM authentication results in Gmail for reference.

DMARC

Structure:

 _dmarc.mydomain.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:dmarc-aggregate@mydomain.com\; ruf=mailto:dmarc-afrf@mydomain.com\; pct=100"

Implementation:

Add DMARC record in the domain TXT record which should look something like this

 _dmarc.mydomain.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:dmarc-aggregate@mydomain.com\; ruf=mailto:dmarc-afrf@mydomain.com\; pct=100"

The parameters that are set in this code snippet have specific functions:

p= DMARC Policy.
v=Version.
rua=Mailbox to which aggregate reports should be sent.
ruf=Mailbox that will be receiving forensic reports.
pct= Percentage of mail to which the domain owner would like to have its policy applied.
You have to define policies how the message has to be dealt with if the validation fails

Here are these policy parameters:

p=none: Treat the mail the same as it would be without any DMARC validation
p=quarantine: Accept the mail but place it somewhere other than the recipient's inbox (typically the spam folder)
p=reject: Reject the message outright

Working:

DMARC works in conjunction with SPF and DKIM Records, which means, if you want to implement a DMARC record, you have to set SPF and DKIM records first.

Then we set the DMARC settings in the TXT records in your domain's DNS settings.

DMARC works based on achieving three things

Email authentication
Define action taken after authentication fails
Enable reporting of the domain doing the spoofing

When an email is sent to the recipient server, it checks the DMARC record will have the parameters that have been discussed above. The DMARC tests the following things:

Ip address validation in the SPF record
Validation of DKIM signature
Then it checks domain alignment that consists of the following checks:
- In the SPF record, the message's From domain and its Return-Path domain must match.
undefined

If the validation fails then based on the policy defined in the DMARC record the necessary action is taken and a report is generated and sent to the respective email id's set in the DMARC record for the reports.

If you want to check the validation pass of the SPF DKIM and DMARC when you have received your emails is to see the original message to see the email body and headers in detail.

In Gmail you can do this by selecting the "Show Original" option.

At the top of the page now opened you will see the email Authentication passes.

ISP Wise Support for email Authentication

Not all of the ISPs provide support for every kind of email validation. Here is a list of multiple ISPs that offer support for SPF DKIM and DMARC respectively.

Gmail

SPF: Yes
DKIM: Yes
DMARC: Yes

Yahoo

SPF: Yes
DKIM: Yes
DMARC: Yes

Outlook

SPF: Yes
DKIM: Yes
DMARC: Yes

Zoho

SPF: Yes
DKIM: Yes
DMARC: Yes

AOL Mail

SPF: Yes
DKIM: Yes
DMARC: Yes

ISP recommendations for Email Authentication

Gmail

Google recommends using SPF with DKIM and DMARC for email authentication with their system. This means you will be a more valid user for Gmail if you send an email validated by all three email validators.

As far as SPF goes. Failing in it alone won't mark you as spam in the G-suite spam filter or drop your message. But failing in SPF and DKIM would be actionable by google to be added to spam or being dropped.

As far as DKIM validation is concerned. Gmail is a little strict on this. If you want your emails to be signed by the DKIM signature, it is recommended to get your DKIM key signed with at least 1024 bits. Now, it is not that you will be straightforwardly rejected for using 512-bit signing, but, For a long term usage of the same keys might cause a problem.

One thing to take from this is that to use DKIM with Gmail, it is better to use 1024 keys for encryption.

It is also recommended to rotate your encryption for DKIM regularly.

Google Supports DMARC implementation and works as per the DMARC credentials and policies defined by the user.

For more information from google docs about email validation on google, please check this link.

Microsoft Outlook

Microsoft is very strict with the SPF validation in Emails. It is mostly seen that they tend to lean on the user's Id based verification using the SFP credentials. It has been a known phenomenon of people experiencing email delivery problems with them if you haven't set the SPF for Microsoft outlook inboxing.

If you don't want any problems with email delivery with outlook, you should definitely use the SFP for validation.

Microsoft 365 automatically creates a DKIM setup for 'onmicrosoft.com' domains. So if you are already using any domain address which is 'subdomain.onmicrosoft.com', then you won't need to set up you DKIM.

For users with custom domains, if you don't opt for configuring DKIM with your emails, Microsoft 365 creates a public and private key and signs up your email with DKIM signing with their default configuration.

With the DMARC record Outlook is a bit lenient since even if you have the policy for DMARC to reject the emails, instead of discarding the email immediately, they will add it to the spoofed emails. After that, you can choose to take action on these emails whichever way you want. This is done to prevent some of the valid emails being rejected.

Microsoft recommends all three validation SPF DKIM and DMARC for a better overall validation of Microsoft outlook.

If you are not sure how to implement email validation on Microsoft outlook, you can check this link

Yahoo

Yahoo allows the following list of selected internal domains to be used for SPF validation:

- yahoo.net

- yahoo.com

Yahoo has recently updated their default DMARC policy with "p=reject" for emails going from yahoo domains. This means all emails sent from yahoo.com that are not from yahoo servers will be rejected immediately.

For more help on Yahoo email authentication check these links:

AOL

DKIM validation from AOL is done on the incoming emails, and they basically use this authentication to evaluate the reputation of the Ip addresses.

AOL checks the DMARC records for the inbound emails. Similar to Yahoo, AOL rejects emails that are validated through DMARC and have failed the validation.

Zoho

Zoho only supports the DKIM policy for the emails that are generated at the Zoho's server and sent to an external server. The emails that are delivered indirectly to external servers or emails that are not created at the Zoho's end are not supported or validated through the DKIM.

Some links for the Zoho mail configuration for email validation.

Conclusion

Doing email validation on your emails is vital for email delivery in this day and age. The policies are only going to get stricter in the future due to numerous email spoofing and breach attempts. Just be sure when you are sending emails through certain ISP domain, check the validation policies on their site to better understand how you can make the best of it with the email deliveries.