What does Lemwatch monitor?

Lemwatch runs 20+ automated checks per site: uptime, response time, SSL/TLS expiry, domain expiry, DNS changes, sitemap health, broken links, content changes, SEO audits, mobile usability, security headers, and more.

Yes. The free tier monitors up to 5 sites. Pro is $19/month for 50 sites and Agency is $59/month for 100 sites, both with full feature access.

How is Lemwatch different from UptimeRobot or Pingdom?

Lemwatch bundles uptime, change detection, SEO audits, security scans, and a public API in one platform — features competitors charge separately for. It also includes team workspaces, white-labelled status pages, and a webhook system out of the box.

Does Lemwatch send alerts?

Yes. Lemwatch supports email, browser push, webhooks, and per-site notification routing so the right person hears about the right incident.

Is there a public API?

Yes. Pro and Agency plans get a public REST API with webhooks for sites, checks, incidents, and reports.

What is the ten-lookup SPF limit?

Evaluating an SPF record may trigger at most ten DNS lookups. Each include, a, mx and redirect mechanism counts, and includes nest — one provider can cost several. Past ten, the record fails outright and every message is treated as unauthenticated.

Why can DMARC fail when SPF and DKIM pass?

Alignment. DMARC requires the domain in the visible From address to match the domain that SPF or DKIM authenticated. A service sending on your behalf that authenticates under its own domain passes SPF and still fails DMARC until alignment is configured.

Should I start DMARC at reject?

No. Start at a monitoring policy, collect aggregate reports for a few weeks until you recognise every legitimate sender, then move to quarantine, then to reject. Starting at reject blocks your own mail from whichever service you forgot.

Why can you not always see my DKIM key?

DKIM keys are published under a selector name chosen by each sending service, and there is no way to list selectors from outside. We check the common ones. The reliable check is in your sending platform's own dashboard.

Do I need separate records for subdomains?

If a subdomain sends mail, yes — give it its own SPF record and consider its own DKIM. DMARC can cover subdomains from the parent, but a subdomain policy lets you apply a stricter rule to the domain that actually sends.

How long do DNS changes take to matter?

Receiving servers see the new record once caches expire, usually within an hour. Reputation, however, recovers slowly — expect weeks of consistent authenticated sending before inbox placement fully reflects the fix.

Free Tool

Updated 14 September 2026

SPF DKIM DMARC checker

Validate your domain's email authentication records. Check SPF, DKIM, and DMARC configuration to improve email deliverability.

By Deepak Shukla — Founder & CEO, Pearl Lemon

Part of DNS monitoring — the full answer, the facts and the alternatives in one place.

Enter your domain

What This Tool Checks

SPF record presence and validity
DKIM record configuration
DMARC policy and reporting
Record syntax validation

Why This Matters

Without proper email authentication, your emails may land in spam or be rejected entirely. Attackers can also spoof your domain to send phishing emails.

How to Fix Issues

1.Add an SPF record listing your authorised mail servers
2.Configure DKIM signing for your email service
3.Set up a DMARC policy starting with p=none for monitoring
4.Gradually move to p=quarantine and then p=reject

Three DNS records decide whether your email reaches an inbox: SPF says which servers may send for your domain, DKIM cryptographically signs the message so it cannot be altered in transit, and DMARC tells receiving servers what to do when one of the first two fails. Enter a domain above and the check reads all three from live DNS and reports what a receiving mail server would see.

Why this stopped being optional

Since the major mailbox providers tightened their bulk sender rules, unauthenticated mail is not judged on content any more — it is filtered on whether it can be verified at all. A domain with no DMARC policy and a weak SPF record does not get a warning; it gets quietly worse inbox placement, and the sender finds out through unexplained drops in password resets and receipts that nobody complained about because nobody knew they were missing.

The order to fix them in

Publish SPF first, as one record, listing every service that sends mail for you — the marketing platform, the CRM, the helpdesk, the application's transactional sender, the accounting tool. Then confirm DKIM signing is enabled at each of those services and its public key is published at the selector they specify. Only then publish DMARC, starting with a monitoring policy so the aggregate reports show you who is sending as you, before you instruct anyone to reject anything.

The mistakes that cause silent failure

Two SPF records on one domain, which invalidates both. An SPF record that exceeds the ten DNS lookup limit because five services were added over five years, after which the whole record fails to evaluate. DKIM enabled at the provider but the key never published in DNS. A DMARC record with a reject policy published before the sending inventory was complete, which blocks your own legitimate mail from the one service nobody remembered. A subdomain used for transactional mail with no policy of its own, inheriting a parent policy that was never designed for it.

What to do after the check passes

Alignment is the part people miss: SPF and DKIM can both pass while DMARC still fails, because DMARC also requires the domain in the visible From address to match the authenticated domain. If your reports show passes for the underlying service domain but failures for yours, alignment is what to fix. Once all three are correct, watch them — these records are edited when tools change, and a well-configured domain drifts quietly out of compliance the next time someone adds a new sending platform.

Methodology

We query live DNS for the domain you enter and evaluate three things. For SPF we read the TXT record beginning v=spf1, check that exactly one exists, parse its mechanisms, count the DNS lookups it will trigger — include, a, mx, ptr, exists and redirect all count against the RFC limit of ten — and read the terminator that decides what happens to mail from unlisted servers. For DKIM we check the selectors we can discover and whether a valid public key is published; because selectors are chosen by each sending service and are not enumerable from the outside, an absent result here means "not found at the selectors we know", not proof that signing is off. For DMARC we read the TXT record at the _dmarc subdomain and report the policy, the subdomain policy, the coverage percentage, the reporting addresses and the alignment modes. Everything is read from public DNS; no mail is sent, received or inspected.

Frequently Asked Questions

Monitor this continuously with LemWatch

A one-off free spf, dkim & dmarc checker shows you today. LemWatch re-runs the same checks around the clock and alerts you the moment something breaks — free for up to 10 sites, no card needed.