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.