Email Security Score

A score of 80 or above is rated "great" on this checker's 0–100 scale and usually means SPF, DKIM, and DMARC are set up correctly. 60–79 is "good" with at least one gap worth closing, 35–59 signals weak protection, and below 35 is critical. Domains that have never set up DMARC usually land in the lower bands on their first check, so a low starting score is normal. The report lists the exact fixes, ranked by impact.

The checker reads your domain's public DNS records and runs individual checks across DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT. Each check looks for a valid record and a safe configuration, and every finding contributes to the 0–100 total. Missing or failing sender-authentication records (SPF, DKIM, and your DMARC policy) typically pull the score down the most, and the report shows which fixes will lift it the most.

Enter your domain in the checker above. It inspects the public DNS records that control sender authentication (SPF, DKIM, DMARC), transport security (MTA-STS, TLS-RPT), mail routing (MX), and brand indicators (BIMI), then returns a 0–100 score with the specific issues it found. This covers the domain side of email security: whether someone else can convincingly send email as you. Securing an individual mailbox is separate, and comes down to strong passwords and two-factor authentication.

Work through the report from the highest-impact finding down. Publish a valid SPF record and keep it under the 10-DNS-lookup limit, enable DKIM signing for every service that sends as your domain, then publish a DMARC record and move it gradually from p=none to p=quarantine and p=reject as legitimate senders come into alignment. MTA-STS, TLS-RPT, and BIMI add further points. Re-run the check after each DNS change to confirm the fix took effect.

Checking domain security is crucial to protect against cyber threats like phishing, domain spoofing, and unauthorized access. Regular security checks help identify vulnerabilities, ensure compliance with best practices, and maintain the integrity and reputation of the domain. This is essential not only for safeguarding sensitive information but also for preserving user trust and confidence in digital interactions with the domain.

An email security assessment (also called an email security audit) reviews how well a domain resists spoofing, phishing, and interception. It covers sender authentication (SPF, DKIM, and the DMARC policy), transport encryption (MTA-STS, TLS-RPT), mail-server setup (MX records), and brand protection (BIMI). This tool runs the domain-layer assessment automatically from public DNS in seconds. A full organizational audit would add items no DNS scan can see, such as mailbox access controls and user awareness.

An email risk score estimates how exposed a domain is to email-based attack, based on whether SPF, DKIM, and DMARC are missing, misconfigured, or left unenforced. The 0–100 score on this page is that kind of domain-level measure. The same phrase is also used in fraud prevention, where vendors score individual email addresses at signup; that is a different measurement. To understand your own domain's spoofing exposure, the domain-level score is the one to track.

Yes. The check is free, runs online in seconds, and needs no account: enter a domain and you get the full score and findings. You can re-run it as often as you like, for example after each DNS fix. It only reads public DNS records, so it makes no changes to your domain.

Yes. The check works on any domain because it reads public DNS records, so you don't need to own or verify a domain to score it. IT teams typically check their own domains and subdomains, while managed service providers use it to assess client and prospect domains before an email-security conversation. Scoring a domain changes nothing on the domain itself.

Re-run the check after any change to your DNS or sending stack: a new marketing platform, CRM, or helpdesk that sends as your domain, a DNS migration, or a DMARC policy update. For a stable domain, a quarterly check is a sensible floor. A check is a point-in-time snapshot, though. Sending services and DNS records drift, which is why teams that take DMARC seriously monitor aggregate reports continuously instead of relying on occasional scans.

To make BIMI work, you need a validated DMARC policy set to either 'quarantine' or 'reject', a square logo in SVG format hosted on a secure location, and a BIMI record in your DNS. Additionally, for some email providers, you might require a Verified Mark Certificate (VMC) to authenticate your logo. These elements together enable the display of your brand's logo in supported email clients, enhancing trust and brand recognition.

BIMI can help with email deliverability, especially when used in conjunction with a robust email authentication setup like DMARC. Implementing BIMI alongside DMARC showcases your commitment to email security, enhancing your reputation among email service providers. This enhanced reputation can positively influence how your emails are processed, increasing the chances of them landing in the recipient's inbox.

No, implementing BIMI is not mandatory. It's an optional email authentication standard used for brand enhancement. BIMI allows businesses to display their logo in supported email clients, thereby increasing brand visibility and trustworthiness. However, it's an additional layer atop standard email authentication practices like SPF, DKIM, and DMARC, and not a basic requirement for email deliverability or security.

Mailbox providers and email clients supporting BIMI include Yahoo Mail, Gmail, and Fastmail, among others. However, the list of supporting providers can change, so it's recommended to check the latest information from BIMI's official website or directly from email client providers for the most current list of BIMI-supporting email services.

If your BIMI logo is not appearing in emails, it could be due to several reasons: your DMARC policy may not be at 'quarantine' or 'reject', the BIMI record might be improperly formatted or missing in DNS, the logo file may not meet specifications (like being an SVG format hosted securely), or the email client may not support BIMI. Ensure all BIMI requirements are met and check if the email client supports BIMI.

For logos used in BIMI records, the specifications include: the logo must be in SVG Tiny P/S format for security and scalability, it should be a square image to display correctly across different email clients, the file should be hosted on a secure (HTTPS) server, and it should visually represent the brand clearly. Some email providers may also require a Verified Mark Certificate (VMC) to authenticate the logo's legitimacy.

BIMI records should be reviewed and updated regularly, particularly if there are changes in your brand's logo, domain ownership, or email authentication practices (like DMARC settings). A good practice is to check them annually or whenever there are significant branding changes, ensuring that your BIMI record accurately reflects your current brand identity and maintains alignment with your email security policies.

When implementing BIMI, legal and compliance considerations mainly revolve around trademark and copyright laws. Ensure that the logo used in your BIMI record is legally owned or appropriately licensed by your organization. Unauthorized use of logos can lead to legal issues. Also, consider data privacy regulations, as DMARC reports generated in BIMI implementation could contain user data that needs to be handled in compliance with laws like GDPR.

BIMI itself doesn't directly prevent email phishing and fraud, but it supports a stronger email authentication framework. By encouraging the use of DMARC at enforcement levels, BIMI indirectly helps reduce email fraud. When a trusted logo appears next to a verified email, it enhances the recipient's confidence in the email's legitimacy, potentially reducing the effectiveness of phishing attempts.

BIMI stands for Brand Indicators for Message Identification. It's an email authentication standard that allows brands to display their logo next to their email in supported email clients, enhancing brand presence and trust in email communications. BIMI works alongside DMARC to ensure email authenticity and protect against fraud.

BIMI works by allowing organizations to attach their brand logo to emails they send. When an email passes DMARC authentication at a strict policy level, the receiving email service can display the sender's logo, as specified in the BIMI record of the sender's DNS. This visual cue helps recipients quickly recognize and trust legitimate emails, enhancing brand visibility and email security.

SPF, or Sender Policy Framework, is an email authentication method that prevents sender address forgery by specifying which mail servers are permitted to send emails on behalf of a domain. It's implemented by adding an SPF record to the domain's DNS records, which lists authorized sending IP addresses. Email receivers can then verify if incoming emails originate from the listed servers, reducing spam and phishing.

SPF authentication works by verifying that an email sent from a domain comes from an IP address authorized by that domain's DNS record. When an email is received, the receiving server checks the domain's SPF record to see if the email's sending server's IP address is listed. If the IP is authorized, the email passes SPF authentication; if not, it can be marked as spam or rejected, enhancing email security against spoofing.

Setting an SPF (Sender Policy Framework) record is essential for email security as it helps prevent sender address forgery. By specifying authorized sending IPs for your domain, it enables email receivers to verify if incoming emails are from legitimate sources. This reduces the likelihood of spam and phishing attacks, enhances your domain's reputation, and improves email deliverability.

Some SPF best practices include: keeping your SPF record up-to-date with all authorized sending IPs, avoiding too many DNS lookups to prevent 'permerror', using a '-all' qualifier to clearly indicate unauthorized senders, regularly reviewing and optimizing your SPF record for changes in sending sources, and ensuring SPF alignment with DKIM and DMARC for cohesive email authentication and security.

SPF flattening is the process of condensing an SPF record by directly listing IP addresses instead of including multiple domains or hostnames. It's necessary to avoid exceeding the SPF 10 DNS lookup limit, which can cause SPF authentication failures. Flattening simplifies the record, ensuring reliable email delivery while maintaining the record's effectiveness in preventing spoofing.

SPF records should be reviewed and updated regularly, ideally every few months or whenever there are changes in your email sending infrastructure. This includes adding or removing email service providers, changes in IP addresses, or updates to email sending policies. Regular maintenance ensures that SPF records accurately reflect authorized senders, maintaining email security and deliverability.

To create an SPF record, first identify all IP addresses and servers that send emails on behalf of your domain. Then, compose a TXT record in the DNS settings for your domain, starting with "v=spf1", followed by the identified IPs or servers, and ending with an appropriate qualifier like "-all" for strict enforcement. Publish this record in your domain's DNS to enable SPF email authentication.

No, you should not have multiple SPF records for a single domain. Having more than one SPF record can lead to conflicts and validation issues, potentially causing legitimate emails to be marked as spam or even rejected. For effective email authentication, only one SPF record should be used per domain.

To combine SPF records, consolidate all authorized sending sources into a single SPF record. Include all IP addresses, domains, and include-statements (like include:spf.provider.com) in one record. Start with "v=spf1" and end with an all mechanism (like "-all" for strict policy). Ensure the record doesn’t exceed the 10 DNS lookup limit to avoid validation issues. Publish this unified record in your domain's DNS.

To check SPF records, use an online SPF record checker tool or perform a DNS query. You can query your domain's DNS using command-line tools like 'nslookup' or 'dig' with a specific query for TXT records. These methods will retrieve and display the SPF record, allowing you to verify its content and ensure it correctly lists all authorized sending IPs and domains for your email security.

SPF record propagation can vary, typically taking anywhere from a few minutes to 48 hours. This time frame depends on the TTL (Time to Live) value set in your DNS settings and the caching policies of external DNS servers. It's important to allow sufficient time for full propagation before making further changes or testing the record's effectiveness.

SPF stands for "Sender Policy Framework." It's an email authentication protocol designed to detect and prevent email spoofing by verifying a sender's IP address against the authorized IP addresses listed in the domain's DNS records. This helps to ensure that emails are sent from legitimate sources and aids in reducing spam and phishing attacks.

Flattening an SPF record involves converting all the domain names included in the record into their respective IP addresses and then listing them directly in the record. This process reduces the number of DNS lookups required, helping to stay within the SPF 10 DNS lookup limit. To flatten, identify all IPs associated with the domains in your SPF record, replace domain references with these IPs, and ensure the updated record is within the lookup limit.

A DKIM (DomainKeys Identified Mail) record is a DNS record used for email authentication. It helps verify the sender's identity and ensures that the email content hasn't been tampered with during transit. The DKIM record contains a public key that corresponds to a private key used by the sending mail server. When an email is sent, it's signed with the private key, and the receiving server uses the public key in the DKIM record to validate the signature, confirming the email's authenticity.

DKIM keys are part of the DomainKeys Identified Mail (DKIM) email authentication process. They include a private key, which is kept secure on the sender's mail server, and a public key, which is published in the domain's DNS records. When an email is sent, it's signed with the private key. The receiving server then uses the public key in the DNS to verify this signature, ensuring the email's authenticity and that it hasn't been altered in transit.

DKIM works by allowing the sending mail server to attach a digital signature to outgoing emails, linked to the domain. This signature is created using a private key unique to the domain. When an email is received, the receiving server checks this signature against a public key listed in the sender's DNS DKIM record. If the keys match, it confirms that the email hasn't been tampered with and authenticates the sender, reducing email fraud and phishing.

To analyze the DKIM selector from DMARC aggregate reports, first identify the DKIM selector tag in the report, which indicates which DKIM key was used to sign the email. Then, cross-reference this selector with your domain's DNS records to ensure it matches the correct DKIM record. This analysis helps verify that emails are being signed properly and assists in identifying any misconfigurations or unauthorized use of your email domain.

Analyzing DKIM selectors from email headers involves examining the DKIM-Signature field in an email's header. This field contains the DKIM selector, which is part of the domain identifier (d=) and selector (s=) tags. By identifying the selector, you can trace which specific DKIM key was used to sign the email. This is useful for verifying that the email was authenticated properly and for troubleshooting any issues related to email authentication and security.

Yes, DKIM is a key component of DMARC protection. DMARC (Domain-based Message Authentication, Reporting, and Conformance) relies on both SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) for validating emails. DMARC checks if an email passes either SPF or DKIM authentication and if the domain in the From header aligns with the domain in the SPF/DKIM authentication. This integrated approach enhances email security by preventing spoofing and ensuring the legitimacy of the sender.

While having an SPF record is beneficial, it's not mandatory to implement DKIM if you already have SPF. However, using both SPF and DKIM together provides a more robust email authentication framework. This combination is particularly effective when used under a DMARC policy, as it allows for more comprehensive protection against email spoofing and phishing, enhancing overall email security and deliverability.

Implementing DKIM positively affects email deliverability by enhancing the legitimacy and trustworthiness of your emails. It provides an additional layer of authentication, ensuring that the content of your emails remains unaltered in transit. Email service providers are more likely to deliver emails that pass DKIM checks to the recipient's inbox, reducing the likelihood of them being marked as spam. This contributes to better sender reputation and improved email delivery rates.

DKIM records should be reviewed and updated periodically, especially if there are changes in email infrastructure or security policies. It's advisable to do this at least annually. Additionally, it's important to update DKIM keys if they are compromised or as a best practice to maintain security. Regular reviews help ensure that DKIM records continue to support effective email authentication and protect against spoofing.

When implementing DKIM, legal and compliance aspects are generally related to data protection and privacy laws. Ensure that your email practices, including DKIM implementation, comply with relevant laws like GDPR, especially regarding the handling and protection of personal data. Also, adhere to industry-specific regulations that might dictate standards for email security and authentication. It's important to stay informed about these regulations to avoid legal issues and maintain compliance.

Managing multiple DKIM records for different sending sources involves using unique DKIM selectors for each source. Each selector corresponds to a different DKIM public/private key pair. In your DNS, create separate DKIM TXT records for each selector. When sending emails, configure each source to sign messages with its respective DKIM key. This setup allows for distinct authentication of emails from different sources, maintaining the integrity and security of your email ecosystem.

A DKIM selector is a specific attribute in a DKIM record that helps identify the particular DKIM key used to sign an email. It's part of the DKIM signature in an email's header, enabling the receiving mail server to locate the correct public key in the sender's DNS to authenticate the message. Selectors allow for multiple DKIM keys to be used under a single domain, facilitating versatile and secure email management.

Setting up DKIM involves several steps: First, generate a DKIM key pair (private and public keys). Then, add the public key to your domain's DNS records as a TXT record with a unique selector. Next, configure your email server or service to use the private key to sign outgoing emails with this selector. Finally, ensure your email system correctly signs emails and verify the setup using DKIM validation tools to confirm that DKIM signatures are being properly attached and recognized.

A DKIM (DomainKeys Identified Mail) record is a DNS record used for email authentication. It contains a public key that corresponds to a private key used by the sending mail server. When an email is sent, it's signed with the private key, and the receiving server uses the public key in the DKIM record to validate the signature. This process confirms the email's authenticity and that it hasn't been tampered with during transit.

DKIM stands for DomainKeys Identified Mail. It's an email authentication method that helps verify the sender's identity and ensures the integrity of the message content. DKIM uses a pair of cryptographic keys to sign and validate emails, aiding in the prevention of email spoofing and phishing.

Yes, multiple DKIM records can be used for a single domain. This allows for different email servers or services sending emails on behalf of the domain to each have their own DKIM key pair. Each key pair is associated with a unique DKIM selector, enabling the domain to manage and authenticate emails from various sources effectively while maintaining security and deliverability.

DKIM (DomainKeys Identified Mail) provides email authentication by allowing the sender to attach a digital signature to outgoing emails. This signature, linked to the sender's domain, is verified against a public key published in the domain's DNS records. DKIM helps confirm that the email has not been altered in transit and verifies the sender's identity, thus reducing email spoofing and phishing, and enhancing the overall trustworthiness of email communication.

Yes, DKIM can improve email deliverability. By providing a method to verify the authenticity of an email's sender and content, DKIM helps build trust with email service providers. Emails that pass DKIM checks are less likely to be marked as spam, increasing the likelihood of reaching the recipient's inbox. This enhances the sender's reputation and overall email deliverability.

DMARC does not specifically require DKIM; it works with either SPF, DKIM, or both. DMARC policy enforcement depends on email messages passing SPF and/or DKIM authentication, along with proper domain alignment. Implementing both SPF and DKIM provides a stronger email authentication framework, but DMARC can function with only one of them being in place.

A DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is a DNS record that helps protect email domains from unauthorized use, such as spoofing. It does this by specifying how emails that fail SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) checks should be handled (e.g., rejected or quarantined). Additionally, DMARC provides feedback to domain owners about the emails being sent from their domain, helping them identify and address security issues.

A DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is a DNS record that helps protect email domains from unauthorized use, such as spoofing. It does this by specifying how emails that fail SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) checks should be handled (e.g., rejected or quarantined). Additionally, DMARC provides feedback to domain owners about the emails being sent from their domain, helping them identify and address security issues.

DMARC reports are important because they provide detailed feedback on email messages sent from your domain. These reports help in identifying unauthorized email sending, such as phishing or spoofing attempts. By analyzing these reports, domain owners can better understand and control their email authentication practices, thus improving email security and protecting their domain's reputation.

Being DMARC compliant means that a domain's outgoing emails pass DMARC authentication checks, which include alignment with SPF and DKIM protocols. It signifies that the domain is actively working to prevent email spoofing and phishing, thereby enhancing email security and maintaining the domain's reputation among email service providers and recipients.

DMARC works by aligning SPF and DKIM authentication results with the sender's domain, and it specifies how receivers should handle emails that fail these checks. When an email is sent, DMARC verifies that it passes SPF and/or DKIM authentication and matches the sender's domain. Based on the DMARC policy set by the domain owner (none, quarantine, reject), the receiving server then decides how to treat emails that fail these checks, enhancing email security and integrity.

DMARC influences email deliverability by providing a clear policy on how email receivers should handle messages failing SPF and DKIM checks. Proper DMARC implementation can improve a domain's trustworthiness and reduce the likelihood of legitimate emails being marked as spam, thus enhancing overall email deliverability. Conversely, a strict DMARC policy without proper alignment of SPF and DKIM can lead to legitimate emails being rejected or quarantined.

To add a DMARC record, first create the record with the desired policy (none, quarantine, reject) and other settings. Then, publish this record in your domain's DNS as a TXT record, with the name "_dmarc.yourdomain.com." Ensure that the record aligns with your SPF and DKIM settings for effective implementation and email authentication.

To set up DMARC, first ensure you have SPF and DKIM records in place. Then, create a DMARC record with your chosen policy (none, quarantine, reject) and reporting preferences. Publish this as a TXT record in your domain's DNS under "_dmarc.yourdomain.com". Finally, monitor DMARC reports to adjust your settings and improve email security.

To read a DMARC report, understand its two main sections: Aggregate Reports and Forensic Reports. Aggregate Reports provide an overview of all received emails from your domain, showing data like source IP, message count, and SPF/DKIM pass status. Forensic Reports detail individual failure incidents. Look for trends in authentication failures to identify and address potential security issues.

DMARC stands for "Domain-based Message Authentication, Reporting, and Conformance." It's an email authentication protocol designed to give email domain owners the ability to protect their domain from unauthorized use, like email spoofing, by specifying how emails failing SPF and DKIM checks should be handled.

A DMARC policy is a specified course of action that a domain owner sets for email receivers to follow when handling emails that fail DMARC checks. The policies include 'none' (monitoring mode, no action on failures), 'quarantine' (treat suspicious emails with caution, like moving to spam), and 'reject' (block and don't deliver failing emails), guiding how receivers should respond to unauthenticated emails.

No, you should not have multiple DMARC records for a single domain. Having more than one DMARC record can lead to conflicts and inconsistencies in email authentication, potentially causing legitimate emails to be marked as spam or rejected. For effective email authentication and policy enforcement, only one DMARC record should be published per domain.

A DMARC aggregate report is a consolidated summary sent by email receivers to the domain owner, detailing the authentication status of emails sent from their domain. It includes information like source IP, message counts, and SPF/DKIM authentication results, helping domain owners monitor and evaluate their email authentication performance and address any security issues.

To become DMARC compliant, first ensure your domain has correctly configured SPF and DKIM records. Then, create and publish a DMARC record in your DNS with a policy of either 'none', 'quarantine', or 'reject'. Gradually move towards a 'reject' policy for stricter enforcement. Regularly monitor DMARC reports to adjust your email authentication practices and address any issues for full compliance.

The "Glossary" section serves as a comprehensive reference for understanding the various technical terms and tags used in these email authentication and branding protocols.