emailmarketing.net
EnglishFrançais

Reading a Domain Check Result

What SPF, DKIM, DMARC, MX and blocklist results mean when the domain check says good, risky, bad or unknown, what the check cannot see (selectors it didn't try, the addresses you actually send from, your reputation), and the next step for each.

Operational9 min read

Who it is for Senders

Applies to senders on any platform

ContentsOn this page — 7 sections

The free domain check reads the records your domain publishes in public DNS for SPF, DKIM, DMARC and MX, and looks up the addresses your SPF record authorises on the blocklists it queries. It gives each result one of four words, and each word has a specific meaning:

Verdict What it means
good The check ran and found what it looks for.
risky The check ran and found a setup that works but leaves a gap.
bad The check ran and found something missing or broken.
unknown The check did not get an answer. It is neither a pass nor a fail, and the check never reports good for a check that did not finish.

The results describe what your domain tells mailbox providers. They are not a prediction of where your mail will land. Authentication makes mail "less likely to be rejected or marked as spam", in Google's words (Gmail sender guidelines). Less likely is not a guarantee, even with every result good.

Every result also carries its own one-line next step. This article explains the reasoning behind those steps, and who usually takes them.

SPF

SPF lists the servers allowed to send mail for your domain, in a TXT record starting with v=spf1 (RFC 7208). Its last term, the "all-mechanism", tells receivers how to treat mail from anywhere else.

Verdict What the check found Next step
good The record ends in -all (strict fail) or ~all (soft fail). Soft fail relies on DMARC to stop spoofed mail, so the DMARC result matters too. No action on this record. Keep it current when you add or change services that send as your domain, and read the DMARC result.
risky The record ends in ?all or +all, which do not meaningfully restrict who can send as your domain, or it has no recognised all-mechanism. Once every legitimate sender is listed, end the record with -all (or ~all while testing).
bad No SPF record; more than one; a syntax error; more than 10 DNS lookups; or a redirect= pointing at a domain with no SPF record, or several. Publish exactly one record starting with v=spf1: merge duplicates, fix the syntax, or remove unused mechanisms until evaluation needs 10 lookups or fewer.
unknown The DNS lookups failed or didn't finish in time, or the record hands its policy to another domain with redirect= and the check did not follow it. Try again in a moment. For a redirect, look up the SPF record at the target domain: its all-mechanism is the policy receivers apply.

Why these count as bad: RFC 7208 says more than one SPF record, a syntax error anywhere in the record, or more than 10 DNS-querying terms all make SPF evaluation end in a "permerror", a permanent error rather than a pass (RFC 7208 §4.5, §4.6 and §4.6.4).

Who acts: the DNS owner edits the record. Your sending platform tells you what to include for its servers. Google says SPF should include all email senders for your domain, and that mail from senders left out is more likely to be marked as spam (Gmail sender guidelines).

DKIM

DKIM signs each message with a key. The public half of that key is published in DNS under a name called a selector, which the signature itself names in its s= tag (RFC 6376 §3.1 and §3.5). The selector is chosen by whoever signs the mail, so a DNS lookup can only try names and see what answers.

Verdict What the check found Next step
good A DKIM key is published at a selector. That is what DNS can show, not that your messages are signed. The same verdict appears when the domain authorises no server to send (v=spf1 -all), since a domain that sends no mail needs no DKIM key. Check a real message: send one to a mailbox you control and look in its Authentication-Results header for dkim=pass with a d= matching your From domain. Rotate the key periodically.
bad A record exists at the selector, but its public key is missing or malformed. Regenerate the key pair and republish the public key. Your sending platform usually provides the record to publish.
unknown No key at any of the common selectors the check tried, or at the selector you entered. The result names the selectors it checked. Ask your sending platform which selector it signs with, then check again with that name in the DKIM selector field.

There is no risky DKIM result. A key is either found and usable, found and broken, or not found where the check looked.

Who acts: the platform generates the key and signs the mail; the DNS owner publishes the public key. The Authentication-Results Header explains how to read dkim=pass (RFC 8601), and DKIM Key Rotation covers rotation.

DMARC

DMARC, published at _dmarc.<your domain>, tells receivers what to do with mail that fails authentication for your domain, and where to send reports (RFC 7489). Its p= tag is the policy: none requests no specific action, quarantine asks receivers to treat failing mail as suspicious, and reject asks them to reject it. The rua= tag names the address that receives aggregate reports (RFC 7489 §6.3).

Verdict What the check found Next step
good A policy is enforced (p=quarantine or p=reject) with aggregate reporting configured. No action. Review the aggregate reports periodically for senders you don't recognise.
risky Monitor-only mode (p=none): reports are collected, but receivers are not asked to quarantine or reject unauthenticated mail. Or a policy is enforced with no rua= address, so nobody sees the reports. Add an rua= address if there is none. Once the reports show all legitimate senders passing, move to p=quarantine, then p=reject.
bad No DMARC record; more than one, in which case receivers apply none of them; or a record with no recognised p= policy. Publish one TXT record at _dmarc.<your domain> starting with v=DMARC1; p=none; to begin monitoring, or remove the extra records, or add the p= tag.
unknown The DNS lookup failed or didn't finish in time. Try again in a moment.

On multiple records, RFC 7489 is explicit: if more than one DMARC record remains, "policy discovery terminates and DMARC processing is not applied to this message" (RFC 7489 §6.6.3).

Risky is not the same as non-compliant. Gmail, Yahoo and Microsoft accept p=none for their bulk-sender DMARC requirement (Gmail, Yahoo, Outlook.com). The risky verdict points at the gap that remains: mail spoofing your domain is not stopped. M3AAWG recommends p=reject where possible, and says every DMARC record, even one with p=none, should include at minimum an rua tag (M3AAWG Email Authentication BCP).

Who acts: the DNS owner publishes and changes the record. Moving from p=none to enforcement is a decision to make with the aggregate reports in hand, because they show which services send as your domain. DMARC Deployment covers the rollout.

MX

MX records name the servers that receive mail for your domain. They matter to a sending domain because replies and bounces come back to it.

Verdict What the check found Next step
good One or more MX records. Or a null MX together with v=spf1 -all: a domain correctly set up to send and receive no mail. No action.
risky A null MX, which says the domain accepts no mail, on a domain that may send mail. If the domain sends mail, replace the null MX with an MX record pointing to a server that can receive replies and bounces.
bad No MX record. Add an MX record pointing to the domain's mail server.
unknown The DNS lookup failed or didn't finish in time. Try again in a moment.

A null MX is defined in RFC 7505. Its §4.2 says mail systems "SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses", and that a domain which does so "risks having its mail rejected". With no MX record at all, SMTP falls back to the domain's own address record, an "implicit MX" (RFC 5321 §5.1), so the check reports that as bad rather than as a designated mail server.

Who acts: the DNS owner, together with whoever runs the mailboxes for your domain.

Blocklists

A DNS blocklist publishes IP addresses in DNS so receivers can look them up while deciding whether to accept mail (RFC 5782). The check reads your SPF record to find the addresses you authorise, then looks each one up on the blocklists it queries.

Verdict What the check found Next step
good No listings on the blocklists checked, across the sending sources checked. If some lists could not be queried, the result says how many. The same verdict appears when the domain authorises no server to send. No action for the lists checked. Check again periodically, especially after your sending addresses change.
bad Listed on one or more blocklists. The result names each address and list. Resolve the cause first, then follow each blocklist's delisting process. Delisting without fixing the cause tends to end in another listing.
unknown Your SPF record names no sending source that resolves to an address, so nothing could be checked; or the lookups failed or gave no usable answer. Check the IP addresses you actually send from directly, using each blocklist's own lookup tool.

Who acts: if you send from your platform's shared IP addresses, the listing belongs to the platform to resolve. Google notes that on a shared IP, "the activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address" (Gmail sender guidelines). If the addresses are yours, the cause is usually in your list or your systems. DNS Blocklists and the Spamhaus Zones covers causes and delisting.

What the check can't see

A clean result covers what the check could read. These are the limits, with where to look instead:

Can't see Why Where to look instead
Selectors it didn't try DKIM selectors are chosen by the signer, not listed in DNS. Ask your platform for the selector and enter it in the DKIM selector field, or read s= in a real message's DKIM-Signature header.
Whether your mail is signed, passes and aligns The check reads DNS only. A published key and a correct SPF record don't show what happens to a real message. Send a message to a mailbox you control and read its Authentication-Results header.
The addresses you actually send from Blocklist lookups use the addresses your SPF record authorises. Senders named through include: are not expanded, a website's address and a mail provider's inbound servers are never checked, and one check covers a limited number of addresses. The result says when any of this applies. Ask your platform which IP addresses your mail leaves from, and check them directly with each blocklist's own lookup tool.
Every blocklist The check queries a fixed set of blocklists. Spamhaus is not checked: its free service is limited to non-commercial use, and the tool has no commercial licence. Each blocklist's own lookup tool.
Your reputation, complaints and placement These live at the mailbox providers, not in DNS. Your platform's bounce and complaint reports, and Google Postmaster Tools for Gmail. Is This a Delivery Problem? shows how to read them together.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 5 in Foundations →