Email is the only internet protocol where the sender is whoever the FROM header says — no questions asked. That design decision from 1982 is why phishing works, why your invoices land in spam, and why an entire industry of authentication standards exists.
Three DNS records fix most of it: SPF, DKIM, and DMARC. They are not optional "enterprise features" — Gmail, Outlook and Yahoo have been enforcing them for years, and bulk senders with failing authentication are throttled or rejected outright.
This guide explains what each record does, how receivers evaluate them, and how to verify yours with the SPF, DMARC and DKIM inspectors built into yas.sh.
SPF — who is allowed to send for this domain?
SPF is a TXT record that publishes a list of servers allowed to send mail for your domain. When a receiver gets a message claiming to be from yourdomain.com, it looks up that TXT record and checks the sending IP against the published mechanisms.
A typical record looks like this:
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Reading it left to right:
v=spf1— version marker (must be the first token).ip4:203.0.113.10— this exact IP may send.include:_spf.google.com— fetch Google's SPF record and evaluate it here (this is how you let Gmail send on your behalf).~all— anything else: softfail.-allwould be hardfail (reject).
The 10-lookup trap
RFC 7208 limits SPF evaluation to 10 DNS lookups. Every include, a, mx, ptr and exists mechanism costs one lookup — and nested includes cost more. Exceed 10 and receivers return permerror and treat the whole record as invalid.
Real-world example:
v=spf1 include:_spf.google.com include:spf.mailchimp.com include:_spf.salesforce.com -allis already 3 lookups before your own IP4 entries — chain a few more providers and you hit the wall.
The SPF Inspector counts lookups for you and shows a green/red meter against the limit. It also flattens the include tree so you see the actual IP list the record expands to.
DKIM — is the message itself intact?
DKIM signs the email with a private key on your sending server and publishes the matching public key in DNS. Receivers verify the signature, which proves the message wasn't altered in transit and that the signing domain really controls that key.
The record lives at a selector:
selector1._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
v=DKIM1— version.k=rsa— key type (RSA is the standard; Ed25519 exists but is rare).p=...— the base64-encoded public key. This is the part that must be complete — a truncated key fails verification silently.t=y— testing mode;t=s— strict (the signing domain must match the FROM domain exactly).
Weak keys matter: 1024-bit RSA keys are considered too small for new deployments — Gmail's own keys are 2048-bit. The DKIM Inspector parses the DER public key and reports the actual bit length, plus a preview of the p= value.
DMARC — what do receivers DO with the verdict?
SPF and DKIM are binary checks. DMARC is policy: it publishes the receiver's instructions when authentication fails, and tells you where to send forensic reports.
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=r"
| Tag | Meaning |
|---|---|
p |
Policy for the domain: none, quarantine or reject |
sp |
Policy for subdomains (optional; inherits p if absent) |
pct |
Percentage of mail the policy applies to (rollout tool) |
rua |
Where aggregate reports go (mailto:) |
ruf |
Where forensic failure reports go (mailto:) |
adkim / aspf |
Alignment mode: r (relaxed) or s (strict) |
Alignment is the clever part: even if DKIM verifies, the signature must be from a domain that matches the visible sender (relaxed = same registered domain; strict = exact). This closes the "I can DKIM-sign with my own domain while claiming to be you" loophole.
The DMARC Inspector shows a policy badge (none/quarantine/reject), alignment chips, and the rua/ruf mailboxes extracted from the record.
The roll-out playbook
- Audit first. Run all three inspectors on every domain you send from. Fix SPF over-limit records and broken DKIM selectors before anything else.
- Start at p=none. Publish DMARC with
p=noneand watch aggregate reports for two weeks. You're collecting data, not blocking mail. - Raise to quarantine. Once you see only legitimate sources in reports, switch to
p=quarantine. - Finish at reject. Keep
rua=so you never lose visibility. This is the state Gmail reports 95%+ of phishing from — and gets your mail delivered.
Verify with one call
Every check in this article is a DNS lookup away. The yas.sh tools wrap them all — the same data the API returns:
curl -X POST https://yas.sh/api/v1/tools/spf-inspector -d '{"domain":"yourdomain.com"}'
curl -X POST https://yas.sh/api/v1/tools/dmarc-inspector -d '{"domain":"yourdomain.com"}'
curl -X POST https://yas.sh/api/v1/tools/dkim-inspector -d '{"domain":"yourdomain.com","selector":"selector1"}'
Authentication isn't a checkbox you tick once. Providers change their rules, your include chains drift, selectors rotate. Run the inspectors quarterly — the records that protect your domain today will rot if you don't look at them.
How the three mechanisms work together
Email authentication is three mechanisms that answer three different questions, and they work best as a system:
- SPF answers "who is allowed to send as this domain?" by publishing the authorized sending servers in a DNS
TXTrecord. Receivers check whether the connecting server is on the list. - DKIM answers "was this message altered in transit?" by attaching a digital signature to the message that receivers verify against the domain's published public key.
- DMARC answers "what should the receiver do when SPF or DKIM fails?" by publishing a policy (
none,quarantine, orreject) and requesting reports on how the domain's mail is being treated.
None of the three is complete alone. SPF and DKIM authenticate the mail, and DMARC tells receivers how to act on the result and how to report it. Aligned together, they protect your domain from forgery, ensure your mail is not tampered with, and give you a mechanism to enforce and observe the policy — which is exactly what the DMARC migration guide uses to tighten protection safely.
Why each one alone is not enough
A common misconception is that a single record is sufficient. SPF alone does not stop a forger from writing your name in the From address of an unsigned or differently-signed message. DKIM alone can be from an unrelated domain and prove nothing about the visible sender without alignment. And without DMARC, a receiver has no instruction about what to do with failing mail, so your protection is not enforced and you cannot see the failures. It is the combination — authenticate, sign, and enforce — that actually protects your domain, which is why treating them as a system rather than three chores matters.
The rollout and monitoring loop
Deploying email authentication is a controlled process, not a single cutover. Publish SPF and DKIM first and confirm your legitimate senders authenticate, then introduce DMARC in p=none and read the aggregate reports to learn who is sending as your domain and whether legitimate sources pass. Only once the passing set is stable do you escalate toward quarantine and then reject. Throughout, monitor the reports — they are the evidence that tells you when it is safe to tighten and when a legitimate sender still needs fixing. This is the same evidence-based escalation the DMARC migration guide walks through in detail, and it completes the picture alongside MX health and transport security.