How to Read an SPF, DKIM and DMARC Check Result
A DNS authentication check returns three statuses per record: pass, warn or fail. This page explains each message that AISend's free SPF and DMARC checker can show, what the underlying standard says, and what the checker does not verify, so a green result is not mistaken for proof that mail will be accepted.
What the checker looks up
- SPF: the TXT records at your root domain that start with v=spf1.
- DMARC: the TXT record at _dmarc.yourdomain.com that starts with v=DMARC1.
- DKIM: the TXT record at selector._domainkey.yourdomain.com for each selector you enter. If you leave the selectors box blank, the checker tries 11 common selectors (default, google, selector1, selector2, s1, s2, k1, k2, mail, dkim, smtp) and shows only the ones it finds, because selectors cannot be listed from DNS. Your provider tells you the real selector.
- The checker allows 30 checks per 10 minutes per IP address; past that it answers 429 with a Retry-After header.
SPF messages
| Status and label | Message | What it means |
|---|---|---|
| Fail: Missing | No SPF record found at the root domain. | Receivers have no list of authorized sending servers for the domain. Publish one SPF TXT record. |
| Fail: Multiple records | More than one SPF record is published. RFC 7208 makes that a permanent error; merge them into one TXT record. | RFC 7208 section 4.5 says that if more than one SPF record is found the result is permerror. Merge every include and ip4 term into a single record. |
| Fail: Too many DNS lookups | This record needs more than 10 DNS lookups once its includes are followed. | The checker follows includes and redirects and counts include, a, mx, ptr, exists and redirect terms across all of them. RFC 7208 section 4.6.4 requires a permerror result above 10. See our guide to counting and fixing it. |
| Fail: Allows every sender | One SPF record, N of 10 allowed DNS lookups, but it ends in "+all" (or a bare "all"). | +all and a bare all authorize every server on the internet to send as the domain. Use ~all or -all. |
| Warn: Uses ptr | The record uses the ptr mechanism. | RFC 7208 section 5.5 says ptr SHOULD NOT be used. Replace it with ip4, ip6 or include terms. |
| Warn: No all mechanism | The record does not end in an "all" mechanism or a redirect. | Senders you have not listed are treated as neutral. End the record with ~all or -all once every sender is listed. |
| Warn: Neutral all | The record ends in "?all". | Unlisted senders are neither accepted nor rejected. Move to ~all or -all when every sender is listed. |
| Pass: Valid | One SPF record, N of 10 allowed DNS lookups, ending in the all mechanism or a redirect. | Exactly one record, no more than 10 lookups, no ptr, and an all mechanism or redirect that is not +all, bare all or ?all. |
Limits of the check: the checker follows includes and redirects recursively (to a depth of 6) but stops after 12 DNS queries, and then the message says "at least N" lookups because the real count may be higher. It does not expand macros such as %{d}, so an include that uses a macro is not followed. A pass says the record parses and stays under the limit, not that your mail passes SPF.
DKIM messages
| Status and label | Message | What it means |
|---|---|---|
| Fail: Not found | No DKIM key record at this selector. | Either the record is not published or you entered the wrong selector. Check the exact name your provider gave you before concluding DKIM is broken. |
| Fail: Revoked key | The record has an empty p= tag. | An empty p= means the key was revoked (RFC 6376 section 3.6.1). Mail signed with it will not verify. |
| Fail: Key too short | RSA key under 1024 bits. | RFC 8301 section 3.2 says signers MUST use RSA keys of at least 1024 bits and verifiers MUST NOT treat signatures from shorter keys as valid. |
| Warn: Valid, short key | RSA key of 1024 to 2047 bits. | It still verifies, but RFC 8301 section 3.2 says signers SHOULD use 2048 bits or more. Google also asks for at least 1024 bits and recommends 2048. |
| Warn: Unreadable key | A record is published but its p= value is not a valid RSA public key. | Re-copy the value from your provider; a stray space, quote or truncation is the usual cause. |
| Pass: Found | DKIM key record found (RSA N-bit). | A usable key is published at that name and its size is shown. The checker does not send a message, so it cannot confirm that your provider signs mail with that key. |
DMARC messages and the three policies
| Status and label | Message | What it means |
|---|---|---|
| Fail: Missing | No DMARC record found at _dmarc. | No policy is published. Google and Yahoo require DMARC from bulk senders. |
| Fail: Multiple records | More than one DMARC record is published. | RFC 7489 section 6.6.3 says that if multiple DMARC records remain, receivers take no action, so you get no policy at all. Keep one TXT record. |
| Fail: Invalid policy | The record has no valid p= tag. | p must be none, quarantine or reject; without it receivers ignore the record. |
| Warn: Monitoring only | DMARC is published with p=none. | Valid, and enough for the minimum Google and Yahoo ask of bulk senders, but nothing is enforced. |
| Pass: Enforced (quarantine) | DMARC is published with p=quarantine. | Failing mail is treated as suspicious by receivers that honor the policy. |
| Pass: Enforced (reject) | DMARC is published with p=reject. | Failing mail should be rejected during the SMTP transaction. |
For a published policy the message can end with Notes: no rua= address (so you receive no aggregate reports), pct below 100 on a quarantine or reject policy (it applies to only part of the mail), or an sp= value that differs from p (subdomains use a different policy).
Per RFC 7489 section 6.3, p=none asks receivers to take no specific action on messages that fail DMARC. p=quarantine asks them to treat failing mail as suspicious, which can mean placing it in the spam folder. p=reject asks them to reject failing mail, ideally during the SMTP transaction. The policy also applies to subdomains unless an sp tag says otherwise. The pct tag, 0 to 100 with a default of 100, exists to roll enforcement out slowly. See our DMARC rollout guide for the order to move in.
The checker reads your DNS only. It does not test DMARC alignment, which requires the domain in the From header to match the domain that SPF or DKIM authenticated, so a passing result here does not mean every real message passes.
A short checklist after you run it
- Fix any Fail first, then any Warn.
- If DKIM says Not found, confirm the selector with your provider and run the check again.
- Send a real message to a mailbox you own and inspect the Authentication-Results header, which shows what the receiving server actually evaluated.
- Re-check after any DNS change; records can take time to propagate.
AISend's 3-day trial is free: 500 emails, no card, one verified domain. Paid plans are charged when you subscribe. AISend is for transactional and consented mail, and sending to anyone other than your own account email requires a verified domain.
Frequently asked questions
What does a warning mean in an SPF or DMARC check?
A warning means the record exists but is weak or at risk. For SPF it flags ptr, a missing all mechanism or ?all; more than 10 DNS lookups is a fail. For DMARC it flags p=none, which monitors but does not enforce. For DKIM it flags a valid RSA key shorter than 2048 bits.
Why does the checker say DKIM is missing when my provider says it is set up?
Most often the selector is wrong. DKIM records live at selector._domainkey.yourdomain.com, and only your provider knows the selector. With the box blank the checker tries 11 common selectors; if yours is not one of them, enter the exact selector your provider gave you and check again.
What is the difference between p=none, p=quarantine and p=reject?
Under RFC 7489, p=none asks receivers to take no specific action on failing mail, p=quarantine asks them to treat it as suspicious (for example, spam folder), and p=reject asks them to reject it.
Does a pass in the checker mean my emails will reach the inbox?
No. It means the DNS records look valid. It does not test alignment, your content, your sending reputation or the receiving server's own filters.