---
title: Why are my emails going to spam? Check SPF, DKIM and DMARC with Email Health
description: Mail from your domain lands in spam, and you want to rule out the usual cause first. To check email authentication, look at the three DNS records receivers use to trust your mail: SPF, DKIM and DMARC. Here's how to check them in one run with the free Email Health check, how to read the grade honestly, and what to fix for each red line.
canonical: https://watchfor.io/blog/how-to-check-email-authentication
---

# Why are my emails going to spam? Check SPF, DKIM and DMARC with Email Health

2026-10-04 · WatchFor Team · Guides · guides, email, deliverability

Mail from your domain lands in spam, and you want to rule out the usual cause first. To check email authentication, look at the three DNS records receivers use to trust your mail: SPF, DKIM and DMARC. Here's how to check them in one run with the free Email Health check, how to read the grade honestly, and what to fix for each red line.

When emails go to spam, check email authentication first: the SPF, DKIM and
DMARC records in your domain's DNS. Receivers like Gmail and Outlook use them
to decide whether a message really comes from you. A missing or broken
record makes your mail look like a forgery, and forgeries go to spam or get
rejected. If all three are in place, the cause lies elsewhere (content,
sending reputation, blocklists).

The free [Email Health](/email-policy-checker) check reads SPF and DMARC for
a domain in one run, from a WatchFor location, and grades the result. No
signup.

## What this tool answers

*Does this domain publish what receivers need to trust its mail?* Reach for
it when a new domain's mail lands in spam, when Gmail or Yahoo bounces with
an authentication error, before a product launch or a newsletter goes to a
big list, or when you take over a domain and want to see what's configured.

## A real example

### Checking email authentication when mail lands in spam

A common case: a team starts sending from a domain, and the first replies
say "found your email in my spam folder". Before rewriting subject lines,
check whether the domain authenticates its mail at all. We ran the check on
a public domain with a mature setup, so you can see what good looks like
and how to read the one red mark.

In [Email Health](/email-policy-checker) we typed `mozilla.org` and pressed
**Run email health check**:

![Email Health for mozilla.org: grade B with SPF and DMARC chips green and DKIM red; SPF record with four includes, policy ~all, DNS lookups 4 / 10; DKIM marked FAIL with the note "No DKIM selectors were probed"; DMARC record v=DMARC1; p=reject; pct=100; adkim=r; aspf=r with reporting rua present, ruf absent; DNS health 2 queries, 0 failures](/blog/how-to-check-email-authentication-result.webp)

The run took 79 ms. Line by line:

- **SPF: OK.** One record, ending in `~all`, with 4 includes and 4 of 10
  lookups. The first include,
  `include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email`, uses SPF macros
  (`%{i}` is the sending IP, `%{d}` the domain): a hosted SPF service
  decides per message, which keeps the record short.
- **DMARC: OK, `p=reject`.** Mail that fails authentication is refused, for
  100% of messages, with aggregate reports (`rua`) going to two addresses.
- **DKIM: FAIL**, with the note "No DKIM selectors were probed". This is
  the part to read carefully. DKIM keys live at
  `<selector>._domainkey.<domain>`, and selectors can't be listed from the
  outside, so this combined check doesn't look any up. The red mark means
  "not checked", not "missing".
- **DNS health: 2 queries, 0 failures**, so every answer above is real,
  not a timeout.

To finish the picture we checked DKIM separately with the selector Google
Workspace uses, `google`, in the [DKIM Checker](/dkim-record-checker): the
key is published and valid.

**The answer:** SPF, DKIM and DMARC are all in place and DMARC enforces, so
authentication isn't what sends this domain's mail to spam. The **B** comes
from DKIM not being probed; with all three verified it would be an A. On
your own domain, a missing SPF or DMARC record shows up here as a red
section with "No SPF record found" or "No DMARC record found", and that is
the first thing to fix.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Grade** | A simple count of verified pieces: A = SPF, DKIM and DMARC all OK; B = two; C = one; F = none. It's a quick summary, not a deliverability score. |
| **SPF / DKIM / DMARC chips** | Green when that record is OK, red when it's missing, invalid or (for DKIM here) not checked. |
| **SPF section** | The record, its `all` policy, DNS lookups in the record itself (out of 10) and the number of includes. Details in the [SPF guide](/blog/how-to-check-an-spf-record). |
| **DKIM section** | Always "No DKIM selectors were probed" in this combined check. Use the DKIM Checker with your selector. |
| **DMARC section** | The record, `p=` policy (reject green, quarantine amber, none red), `sp=` if set, `pct`, alignment and whether reports are requested. Details in the [DMARC guide](/blog/how-to-check-a-dmarc-record). |
| **DNS health** | How many lookups ran and how many failed (timeouts, NXDOMAIN, SERVFAIL). Failures make the other sections unreliable; run it again. |

## More ways to use it

- **New domain, first send.** Run it before the first campaign. A domain
  with no SPF and no DMARC is exactly what spam filters expect from a
  throwaway sender.
- **Bulk sender requirements.** Gmail asks bulk senders for SPF, DKIM and a
  DMARC record (at least `p=none`) with alignment. This check covers the SPF
  and DMARC half in one run.
- **After a DNS or provider migration.** TXT records are easy to lose when a
  zone is rebuilt. Compare before and after.
- **Vendor or acquisition due diligence.** A quick read of another
  company's domain shows whether it can be spoofed easily (`p=none` or no
  DMARC).

## Tips and gotchas

- **Fix order matters.** If SPF is missing, publish one record listing every
  service that sends as you (the
  [SPF and DMARC generator guide](/blog/how-to-create-spf-and-dmarc-records)
  builds it). Then turn on DKIM in each sending service, which gives you the
  `_domainkey` records to publish. Last, add DMARC at `p=none` with an `rua`
  address and tighten it once reports are clean.
- **Records being present isn't the same as mail passing.** DMARC needs SPF
  or DKIM to pass *for your From domain*. A service that sends with its own
  bounce domain and its own DKIM signature passes both checks and still
  fails DMARC. A real message's headers show it; see the
  [email header guide](/blog/how-to-read-email-headers).
- **Everything green and still in spam?** Then look at reputation: a listed
  sending IP (the [blacklist guide](/blog/how-to-check-if-your-ip-is-blacklisted)),
  complaint rates, sudden volume from a new domain, and content. The
  [spam folder post](/blog/why-emails-go-to-spam) covers those causes.
- **It reads DNS, not your mail.** The check can't see how a particular
  message was signed or routed; it shows what your domain publishes.

## Check it from the command line too

The same two records with `dig`:

```bash
dig +short @1.1.1.1 TXT mozilla.org | grep spf1
dig +short @1.1.1.1 TXT _dmarc.mozilla.org
```

```text
"v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:_spf.mozilla.com include:_spf.google.com include:spf.fundraiseup.com ~all"
"v=DMARC1; p=reject; pct=100; adkim=r; aspf=r; rua=mailto:dmarc_agg@vali.email,mailto:dmarc@mozilla.com"
```

And DKIM, which needs the selector:

```bash
dig +short @1.1.1.1 TXT google._domainkey.mozilla.org | cut -c1-40
```

```text
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA
```

## Keep watching it

Authentication records break quietly: a DNS migration drops a TXT record, a
new sender pushes SPF over its limit, or a DMARC record is loosened during
troubleshooting. An [email monitor](/email-monitoring) (the email policy
type) re-checks SPF, DMARC and, with your selectors configured, DKIM on a
schedule. **SPF Record Missing** and **DMARC Record Missing** fire by
default; **DKIM Record Missing**, **SPF Too Many DNS Lookups** and **Weak
DMARC Policy** can be switched on.

## FAQ

**Why are my emails going to spam even though they're legitimate?**
Most often the domain fails authentication: no SPF, no DKIM signature, or
no DMARC record, or the sending service isn't aligned with your From
domain. Once those pass, sender reputation, blocklists and content are the
next things to check.

**How do I check if SPF, DKIM and DMARC are set up?**
Run an email authentication check on your domain for SPF and DMARC, and a
DKIM check with your selector (the `s=` value from a sent message's
`DKIM-Signature` header). With `dig`: `TXT yourdomain`,
`TXT _dmarc.yourdomain` and `TXT selector._domainkey.yourdomain`.

**Do I need all three?**
Yes. SPF and DKIM prove where a message came from; DMARC tells receivers
what to do when that proof fails and sends you reports. Gmail requires all
three from bulk senders. How they fit together:
[SPF, DKIM and DMARC explained](/blog/spf-dkim-dmarc-explained).

---

Canonical page: https://watchfor.io/blog/how-to-check-email-authentication · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt