Email Security Tools & Guides

Without authentication, anyone can send a message claiming to be from any domain. The receiver has no way to tell the difference between your CFO and an attacker spoofing your CFO's address. That gap is the reason business email compromise, vendor fraud, and phishing remain the single largest category of cyber-loss reported every year. The protocols below close it — but only if all of them are configured correctly and aligned with one another.

What follows walks through the full email security stack in the order most teams should deploy it, points to the tool on this site for testing each layer, and links the deep-dive blog posts that explain the protocols in detail. None of the tools below require an account, none store the query, and they all run against live DNS and live SMTP endpoints — so the answer you get reflects production state, not a stale crawl.

Test your email security

The tools below cover every layer of the stack. Each one runs in your browser against a single domain or message; none store the query or require an account. Start with whatever you're investigating — a new domain rollout, a customer complaint, or a deliverability regression — and the linked tool will tell you what's wrong.

How email authentication works

Authentication answers three independent questions about a message: who sent it, was the content modified, and what should I do if either of those fails? Three protocols answer those questions in sequence.

SPF — which servers can send for me

Sender Policy Framework publishes a list of IP addresses (and other senders, by reference) that are authorised to send mail with your domain in the envelope From: address. It lives in a DNS TXT record at the apex of your domain and looks like v=spf1 include:_spf.google.com include:mail.zendesk.com -all. The receiver checks the IP of the connecting SMTP server against this list. If it matches, SPF passes. If not, the -all tells the receiver to treat the message as unauthorised.

The single biggest SPF gotcha is the 10 DNS-lookup limit. Every include:, a, mx, ptr, exists, and redirect mechanism costs one lookup, and includes nest. Add Microsoft 365, Mailchimp, Salesforce, and SendGrid and you can easily blow past the limit; once you do, every SPF check fails as a permanent error and your DMARC policy starts treating compliant traffic as unauthorised. The other classic trap is ~all vs -all: ~all means "soft fail, deliver anyway" — fine for a monitoring phase, weak as enforcement. Move to -all once you trust the record. Validate yours with the SPF Record Checker.

DKIM — proof the message wasn't tampered with

DomainKeys Identified Mail attaches a cryptographic signature to outgoing messages. The sending server signs a chosen set of headers plus the message body with a private key. The receiver fetches the matching public key from DNS — at {selector}._domainkey.{domain} — and verifies the signature. If it checks out, the receiver knows the message was authored by someone holding the private key for that domain and that the signed content hasn't been changed in transit.

DKIM survives forwarding (because the signature travels with the headers, not the connection) which is the part that fundamentally differs from SPF. The cost is per-provider key management: every sending service publishes its own selector and rotates keys on its own schedule. Modern setups should use RSA 2048-bit keys at minimum; 1024-bit RSA is deprecated and increasingly rejected by major receivers. The DKIM Lookup tool auto-probes 50+ common selectors so you don't have to guess what each provider uses.

DMARC — the enforcement layer

Domain-based Message Authentication, Reporting, and Conformance sits on top of SPF and DKIM and answers the third question: what should the receiver do when neither passes? The DMARC record is a TXT at _dmarc.yourdomain.com declaring a policy (p=none, p=quarantine, or p=reject), an optional subdomain policy (sp=), and reporting addresses (rua= for daily aggregate reports, ruf= for forensic per-message reports).

The critical concept is alignment. DMARC requires that the domain SPF or DKIM validated matches the domain in the visible From: header. SPF can pass on a third-party sender (say, Mailchimp's bounce domain) but the From: line still says yourbrand.com — without alignment, the receiver would have no way to tell apart a legitimate Mailchimp campaign from someone spoofing your brand via Mailchimp's IPs. Alignment closes that loop. Grade your record with the DMARC Checker.

How they work together

The path of a single message tells the story. The sender's outbound mail server signs the message with DKIM and ships it over SMTP. The receiver opens the TCP connection, sees the sending IP, and runs SPF: is this IP listed in example.com's SPF record? Then it parses the headers and runs DKIM: is there a valid signature, and does the signing domain match the From: header? Finally it consults the DMARC record: at least one of SPF or DKIM passed with alignment — so deliver. Otherwise apply p=reject.

You need all three because each closes a different attack. SPF alone leaves forwarding broken. DKIM alone has no way to fail a message that simply isn't signed. DMARC alone can't authenticate anything — it only enforces policy on what SPF and DKIM tell it. Skip one of the three and the chain doesn't close.

The receiver typically records the outcome of all three checks in an Authentication-Results: header on the delivered message. Reading that header is the fastest way to debug a specific failed delivery — it shows, in order, what each protocol returned, the identity that was checked, and whether alignment was satisfied. The Email Header Analyzer parses these headers into a hop-by-hop view and surfaces the SPF/DKIM/DMARC results for a single message in plain language.

Google & Yahoo's bulk sender requirements

Since February 2024, Google and Yahoo require any sender shipping more than 5,000 messages a day to a Gmail or Yahoo mailbox to publish SPF, DKIM, and a DMARC record (at minimum p=none). Microsoft followed with a similar policy in mid-2024. Senders that don't comply see their mail rate-limited or junked outright. The thresholds matter only at scale, but the requirements are now the de-facto baseline for any commercial sending domain — including your transactional mail. The rules also require a one-click List-Unsubscribe (RFC 8058) for marketing mail, and they apply per-sender across all your sending IPs combined, not per-IP — so spreading volume across multiple addresses doesn't get you under the threshold.

For deeper coverage, see the deep-dive posts on SPF, DKIM, and DMARC.

Encryption and brand verification

The SPF/DKIM/DMARC trio authenticates messages. Two newer protocols cover what authentication can't — encrypted transport between servers, and visible brand identity in the inbox.

MTA-STS — enforced TLS for inbound mail

SMTP is plaintext by default. STARTTLS upgrades a plaintext SMTP session to TLS, but the upgrade is opportunistic: a man-in-the-middle can strip the upgrade from the EHLO response and watch the conversation continue in cleartext. MTA-STS (RFC 8461) eliminates the optionality by publishing a policy stating that senders must use TLS with a verifiable certificate.

The configuration lives in two places: a TXT record at _mta-sts.yourdomain.com announces the policy version and ID, and the policy itself is served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The policy declares the mode (enforce, testing, or none), the MX hostnames or wildcard patterns it covers, and a max_age. Senders cache the policy for that duration and refuse to deliver if TLS isn't available.

MTA-STS uses HTTPS rather than DNSSEC for authenticity — the policy file is fetched over a TLS-validated connection to mta-sts.yourdomain.com, so an attacker would need a valid certificate for that name to forge a policy. Most operators choose MTA-STS over DANE (the older DNSSEC-based alternative) for exactly this reason: DNSSEC adoption is still patchy, while the web PKI works everywhere. Pair MTA-STS with TLS-RPT (RFC 8460) to get daily JSON reports of TLS failures from receiving servers — without it, you only learn about TLS problems when users complain. Check both on the MTA-STS & TLS-RPT Lookup.

BIMI — your brand logo, next to authenticated mail

Brand Indicators for Message Identification is the visible reward for having everything above working. With BIMI configured, mail clients that support it (Gmail, Apple Mail, Yahoo) render your brand logo in the inbox row next to messages from your domain — instead of the generic initials avatar. The configuration is a TXT record at default._bimi.yourdomain.com pointing to an SVG logo and, optionally, a Verified Mark Certificate.

The prerequisites are strict: DMARC must be at p=quarantine or p=reject (monitoring-only doesn't qualify), the logo must be a specific SVG Tiny PS profile served over HTTPS, and the URL must be on your own domain. For Gmail specifically, you also need a VMC issued by DigiCert or Entrust — roughly $1,500/year and requiring a registered trademark. Apple Mail and Yahoo display the logo without VMC. Either way, BIMI only works if the rest of the stack is enforcing. Test yours with the BIMI Record Lookup.

BIMI matters most for brands users see in their inbox often — banks, retailers, airlines, government services. For these senders, a visible logo measurably lifts open rates and reduces phishing impersonation, because users learn to distrust the unbadged copy of the same brand. For smaller domains or pure transactional senders, BIMI is harder to justify on ROI alone — but it's the last visible signal you can add once everything below it is working, and it costs nothing beyond hosting the logo if you skip the VMC.

Common email security problems

Most deliverability incidents fall into a small handful of patterns. The five below cover the majority of what teams actually run into.

"SPF too many DNS lookups"

SPF allows ten DNS lookups during evaluation, and the count includes every level of every nested include:. Microsoft 365's standard spf.protection.outlook.com spends three lookups on its own; Mailchimp's servers.mcsv.net spends three more; add a couple of CRM and support providers and the limit is exhausted. When it overflows, SPF returns permerror — which DMARC treats as a failure. The fix is to flatten: replace nested includes with the underlying IPs (either by hand for one or two of your stable providers, or via a flattening service that re-resolves on a schedule). The SPF tool shows the lookup count and pinpoints the include responsible.

"DKIM signature not found"

Three causes, in order of likelihood. Wrong selector: every sending service uses a different selector, and switching providers without updating DNS leaves the new mail unsigned. The DKIM tool auto-probes common selectors and tells you which ones actually exist. Key not published: the provider issued the key but the DNS record was never added, or the record was added to the wrong zone. DNS propagation delay: just published the record but the receiver is still seeing the cached NXDOMAIN. Wait out the TTL, then re-check.

"DMARC alignment failure"

SPF or DKIM passes, but DMARC still fails — because the validated domain doesn't match the visible From: header. The two classic causes are mailing lists (which rewrite the From: to their own domain) and forwarding (which keeps the original From: but breaks SPF and may break DKIM if footers are appended). For mailing lists, configure them to use ARC or rewrite the From: to a domain you control. For forwarding, there's no clean fix — DMARC was designed to surface this gap, and the practical answer is to coordinate with major receivers who handle forwarding via inbox-level rules.

"Going to spam despite passing authentication"

Authentication and reputation are different problems. SPF/DKIM/DMARC tell the receiver who you are; reputation tells them whether to trust you. New sending IPs with no history start neutral and only build reputation through good behaviour over weeks. Sending IPs shared with other senders inherit those senders' reputations. And if any IP in your fleet has landed on a DNSBL, every message from it is suspect. Scan with the IP Blacklist Check first; if you're clean, the next thing to investigate is content (link-heavy templates, mismatched display names, missing List-Unsubscribe headers).

"MTA-STS policy not found"

The MTA-STS TXT exists but senders can't fetch the policy file. Usually the mta-sts.yourdomain.com subdomain isn't actually hosting anything, or the .well-known/mta-sts.txt path is returning a 404, or the mx: patterns in the policy don't match the real MX records. A common variant of the last one is publishing a policy that lists only *.yourdomain.com while the real MX is on a third-party hostname like aspmx.l.google.com — the wildcard doesn't match, so the policy effectively covers no MX. The MTA-STS tool tries the same fetch that any sending MTA would and reports each failure mode by name, and cross-checks the mx: patterns against the actual MX record per RFC 8461 §4.1 wildcard rules.

Setting up email security from scratch

If you're starting from an unconfigured domain, the order matters: each step assumes the previous ones are in place, and skipping monitoring leads to enforcement that breaks legitimate mail.

Learn more

The deep-dive posts below walk through each protocol in detail — history, threat model, and the gotchas that surface in real-world deployments. Each post is self-contained and assumes no prior knowledge, but they're written to be read in stack order if you want a full grounding.