Freestate Electric will require all incoming emails domains to meet certain minimum security requirments to be delivered and not sent to SPAM Quarentine.  We will be requiring a valid DMARC and SPF record for the domains sending emails.  These are the same requirments recomended by the FBI and used by major email providers like Google and Yahoo.

SPF Record (Required)

An SPF record defines the mail servers and domains that are allowed to send email on behalf of your domain. It also tells receiving servers what to do with messages after they’re checked. Receiving servers check your SPF record to verify that incoming messages that appear to be from your organization are sent from servers authorized by you. Domains can have one SPF record. However, the SPF record for a domain can specify multiple servers and third parties that are allowed to send email for the domain.

To learn how to create an SPF record please click here:  How to build an SPF Record

Domain SDR Score and Blacklistings

A blacklist, also known as DNSBL or RBL (DNS Blacklist or Realtime Blacklist respectively) is a spam blocking list, that can prevent your mail server from sending email. If you find your mail server has been blacklisted, some email you send may never be delivered. Currently, there are more than 100 organizations that run these lists and each one has different specifications for adding your domain or ip to their list.

Check the blacklist status of a domain:  Domain Blacklist

DMARC Record (Prefered, but not required at this time)

To check youir domain’s DMARC records click here:  DMARC Record Check

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a DNS TXT record that can be published for a domain to control what happens if a message fails authentication (i.e., the recipient server can’t verify that the message’s sender is who they say they are). A published DMARC record basically serves two purposes:

  1. Tells the recipient server to either: Quarantine the message, Reject the message, or Allow the message to continue delivery
  2. Sends reports to an email address or addresses with data about all the messages seen from the domain

Those two benefits alone drive home the huge value of setting up DMARC! Once published, a DMARC record is used by receiving mail servers (think Gmail or Yahoo! Mail) to determine what to do with a failed message. The receiving mail server at Gmail looks at the DMARC record for the policy to follow from the following choices:

  • Do nothing to the message
  • Quarantine the message
  • Reject the message

Action is taken by the recipient mail server on one of those three options above if the domain has published a DMARC record. If the domain has not published a DMARC record, the recipient server makes its own determination if the message should be delivered. With phishing, malware threats, and a variety of other security concerns, the direct value of being able to tell recipient mail servers to quarantine or reject messages that fail DMARC has now become the gold standard for sending legitimate email by blocking fraudsters.

Sample DMARC Record Explained

A DMARC record is essentially made up of a specified Host/Name (i.e., the record name – for example: is the Host/Name for MxToolbox) and tag-value pairs. Tag-value pairs are pretty much what they sound like. You have a tag (e.g., policy is represented by “p=”) and a value, such as “none”, which are paired to tell the receiving mail server what actions to take.

You can see this by looking at the following example record, which contains three tag-value pairs:

  • “v=DMARC1; p=none;”

The three tags are: v, p, and rua; the three values are: DMARC1, none, and The “v” tag is the version of DMARC, the “p” tag is the policy (meaning what action to take if the message fails DMARC), and the “rua” tag is the email address to send DMARC aggregate reports to. Below is an example of how a correctly formatted DMARC record should look when published at a DNS Host:


There is a total of 11 tags that can be applied to a DMARC policy. Of those 11, the “v” and “p” tags are required, and we also strongly recommend the “rua” tag in order to receive the reports. Below is a full list of tags that can be added to a DMARC record.

Tag Description
Version (v) The v tag is required and represents the protocol version. An example is v=DMARC1  More Info
Policy (p) The required p tag demonstrates the policy for domain (or requested handling policy). It directs the receiver to report, quarantine, or reject emails that fail authentication checks. Policy options are: 1) None 2) Quarantine or 3) Reject.  More Info
Percentage (pct) This DMARC tag specifies the percentage of email messages subjected to filtering. For example, pct=25 means a quarter of your company’s emails will be filtered by the recipient.  More Info
RUA Report Email Address(es) (rua): This optional tag is designed for reporting URI(s) for aggregate data. An rua example is  More Info
RUF Report Email Address(es) (ruf) Like the rua tag, the ruf designation is an optional tag. It directs addresses to which message-specific forensic information is to be reported (i.e., comma-separated plain-text list of URIs). An ruf example is  More Info
Forensic Reporting Options (fo) The fo tag pertains to how forensic reports are created and presented to DMARC users.  More Info
ASPF Tag (aspf) The aspf tag represents alignment mode for SPF. An optional tag, aspf=r is a common example of its configuration.  More Info
ADKIM Tag (adkim) Similar to aspf, the optional adkim tag is the alignment mode for the DKIM protocol. A sample tag is adkim=r  More Info
Report Format (rf) Forensic reporting format(s) is declared by the DMARC rf tag.  More Info
Report Interval (ri) The ri tag corresponds to the aggregate reporting interval and provides DMARC feedback for the outlined criteria.  More Info
Subdomain Policy (sp) This tag represents the requested handling policy for subdomains.  More Info