Email Security Checker

Audit passive DNS evidence for MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI, plus guarded HTTPS resources for published policies and assets. Results separate configuration failures from missing, unavailable, unknown and non-applicable evidence.

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 is not ready for display because the domain has not enforced DMARC. Zunavek checks the records together so you can see the real posture of a domain, not just one isolated setting.

MX records

MX records identify a domain's receiving mail servers. Zunavek recognizes explicit null MX for non-receiving domains, warns about implicit MX fallback, rejects mixed null/normal records, and verifies normal targets have A or AAAA addresses.

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. Zunavek 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 a selector-specific public key in DNS to verify a signature. Zunavek scores only selectors you supply from a message header or provider configuration; common-selector lookups are unscored hints and do not prove use or alignment.

DMARC

DMARC connects SPF and DKIM to the visible From domain and publishes receiver policy. Zunavek uses the bounded RFC 9989 DNS tree walk, applies p, sp, np, psd and t semantics, treats pct as historic, and checks RFC 9990 external-report authorization.

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. Zunavek 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 consider displaying a brand logo for authenticated mail. BIMI depends on strong DMARC enforcement. Zunavek 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; display eligibility remains unknown.

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:

Spoofing protection - DMARC enforcement tells receivers to quarantine or reject messages that fail authentication.
Deliverability context - valid SPF, explicit DKIM evidence, and DMARC reduce authentication failures, though this passive audit cannot predict inbox placement.
Visibility configuration - DMARC and TLS-RPT records publish destinations for reports; this checker does not verify that reports are received or monitored.

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

Enter the root domain you want to audit, such as example.com.
Run the check and review the overall score.
Start with critical issues first: missing DMARC, multiple SPF records, invalid MX records, or broken MTA-STS policy files.
Review warnings next, such as p=none, SPF softfail, malformed TLS-RPT, weak DMARC policy, or incomplete selector evidence.
Use the recommended fix text to update DNS records with your DNS provider, mail host, or security platform.
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

Zunavek 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 invalid. Examples include missing DMARC, multiple SPF records, invalid MX records, or malformed MTA-STS policy data. Temporary DNS and HTTPS failures are unavailable evidence, not failed controls.

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 or contextual evidence. Examples include missing TLS-RPT, BIMI readiness details, historic DMARC pct tags, or common-selector DKIM hints.

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

Email Header Analyzer - read a message route, hop delays, and the authentication results reported by receiving servers.
Forward DNS Lookup - resolve MX, TXT, NS, A and AAAA records for a domain.
Reverse DNS Lookup - check PTR records and forward-confirmed reverse DNS for mail server IPs.
RDAP / WHOIS Lookup - inspect domain registration and network ownership data.
Certificate Transparency Monitor - find certificates issued for a domain and its subdomains.
IP Lookup - inspect geolocation, ASN, hosting, VPN and risk context for mail server IPs.
Email Authentication Guide - learn how SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI work together.

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. Enter a selector from a DKIM-Signature header or sending provider for scored evidence. Common-selector lookups are shown only as unscored hints and cannot prove DKIM use or alignment.

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.