What is DMARC? SPF, DKIM and DMARC in plain words
Anyone can put your domain in the From line of an email. SPF, DKIM and DMARC are three DNS records that help receiving mail servers tell your real mail from forgeries, and tell them what to do with the forgeries.
The problem these records solve
Email was designed without sender checks. Any server can send a message that claims to come from billing@your-company.example, and nothing in the protocol stops it. Your customers then receive a convincing invoice or password reset link that you never sent.
The three records work as a team. SPF and DKIM let a receiver verify where a message came from. DMARC ties that check to the address people actually see and publishes your instructions for messages that fail.
SPF: who may send for your domain
SPF (RFC 7208) is a single TXT record on your domain that lists the servers and services allowed to send your mail: your mailbox provider, your newsletter tool, your online shop.
Example: v=spf1 include:_spf.mail-provider.example ip4:203.0.113.10 ~all
- The ending tells receivers what to think of every other server:
~all(soft fail) or-all(fail).+allallows anyone and defeats the purpose;?allsays nothing. - Publish only one SPF record per domain. With two, SPF evaluation ends in an error.
- SPF may use at most 10 DNS lookups (
include,a,mx,ptr,exists,redirect). Every added service costs lookups, and above 10 the result is an error, so trim services you no longer use.
SPF has a blind spot: it checks the technical envelope sender, not the From address a person sees. This is why DMARC exists.
DKIM: a signature on every message
DKIM (RFC 6376) adds a cryptographic signature to each outgoing message. The receiving server fetches the public key from DNS and checks that the message was signed for your domain and not changed on the way.
The key is published at a name like selector._domainkey.your-domain.example. The selector is a label chosen by whoever signs your mail, such as google, selector1 or s1. One domain can have several selectors, typically one per sending service.
Why scanners guess DKIM selectors
DNS offers no way to list every selector of a domain. The selector is written inside each signed message (the s= tag of the signature), so the only reliable way to learn it is to read the headers of a real email from you.
An external check can therefore only try common names. ZNIMOK tries 19 of them, including selector1 and selector2 (used by Microsoft 365), google, default, k1 and zoho, plus names used by some newsletter services it recognizes on your homepage. If none answers, the report says that no key was found on common selectors and that this does not prove the domain has no DKIM.
To check DKIM yourself, send a message to a mailbox you control, open the original headers and look for dkim=pass with your domain next to it.
DMARC: tie it together and set a policy
DMARC is a TXT record at _dmarc.your-domain.example. A message passes DMARC when SPF or DKIM passes and the domain they verified matches (aligns with) the domain in the visible From address. The record also tells receivers what to do with mail that fails and where to send reports.
Example: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.example
| Policy | What it asks receivers to do | When to use it |
|---|---|---|
| p=none | Nothing special: deliver as usual and send reports | The first weeks, while you collect reports |
| p=quarantine | Treat failing mail as suspicious, usually the spam folder | Once all your real senders pass |
| p=reject | Refuse failing mail | The goal for most domains |
The DMARC standard was revised in May 2026: RFC 9989 replaced RFC 7489. The three policy values did not change. The new version retires the pct tag and adds a test flag, t=y, for trying a stricter policy.
Why p=none is only monitoring
p=none is where many domains get stuck. It is useful for collecting reports, but it stops nothing: a forged message in your name is delivered just as before. Without a report address (rua) you get neither protection nor information.
Aggregate reports arrive as XML files from large mailbox providers. They show which servers send mail in your name, so you can find a forgotten service, such as an old CRM or a booking system, before you tighten the policy.
A practical path: start with p=none and a report address, read the reports for a few weeks, fix every legitimate sender that fails, then move to p=quarantine and later to p=reject. Remember subdomains: sp=none leaves them open to forgery even when the main domain is protected.
What Gmail and Yahoo require
Since February 2024 Gmail and Yahoo have required authentication from everyone who sends to their users, with stricter rules for bulk senders:
| Requirement | All senders | Bulk senders |
|---|---|---|
| SPF and DKIM | SPF or DKIM | Both SPF and DKIM |
| DMARC record | Not required | Required, p=none is enough |
| From domain alignment | Not required | Aligned with SPF or DKIM |
| One-click unsubscribe | Not required | For marketing and subscribed mail |
| Spam complaint rate | Below 0.3% (Google recommends under 0.1%) | Below 0.3% (Google recommends under 0.1%) |
Google counts as a bulk sender anyone who sends close to 5,000 or more messages a day to personal Gmail accounts, and the status is permanent once reached. Gmail also asks all senders for valid forward and reverse DNS and for TLS, and says it is increasing enforcement from November 2025: failing mail can be rejected or sent to spam. Yahoo asks bulk senders to honor unsubscribe requests within 2 days.
What the ZNIMOK check looks at
The email security check reads the public DNS records of your domain. It does not send email and does not start an SMTP session with your mail server. It looks at:
- SPF: missing, more than one record,
+allor?allat the end, more than 10 lookups. - DMARC: missing,
p=none, no report address,sp=nonefor subdomains, more than one record. - DKIM on 19 common selectors, and whether a found key has been revoked.
- MX records, MTA-STS and TLS-RPT for encrypted delivery between mail servers.
Questions
Do I need DMARC if I send only a few emails a month?
Yes, if the domain sends mail at all. DMARC protects the people who receive mail that claims to be from you, and forgers do not care how much you send yourself. A common setup for a domain that never sends mail is v=spf1 -all plus v=DMARC1; p=reject.
Will p=reject break my mail?
It can, if a legitimate service sends in your name without passing aligned SPF or DKIM. That is why you read the reports under p=none first and fix those services before you switch.
The report says no DKIM was found, but my mail is signed. Why?
Your provider probably uses a selector outside the common list. Check the s= value in the DKIM-Signature header of a real message; if the headers show dkim=pass for your domain, DKIM works.
Sources
- RFC 9989: DMARC (May 2026) rfc-editor.org
- RFC 7208: Sender Policy Framework (SPF) rfc-editor.org
- RFC 6376: DomainKeys Identified Mail (DKIM) rfc-editor.org
- Google: Email sender guidelines support.google.com
- Google: Email sender guidelines FAQ support.google.com
- Yahoo Sender Hub: best practices senders.yahooinc.com