What happens when someone sends an email claiming to be your bank, your boss, or your own company? Without email authentication, the receiving server has no reliable way to tell the difference between a genuine message and a forgery. That single gap is why phishing remains so effective. The good news is that the defenses already exist, and they are not complicated once you see them in action.
This article walks through concrete email authentication examples across SPF, DKIM, and DMARC, shows what real DNS records look like, explains why messages still fail, and highlights the mistakes that quietly undermine otherwise solid setups. By the end, the reader should be able to look at any domain’s configuration and understand what it is actually saying.
Why Email Authentication Matters in Practice
Email was designed to move messages between servers, not to prove who sent them. Authentication protocols add that proof layer on top of the original system. Three standards do most of the work, and they are designed to be used together rather than as alternatives.
| Protocol | What it proves | Where it lives | Typical record type |
|---|---|---|---|
| SPF | Which servers may send mail for a domain | DNS TXT record | `v=spf1 …` |
| DKIM | That a message was signed by the domain and not altered | DNS TXT record (public key) | `v=DKIM1; p=…` |
| DMARC | That SPF or DKIM actually aligns with the visible From domain, plus a policy | DNS TXT record | `v=DMARC1; p=…` |
SPF is specified in RFC 7208, DKIM in RFC 6376, and DMARC in RFC 7489. Each builds on the one before it. The critical insight is alignment: it is not enough for SPF or DKIM to pass somewhere in the message path. The authenticated domain has to match the domain the recipient actually sees in the From header. A message can pass SPF and still fail DMARC if the passing domain belongs to a third party.
SPF Examples: Reading a Sender Policy Record
The simplest useful example is a small business that sends mail through one provider and its own web server. Its SPF record might read:
`v=spf1 include:_spf.provider.example ip4:203.0.113.25 -all`
Read it left to right. The `v=spf1` tag identifies the record. The `include` mechanism pulls in the sending IP ranges of the mail provider. The `ip4` mechanism authorizes one specific server. The `-all` at the end is the qualifier and it means “hard fail everything else”: any server not listed is not authorized, and receivers should reject the message.
Now compare that with a record ending in `~all`. The tilde is a soft fail. It marks unlisted senders as suspicious but stops short of a hard rejection. Plenty of organizations use `~all` while they are still mapping out which systems send mail on their behalf. It is a reasonable transitional choice and a weak permanent one.
A third common pattern is the “too many lookups” record. SPF allows a maximum of ten DNS lookups during evaluation. Each `include` can trigger more lookups, and a record that chains several providers together can silently exceed the limit. When that happens, SPF returns a permerror, which usually behaves like no SPF at all. This is one of the most common invisible failures in real deployments.
A quick way to spot SPF problems
- Count every `include`, `a`, `mx`, `ptr`, and `exists` mechanism in the record.
- Remember that each one consumes a lookup, and includes can nest.
- Flatten or split the record if the total creeps toward ten.
- Confirm the record is a single TXT string, not several competing TXT records on the same name.
DKIM Examples: What a Signature Actually Does
DKIM adds a cryptographic signature to the message headers. The sending server signs selected headers with a private key, and the public key sits in DNS so receivers can verify it. A typical selector record looks like this:
`selector1._domainkey.example.com TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSq…”`
The `selector1` part is the selector. It lets a domain publish multiple keys at once, which is essential for key rotation. Rotating keys without breaking live mail is one of the practical skills that separates a mature setup from a fragile one.
DKIM has a subtle weakness worth understanding. The signature covers only the headers the signer chose to sign, plus the body hash. If a mailing list or forwarding service adds a footer, changes the subject line, or rewrites the body, the signature breaks. The message then fails DKIM even though nobody did anything malicious. This is why forwarding is the classic cause of authentication failures, and why DMARC has to tolerate some of it.
From a practical standpoint, the best DKIM advice is boring: use 2048-bit keys, rotate them on a schedule, keep the private key off shared infrastructure, and sign consistently. A domain that signs some messages and not others creates exactly the kind of ambiguity attackers exploit.
DMARC Examples: Turning Policy Into Enforcement
DMARC is where the three protocols become a decision. A monitoring-only record looks like this:
`v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100`
The `p=none` policy means “take no action, just tell me what you see.” The `rua` address receives aggregate reports, which are XML summaries of who sent mail as your domain and whether it passed. This is the correct starting point for almost every organization, because it reveals the shadow senders nobody remembered: the CRM, the invoicing system, the old marketing tool.
After a few weeks of reports, the policy moves up. A mid-stage record looks like:
`v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com`
Here, quarantine tells receivers to treat failing mail as suspicious, and `pct=25` applies that to a quarter of messages. This staged rollout is how teams avoid breaking legitimate mail in one dramatic move. The final state is `p=reject`, which instructs receivers to refuse failing messages outright.
| Stage | Policy | What it does | When to use it |
|---|---|---|---|
| Monitor | `p=none` | Collects reports, enforces nothing | First 30 to 60 days |
| Partial | `p=quarantine; pct=25` | Filters a fraction of failures | After senders are identified |
| Enforce | `p=quarantine; pct=100` | Filters all failures | Once reports look clean |
| Lock down | `p=reject` | Rejects all failures | Final steady state |
The reporting addresses matter more than people expect. Aggregate reports are dense XML files that are nearly unreadable by hand, so most teams feed them into a monitoring tool or a script. The forensic or failure reports (`ruf`) are far less useful in practice because many large receivers simply do not send them.
Real-World Examples of Authentication in Action
Government mandates pushed adoption faster than any marketing campaign could. The U.S. federal government’s Binding Operational Directive 18-01 required agencies to deploy DMARC, and later deadlines pushed them toward enforcement rather than monitoring. That created a large, publicly observable population of domains at various maturity levels, which is a useful study set for anyone learning the protocols.
Consumer mailbox providers moved next. In February 2024, major providers including Gmail and Yahoo introduced bulk-sender requirements that pushed high-volume senders toward SPF, DKIM, and DMARC. The practical effect was that organizations which had been quietly running `p=none` for years suddenly had a deadline. For a deeper look at how these layered checks fit together, see what multi factor authentication covers, since email authentication and account-level verification solve related but distinct problems.
The most instructive examples are the failures. A company sends through a third-party platform that uses its own domain in the envelope sender. SPF passes for the platform’s domain, DKIM passes for the platform’s domain, and DMARC fails because neither aligns with the company’s From domain. The fix is configuration, not cryptography: send through a platform that either uses your domain in the envelope or signs with your DKIM key. This is also why security teams pair authentication with user-side awareness, and understanding how to identify a scam email remains a useful complement to any technical control. (Email security and anti-spoofing)
Common Mistakes That Undermine Good Configurations
The gap between a configured domain and a protected domain is usually a handful of predictable errors.
Publishing multiple SPF records. Two TXT records starting with `v=spf1` produce a permanent error. There must be exactly one.
Forgetting subdomains. A record on the root domain does nothing for `mail.example.com` unless a DMARC record with a `sp=` tag or a separate policy covers it. Attackers know this and spoof the subdomain instead.
Leaving `p=none` forever. Monitoring without enforcement is a smoke alarm with the battery removed. It reports, but it never acts.
Ignoring the reporting mailbox. Aggregate reports pile up unread, and nobody notices the unauthorized sender until a customer complains.
Breaking forwarding and then blaming the protocol. Forwarded mail often fails SPF because the forwarding server’s IP is not authorized. DMARC handles this through alignment and DKIM survival, which is why signing matters so much.
Skipping key rotation. A DKIM key that has never been rotated is a long-lived secret. Rotation is cheap if selectors are set up properly from the start.
For teams thinking about the wider identity picture, the same layered logic applies elsewhere: what is biometric authentication explains how verification factors stack, and what is an ai agent examples and applications covers how automated systems increasingly act on a user’s behalf, which raises the stakes for proving who is really behind a message.
A Practical Rollout Sequence That Works
The sequence below reflects what tends to succeed in real organizations, not the theoretical ideal.
- Inventory every sender. Ask finance, sales, support, and engineering which systems send mail as the domain. Include the forgotten ones.
- Publish SPF with `~all`. Get it live and correct before tightening.
- Enable DKIM signing everywhere. Rotate to 2048-bit keys and document the selectors.
- Start DMARC at `p=none` with a monitored `rua` address. Give it 30 to 60 days.
- Reconcile the reports. Fix or authorize every legitimate sender that appears.
- Step to `p=quarantine` with a low `pct`. Raise it gradually.
- Move to `p=reject`. Then keep watching, because senders change.
Step six is where most rollouts stall. The temptation is to jump straight to enforcement, and the result is a week of broken invoices. A gradual percentage ramp costs a little patience and saves a lot of embarrassment. The same discipline applies to account security generally, and how to enable two factor authentication follows a similar staged pattern of enabling, testing, and widening coverage.
Conclusion
Email authentication is less mysterious than its acronyms suggest. SPF lists who may send. DKIM proves the message was signed and unaltered. DMARC ties the two together, checks alignment against the visible From domain, and gives the domain owner a policy that receivers will actually enforce. The examples above show that the difference between a working setup and a broken one is rarely the protocol. It is the details: one SPF record instead of two, selectors that rotate, a reporting mailbox someone actually reads, and the patience to move from monitoring to rejection in stages. Start with visibility, fix what the reports reveal, and tighten the policy once the noise clears. That path works for a five-person shop and a federal agency alike.
Frequently Asked Questions
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes sending servers by IP address. DKIM adds a cryptographic signature that proves the message came from the domain and was not modified. DMARC ties them together by requiring that SPF or DKIM align with the domain in the From header, and it adds a policy telling receivers what to do when checks fail.
Can a message pass SPF and still fail DMARC?
Yes, and it happens often. SPF checks the envelope sender, which may belong to a third-party sending platform. If that passing domain does not align with the visible From domain, DMARC fails. This is the single most common cause of “SPF passes but mail is still rejected.”
Why does forwarded email fail authentication?
Forwarding breaks SPF because the forwarding server’s IP address is not in the original domain’s SPF record. It can also break DKIM if the forwarder modifies headers or the body. DMARC mitigates this through alignment, and DKIM signatures usually survive simple forwarding better than SPF does.
How long should a domain stay at p=none?
Most organizations need 30 to 60 days to collect enough aggregate reports to identify every legitimate sender. Moving faster risks blocking real mail from systems nobody remembered. The goal is to leave `p=none` as soon as the reports are clean, not to stay there indefinitely.
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM without DMARC give receivers information but no instruction. DMARC is what tells them to quarantine or reject failing messages, and it is what produces the reporting that reveals unauthorized senders. Without it, a spoofed message can still reach the inbox.
What is a DKIM selector and why does it matter?
A selector is the label in front of `._domainkey` that points to a specific public key in DNS. It lets a domain publish several keys at once, so keys can be rotated without breaking live mail. Domains that never rotate keys are carrying a long-lived secret they cannot safely replace.
