## TL;DR
SPF and DKIM are two ID checks that prove your email really came from you, and failing either one is the fastest route to the spam folder. Users cannot fix these themselves, their domain admin can, so your job is explaining the problem in human terms and handing them the exact sentence to send IT. Keep it to the analogy, the symptom, and the ask. The cryptography is not their problem.

## The query

```text
email going to spam: SPF/DKIM explanation for users
```

## Use this when

- Users report your legitimate mail hitting spam
- A customer asks why their sent mail is flagged
- You need the deliverability explainer for the help center
- Onboarding a customer on a custom sending domain
- IT asks what records you need added

## Not for

- Debugging your own mail server configuration
- Getting off a blocklist
- Spam complaints about message content
- Phishing or spoofing incidents

## Steps

### 1. Explain the two checks with the ID analogy

SPF is the bouncer with a guest list: it checks whether the server sending the mail is allowed to send for your domain. DKIM is the wax seal on the letter: a signature that proves the message was not tampered with in transit. Failing either one makes receivers suspicious.

Expected output: the user understands there are two separate checks.

### 2. Show them how to see a failure themselves

In Gmail, open the message, click the three dots, Show original, and look for the SPF and DKIM lines near the top. They will say pass or fail in plain words. This turns "trust me" into "see for yourself."

Expected output: the user can point at the failing check.

### 3. Explain why it fails in human terms

The usual causes: the company changed email providers and nobody updated the records, or they send from a new tool that was never added to the list. It is a paperwork problem, not a hacking problem, which calms people down fast.

Expected output: the likely cause narrowed to a records issue.

### 4. Give them the exact ask for their IT admin

"Hi, our emails are landing in spam because our domain is failing the SPF and DKIM checks. Can you check our domain's DNS records and make sure our sending service is included and the DKIM signature is set up?" One paragraph their admin can act on without a follow-up call.

Expected output: a forwardable request in the user's hands.

### 5. Set expectations on timing

DNS changes can take a few hours to spread across the internet. Tell the user not to retest immediately, and to retest with a fresh email, not by moving the old one out of spam, which teaches the filter nothing.

Expected output: a realistic timeline and a correct retest method.

## Ready-to-use explainer

```text
Think of it like this: every email carries two ID checks.

SPF is the guest list. It asks "is this server allowed to send
mail for your company?" If your company switched email tools
and nobody updated the list, your mail gets turned away.

DKIM is the wax seal. It proves nobody tampered with the
message on the way. If the seal is missing or broken, mail
providers treat it as suspicious.

You can't fix these yourself, but your IT person can in about
ten minutes. Forward them this: "our mail is failing SPF and
DKIM checks, can you verify our domain records include our
sending service?" Changes take a few hours to take effect.
```

## Variant phrasings

### why are my emails going to spam

Steps 1 and 2. Analogy first, then show them the failure with their own eyes.

### what is SPF and DKIM simple explanation

Step 1 on its own. Guest list and wax seal, nothing more.

### emails marked as spam authentication failed

Steps 2 through 4. Find the failing check, explain the cause, hand off the IT request.

## Why it happens

Email was built in trusting times, and SPF and DKIM are the retrofitted trust layer. Big providers now treat missing or failing authentication as a spam signal by default, which means legitimate mail from misconfigured domains gets filtered alongside actual spam. The user experiences this as a sudden, mysterious spam problem, but underneath it is almost always a DNS record that went stale when something else changed.

## Edge cases

- Everything passes but mail still hits spam: then it is content, reputation, or engagement, not authentication. Do not keep fiddling with DNS.
- Forwarded mail breaks the seal: forwarding often invalidates DKIM, so mail that passes direct fails after a forward rule. Warn users with forwarding set up.
- Multiple sending tools: each tool needs its own records. The company that set up SPF for their main provider but not the new marketing tool will fail on the new tool's mail only.
- Shared or free domains: users on generic free addresses cannot change these records at all. The fix is sending from their own domain.
- DMARC rejections: a strict DMARC policy turns soft failures into hard bounces. If mail is bouncing rather than spamming, escalate, because that policy lives with their admin.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0nCXAw6TnjOpk9N0UyjoQQ