DMARC Record - Explained

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishing and email spam are the biggest opportunities for hackers to enter the network. If a user clicks on a malicious email attachment, it can compromise an entire enterprise with ransomware, crypto-jacking scripts, data leakages, or privilege escalation exploits.

Source - From the Internet

DMARC is an acronym for “Domain-based Message Authentication, Reporting, and Conformance”. It’s an email authentication, policy, and reporting protocol that’s actually built around both SPF and DKIM. It has three basic purposes:

  • Verifies that a sender’s email messages are protected by both SPF and DKIM,
  • Tells the receiving mail server what to do if neither of those authentication methods pass, and
  • Provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation (it is kinda a big fellow in the ground).

Since DMARC uses both SPF and DKIM, you may wonder why it’s even necessary. Well, it’s simple: DMARC basically builds on SPF and DKIM to ensure that, when an email is received, the information contained in both records matches the “friendly from” domain (e.g., me@my-domain.com) that the user actually sees and the "from address" that is in the message’s header. This is what the folks at Dmarcian, a company founded by one of the primary authors of the DMARC specification, call “Identifier Alignment.”

CHECKING FOR DMARC RECORDS

DMARC Check Tool by MX Toolbox
  • Enter your domain name for which you want to check DMARC record. For example, GitHub.com
  • If you get the results in the following way congrats you already have your DMARC configured and your webmail is safe from phishing.
DMARC Record Example
If the website does not have the Records, check the below section.

CREATE DMARC RECORDS

Once you have both SPF and DKIM in place, then it’s time to create your DMARC record. The easiest way to do this is to use a DMARC wizard. There are many sites that offer such a tool: MXToolbox, DMARC Analyzer (requires to sign up), Dmarcian, and more. The Dmarc.org site also provides a list of utilities for generating DMARC records, DMARC lookup and parsing, message validation, and more. Most of these sites also have tools to validate your DMARC record once DNS propagation has taken place.

Regardless of the tool you use, a DMARC record utilizes a number of “tags”. There are really only 2 tags that are actually required: “v” and “p”. Other tags are purely optional, and DMARC experts kind of disagree on which optional tags are recommended and which are not. Let’s look at the required tags first:

  • v - This is the version tag, just like with SPF. It MUST be “DMARC1” and be the first tag listed in the DMARC record.
  • p - This is the policy tag. It tells the receiving server which policy to apply to a message that fails DMARC: “none” or do nothing to a message, “quarantine” a message, or “reject” the message.
Optional tags include the following:
  • pct - This is the percent of suspicious messages that the DMARC policy applies to. Of course, the default is 100, but it can be set to whatever you want it to be.
  • rua=mailto:address@company.com - This tag tells receiving servers where to send aggregate reports. These reports provide visibility into the health of the sending server by helping to identify potential authentication issues or malicious activity. These reports are sent daily, so, ideally, if you want reports sent, they’re sent to a mail address set up specifically FOR these reports and not a domain admin account.
  • fo - This tag lets receiving servers know that samples of messages that fail either SPF and/or DKIM should be returned to the sender. There are four value options for this tag:
    • 0: Generate a DMARC failure report if both SPF and DKIM fail to produce a “Pass” result. This is the default option.
    • 1: Generate a DMARC failure report if both SPF and DKIM produce something other than a “Pass” result. This is the recommended option.
    • d: Generate a DKIM failure report if the message had a DKIM signature that failed the evaluation, regardless of why.
    • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of why.

So what does a DMARC record look like? Let's look at the record for SmarterTools:


v=DMARC1; p=none; rua=mailto:fbl@smartertools.com; fo=1


As you can see, we have both required tags: v and p, set, but a few optional tags as well. For the policy tag (p) it is set to “none”. So, we’re basically collecting feedback on messages but we’re not necessarily “interrupting the flow of messages”, even if they fail SPF and/or DKIM. From a DMARC rollout perspective, this is a prudent course of action. That’s because while DMARC is a serious way to catch potential phishing emails, it’s not a widely adopted policy. Therefore, many domains don’t have SPF or DKIM set up, let alone both. So for the time being, simply watching messages and seeing their disposition, without quarantining or outright rejecting them, is the best way to go for DMARC implementation.


You might also interested in,

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishin...

Are SPF, DKIM, and DMARC records Necessary

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishing and email spam are the biggest opportunities for hackers to enter the network. If a user clicks on a malicious email attachment, it can compromise an entire enterprise with ransomware, crypto-jacking scripts, data leakages, or privilege escalation exploits.

Source - From the Internet

Having those three records in place is considered the best practice. As the saying goes, “An ounce of prevention is worth a pound of cure.” For email, this has never been more true. Having all three records in place shows that your email domains are truly who they say they are. It also shows that you as an administrator, and your domain administrators as well, are all serious about ensuring you’re following best practices and doing your part to prevent spam, phishing, and other email security issues.

You might also interested in,

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishin...

DKIM Record - Explained


SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishing and email spam are the biggest opportunities for hackers to enter the network. If a user clicks on a malicious email attachment, it can compromise an entire enterprise with ransomware, crypto-jacking scripts, data leakages, or privilege escalation exploits.

Source - From the Internet

DKIM is an acronym for DomainKeys Identified Mail. When sending an email from a server that has DKIM configured, the server will hash the body and the header of the email separately. It will then,  create a signature with a private key which will send along with the email.


When the receiver receives the email, it will do a DNS request to the domain that the email claim it is from. By doing so, the receiver will get the public key which is the DKIM-record. It will then with the key can verify the signature is correct or not, and by doing so it will confirm that the sender is genuine and the mail has not been manipulated on its way there.

CHECKING FOR DKIM RECORDS

DKIM Records Lookup by MX Toolbox
  • Enter the domain name and selector (A DKIM selector is text, that is added with the domain to create a unique DNS record used during DKIM. This allows multiple keys to exist under one domain which allows for different signatures to be created by different systems, date ranges, or third-party services). For example, GitHub.com.
  • If you get the results in the following way that means the website has DKIM records and it's safe.

If the website does not have the Records, check the below section.

Create DKIM Records

Ideally, your mail server will provide a tool that allows you to create the information right on the server. (For SmarterMail users, information on “Setting Up Email Signing” is available in the Help documentation). Regardless of how you create your record, the following information is part of it:
  • s - This is the selector and it indicates the record “name” used with the domain to locate the public key in DNS. The sender creates this (again, ideally automatically).
  • d - This indicates the domain, used by the sender. Used with the selector record and helps locate the public key.
  • p - This is the actual public key that gets published to DNS as part of the record. Therefore, it will look like a random set of upper and lower case letters, numbers, and some punctuation marks.

These are the three key parts of a DKIM record. Other tags are available, but these three are the most commonly used. Therefore, a typical DKIM record will look like this:

2B8U4DAB93D58YR._domainKey.yourdomain.com;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV

In the above, you’ll find the following:

  • Selector (s): 2B8U4DAB93D58YR
  • Domain (d): yourdomain.com
  • Public Key (p): MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV
The other information in the record will be added automatically, but it is generally the same regardless of how the record is created. (I.e., _domainKey).
You might also interested in,

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishi...

SPF Record - Explained


SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishing and email spam are the biggest opportunities for hackers to enter the network. If a user clicks on a malicious email attachment, it can compromise an entire enterprise with ransomware, crypto-jacking scripts, data leakages, or privilege escalation exploits.

Source - From the Internet

SPF is an acronym for “Sender Policy Framework”. As with all three checks, SPF is a DNS TXT record that specifies which IP addresses and/or servers are allowed to send email “from” that particular domain. It’s essentially like the return address that’s placed on a letter or postcard that lets the recipient know who sent the communication. The idea is that if they know who sent them the letter, the recipient is more likely to open it. 

Sender Policy Framework (SPF) hardens your DNS servers and restricts who can send emails from your domain. SPF can prevent domain spoofing. It enables your mail server to determine which message came from the verified domain. SPF has three major elements: a policy framework as its name implies, an authentication method, and specialized headers in the actual email that convey this information. SPF was first proposed with IETF standard 4408 back in 2006 and has been updated most recently to standard 7208 in 2014.


CHECKING FOR SPF RECORDS

SPF Checker website by MX Toolbox
  • Enter the domain name and search for the records. For Example, GitHub.com.
  • If you get the results in the following way that means the website has SPF records and it's safe.
SPF Records of GitHub
If the website does not have the Records, check the below section.

Create SPF Records

An SPF record is a very simple string that can be easily created and added to DNS records by a domain administrator as a TXT entry. Few things to keep in mind:
  • The SPF version being used.
  • The IPs that are authorized to send an email for the domain.
  • Any third-party domains that are authorized to send an email.
  • An ending "all" tag indicates that the policy should be applied when a "receiving server" detects an IP/domain that’s not part of the SPF record.

v=spf1 ip4:22.23.24.25 include:another-domain-that-can-send-email-for-us.com -all

  • v=spf1 - This simply states that version 1 of SPF is being implemented. There is no other version at this point, so this should always be “v=spf1”, at least until another version is released. (If you’re curious, there was another version at one time -- SenderID -- but it’s been discontinued.)
  • ip4:22.23.24.25 - This is the IP address of the mail server and/or domain that’s authorized to send an email. Multiple IPs can be used. So if your mail provider rotates IPs, all IP addresses can be listed either individually (ip4:22.23.24.25 ip4:12.13.14.15) or through a CIDR range (ip4:22.23.24.0/20). Note that both IPv4 and IPv6 addresses should be listed if any used by the mail server.
  • include:another-domain-that-can-send-email-for-us.com - This is a secondary domain that is authorized to send an email on behalf of the primary mail domain. If multiple domains are authorized, they should all be listed as separate “includes.” However, a maximum of 10 includes is allowed for any sending domain.
  • all - The “all” tag basically tells the receiving server how it should handle all messages sent from a domain if it sees a domain in the header that’s not listed in the SPF record. There are a few options, and these options are dictated by the character that precedes the “all” tag. These are:
    • -all (dash all) - This is a hard fail. This means that servers that aren’t listed in the SPF record aren’t recognized or authorized to send an email for the domain, so the email should be rejected by the receiving server.
    • ~all (tilde all) - This is a soft fail. Basically, that means that the server isn’t listed in the SPF record, but it should not be flat-out rejected by the receiving server. Instead, the message will be marked as possible spam.
    • +all (plus all) - THIS IS NOT RECOMMENDED. This tag essentially means any domain listed is authorized to send an email, even if it’s not listed in the SPF record.

You might also be interested in,

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishi...

Get Your First Private Invite In HackerOne


In order to get private invites Bug Hunters must have a good reputation and valid bugs but for the newcomers, it would be a bit hard to hunt on the public programs as they have been there for a long time and many researchers have already participated and swept the bugs in it. 


A private invite could really encourage a newcomer to hunt and increase their chances of getting the first valid bug. HackerOne hosts a CTF, where any participants who score 26 points would get a private invite. We are going to show you how to solve the CTF in an easy way and get your first private invite.

Let's get started


This will give you 28 points and a private invite to start with :)

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

In order to get private invites Bug Hunters must have a good reputation and valid bugs but for the newcomers, it would be a bit ...