PrivKitPrivKit
Full ScanIP Lookup

Email Security Checker

Audit a domain's MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI records from one place. Find missing authentication, weak DMARC policies, transport-security gaps and mail-server configuration issues that attackers can abuse for spoofing or phishing.

Enter a root domain such as example.com. Do not enter an email address or URL.

Runs live DNS and HTTPS policy checks. Results are not stored.

Leave blank to try common selector names, or add provider selectors separated by commas.

What This Email Security Checker Tests

Email security depends on more than one DNS record. A domain can have SPF but no DMARC enforcement, valid MX records but weak transport protection, or a BIMI record that will never display because the domain has not enforced DMARC. PrivKit checks the records together so you can see the real posture of a domain, not just one isolated setting.

MX records

MX records tell the internet which mail servers receive email for your domain. This checker verifies that MX records exist, that the listed hostnames resolve, and that the mail-routing foundation is not obviously broken. If a domain accepts email, missing or invalid MX records are a critical configuration problem.

SPF

Sender Policy Framework, or SPF, lists the servers that are allowed to send email for your domain. A good SPF record helps receivers detect forged mail, but a broken SPF record can create deliverability problems or leave spoofing gaps. PrivKit checks for duplicate SPF records, missing all mechanisms, softfail versus hardfail policies, and DNS lookup limits.

DKIM

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing messages. Receivers use the public key published in DNS to verify that the message was signed by a trusted domain and was not modified after signing. Because DKIM records use selectors, PrivKit can check a selector you provide and can also try common selector names used by major mail providers.

DMARC

DMARC connects SPF and DKIM to the visible From domain and tells receivers what to do when authentication fails. A DMARC policy of p=none is useful for monitoring, but it does not block spoofed mail. A policy of p=quarantine or p=reject gives receivers stronger instructions and is the target state for most production domains.

MTA-STS

SMTP MTA Strict Transport Security, or MTA-STS, lets a domain publish a policy requiring encrypted SMTP delivery to its mail servers. This protects against downgrade attacks where an attacker tries to force mail delivery without trusted TLS. PrivKit checks the DNS TXT record and the HTTPS-hosted policy file.

TLS-RPT

SMTP TLS Reporting, or TLS-RPT, tells senders where to report TLS delivery failures. It is especially useful when MTA-STS is enabled because it gives domain owners visibility into failed encrypted delivery attempts, certificate problems, and policy mismatches.

BIMI

Brand Indicators for Message Identification, or BIMI, lets participating inbox providers display a brand logo for authenticated mail. BIMI depends on strong DMARC enforcement. PrivKit checks the BIMI TXT record, logo URL, evidence certificate URL when present, and whether the domain's DMARC policy is strong enough to support BIMI.

Reverse DNS and PTR records

Many receiving mail systems look at the reverse DNS of sending mail servers. If an MX or sending host has no PTR record, or if the PTR does not resolve back to the same IP address, mail can look less trustworthy. PrivKit highlights reverse DNS and forward-confirmed reverse DNS issues where available.

Why Email Authentication Matters

Attackers often impersonate trusted domains because people are more likely to open email that appears to come from a familiar company, coworker, bank, vendor, or product. Email authentication records reduce that risk by giving receiving servers a way to verify whether a message is allowed to use your domain.

A strong setup helps with three things:

  1. Spoofing protection - DMARC enforcement tells receivers to quarantine or reject messages that fail authentication.
  2. Deliverability - valid SPF, DKIM, and reverse DNS make legitimate mail easier for receivers to trust.
  3. Visibility - DMARC and TLS-RPT reports show authentication and transport failures that would otherwise be invisible.

No DNS record can stop every phishing attack. Attackers can still use lookalike domains, compromised accounts, or malicious content sent from legitimate infrastructure. But a correct SPF, DKIM, DMARC, MTA-STS and TLS-RPT setup closes the easiest impersonation paths and gives you a baseline for monitoring abuse.

How to Use the Email Security Checker

  1. Enter the root domain you want to audit, such as example.com.
  2. Run the check and review the overall score.
  3. Start with critical issues first: missing DMARC, multiple SPF records, invalid MX records, or broken MTA-STS policy files.
  4. Review warnings next, such as p=none, SPF softfail, missing TLS-RPT, weak alignment, or missing reverse DNS.
  5. Use the recommended fix text to update DNS records with your DNS provider, mail host, or security platform.
  6. Re-run the check after DNS changes propagate.

DNS changes can take time to appear everywhere because each record has a TTL. If you just updated a record, wait for the TTL window and test again.

Understanding Your Results

PrivKit groups findings by severity so you can act in the right order.

Critical

Critical findings indicate a configuration that can directly enable spoofing, break legitimate mail flow, or make a published security policy fail. Examples include missing DMARC, multiple SPF records, invalid MX records, or an MTA-STS TXT record that points to a policy file that cannot be fetched.

Warning

Warnings are not always urgent, but they reduce protection or visibility. Examples include DMARC set to p=none, SPF ending in ~all, missing aggregate reports, no TLS-RPT record, or BIMI published before DMARC is enforced.

Informational

Informational findings identify optional improvements or advanced protections. Examples include missing BIMI, missing DANE/TLSA, relaxed DMARC alignment, or no subdomain-specific DMARC policy.

Passed

Passed checks confirm that a record exists and appears consistent with the expected format. Passing one check does not guarantee the whole domain is secure; email protection works best when the records reinforce each other.

Common Email Security Misconfigurations

Multiple SPF records

A domain should publish one SPF record. Multiple v=spf1 TXT records can cause SPF evaluation to fail. Combine all authorized senders into a single record instead of publishing separate records for each mail provider.

SPF record too complex

SPF processing has a DNS lookup limit. Too many include, a, mx, ptr, exists, or redirect mechanisms can make SPF fail even when the record looks correct. Remove unused providers, avoid unnecessary mechanisms, and keep the record focused.

DMARC set to monitoring forever

p=none is a good starting point because it lets you collect reports without blocking mail. It should not be the final state for a production domain. After confirming legitimate senders pass SPF or DKIM alignment, move gradually to p=quarantine and then p=reject.

DKIM selector not documented

DKIM records are stored under selector-specific names such as selector1._domainkey.example.com. If your team does not know which selectors your mail providers use, DKIM becomes harder to audit. Keep a list of providers, selectors, and rotation dates.

MTA-STS TXT exists but policy file is broken

MTA-STS requires both DNS and HTTPS. Publishing _mta-sts.example.com is not enough if the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt is missing, invalid, or served with a bad certificate.

Missing TLS reporting

TLS-RPT gives you visibility into encrypted delivery failures. Without it, you may not notice that senders are failing to deliver because of certificate errors, MTA-STS mismatches, or TLS negotiation problems.

BIMI without DMARC enforcement

BIMI is not a shortcut to inbox logos. Most mailbox providers require strong DMARC enforcement before they display a BIMI logo. If DMARC is still p=none, fix DMARC first.

Related Tools & Guides

Frequently Asked Questions

What is an email security checker?

An email security checker audits the DNS and policy records that protect a domain's email. It looks for records such as MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI, then flags missing records, weak policies, and configuration errors that can affect spoofing protection or deliverability.

Do I need SPF, DKIM and DMARC?

Yes, most production domains should use all three. SPF authorizes sending servers, DKIM signs messages, and DMARC tells receivers how to handle messages that fail authentication for the visible From domain. DMARC is the policy layer that turns SPF and DKIM into practical anti-spoofing protection.

Is p=none enough for DMARC?

p=none is useful for collecting reports while you learn which systems send mail for your domain. It does not tell receivers to block spoofed messages. For stronger protection, move toward p=quarantine or p=reject after legitimate senders are aligned.

Why can't DKIM always be checked from only a domain name?

DKIM records are published under selector-specific DNS names, not only the root domain. A selector is chosen by the sending system, such as a mail provider or marketing platform. If you know the selector, enter it for a precise check. Without a selector, the tool can only try common selector names.

What is the difference between MTA-STS and TLS-RPT?

MTA-STS publishes a policy that asks senders to use trusted TLS when delivering mail to your MX hosts. TLS-RPT publishes a reporting destination so senders can report TLS delivery failures. MTA-STS is the enforcement policy; TLS-RPT is the visibility layer.

Does BIMI improve email security?

BIMI is mainly a brand-trust and recognition layer. It depends on strong email authentication, especially DMARC enforcement. BIMI can help recipients recognize legitimate mail, but it should be implemented after SPF, DKIM and DMARC are already working correctly.

Can this tool guarantee email deliverability?

No tool can guarantee deliverability because inbox placement depends on reputation, content, complaint rates, sending practices, and mailbox-provider rules. This checker identifies technical authentication and transport-security issues that commonly affect trust and deliverability.

How often should I audit email security records?

Audit after adding or removing any mail provider, changing DNS providers, rotating DKIM keys, updating DMARC policy, or changing MX hosts. For business domains, a monthly check is a good baseline, with additional checks after any email-platform change.