Email Security & Deliverability Checker

The Email Security and Deliverability Checking tool is designed to identify the security gaps and misconfigurations in your domain email setup. It is the best email deliverance validation tool available that gives a complete analysis of your mail server and the email records on the Domain Name server (DNS).

If you are experiencing issues with email delivery, seeing error codes and messages, or receiving bounce-back messages, you can use the Email Security and Deliverability Checker tool to troubleshoot your configurations. This tool will look up your DNS records and check whether they are configured correctly. It checks whether the relative records exist, and if it does, whether or not their syntax and values are as they should be. Additionally, the Email Security and Deliverability Checker performs several DNS configuration checks to confirm best practices for optimized email performance.

This tool also matches your domain name against the records in various IP history maintenance servers to see if it has been blocked anywhere, which can often result in email deliverability issues.

To use this email verification tool, simply enter your domain name in the given field at the top (example: itechtics.com), and click the “Analyze” button. This tool will then look up the domain’s DNS records and fetch and analyze the information.

If the MX, SPF, DMARC, DKIM, MTA-STS, or BIMI records are found, this tool will show the information with a green highlight. However, if a result does not exist, it will display “Record not found” with a red highlight.

Whether DNS records that have been gathered are correctly configured or not, is shown by the checks in the “DNS Configurations Check” section. A check is passed if the record is correctly configured, satisfies the statement, and is shown with a green checkmark. However, in case a check fails, it is highlighted with a red cross.

The next section in the Email Security and Deliverability Checking tool is the “Email Blacklist Check”, which scans several publically available IP history maintenance servers to check if the provided domain has been blocked anywhere. If the domain name matches a record in the given servers, it means that the domain has been blocked, and that server will be highlighted in red.

The Email Security and Deliverability Checking tool is not only limited to a DNS lookup – it also performs a record analysis to determine whether the records are configured correctly and are functional. It performs 10 DNS configuration checks, some of which are a requirement for successful email configuration, while others are industry best practices for optimized email delivery.

This tool checks whether the domain has two name servers configured. This configuration is not mandatory but serves as a fail-safe so the website doesn’t go down in case one name server fails.

If the domain has a DMARC DNS TXT record configured, it should be in the correct format, otherwise, the legitimate emails could end up being discarded, or the spoofed emails could land inside the recipient’s inbox. Additionally, all the configured name servers must have the same DMARC record. If different DMARC records are configured, the DMARC policy can fail to apply altogether.

Similarly, the SPF records are also checked for format, but this check goes a step further. The values for the “include” and “redirect” mechanisms in the SPF record, which are domain/subdomain names, are also analyzed to confirm that the SPF record is resolved within 10 queries. If it is not resolved inside the 10-DNS-lookup range, the SPF check fails. This is a limit applied by the IETF (responsible for setting emailing standards) that prevents DDoS attacks via emails.

If the SPF record is not resolved within 10 queries, you may encounter the “PermError too many DNS lookups” error.

Another mandatory check is resolving the naked domain name to an A or AAAA record, and not a CNAME. The “naked” domain name refers to a domain name without the “www”. For example, “itechtics.com” is a naked domain name, whereas www.itechtics.com is not. Moreover, an A record or an AAAA record translates a domain name to an IP address, whereas a CNAME, or a canonical name, translates one name to another.

As stated by IETF in their documentation, when a domain name is queried, the DNS must return at least one IP address. Any other response, specifically including a value that will return a CNAME record, lies outside the scope of the conventional standard.

Other than these, this tool also checks that other records, including DKIM, MTA-STS, DMARC, and MX records, are consistent across the different name servers.

Domains are blacklisted so that they cannot continue to send out emails. Email Service Providers (ESPs) often blacklist a domain if they violate the terms and agreements. The most common causes for landing inside a blacklist are sending out emails that are flagged as spam by the recipients or exceeding the daily allowed limit to send out emails. However, sometimes, organizations have found themselves on the blacklist for no apparent reason.

If you end up on a blacklist, you will no longer be able to send out emails, and will likely be seeing bounce-back messages. In certain cases, you may not get bounce-back messages, but the emails you are sending out won’t be delivered either. In this case, the sender thinks that they have sent out the email, whereas the recipient never gets them.

Ending up in an email blacklist is not good for the domain’s credibility. For one, any mails sent out from blacklisted domains will either not be delivered, or would land in the spam folder. If they start ending up in the spam folder, you may exceed the spam threshold enforced by Google and other ESPs, which is greater than 0.3%. If you exceed this limit, your domain may be automatically blacklisted across their servers as well.

Additionally, your emails may not be taken seriously or may be considered legitimate spam by the recipients if they find that your mail is going straight to the spam folder.

It is for these reasons that you should stay clear of being blacklisted.

A Mail Exchange (MX) record is stored inside a DNS which points to the mail servers. It tells the services how an email should be routed in accordance with the Simple Mail Transfer Protocol (SMTP). A DNS could have one or more MX records, and each record could have the same or different priorities.

The same-priority email server records are used for load balancing. The lower the priority number, the higher its priority.

An MX record will look something like this:

The first portion gives the address of the mail server, followed by the defined priority.

One additional configuration associated with an MX record is its Time To Live (TTL), which is the time, in seconds, for which the MX record is valid. Once the time is up, the data needs to be refreshed and fetched again from the DNS.

Sender Policy Framework (SPF) is a TXT record stored in the DNS. Its purpose is to verify whether the sending party is allowed to send emails to your domain. Think of it as a guest list – you are only allowed if your name is on the list.

SPF records prevent spoofers from manipulating the email headers to make it seem like they are legitimate senders. For example, they can make it seem like they are sending the email from your own domain, when in fact they are hackers trying to gain sensitive information.

SPF works by matching the domain name in the envelope header with the domain name stored in the SPF record. If the domain names match, or partially match with the subdomain, the SPF check passes and is labeled as such.

An SPF record uses qualifiers and mechanisms to define its values. Here is an example of an SPF record:

To learn what the different qualifiers and mechanisms mean, or to set up an SPF record, refer to our detailed post on SPF records.

A DKIM record is also a TXT record stored in a DNS. Like the SPF record, a DKIM record’s purpose is to validate the contents of the email and make sure that they are not tampered with. It does so by verifying the digital signature in the email header (DKIM header) and contains a public encryption key.

When an email leaves a mail server, an encrypted digital signature is embedded in its header using a public key. The receiving mail server receives the email, looks up the domain in the “FROM” header, and performs a DNS DKIM lookup. If a DKIM record is found, it fetches the public key and decrypts the digital signature to verify it.

If the digital signature matches the one from the sending domain, the email passes the DKIM check, and the email lands in the recipient’s inbox. However, if the signature is not a match, or a DKIM record is not found, or a matching DKIM record for the associated private key does not exist, the email will either be rejected, or flagged and sent to the spam folder.

A DKIM record uses a “selector”, which is essentially a name. This selector is used to save the TXT record so a lookup can identify the DKIM record. The same selector is also a part of the incoming email’s DKIM header so it can inform the recipient mail server what to look for. Moreover, the name for the DKIM record has a constant centered, which is universal, and goes like “._domainkey”. Therefore, you may find a DKIM record saved with the following naming nomenclature:

Here, the [selector] and “yourdomain.com” are variables and depend upon your email provider’s and domain’s configurations.

The DKIM record itself would be something like the following:

Note that the content followed by the “p=” is the public key, and can be quite lengthy.

To learn more about what the DKIM tags and values mean, and how to configure a DNS DKIM record, refer to our detailed post on DKIM records.

Domain-based Message Authentication Reporting and Conformance (DMARC) is also a TXT record stored on a DNS. DMARC’s purpose is to handle the unauthenticated emails that fail the SPF and DKIM checks. It instructs the mail server what to do in case an email’s authenticity cannot be verified.

You can configure the DMARC record to do nothing and let the emails pass as-is, mark them and send them to the spam folder, or reject the email completely.

Moreover, the DMARC records are also used to generate reports of unauthenticated emails, which in turn helps tighten email security further.

Like the DKIM record, a DMARC record must also be saved with a special naming nomenclature, and may look something like this:

The “_dmarc” will remain constant, and “domain.com” will be replaced by your domain.

The actual DMARC record may look something like this:

A DMARC record can be complex to understand, especially with the many optional tags and values. To learn more about a DMARC record, what it means, and how to configure it, refer to our detailed post on DMARC records.

Mail Transfer Agent – Strict Transport Security (MTA-STS) is a standard that ensures that mail servers always use Transport Layer Security (TLS) when communicating messages between them. This standard prevents third-party unauthorized users from accessing the email or its contents when in transit, or Man-in-the-Middle attacks.

Like most DNS records, the MTA-STS record is also a TXT record in the DNS. This record defines that an MTA-STS policy is configured for the said domain. However, that record is not sufficient. It works in tandem with an MTA-STS policy defined in a plain-text file, stored on the hosting of the domain. The policy controls how the emails are delivered that are not communicated through encrypted TLS connections.

Other than these two elements, an additional MTA-STS record can also be created as a DNS TXT record that defines the email address to send MTA-STS reports of failed TLS connections, just like the DMARC record does. However, this additional DNS record is optional.

The primary MTA-STS DNS record needs to have a specialized name, and should look like the following:

The MTA-STS DNS TXT record will look something like this:

Moving ahead, the optional MTA-STS DNS record that defines the reporting email address must also have a specialized name, and should be like this:

Moreover, the defining policy for MTA-STS, which is stored in a plain text file, should be at the following path:

The Email Security and Deliverability Checking tool looks up the DNS records for the MTA-STS policy. If the policy is found, it will display its tags and values with a green highlight.

Understanding the different DNS records and policies for the TA-STS standard can be confusing. If you would like to read more about this standard, refer to our dedicated guide post on MTA-STS.

Brand Indicator Message Identification (BIMI) is a standard that attaches your brand’s verified mark/logo, which is a verified brand logo, to the authenticated emails that you send from the allowed servers. Basically, it is a stamp of authentication.

This technology adds your brand’s logo to the emails that land in the recipient’s inboxes once the email has a positive DMARC alignment. This adds validation and authority to your emails when the recipient sees your logo beside an email.

Just like other email security technologies, BIMI also exists as a DNS TXT record that defines the BIMI version, and a link to the location of where the brand logo image is stored. When verified, the mail server automatically fetches the image from the link stored in the BIMI record.

That said, at the moment, BIMI only supports SVG images. Therefore, your brand logo must be saved as a .SVG file. Moreover, when performing a DNS lookup, a mail server may also look for Verified Mark Certificates (VMC). A VMC, issued by a Mark Verifying Authority (MVA), attests that you own the trademark of your logo, and you are its proprietary. When a VMC is issued, you receive an entity certificate Privacy Enhanced Mail (PEM) file. Your logo and VMC are embedded in the PEM file, which can also be used instead of the SVG file.

Additionally, a BIMI record also uses a selector, similar to a DKIM record. A BIMI email header may specify a selector for a BIMI record to be used. A BIMI record with that specific selector, if exists, will use the SVG or PEM file given inside that record. This allows users from the same domain to use different logos (for example, a user from the marketing department might use a different logo than the user from the sales or support department, while they both use the same primary domain).

With the use of selectors, multiple BIMI records can exist for the same domain. A BIMI record has the following naming nomenclature:

If this tool finds a BIMI record against your domain, it may have values such as this:

Note that the “a” tag is optional, and is only needed to define the path for a PEM file.

To read more in-depth about what BIMI is, read the detailed post on BIMI.