• Contact Us
  • Pricing
  • Search
  • Register
  • Login
  • DNS Tools
    • MX Records
    • A Records
    • CNAME Record
    • PTR Record
    • SPF/TXT Records
    • NS Records
  • Domain Tools
    • ARIN Records
    • WHOIS Records
  • Blacklists
    • Blacklist Checker
    • Whitelist Checker
    • Email Blacklist Removal Tool
  • Email Tools
  • Port Scans
  • Other Tools
    • IP Tools
      • IP Address Converter
      • IP Address Locator
      • IP Range To CIDR
    • Chrome Extension - Email Deliverability Checker
    • 3D Trace Route
  • Blog
    • First Time Sender
      • Email Certification
      • Email Throttling
      • IP Warming
    • Formatting Emails
      • For Browsers
      • For Devices
      • For Email Clients
    • How To Avoid
    • How To Set Up
    • Mail Tester Guide
      • Email Headers Explained
      • MX Records, PTR Records, and Reverse PTR Records AKA rDNS
      • RFC Syntax Checking
      • Email Port Checks
      • SPF Record and Alignment
      • DKIM Signatures and Alignment
      • DMARC Validation
      • Mail Tester Test Tool
    • Measuring Peformance
      • Bounces
      • Clickthrough Rates
      • Open Rates
    • Related Resources
      • Abuse Contacts
      • Common Ports
      • DMARC and the Contact Us Form
      • Email Identifier
      • Email Headers
      • Email Statistics
      • How Email Works
      • How to Treat Spammers
      • Securing Your Server
    • Rules to Follow
      • Can Spam Act
      • Postmaster Guidelines
  • Member Services
    • Members Area
    • Community Forums
    • Blacklist Monitoring
    • Bulk Email Validation Tool
    • Complete Monitoring Solution
    • Domain Name Monitoring
    • Feedback Loop Submissions
    • Full Port Scan Monitoring
    • Mail Tester Pro Tool
    • Mail Miner
    • Spam Detector Toolbox
    • Trusted Sender Site Seal

Mail Tester Knowledge Base


If you stumbled on this page through a search engine result, please view this page first Mail Tester

There are many different reasons why your email authentication test results can be failing. Below are sections of actual results that people received while testing their email authentication. Some of the information below has been changed to protect the innocent!

PTR Record Check Test Results:


rDNS PTR Records
Records Results
Domain: mx2.hotmail.com
- Type: MX
- IP Address: 5.54.188.72
- ARPA Record: 72.188.54.65.in-addr.arpa.
- rDNS PTR Record: Critical - Not Found
- rDNS PTR Test: Failed - No RDNS PTR Record
- RDNS PTR Count: 0 - Not Found

In the example above, the PTR Record is missing on one of the MX records of HOTMAIL.COM. For a company that uses different outgoing IP's, then they do incoming IP's (Like Hotmail) this is ok as long as its not the LSIP (LAST SENDING IP ADRESSS), which will be listed under (TYPE as LSIP). But for most small and medium size business their incoming and outgoing mail servers use the same IP and every MX record should have a rDNS PTR Record.

rDNS PTR Records
Records Results
Domain: mx2.hotmail.com
- Type: MX
- IP Address: 65.55.37.88
- ARPA Record: 88.37.55.65.in-addr.arpa.
- rDNS PTR Record: col0-mc2-f.col0.hotmail.com
- rDNS PTR Test: Warning - PTR Record doesn't Match Domain Name
- RDNS PTR Count: 1 Found - Passed

In the example above, notice the warning in orange, the PTR Record does not match the DOMAIN, if this was the LSIP it can cause spam triggers in certain spam engines.

Email Port Check Test Results:


If your mail server receives mail, it's critical that port 25 is open. Actually, if port 25 isn't open on your mail server, chances are you're not going to get a reply from our email authentication auto-responder. The other ports are mainly used by email clients and should relay emails though authenticated connections. Most Smartphones connect to mail servers using IMAP SSL in order to receive and send email.

Email Port Checks for: lukesallnatural.com
Protocol Results
SMTP (Port 25): Connection Established
- Extensions: SIZE, 8BITMIME, PIPELINING, AUTH, STARTTLS, HELP
- Server Greeting: lukesallnatural.com
- SSL Hostname: vps.lukesallnatural.com
- SSL Subject: E=ssl@vps.lukesallnatural.com, CN=vps.lukesallnatural.com, OU=Unknown, O=Unknown, L=Unknown, S=Unknown, C=US
- SSL Issuer: E=ssl@vps.lukesallnatural.com, CN=vps.lukesallnatural.com, OU=Unknown, O=Unknown, L=Unknown, S=Unknown, C=US
- SSL Error: Certificate Chain is Invalid
- SSL Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
- SSL Error: Certificate Does Not Match Hostname
SMTP SSL (Port 465): Unable to Establish Connection
POP3 (Port 110): Connection Established
- Extensions: TOP, USER, LOGIN-DELAY, PIPELINING, UIDL, IMPLEMENTATION
- SSL Valid: No SSL Certificate Found
POP3 SSL (Port 995): Unable to Establish Connection
IMAP (Port 143): Unable to Establish Connection
IMAP SSL (Port 993): Connection Established, but unable to communicate

In the example above, we attempt to establish communication on the most common mail ports. As long as a connection can be established on one of the ports it generally means you have the capabilities to send and receive mail. If we are unable to communicate, for example, with POP3 SSL, that most likely means your firewall is blocking port 995 or your mail server is not configured to receive and/or send email via POP3 SSL.

Back to the example, two certificate errors were encountered on port 25.
  • Certificate Does Not Match Hostname -The SSL Certificate on your mail server does not match the hostname of your mail server. In the example above, your mail server is "webmail.domain.com" and the SSL Certificate is for "mail.domain.com", which does not match.
  • Certificate Chain is Invalid - Most SSL Certificates have a chain. They are commonly glued together by an intermediate and a trusted root certificates. There can be one to many certificates in a chain. At some point in the chain the certification is broken.

    Common causes for a broken chain are:
    • One or more certificates in the chain are missing.
    • One or more certificates in the chain are expired.
    • One or more certificates in the chain are not valid.
    • The root certificate is not trusted.
On port 110, communication was established but there was no support for SSL which means all traffic over that port will be unencrypted and sent in plain text. This is a very big risk.

On Port 993, a connection was made, but we were unable to communicate. What this can mean is that your server is using old/obsolete cipher suites like RC4. Most secure servers do not allow older communication protocols to run on their servers, like ours. It's a very easy test to confirm using OpenSSL libraries, making the connection to your mail server port and look for the cipher being used. In IIS, you can use IISCyrpto to see if you have RC4 enabled. In apache, it's located in this file "/etc/apache/conf.d/security".

SMTP Banner Reverse DNS Check

Protocol Results
- Server Greeting: lukesallnatural.com
SMTP Banner Reverse DNS Check: Failed - The SMTP banner issued by your email server did not contain the hostname or MX records we resolved for your server’s IP address

In the example above, we isolated one test (Which is part of a broader email port check). The STMP Banner Reverse DNS Check is performed by many different ISP, ESP if this test fails, mail will automatically be rejected in some cases. The Server Greeting also known as the SMTP Banner should contain the name of your server. What happens is a DSN lookup is preformed on the IP address of the mail server to get the PTR Record, that PTR Records Hostname is then used to find all MX records for it, if not it uses itself as the MX Record. If one of those MX records match the SMTP Banner Hostname. The Match is then successful.

SSLv3 - Poodle Vulnerability Test

Protocol Results
- SSLv3 Disabled: No - You should Disable SSLv3 - It's open to the POODLE Vulnerability.

In the example above, we isolated one test (Which is part of a broader email port check). The SSLv3 Check is used to determine if your mail server allows communications over this protocol. If your server does communicate over SSLv3, you are exposed to different Vulnerabilities, the most well known is the POODLE Vulnerability. It is recommened that you disable SSLv3.

SPF Check Test Results:

Publication: RFC 4408
SPF Records
SPF Check: Failed
SPF Record in TXT (TYPE 16): av=spf1 mx ~all

In the above example the issue is that the SPF record syntax is invalid. It should start with "v=spf1" not "av=spf1".

Publication: RFC 4408
SPF Records
SPF Check: Failed
SPF Record in TXT (TYPE 16): v=spf1 ip4:10.10.1.10 -all

A lot of times when SPF fails it's because it's supposed to. In the example above the email originated from a different IP than 10.10.1.10, which is the only IP allowed to send mail for this domain.

Publication: RFC 4408
SPF Records
SPF Check: Soft Fail - Learn how to set up SPF records by clicking here: SPF Records
SPF Record in TXT (TYPE 16): v=spf1 a mx a:example.com include:_spf.google.com ~all

When you see a Soft Fail it's because the SPF checked didn't pass but instead of failing it, you're instructing the receiving mail server to soft fail it. The "~" in “~all” means to soft fail the email.

Publication: RFC 4408
SPF Records
SPF Check: Passed
SPF Record in TXT (TYPE 16): v=spf1 a mx ~all
SPF Record in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here


In the above record the SPF (TYPE 99) record is not found. This is very common as it's a new record type and a lot of DNS software currently doesn't support it. In the future this will be required and the TXT (TYPE 16) will be phased out.

Publication: RFC 4408
SPF Records
SPF Check: Not Found - Learn how to set up SPF records by clicking here: SPF Records
SPF Record in TXT (TYPE 16): v=spf1 mx include:_spf.google.com ~all
SPF Record in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here


If you see results like this (which is obviously an error) then you do have an SPF record but the SPF Check shows as not found. This is what I will consider to be a DNS issue.
  • The SPF Check is done off Public DNS, but the record lookup was done against your authoritative server - which basically means the changes you just made have not propagated throughout the Internet yet. Wait a few minutes and try again.
 
Publication: RFC 4408
SPF Records
SPF Check: Failed
SPF Record in TXT (TYPE 16): v=spf1 a mx ip4:67.215.65.132 ip4:209.174.179.4 ip4:209.174.179.2 ip4:67.215.65.132 include:secureserver.net ~all
SPF Record in TXT (TYPE 16): v=spf1 a mx ip4:206.166.98.145/24 -all ip4:50.194.72.241 ip4:outlook.com -all ~all
SPF Record in TXT (TYPE 16): v=spf1 ip4:50.194.72.241 include:outlook.com -all
SPF Record in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here
TXT (TYPE 16) Count: Failed: 3 - TXT (TYPE 16) Records were found - only 1 is allowed.

This means that you have 3 Authentication records and only 1 is allowed for SPF. You'll need to combine all the statements into 1 SPF record or use multiple includes.

Publication: RFC 4408
SPF Records
SPF Check: Passed
SPF Record in TXT (TYPE 16): v=spf1 mx ip4:69.61.58.0/24 -all
(TYPE 16) Syntax: Passed
SPF Record in SPF (TYPE 99): v=spf1 mx ip4:69.61.58.0/24 ip4:166.102.123.133/32 ~all
(TYPE 99) Syntax: Passed
SPF/TXT Match: Failed - your SPF records in TXT (TYPE 16) and SPF (TYPE 99) must match.

TYPE 16 and TYPE 99 Records for SPF must match excately to be considered valid.

Publication: RFC 4408
SPF Records
SPF Check: Failed
SPF Record in TXT (TYPE 16): v=spf1 mx ip4:mail.boumatic.com -all
(TYPE 16) Syntax: Failed
ip4:mail.boumatic.com - IP Address is Invalid
SPF Record in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here

We do extensive SPF Record Syntax Checking. If your SPF record is constructed wrong, mailtest will tell you the reason why. In the example above the SPF contains an URL in the IP4 tag when it should be an IP Address.

Sender ID Test Results:

Publication: RFC 4406
Sender ID
Sender ID Check: Failed - Learn how to set up Sender ID by clicking here: Sender ID Records
Sender ID Record: spf2.0/pra ?all

Sender ID is an authentication standard published by Microsoft. This check is related to have either v=spf1 TXT records or spf2.0/pra records published. If the spf2.0/pra records are not present it will perform the check with the v=spf1 record.

Publication: RFC 4406
Sender ID
Sender ID Check: Temporary Error - Learn how to set up Sender ID by clicking here: Sender ID Records
Sender ID in TXT (TYPE 16): spf2.0/pra ?all

Temporary errors normally occur when the test is unavailable.

Publication: RFC 4406
Sender ID
Sender ID Check: Soft Fail - Learn how to set up Sender ID by clicking here: Sender ID Records
Sender ID in TXT (TYPE 16): spf2.0/pra ~all
Sender ID in SPF (TYPE 99): spf2.0/pra ~all

When you see a Soft Fail, it's because the Sender ID check didn't pass, but instead of failing it you're instructing the receiving mail server to soft fail it. The "~" before the all on the Sender ID Record, means to soft fail the email.
 
Publication: RFC 4406
Sender ID
Sender ID Check: Not Found - Learn how to set up Sender ID by clicking here: Sender ID Records
Sender ID in TXT (TYPE 16): Not Found - Learn about TXT (TYPE 16) Click Here
Sender ID in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here

In this example you don't have any Sender ID records set up. You simply need to follow the documentation and use the SPF Wizard to generate the record you need and insert it into your DNS.
 
Publication: RFC 4406
Sender ID
Sender ID Check: Passed
Sender ID Record: Uses SPF implementation above

What this means is that your Sender ID check is based off of your SPF Records since you don't have any specific spf2 records located in DNS.

Identifier Alignment Test Results:


Identifier Alignments are primarily used in DMARC authentication. Alignments for SPF can be tested even if SPF is not present. DKIM however needs a DKIM-Signature record to be tested. If you don't have DKIM authentication in your email, this test result will not be present.

Information: Identifier Alignments
SPF Alignment Test (Used in DMARC ASPF Test)
Mail From/Return Path Domain: mail271.us4.example.com
From Domain: domain.com
SPF Identifier Alignment: Unaligned - Learn about SPF Identifier Alignments by  clicking here:Identifier Alignments

In the example above, the SPF Identifier Alignment is Unaligned. We mark this in Orange, because it's not a failure but it's something to be concerned about if you set up a DMARC Policy. If the domain endings matched exactly, they would be in 'Strict' alignment, if they match partially they would be in 'Relaxed' alignment.

Information: Identifier Alignments
DKIM Alignment Test (Used in DMARC ADKIM Test)
DKIM d= Tag: mail271.us4.example.com
From Domain: domain.com
DKIM Identifier Alignment: Unaligned - Learn about SPF Identifier Alignments by  clicking here:Identifier Alignments

In the example above, the DKIM Identifier Alignment is Unaligned, we mark this in 'Orange', because it's not a failure, but it's something to be concerned about if you set up a DMARC Policy. If the domain endings matched excately they would be in 'Strict' alignment, if they match partially they would be in 'Relaxed' alignment.

Domain Key Check Test Results:


Domain Keys is considered to be an obsolete standard, replaced by DKIM. Some older mail servers still take this standard into account. If you're publishing a Domain Key it would be in your best interest to ensure it's correct or remove it all together. Many of the newer mail servers will still validate Domain Keys and if it's set up incorrectly they will penalize your emails.

 
Domain Keys Check (Obsolete)
Signature Found: Yes
Signature Verified: Failed - Bad Signature
From Signed: The FROM field must be signed: DomainKeys Signature Standards

In this example it clearly states that the "FROM" is unsigned. Please check the "h" tag. You will see that it's missing the "FROM". This information will be found in the "Domain Keys Additional Information (Obsolete)" section in the test. It might also be missing the "h" tag altogether.
Domain Keys Check (Obsolete)
Signature Found: Yes
Signature Verified: Failed - Bad Signature
From Signed: Yes

In this example the signature didn't verify. This means the "signature-data" or "b=" tag, which is located in the "Domain Keys Additional Information (Obsolete)" section of the test, didn't match the hash generated from the public key located in "Public Domain Key (Obsolete)" section of the test results. There can be a number of things that can cause this:
  • The most common is that the email was altered after it was sent out
  • The signing mail server signed it improperly
  • Our Domain Key Signature Verifier has a bug in it - If you believe this is the case let us know, we will look into it.

Domain Keys Check (Obsolete)
Signature Found: Yes
Signature Verified: Yes
From Signed: Yes
Restricted Headers Signed: Yes - Return-Path, Received, Comments, Keywords, Bcc, Resent-Bcc, DKIM-Signature should not be signed.

Certain headers should not be signed, for instance, if you sign the BCC field of an email, and then you send an email that has a BCC recipient and it's signed, the receiving email server will strip off the BCC out of the headers and then it will fail the DKIM Verification test.

Public Domain Key Check Results:


If you publish a Domain Key Signature, part of the requirements is for the receiving mail server to validate the signature in the email against the Public Domain Key that the sending mail server publishes. The location of the key is found in the Domain Key signature in the "s" tag. That location is then looked up in DNS and the Public Key is retrieved and then the contents of the email are hashed against that public key and matched against the signature data in the header. Everything must match in order for it to validate correctly.

Public Domain Key (Obsolete)
Selector Location: default._domainkey.domain.com
DNS Record Found: Yes
Record Syntax: p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAL9zSG5xEOV8iRLnTjhKy2R94VfxNaRqdpz1PfSPQRrkHIRK4jsT2NSjvjPTSY+GUMWYoZcWAcThBthJ6O36NsOaEJrxqpVGxM9+jUFCO+BmO3quey7/bbdWM/dy5gCxXQIDAQAB
Key Size: 768 - Key Size should be a minimum of 1024 bits - Generate a 1024 Key Bit Key


In this example the Public Key Size is 768 bits. This doesn't affect your email authentication but it does make it less secure. Using a 1024 bit key and above is currently recommended.
 
Public Domain Key (Obsolete)
Selector Location: default._domainkey.domain.com
DNS Record Found: No - Learn how to set up Domain Keys by clicking here: Domain Keys Instructions

In this example a lookup was performed to retrieve your public key and the information was not present in DNS under the selector location. This will automatically cause your Domain Key Test to fail because it's impossible to perform this test without the public key.

DKIM Test Results:

Publication: RFC 6376
DKIM Check
Signature Found: Yes
SM Sig Verification: Failed - Bad Signature
LL Sig Verification: Failed - Bad Signature
From Signed: Yes


In this example the signature didn't verify. That means the "signature-data" or "b=" tag, which is located in the "DKIM Additional Information" section of the test, didn't match the hash generated from the public key located in "Public DKIM" section of the test results. There can be a number of things that can cause this:
  • The most common is that the email was altered after it was sent out.
  • The mail server that signed it, signed it improperly.
  • The DKIM Verifiers have a bug in it - If you believe this is the case let us know, we will look into it.
In the above test we use two third party signature verification tools, (SmarterMail and Limilabs). If they both fail there is most likely not a bug. But if only one fails and the other passes it can be bug related. Please report those to us so we can look into the reason why and contact the third party to let them know there is a potential bug in their verification system.

Publication: RFC 6376
DKIM Check
Tag Value
Signature Found: Not Found - Learn how to set up DKIM by clicking here: DKIM Instructions

There is no DKIM Signature information because there is no DKIM Signature on the email.  

Public DKIM Key Check Results:


If you publish a Domain Key Signature, part of the requirements is for the receiving mail server to validate the signature in the email against the Public Domain Key that the sending mail server publishes. The location of the key is found in the Domain Key signature in the "s" tag. That location is then looked up in DNS and the Public Key is retrieved and then the contents of the email are hash against that public key and match against the signature data in the header. If it matches everything validates correctly.

Public DKIM Key
Selector Location: dkim._domainkey.domain.com
DNS Record Found: Yes
Record Syntax: p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAL9zSG5xEOV8iRLnTjhKy2R94VfxNaRqdpz1PfSPQRrkHIRK4jsT2NSjvjPTSY+GUMWYoZcWAcThBthJ6O36NsOaEJrxqpVGxM9+jUFCO+BmO3quey7/bbdWM/dy5gCxXQIDAQAB
Key Size: 768 - Key Size should be a minimum of 1024 bits - Generate a 1024 Key Bit Key

In this example, the Public Key Size is 768 bits. This doesn't affect your email authentication, but makes it less secure. Using a 1024 bit key and above is currently recommended.
 
Public DKIM Key
Selector Location: dkim._domainkey.domain.com
DNS Record Found: No - Learn how to set up DKIM by clicking here: DKIM Instructions

In this example a lookup was performed to retrieve your public key and the information was not present in DNS under the selector Location. This will automatically cause your DKIM Key Test to fail, because it's impossible to perform the test without the public key.

Public DKIM Key
Selector Location: Not Found - Learn how to set up DKIM by clicking here: DKIM Instructions

In this example there is no selector location which is most likely because there is no DKIM Signature on the email.

DMARC Check Test Results:


DMARC is the new authentication draft that caught fire. It combines SPF and DKIM and wraps a new level of protection on top to help prevent phishing and spoofing.

Publication: RFC 7489
DMARC Check
DMARC Record: Not Found - Learn how to set up your DMARC record by clicking here: DMARC Record


In the example above no DMARC Record was found for your domain. This is common. It's a new publication that will become a standard very soon. You can definitely get ahead of the curve by implementing this standard now.

Publication: RFC 7489
DMARC Check
Record Syntax: Passed
DKIM Test: Passed
SPF Test: Passed
ADKIM Test: Failed - DMARC Requires that ADKIM or ASPF must pass to be considered valid. Check your Identifier Alignments
ASPF Test: Passed
RUA Test: Failed - The 'rua' tag value is not allowed to receive the report
RUF Test: Passed
DMARC Passed: Yes
DMARC Record Location: _dmarc.subdomain.net
DMARC Record: v=DMARC1;p=none;rua=mailto:dmarc@domain.net;pct=100;aspf=r;adkim=r;

In the example above, two test failed:

  • ADKIM Test - failed because it's expecting relaxed Identifier Alignments, as seen in the DMARC Record 'adkim=r', but they are actually unaligned.
  • RUA Test - failed, because domain.net is missing the DMARC tag in DNS to allow it to accept DMARC emails from subdomain.net this was added in draft 2 of DMARC to prevent spamming through rua and ruf fields. The DNSTXT Record that is needed would be under subdomain.net._report._dmarc.domain.net and contain at least a V=DMARC1 value in order for this test to pass.
Draft Publication: DMARC Base-00-02
DMARC Check
Record Syntax: Passed
DKIM Test: Failed - DKIM must pass, see you DKIM results above.
SPF Test: Failed - SPF must pass, see you SPF results above.
ADKIM Test: Passed
ASPF Test: Passed
RUA Test: Passed
RUF Test: Passed
DMARC Passed: No - Review each component of the DMARC test to determine why.
DMARC Record Location: _dmarc.subdomain.com
DMARC Record: v=DMARC1;p=none;rua=mailto:dmarc@domain.net;pct=100;aspf=r;adkim=r;

In this example, two test failed:

  • DKIM Test - This means that the DKIM test fail, in the DKIM section of the report, you should see the reason why DKIM Failed. If you didn't implement DKIM this will also cause it to fail this check.
  • SPF Test - This means that the SPF test fail, in the SPF section of the report, you should see the reason why SPF Failed. If you didn't implement SPF this will also cause it to fail this check.
Publication: RFC 7489
DMARC Check
Record Syntax: Passed
DKIM Test: Passed
SPF Test: Passed
ADKIM Test: Passed
ASPF Test: Passed
RUA Test: Passed
RUF Test: Failed
The 'ruf' tag message size must be an integer
DMARC Passed: Yes
DMARC Record Location: _dmarc.example.com
DMARC Record: v=DMARC1;p=none;pct=100;ruf=mailto:dmarc@example.com!2am;rua=mailto:dmarc@example.com

In this example, the RUF message size is listed as "2a" megs, which is incorrect. It should be an integer. DMARC will pass because the rest of your syntax is valid and DMARC evaluators will just ignore the RUF tag (since it is optional) and you won't receive any reports because the RUA information is invalid.
 
Publication: RFC 7489
DMARC Check
Record Syntax: Failed
The 'v' tag must be equal to 'DMARC1'
The 'p' tag must be equal to 'none', 'quarantine', or 'reject'
The 'sp' tag must be equal to 'none', 'quarantine', or 'reject'
The 'a' tag is unknown, remove it
The 'ri' tag must contain an unsigned integer
The 'rf' tag must equal to 'afrf' or 'iodef'
The 'pct' tag must be whole integer
The 'pct' tag must be a numeric value between 0 and 100
The 'aspf' tag must be equal to 's' or 'r'
The 'adkim' tag must be equal to 's' or 'r'"
DMARC Record Location: _dmarc.badexample.com
DMARC Record: v=DMARC2;p=noone;pct=110.4;sp=some, a=bagtag, ri=-12220,aspf=t;adkim=u,rf=word

The example above is self-explanatory. Obviously, there's a lot of little syntax issues that can completely invalidate your DMARC record. It's best to use our online DMARC Wizard to create the syntax for you to avoid issues like this.

ADSP Test Results:

Publication: RFC 5617
ADSP (Author Domain Signing Policy) Check
ADSP Record: Not Found - Learn how to set up your ADSP record by clicking here: ADSP Record
ADSP Record Syntax: Not Found


This is just basically saying that an ADSP is not found for your domain, if it's not found, then mail servers assumes a default policy of "dkim=unknown", that's why this test is in gray. Everyone has a Default ADSP policy

Acceptance of Postmaster Address Test Results:


Publication: RFC 822 (6.3), RFC 1123 (5.2.7), RFC 2821 (4.5.1)
Acceptance of Postmaster Address
postmaster@mydomain.com Failed

If your email server doesn't have a postmaster email address set up it will fail this test. All email domains are required to have a postmaster address according to RFC standards. However, sometimes the Email Authentication test will show "Passed" when we are unable to determine the existence of the postmaster account.

Acceptance of Abuse Address Test Results:


Acceptance of Abuse Address
abuse@mydomain.com Failed - Learn how to set up your abuse contacts by clicking here: Abuse Contacts

It is common practice to have and "abuse" email set up on your domain so people can send information to your domain if someone is abusing it (spamming from it, sending threats from it, etc.) The link above will teach you have to register your abuse contacts at the Network Abuse Clearing House.

Authoritative DNS Server Results:

 
Authoritative DNS Server (SOA) Check for: iku.com
SOA Server Results
No Authoritative Server (SOA) Record Found For Your Domain. Using Public DNS to perform lookups.

When performing DNS lookups we try to go after the SOA server (Statement of Authority). This is the DNS that has the most current information that is propagated to other DNS servers. Some SOA servers are not available to the public. In those cases we use a "Public DNS" server to get your DNS information.

Source: Unlock The Inbox
Copyright © 2017 Unlock The Inbox