This page will explain all the issues, warnings, informational and best practice recommendations found in your domains SMTP configuration. 

SPF analyzer:

The following list of issues describe all possible issues found by the SPF analyzer. This analyzer could be run as part of the full suite analyzer or via the individual SPF analyzer. 

Issue 1: Your DNS record contains more than 10 DNS lookups

Explanation in plain words:
To protect from DNS DDOS attacks the SPF protocol has a safeguard in place that states a MTA (Mail transfer Agent) should only honor the first 10 DNS query’s of a SPF record.  If any query is done after the first 10 query`s the MTA should stop processing and return a permerror causing a negative SPF verdict. The EXP modifier does not count towards the SPF query limit.

What can I do to resolve this:
You should reduce the number of DNS query`s by either switching mechanisms (A or MX  to IPV4) or reduce the number of includes. Additionally you can also move sending 3rd parties (that consume a include ) to their own subdomain (preferred) or relay the mail via your own servers.   

Official IETF RFC 7208 text:
Some mechanisms and modifiers (collectively, “terms”) cause DNS queries at the time of evaluation, and some do not.  The following terms cause DNS queries: the “include”, “a”, “mx”, “ptr”, and “exists” mechanisms, and the “redirect” modifier. 

SPF Implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”. The other terms — the “all”, “ip4”, and “ip6” mechanisms, and the “exp” modifier — do not cause DNS queries at the time of SPF evaluation (the “exp” modifier only causes a lookup at a later time), and their use is not subject to this limit.

When evaluating the “mx” mechanism, the number of “MX” resource records queried is included in the overall limit of 10 mechanisms/modifiers that cause DNS lookups as described above.  In addition to that limit, the evaluation of each “MX” record MUST NOT result in querying more than 10 address records — either “A” or “AAAA” resource records.  If this limit is exceeded, the “mx” mechanism MUST produce a “permerror” result.

When evaluating the “ptr” mechanism or the %{p} macro, the number of “PTR” resource records queried is included in the overall limit of 10 mechanisms/modifiers that cause DNS lookups as described above.  In addition to that limit, the evaluation of each “PTR” record MUST NOT result in querying more than 10 address records — either “A” or “AAAA” resource records.  If this limit is exceeded, all records other than the first 10 MUST be ignored.The reason for the disparity is that the set of and contents of the MX record are under control of the publishing ADMD, while the set of and contents of PTR records are under control of the owner of the IP address actually making the connection. These limits are per mechanism or macro in the record, and are in addition to the lookup limits specified above.

MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host().  Such a limit SHOULD allow at least 20 seconds.  If such a limit is exceeded, the result of authorization SHOULD be “temperror”.

Issue 2: Your record contains PTR mechanisms or PTR mechanisms don`t have corresponding A records

Explanation in plain words:
The use of PTR records is discouraged do to the intensive DNS query`s that need to be performed making it more vulnerable to DNS issues. Both forward and backward lookups using the “in-addr.arpa” zone are being used. If PTR is used it is a best practice to have it as the last mechanism before the all mechanism. If there is no A record registered on the result of the reverse address lookup the check still fails. PTR is the only mechanisms that masks (does not expose) your infrastructure to the internet.

What can I do to resolve this:
If there is no business reason to use PTR move to a other mechanism. If the analyzer detected that the A record is not registered you should validate your A host name registrations for missing records. If PTR is not the last mechanism in the line you should move it backwards in your SPF record to the position just before the “all” mechanism.

Official IETF RFC 7208 text:
This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain. This mechanism SHOULD NOT be published. See the note at the end of this section for more information.ptr = “ptr” [ “:” domain-spec ]The <ip>’s name is looked up using this procedure:

• Perform a DNS reverse-mapping for <ip>
• Look up the corresponding PTR record in “in-addr.arpa.” if the address is an IPv4 address and in “ip6.arpa.” if it is an IPv6 address
  For each record returned, validate the domain name by looking up its IP addresses
• To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied. If they are exceeded, processing is terminated and the mechanism does not match.
• If <ip> is among the returned IP addresses, then that domain name is validated.Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain.
• If any do, this mechanism match If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues.
• This mechanism matches if :
  • the <target-name> is a subdomain of a validated domain name.
  • or the <target-name> and a validated domain name are the same.

For example, “mail.example.com” is within the domain “example.com”, but “mail.bad-example.com” is not. Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain’s hosts and the “ptr” mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead. It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.

Issue 3: White space detected in SPF record

Explanation in plain words:
The Analyzer has detected additional white space in the txt record that has no value. As additional white space chews up space in the limited room of a SPF and TXT record it is best practice to remove all the additional white space from your record.

What can I do to resolve this:
The Analyzer adds a “&” sign at the point where it detected the whitespace. Look at the record where the analyzer detected the white space and remove it from your record.

Official IETF RFC 7208 text:
None. This is a best practice.

Issue 4: An incorrect formatted IPv4 address has been detected

Explanation in plain words:
As IPv4 has a IETF standard all IPv4 addresses should be in the form of those standards. Your records contain a IPv4 that is either malformed or out of the range of the IPv4 standard. Most common issue is a typo in the record.

What can I do to resolve this:
Validate all IPv4 records and correct any malformed IPv4 address in your record with the correct address.

Official IETF RFC 791 text:
https://tools.ietf.org/html/rfc791

Wikipedia:
https://en.wikipedia.org/wiki/IPv4

Issue 5: An incorrect formatted IPv6 address has been detected

Explanation in plain words:
As IPv6 has a IETF standard, all IPv6 addresses should be in the form of those standards. Your records contain a IPv6 that is either malformed or out of the range of the IPv6 standard. Most common issue is a typo in the record.

What can I do to resolve this:
Validate all IPv6 records and correct any malformed IPv6 address in your record with the correct address.

Official IETF RFC 2460 text:
https://tools.ietf.org/html/rfc2460
Wikipedia:
https://en.wikipedia.org/wiki/IPv6

Issue 6: The SPF record does not contain a “EXP” Modifier

Explanation in plain words:
When ever a 3rd party or your own employees experience issues with sending email on behalf of your domain they might not have any clue about where to raise concerns. Especially for 3rd party`s it can take days to find the proper contact.
To mitigate the time of impact and streamline the process for a email administrative department it is wise to add a explanation with whom to contact in case of a SPF failure. this will speed up remediation. EXP records are only honored on the root SPF record and not in includes. If a redirect is encountered the redirected EXP will be honored.

What can I do to resolve this:
Add the “EXP” modifier to your text record and point it to the “TXT” record containing the correct procedure / contact point. This way any sender that sends mail on your behalf can contact you directly when facing issues.

Official IETF RFC 2460 text: 
If check_host() results in a “fail” due to a mechanism match (such as “-all”), and the “exp” modifier is present, then the explanation string returned is computed as described below. If no “exp” modifier is present, then either a default explanation string or an empty explanation string MUST be returned to the calling application.

The <domain-spec> is macro expanded (see Section 7) and becomes the <target-name>. The DNS TXT RRset for the <target-name> is fetched. If there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no “exp” modifier was given.

Issue 7a: Incorrect use of the “+all” mechanism

Explanation in plain words:
The most powerful mechanism that can be used in SPF is the “+all” as it has the option to validate multiple statements. “+all” should only be used  when you want to validate multiple mechanisms. Your record is currently using less than 2 mechanisms.

What can I do to resolve this:
Switch your mechanism to “-all” if this is a empty domain with no MTA`s sending email. 
Switch to “-all” and revert your current mechanism to produce a “+” verdict on a positive match instead of on a negative match.

Official IETF RFC 7208 text:
Say that your sender policy requires both that the IP address is within a certain range and that the reverse DNS for the IP matches. This can be done several ways, including the following:

• example.com.  SPF 
  • (“v=spf1 “
  • “-include:ip4._spf.%{d}”
  • “-include:ptr._spf.%{d} “
  • “+all” )
• ip4._spf.example.com.  SPF  “v=spf1 -ip4:192.0.2.0/24 +all”
• ptr._spf.example.com.  SPF  “v=spf1 -ptr +all”

This example shows how the “-include” mechanism can be useful, how an
SPF record that ends in “+all” can be very restrictive, and the use
of De Morgan’s Law.

Issue 7b: The “all” mechanism does not have a “-” quantifier

Explanation in plain words:
The “all” mechanism does not have a qualifier of “-“. This means that your SPF record is not set to advise a drop of all non authorized servers. This is ok if you are still testing your systems but you should work towards a “-all” implementation.

What can I do to resolve this:
Work on a DMARC project using tools from either this site or a 3rd party to test your domains mail flow. DMARC can help you gain insight in who sends on your behalf. Slowly work towards a SPF record where you only authorize servers you trust.

Official IETF RFC 7208 text:
None, This is a best practice.

Issue 8: Office 365 or a high volume server are not at the start of your SPF record

Explanation in plain words:
As a SPF record is being evaluated from left to right you can optimize it by defining your highest volume server first. In doing so you save the hole world some CPU power and DNS lookups due to the most mail is directly gaining a SPF verdict without having to process the entire record.

What can I do to resolve this:
Reorder your SPF record in sequence from highest volume to lowest volume.

Official IETF RFC 7208 text:
Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is the default result as described in Section 4.7. 
When a mechanism is evaluated, one of three things can happen: it can match, not match, or return an exception. If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing continues with the next mechanism. If it returns an exception, mechanism processing ends and the exception value is returned.

Issue 9: No EXP modifier exists in your SPF record

Explanation in plain words:
Whenever you are masking your allowed recipients or servers using SPF “exist” mechanism query`s your are stressing out DNS and MTA compute capacity. Exist should only be used if you have very special multiple verification needs or want to utilize macro capabilities to allow specific users / servers to have a SPF override. Using exist is usually less secure than the other mechanisms available.

What can I do to resolve this:
If you are not aware of all risks of using “exist” mechanism it is better to switch to the other mechanisms als “IP4” and remove the exists out of your SPF record or move users and servers that need this functionality to a sub domain.

See part 2 of the antispam counter measures explained of my blogpost series for more information.

Official IETF RFC 7208 text:
This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query.  It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted. The <domain-spec> is expanded as per Section 7.  The resulting domain name is used for a DNS A RR lookup (even when the connection type is IPv6).  If any A record is returned, this mechanism matches. Domains can use this mechanism to specify arbitrarily complex queries.  For example, suppose example.com publishes the record:

      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all

The <target-name> might expand to “1.2.0.192.someuser._spf.example.com”. This makes fine-grained decisions possible at the level of the user and client IP address.

Issue 10: The Query size of the TXT record exceeds the recommend size 

Issue 11: Subdomains are not protected from spoofing

TLS Analyzer:

The following list of issues describe all possible issues found by the TLS analyzer. This analyzer could be run as part of the full suite analyzer or via the individual TLS analyzer.

Issue 1: TLS Fallback SCSV is not supported

Risk assessment:
Low if SSL3.0 is disabled 
High if SSL3.0 is not disabled

Explanation in plain words:
Whenever a client ( sending MTA ) connects to a server (receiving MTA) and uses a TLS protocol to secure the connection, the client either directly connects at it`s set protocol version ( old client ) or tries to negotiate the highest possible security protocol ( new client). In all modern clients RFC 7507 should have been implemented. This means that whenever the client is advertising its capability`s or it Is forced on a lower than capable connection protocol it will send the TLS Fallback SCSV flag in the hello message. Whenever a server detects this flag and the client protocol is lower the servers highest security protocol the server will disconnect the session because a higher protocol level is available and should be used bij the client.

Currently most servers have disabled SSL3.0 due to weakness in the protocol, but TLS version 1.0 is still very common. As TLS 1.0 has a few known security vulnerability`s this means that TLS Faalback SCSV support can prevent a attacker from forcing the connection from TLS 1.2 ( with no currently known security breaches ) back to a TLS 1.0 version and abusing the current known breaches.

What can I do to resolve this:
Investigate if your edge MTA has support to enable  TLS fallback scsv support. If it is supported you could enable this functionality. Contact your vendor of your edge MTA to see if this can be enabled as this is not supported in al OS systems.

Additional reading:
IETF RFC 7507

Issue 2: Use Secure renegotiation

Risk assessment:
High

Explanation in plain words:
Secure renegotiation is a TLS renegotiation extension that prevents a data injection vulnerability. A hacker can perform a Man in the middle on a connection between 2 servers. He will than first inject his own data onto the conversation and than proxy the sending servers handshake to the target server. The target server believes that the data send by the hacker is actually coming from the original sender and accepts the data and the TLS handshake from the original sender and processes both client and hacker data as if it was send from the client. 

What can I do to resolve this:
When using OpenSSL you should upgrade to a version higher than 0.98l and enable secure renegotiation. For Microsoft products see MS10-049. any other OS or TLS implementation see CVE 2009 3555 that mentions fixes for a lot of OS and vendor based products.

Additional reading:
IETF RFC 5746
MS10-049
CVE 2009 3555

Issue 3: TLS compression is supported

Risk assessment:
Very low

Explanation in plain words:
At the moment of this writing there is no known exploit in use that abuses TLS compression support on the SMTP protocol. General discussions among security specialists agree that disabling compression is a good thing to do even for SMTP. Note that before the “CRIME” attack became know there was also no known exploit in use that abused TLS compression for TLS. Just because someone did not yet use it or found a case for it doesn`t mean someone else might. The scenario here is that a attacker could repeat multiple mails that where send and make minor adjustments to compare the differences in compression size to guess the content of a mail. A Possible secret that could be extracted or targeted would be a unauthenticated http link secret. These links are often used in unsubscribe links, Password reset links, fileshare links or calendar links , etc.  Although hopefully most of them are additionally secured with strong authentication, but if not this could be the entrance into a network especially if the secret is a password reset link that can be broken with social enginering. As the targeted user will see all attack mails the risk of this is assessed at very low.

What can I do to resolve this:
Investigate if your edge MTA has support to disable TLS compression. If it is supported you could disable this functionality. Contact your vendor of your edge MTA to see if this can be disabled as this is not supported in al OS systems.

Additional reading:
IETF RFC 3749
About the CRIME attack used in HTTP

Issue 4: No protection from TLS Heartbleed 

Risk assessment:
High

Explanation in plain words:
Whenever a malicious person sends a specially crafted command to a server accepting a TLS session it will exposes a small set of system memory in the response. This leaked data can contain anything from private keys to usernames and passwords. This is due to a faulty implementation of IETF RFC 6520 in OpenSSL version 1.0.1 / 1.0.1F. (versions 1.0.0 and lower are not affected)

What can I do to resolve this:
When you MTA or application uses OpenSSL you should upgrade it to a version higher than 1.0.1f or contact the manufacture for a updated version of the MTA or appliance. 

Additional reading:
CVE 2014 0160
IETF RFC 6520

Issue 5: Use of SSL protocols allowed for start TLS

Risk assessment:
Medium

Explanation in plain words:
Even though the biggest issues with SSL are based on web site hosted servers. The security issue for use of the SSL protocol to encrypt short lived SMTP sessions is debatable. It is still a fact that there a number of issues found and still not fixed with the protocol. Due to these issues multiple vulnerability’s impact the security of the protocol that make use of the protocol inadvisable. This was already before the “POODLE” attack finally killed of the protocol as a safe protocol.

What can I do to resolve this:
If you MTA is windows based you can use the “IIS crypto” tool created by Nartac to change your protocol and cipher suites.
If you MTA is any other brand/OS contact your vendor to validate how to change the protocols used for TLS sessions. 

Disable the SSL protocol with the tools mentioned above.

Additional reading:
OWASP Advisory
CVE 2014 3566
POODLE whitepaper by openssl
Exhange TLS best practise

Issue 6: Use of very weak RC2 cipher suites in start TLS

Risk assessment:
High

Explanation in plain words:
Even though the biggest issues with very weak ciphers are based on web site hosted servers, the security issue for weaker ciphers to encrypt short lived SMTP sessions is debatable. It is still a fact that a weak cipher makes it easy to break open the TLS channel and capture the data that is send between the 2 servers.

What can I do to resolve this:
If you MTA is windows based you can use the “IIS crypto” tool created by Nartac to change your protocol and cipher suites.
If you MTA is any other brand/OS contact your vendor to validate how to change the protocols used for TLS sessions. 

Disable the RC2 ciphers with the tools mentioned above.

Additional reading:
OWASP Advisory
CVE 2014 3566
POODLE whitepaper by openssl