Skip to main content
HostTracker
HostTracker
website monitoring service
Status pages Instant check Price
Login Register

Email authentication check: SPF, DKIM and DMARC

Enter a domain to read its SPF, DKIM and DMARC records. You get a pass, weak or missing verdict for each, the SPF lookup count against the limit of 10, the DMARC policy, the DKIM key size and the next step to fix. The check only looks up DNS records: nothing is sent to your domain.

What the checker reads

Only DNS records: the SPF record at the domain, the DMARC record at _dmarc, DKIM keys at selector._domainkey, and the MX hosts. Nothing is sent to your domain's servers.

Find out more

What pass, weak and missing mean

Pass: the record is there and does its job. Weak: it exists but protects little or is broken. Missing: nothing is published. DKIM can also be Not found among common selectors.

Find out more

A check shows today, a monitor shows the change

HostTracker checks these records here, on request, and does not watch them continuously. A website monitor with the DNS blacklist check attached watches the address the site resolves to.

Find out more

Guides to SPF, DKIM and DMARC

Related checkers and monitoring

Standards: RFC 7208 (SPF), RFC 6376 and RFC 8301 (DKIM), RFC 7489 (DMARC), RFC 7505 (null MX). HostTracker is not affiliated with any domain or vendor named on this page.

A check tells you today. Monitoring tells you when it changes. See DNS blacklist monitoring

Key takeaways

  • SPF allows at most 10 DNS-querying terms (include, a, mx, ptr, exists, redirect) per evaluation; past that the result is a permerror (RFC 7208, section 4.6.4).
  • A domain must publish exactly one SPF record; two or more is a permerror (RFC 7208, section 4.5).
  • DMARC p=none asks receivers to take no action: it gives reports, not protection. p=quarantine and p=reject enforce (RFC 7489).
  • DKIM keys sit at selector._domainkey.domain and DNS cannot list selectors; RFC 8301 recommends RSA keys of at least 2048 bits for signing.
  • The checker reads SPF, DMARC, DKIM and MX with DNS lookups only and shows pass, weak or missing for each; HostTracker does not monitor those records over time.

Frequently asked questions.

SPF is a DNS record that lists the servers allowed to send mail for a domain (RFC 7208). DKIM adds a cryptographic signature to each message, which receivers check against a public key published in DNS (RFC 6376). DMARC builds on the other two: it asks receivers to check that SPF or DKIM passed for the same domain shown in the From address, says what to do with mail that fails (nothing, quarantine or reject), and says where to send reports (RFC 7489).
p=none asks receivers to take no action on mail that fails DMARC, so a spoofed message is delivered just as it would be with no DMARC record. Its value is the reports: with a rua address you see who sends mail as your domain and which of your own senders fail. That makes it the right first step and a poor place to stay. Once the reports are clean, move to p=quarantine and then p=reject, optionally ramping up with the pct tag (RFC 7489, section 6.3).
While it evaluates one message, a receiver may run at most 10 DNS-querying terms from an SPF record. The terms include, a, mx, ptr, exists and redirect count; ip4, ip6 and all do not. Terms inside every included record count too, so a short record that includes several mail providers can pass 10. Past the limit the result is a permerror, which fails the message (RFC 7208, section 4.6.4). Which terms a receiver reaches depends on the sending server, so the checker counts every term in the whole tree and shows that total.
A DKIM key is published at selector._domainkey.yourdomain, and the selector is a name your mail provider or your own server chooses. DNS can answer a question about a name you already know; it cannot list the names under _domainkey. So the checker tries a short list of common selectors, and when none matches it says so without claiming the domain has no DKIM. To find yours, open a message the domain sent and read the s= tag in its DKIM-Signature header (RFC 6376).
If nothing sends mail as the domain, say so: an SPF record of v=spf1 -all and a DMARC record of v=DMARC1; p=reject; tell receivers to reject anything that claims to come from it. If the domain also receives no mail, an MX record of 0 ., a null MX, says that too (RFC 7505). Publish these only after you are sure that no mail service, web form, newsletter tool or subdomain sends as this domain, because their mail would be rejected.
Both end an SPF record by saying what to do with a server that is not listed. -all is a hard fail: the message should be rejected or marked as failing. ~all is a softfail: it is accepted but marked as suspicious. +all authorizes every server and ?all makes no claim, so neither protects anything (RFC 7208, section 8). Many domains start with ~all and move to -all once DMARC reports show that every legitimate sender is listed.
No. The checker reads DNS records at one moment from public resolvers. It shows that they exist and are well formed, not that your mail passes: that depends on the sending server, the envelope domain and the signing domain of each real message. The Authentication-Results header of a message you received shows what a receiving server decided. Receivers also weigh reputation and content, so a message that passes can still land in spam. The guide to checking SPF, DKIM and DMARC shows how to read that header.

Part of HostTracker's website monitoring software.