# SPF, DKIM, and DMARC Explained: How to Stop Email Spoofing on Your Domain

> SPF says who can send, DKIM proves nothing was tampered with, and DMARC ties them together and tells receivers what to do. Here's how the three work — and how to check yours are set up right.

- URL: https://www.pyalm.com/blog/spf-dkim-dmarc-explained-stop-email-spoofing
- Author: Fadhil Abdulla
- Category: Pyalm Guard
- Published: 2026-07-07
- Updated: 2026-07-07

---

Anyone can put your domain in the "From" field of an email. Without the right DNS records, receiving mail servers have no way to tell your real mail from a spoof — which is why email authentication exists. Three records do the work: **SPF**, **DKIM**, and **DMARC**. They're easy to confuse, so here's what each actually does.

## SPF — who is allowed to send

**Sender Policy Framework** is a DNS TXT record listing the servers permitted to send mail for your domain:

```
v=spf1 include:_spf.google.com include:sendgrid.net -all
```

When a server receives mail claiming to be from you, it checks whether the sending IP is in that list. The ending matters: `-all` (hard fail) says "reject anything not listed," while `~all` (soft fail) says "accept but mark suspicious." SPF's main limit is that it validates the **envelope** sender, not the "From" header a human sees — which is where DMARC comes in.

## DKIM — proof it wasn't tampered with

**DomainKeys Identified Mail** adds a cryptographic signature to your outgoing messages. Your mail server signs each message with a private key; the matching public key lives in a DNS TXT record at a **selector** (e.g. `selector1._domainkey.example.com`). The receiver verifies the signature, proving two things: the message really came through your infrastructure, and its signed content wasn't altered in transit. Because it's keyed to a selector, you can run multiple selectors for different providers and rotate keys without downtime.

## DMARC — the policy that ties it together

**SPF and DKIM authenticate. DMARC decides what to do about failures** — and closes the "From" header gap. A DMARC record specifies a policy and where to send reports:

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s
```

DMARC requires **alignment**: the domain that passed SPF or DKIM must match the visible "From" domain. Then `p=` tells receivers how to treat mail that fails: `none` (monitor only), `quarantine` (send to spam), or `reject` (block outright). The `rua` address receives aggregate reports so you can see who's sending as you before you tighten the policy.

## The order to roll it out

1. **Publish SPF** listing every legitimate sender — don't forget your CRM, invoicing, and support tools.
2. **Enable DKIM** with your provider and publish the selector's public key.
3. **Start DMARC at `p=none`** with a `rua` address, read the reports, fix any legitimate source that's failing alignment.
4. **Move to `quarantine`, then `reject`** once the reports are clean.

## DNSSEC — the layer underneath

All three records live in DNS, and DNS answers can themselves be forged. **DNSSEC** cryptographically signs your DNS zone so resolvers can detect tampering — worth enabling so the records above can be trusted in the first place.

## Check what you actually have

The gap between "we set up SPF once" and "our email authentication is correct today" is where spoofing lives — a missing DMARC policy, a soft `~all` nobody tightened, an expired DKIM selector. [**Pyalm Guard**](https://www.pyalm.com/products/guard) inspects SPF, DKIM across multiple selectors, DMARC, and DNSSEC in one pass and flags spoofing risk. [Check your domain](https://guard.pyalm.com).

## Related reading

[Assess your domain with Pyalm Guard](https://www.pyalm.com/products/guard) | [Introducing Pyalm Guard](https://www.pyalm.com/blog/introducing-pyalm-guard-security-posture-assessment) | [Subdomain takeover explained](https://www.pyalm.com/blog/subdomain-takeover-explained-detect-prevent) | [HTTP security headers guide](https://www.pyalm.com/blog/http-security-headers-guide-hsts-csp)