What this SPF, DKIM, and DMARC checker shows
Email has no built-in proof of who really sent a message, so domains publish three kinds of DNS record to fill the gap. Receiving mail servers look them up before they decide whether to deliver, flag, or reject a message that claims to come from the domain.
- SPF (Sender Policy Framework) is a TXT record on the domain that starts with
v=spf1and lists the servers allowed to send its mail. Receivers check it against the address of the server that connected to them and the sender address given in the delivery (the “envelope” sender), which is not always the address you see in the From line. - DKIM (DomainKeys Identified Mail) has the sending server sign each message. The matching public key is published in DNS at
selector._domainkey.example.com, where the selector is a name the domain owner chose, and receivers use that key to check the signature. - DMARC is a TXT record at
_dmarc.example.com. It says what receivers should do with mail that does not pass SPF or DKIM in a way that lines up with the domain in the From line (nothing special, quarantine, or reject), and where to send reports about it.
When you run a check, HostChecker reads those records from DNS with the standard dig command. It looks for the SPF record on the domain, for the DMARC record at _dmarc (and, when the domain has none, on its parent domains, the way receivers do), and for a DKIM key at six common selectors. It then points out the problems it can see in the records themselves. Nothing is sent to the domain’s mail servers. You can type a domain, a web address, or an email address, and only the domain part is used. Here is an example, with what each part tells you:
Email records
- The policy is none: receivers still deliver mail that fails DMARC and only send reports. That is a sensible first step, but it does not stop anyone forging this domain.
DKIM has no public list of selectors, so only the common ones are tried (google, default, selector1, selector2, k1, mail). Not seen here does not mean DKIM is not set up under another selector. SPF is limited to 10 DNS lookups in total, counting everything inside its include: records, which this check does not expand.
Above the cards, a live result also has a one-line verdict. For this example it would read “Good: SPF found, DMARC found (none), DKIM found.” Records are read from a DNS resolver that may keep answers until their TTL runs out, so a change you made a few minutes ago can still show the old value. DNS Propagation compares public resolvers side by side.
This check reads the three records and what they say. It does not send a test message, so it cannot tell you whether your mail is delivered or lands in spam, and it does not look at the other things that affect delivery. The last section lists exactly what is and is not covered.
How to read the result
- The verdict. “Excellent” means SPF, DMARC, and DKIM were all found and there is nothing to flag. “Good” means two of the three were found, or all three with something to flag. “Basic” means one, and “Minimal” means none. Excellent and Good show green, Basic amber, and Minimal red. DKIM only counts when it is found at one of the six selectors that are tried, so a domain that signs under another selector cannot score above Good, however well it is set up. Treat it as a summary, not a grade.
- SPF. Found (green) means one SPF record. Missing (red) means none. Broken (red) means two or more. Found turns amber, with “see the notes below”, when the record itself has a problem such as ending in
+all. - DMARC. The tile shows the policy that applies. Reject and quarantine are green. None is amber because it only collects reports. “from example.com” means the name you typed has no DMARC record of its own and the record on its parent domain applies (see the subdomain section below). Missing is red. Unknown (grey) means DNS did not answer for the lookup, so try again.
- DKIM. Found (green) means a usable key exists at one of six selectors. Not seen (grey) means none did, which is neither a failure nor proof that DKIM is missing. If a selector holds a revoked key, it is listed on a separate “DKIM revoked” row.
- Notes with a “!”. Each one describes a specific problem in a record, in plain English, with the fix.
- Show complete raw command output. The real
digcommands and what they returned, so you can repeat any lookup yourself.
Common SPF, DKIM, and DMARC problems and fixes
There is no SPF record
Receivers have no list of servers allowed to send for the domain. Add one TXT record on the domain itself (not on www). Your mail provider’s setup guide gives the include: value to use, and the record looks like v=spf1 include:provider.example ~all. A domain that never sends mail can publish v=spf1 -all, which RFC 7208 calls a well-established best practice. Other TXT records on the domain, such as site verification tokens, are normal and have nothing to do with SPF.
Two SPF records are published
This usually happens when two services each said “add this TXT record”. A domain may publish only one. With two or more, receivers stop with a permanent error (permerror) instead of checking senders, so SPF cannot pass for any message. Merge them into one record that lists every service: v=spf1 include:first.example include:second.example ~all.
The record ends in +all, ?all, or has no all
The last term says what happens to a server the record does not list. -all asks receivers to fail it and ~all to treat it as suspicious (a softfail); both are normal choices. +all, or a bare all, passes every server on the internet, which switches SPF off in practice. ?all is neutral and can never fail a forged message. A record with no all and no redirect= gets a neutral result for unlisted servers as well. The result lists each of these as a note.
The record is over the 10-lookup limit
While checking one message, a receiver may follow at most 10 terms that cost a DNS lookup: include, a, mx, ptr, exists, and redirect. The count includes lookups inside every included record, and the ip4, ip6, and all terms are free. Going over makes receivers stop with a permanent error, and SPF cannot pass. A record that lists many mail services reaches the limit quickly. Remove services you no longer use, replace a and mx with ip4 or ip6 ranges where the addresses are stable, or use a flattening service, keeping in mind that a flattened list goes stale when a provider changes its addresses. This check counts only the terms written in the record itself and does not follow the includes. It reports a problem when that number alone is above 10, so a record can pass here and still be over the limit once the includes are expanded.
A long SPF record is shown on one line
One string in a DNS TXT record holds at most 255 characters, so a long record is published as several quoted strings, and receivers join them with nothing in between (RFC 7208, section 3.3). This check joins them the same way. Many DNS hosts split long values for you. The RFC also recommends keeping the whole record small enough to fit in a 512-byte DNS reply.
DMARC is missing
Without a DMARC record, receivers have no instruction for mail that fails, and you get no reports. Publish a TXT record at _dmarc.example.com, starting with v=DMARC1; p=none; rua=mailto:you@example.com. Read the reports for a few weeks to see which of your services send mail as your domain and whether each passes SPF or DKIM, fix the ones that do not, and then move the policy to quarantine and later reject.
DMARC is set to p=none
The policy none asks receivers to take no special action, so forged mail is still delivered, and only reports are collected. It is the right first step, and Gmail, Yahoo, and Outlook.com accept it for bulk senders (see the FAQ), but it does not protect the domain from being forged. Once the reports show that your real mail passes, tighten the policy. The current DMARC specification advises domains whose users post to mailing lists not to publish reject, and says a domain that does publish it must not rely on SPF alone, because forwarding and mailing lists break SPF while DKIM signatures generally survive. Sign your mail with DKIM first.
A subdomain shows a DMARC record from its parent
DMARC is the one record that receivers look for up the tree: when the domain in the From line has no record at its own _dmarc name, they use the parent domain’s. This check does the same, up to five parent names and never the top-level domain, and says where the record came from. The parent’s sp= tag sets the policy for subdomains when it exists, and its p= tag covers them otherwise. A record published on the subdomain itself replaces the parent’s. Here is how www.example.com could look when only example.com publishes DMARC:
Email records
No DMARC record is published on www.example.com itself, so receivers use the one on example.com. It applies to subdomains through its sp= tag, or its p= tag if there is no sp=.
SPF and DKIM do not work this way. A subdomain that sends mail needs its own SPF record, and a DKIM key is found under the domain named in the signature, so a subdomain with no SPF record of its own shows SPF as Missing even when its parent has one.
DKIM shows “Not seen”
DKIM has no directory. The selector is chosen by whoever set it up, and nothing in DNS lists the selectors a domain uses, so a tool can only try likely names. This one tries google, default, selector1, selector2, k1, and mail: the first is the usual one for Google Workspace, the next two for Microsoft 365, k1 is used by Mailchimp, and default and mail are common defaults in self-hosted mail software. Finding a key proves DKIM is set up. Finding none proves nothing, because most providers use other names or a dated selector. To find the real one, open a message the domain sent, view its full headers, and look at the DKIM-Signature header: s= is the selector and d= is the domain. Then look it up yourself with dig +short TXT selector._domainkey.example.com.
A DKIM key is revoked
A key record whose p= tag is empty means the key has been revoked, and any message signed with it fails DKIM (RFC 6376). It is listed on its own row and does not count as found. Revoking a selector you no longer use is deliberate and fine. If the domain sends mail and the selector is the one your provider signs with, publish the key your provider gives you.
“Does not exist” or “DNS did not answer”
“Does not exist” (NXDOMAIN) means the name is not in DNS at all: check the spelling, and use WHOIS to see whether the domain is registered. “An alias for a name that does not exist” means the name is a CNAME pointing at a name that is not in DNS. “DNS did not answer” means the lookup timed out or the domain’s name servers returned an error such as SERVFAIL. Try again in a minute. If it keeps happening, the name servers are failing or the domain’s DNSSEC is broken, which DNS Lookup can help narrow down.
What this check does not cover
- Whether your mail is delivered. No message is sent. Delivery also depends on your sending server’s reputation, the content, and the receiver’s own filters. A result of Excellent does not mean your mail reaches the inbox.
- Whether a particular server passes SPF. The record is read and checked for the problems above, but it is not evaluated against a sending address, and the
include:records are not followed. So the full lookup count and whether each included record exists are not checked. - DKIM beyond the six selectors. Signatures on real messages are not verified, and the key length is not read. RFC 8301 requires signers to use RSA keys of at least 1024 bits and recommends at least 2048.
- The finer points of DMARC. Alignment settings (
adkim,aspf) are not interpreted, and neither are report addresses on other domains, which must be authorized by a record on the receiving domain, or the reports themselves. - Where mail is received. MX records are not checked. DNS Lookup shows them.
- Other mail-security records and settings: MTA-STS, TLS-RPT, BIMI, and DANE are not checked, and neither is the reverse DNS (PTR) name of your sending server, which DNS Lookup shows when you enter the server’s IP address. Whether the server’s IP address is on a spam blacklist is a separate check, in Blacklists.
- IP addresses. SPF, DKIM, and DMARC are published for a domain name, so entering an IP address returns a message saying a domain is needed (and IPv6 addresses are rejected as invalid input).
Frequently asked questions
How do I check my SPF, DKIM, and DMARC records?
Type the domain into the box above and run the check. It shows the SPF record published on the domain, the DMARC record and its policy, and any DKIM key found at six common selectors, and it points out problems in the records. To look at a record yourself, run dig +short TXT example.com and find the line that starts with v=spf1, or dig +short TXT _dmarc.example.com for DMARC.
How do I check a DKIM record if I know the selector?
Look up selector._domainkey.example.com as a TXT record, for example dig +short TXT selector1._domainkey.example.com. A working key looks like v=DKIM1; k=rsa; p= followed by a long string of characters. If you do not know the selector, open a message the domain sent, view its full headers, and read the s= tag of the DKIM-Signature header. This tool only tries six common names, so it cannot find a selector it was not given.
Why does it say DKIM was not found when DKIM works?
DKIM keys live at names the domain owner picks, and DNS has no way to list them, so this check tries google, default, selector1, selector2, k1, and mail and nothing else. Finding a key proves DKIM is set up, but finding none proves nothing. Many providers use a different selector, or a dated one that changes. The selector is in the s= tag of the DKIM-Signature header of any message the domain sent.
How many DNS lookups can an SPF record use?
Ten. RFC 7208 counts every include, a, mx, ptr, and exists term and the redirect modifier, including the ones inside included records, and a receiver must stop with a permanent error (permerror) when the total passes 10. The ip4, ip6, and all terms do not count. Receivers are also advised to stop after two lookups that return no data. This check counts only the terms in the record itself, not the ones inside the includes, so it flags a record only when that number alone is above 10.
Can a domain have more than one SPF record?
No. If a name publishes two or more records starting with v=spf1, receivers produce a permanent error instead of checking senders (RFC 7208, section 4.5), and SPF cannot pass. Put every service in one record. A single record can hold many include: terms. Other TXT records, such as site verification tokens, do not count.
Should my SPF record end in ~all or -all?
Both are valid. -all asks receivers to fail mail from servers that are not listed, and ~all asks them to treat it as suspicious. The current DMARC specification warns that a hard fail can make a receiver reject a message during the SMTP conversation, before it ever looks at DMARC, so mail that would have passed DMARC through an aligned DKIM signature can be rejected, and those rejections never show up in DMARC reports. Either is acceptable, and a domain that sends no mail should publish v=spf1 -all. ?all and +all are not good choices, because they let everything through.
What do DMARC p=none, quarantine, and reject mean?
They are the policy the domain owner asks receivers to apply to mail that fails DMARC. none asks for no special action, and only reports are collected. quarantine asks receivers to treat the mail as suspicious, which usually means the spam folder. reject asks them to refuse it. Receivers make the final decision: the current specification says they must not reject a message solely because of a reject policy, and without other information they should treat it like quarantine. The sp= tag sets a separate policy for subdomains.
Is a DMARC policy of none good enough?
It is a valid starting point and satisfies the minimum that Gmail, Yahoo, and Outlook.com ask of bulk senders, but it does not stop anyone from forging your domain, because mail that fails is still delivered. Its value is the reports, which show everything that sends mail as your domain. Use them to fix legitimate senders, then move to quarantine and reject.
What are the rua and ruf tags?
They are the addresses for DMARC reports. rua receives aggregate reports, usually daily summaries from each receiver, of who sent mail as your domain and whether it passed. ruf asks for reports about individual failed messages. Whether to send either is up to each receiver, and Gmail says it does not support ruf. If an address is on a different domain from the one publishing the record, receivers only use it when that other domain publishes a TXT record authorizing it at yourdomain._report._dmarc.theirdomain (RFC 9990). Report services normally set this up for you, and this check does not test it.
Do Gmail, Yahoo, and Outlook.com require SPF, DKIM, and DMARC?
For bulk senders, yes. Each of the three publishes its own requirements: authenticate with both SPF and DKIM, and publish a DMARC record that passes with alignment (a policy of none is accepted). Google and Yahoo add rules such as one-click unsubscribe and a low spam rate. What counts as bulk is defined by daily volume, and the number belongs to each provider and can change, so read their pages: Google, Yahoo, and Microsoft (Outlook.com). Google asks every sender for at least SPF or DKIM, and says messages that are not authenticated can be marked as spam or rejected. Whatever your volume, a domain with all three in place is easier for any receiver to trust.
What DKIM key length should I use?
Use RSA keys of at least 2048 bits if your DNS host allows it. RFC 8301 requires signers to use at least 1024 bits and recommends at least 2048, and Google asks for 1024 bits or longer when sending to personal Gmail accounts. A 2048-bit key is longer than one 255-character DNS string, so it is published as two strings that receivers join. This check does not read the key length.
Which standards define SPF, DKIM, and DMARC?
SPF is RFC 7208, and DKIM is RFC 6376 with later updates (RFC 8301 bans the old rsa-sha1 signing algorithm, and RFC 8463 adds Ed25519 keys). DMARC was RFC 7489, an informational document. It has been replaced by RFC 9989, which is on the IETF standards track, together with RFC 9990 and RFC 9991 for aggregate and failure reports. The core ideas are unchanged. RFC 9989 finds the policy by walking up the domain name one label at a time instead of using a public suffix list, and it drops the pct tag in favor of a simple test flag, t. Some receivers still follow the older behavior.
Does this check tell me if my email will be delivered or land in spam?
No. It reads three kinds of DNS record and does not send a message. Missing or broken records are a common reason mail is rejected or sent to spam, so fixing them helps, but delivery also depends on your sending server’s reputation, its reverse DNS, whether its IP address is on a blacklist (Blacklists checks that), and the content of the message.
Can I check an email address or an IP address?
You can paste an email address, and the check uses the part after the @. An IP address does not work, because SPF, DKIM, and DMARC are published for domain names, so you get a message asking for a domain. To look up the reverse DNS name of a server’s IP address, use DNS Lookup.
Does this check MX records?
No. MX records say where a domain receives mail, and SPF, DKIM, and DMARC describe who may send it. Use DNS Lookup to see the MX records.
Is the SPF, DKIM, and DMARC checker free?
Yes. There is no signup, no account, and no limit on how many domains you check, apart from a per-visitor rate limit that keeps the service fast for everyone.