SPF, DKIM, DMARC: Email Security Basics

This post explains the risks and theory behind SPF, DKIM, and DMARC, and why domain permutations (look-alike domains) are the silent amplifier that turns “one spoofed email” into a brand, finance, and credential-theft disaster.

The core problem: email was built for delivery, not identity

SMTP (the protocol that moves email around) was designed in an era where trust was implicit. By default:

The “From:” header is just text.
Anyone can attempt to send mail claiming to be ceo@yourcompany.com.
Many mail systems historically accepted messages as long as they could be delivered.

Modern defenses add domain-level authentication on top of SMTP. That’s what SPF, DKIM, and DMARC do.

SPF: “Which servers are allowed to send mail for my domain?”

SPF (Sender Policy Framework) is a DNS record that lists the mail servers (or sending services) allowed to send email using your domain in the envelope-from / return-path.

How SPF works (theory)

When a receiving mail server gets a message, it checks:

What domain is used in the envelope sender (Return-Path).
Does that domain publish an SPF record in DNS?
Is the connecting IP allowed by that SPF record?

If yes → SPF passes. If not → SPF fails (or softfails/neutral depending on policy).

Example SPF record

example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Common SPF failure modes (where attackers win)

Too permissive: v=spf1 +all (basically “anyone can send”).
Softfail forever: ~all without DMARC enforcement, leading to “shrug” handling.
Missing includes: your CRM, ticketing system, newsletter tool not listed → legitimate mail fails.
DNS lookup limit: SPF has a 10 DNS-lookup limit; complex include: chains can break delivery.
SPF only protects the envelope domain: attackers can still make the visible From look like you unless DMARC is enforcing alignment.

Bottom line: SPF is necessary, but not sufficient for stopping spoofing.

DKIM: “Was this email really sent by someone with the domain’s private key?”

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. The sender signs selected headers (and sometimes body) with a private key. The receiver fetches the public key from DNS and verifies the signature.

How DKIM works (theory)

Outbound mail server adds a header like:
- DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Receiver queries DNS:
- selector1._domainkey.example.com → public key
If signature matches → DKIM passes.

Example DKIM DNS record

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

DKIM failure modes (where attackers win)

No DKIM at all: lots of domains still don’t sign mail consistently.
Selective signing: only some systems sign (e.g., Microsoft 365 does, your marketing tool doesn’t).
Broken signatures: forwarders/mailing lists can modify content/headers and break DKIM.
Weak/old keys: short keys or long-lived keys increase risk (if compromised, impersonation becomes trivial).
Misaligned domain: DKIM passes for a different domain than what users see in “From”.

Bottom line: DKIM is powerful because it’s cryptographic, but it needs alignment and policy—that’s DMARC’s job.

DMARC: “What should receivers do if SPF/DKIM fails—and does it match my visible From?”

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties everything together:

It requires that SPF and/or DKIM pass, and
They must be aligned with the From: domain users actually see.

Then it tells receivers what to do if authentication fails:

p=none (monitor only)
p=quarantine (send suspicious mail to spam/junk)
p=reject (block outright)

DMARC alignment (the key concept)

Attackers love this gap:

SPF passes for random-sender.com
“From:” shows ceo@yourcompany.com

Without DMARC alignment, a message can look like it’s from you even if the authenticated domain is unrelated.

DMARC says: the authenticated identity must match the visible From, not just “something passed somewhere”.

Example DMARC record (monitoring)

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Example DMARC record (enforced)

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"

DMARC failure modes (where attackers win)

Stuck at p=none forever: you get reports, but spoofing still lands.
No reporting address / ignored reports: you’re blind to who’s abusing your domain.
Misconfigured alignment: legitimate services fail and you roll back enforcement.
Subdomain gaps: without a subdomain policy, attackers spoof anything.yourcompany.com.
No external monitoring: DMARC is not “set and forget” when tooling changes.

Bottom line: DMARC is the enforcement layer that turns SPF/DKIM from “signals” into “protection.”

What attackers actually do with weak email authentication

Here are the high-impact abuse paths SPF/DKIM/DMARC help prevent:

1) CEO fraud / invoice redirection (BEC)

Attackers send emails that appear to be from leadership or finance to change IBANs, approve payments, or request gift cards. Even one successful spoof can cost more than a year of security tooling.

2) Credential harvesting

A perfect-looking email “from IT” pushes a fake Microsoft 365 login page. The moment credentials are captured, the attacker can pivot to real internal mailboxes and send legitimate phishing from inside your tenant.

3) Brand impersonation against customers/partners

Even if your internal team is trained, your customers aren’t. Spoofed messages can damage your reputation, trigger fraud, and create support nightmares.

Domain permutations: the “look-alike domain” multiplier

Even with perfect DMARC enforcement, attackers can simply register a different domain that looks like yours and send from that.

Examples:

examp1e.com (1 instead of l)
exarnple.com (rn instead of m)
example-support.com
example.com-security.net
exämple.com (IDN / homograph tricks)
Different TLD: example.co, example.net, example.io

This is called domain permutation / typosquatting (and includes homograph attacks, combo-squatting, bitsquatting, and more).

Why permutations are dangerous

Users read “shapes,” not strings: a quick glance at a sender address is unreliable.
Mobile clients hide details: many interfaces collapse or truncate sender info.
SPF/DKIM/DMARC won’t help: those protect your domain, not look-alikes.
Attackers can build “legit-looking” infrastructure: TLS certs, branded landing pages, realistic reply flows.

Typical attack flow with a look-alike domain

Register a domain close to yours.
Set up SPF/DKIM/DMARC correctly (yes, attackers do this).
Send “urgent” messages to finance, HR, customers, or vendors.
Harvest credentials or redirect payments.
If a reply happens, keep the conversation going (thread hijacking style).

Takeaway: you need both authentication monitoring and look-alike detection.

What “good” looks like: a practical baseline

If you want a clean, modern posture:

SPF

Exactly one SPF TXT record per domain.
Only include the senders you actually use.
End with -all once you’ve validated all sources.

DKIM

Ensure every sending platform signs mail.
Rotate keys periodically.
Use sufficiently strong keys (and don’t reuse keys forever).

DMARC

Start with p=none briefly to observe legitimate senders.
Move to p=quarantine, then p=reject.
Use strict alignment where possible (aspf=s; adkim=s).
Consider subdomain policy (sp=) so subdomains aren’t a loophole.

Domain permutations

Monitor for look-alikes across common TLDs and obvious typo patterns.
Prioritize ones that:
- have MX records (can send/receive email),
- host phishing pages,
- are newly registered,
- resemble brand + “billing / login / support”.

Why continuous monitoring matters (even if you “set it up once”)

DNS changes for boring reasons—migrations, vendor switches, “quick fixes,” expired domains—and those boring changes can quietly break authentication.

Continuous monitoring catches:

SPF lookup blowups after someone adds a new tool
DKIM selectors removed or rotated incorrectly
DMARC downgraded to p=none
A suddenly-appearing look-alike domain that starts emailing your staff

That’s why AutoPhish now includes an Email Security / DNS Scanner for quick checks, and continuous monitoring with alerts for logged-in orgs.

Quick checklist you can copy into your internal runbook

SPF exists, is unique, and ends in -all (after validation)
All mail sources are accounted for (M365/Google + marketing + support + transactional)
DKIM enabled across all sources, keys not stale
DMARC exists with reporting enabled
DMARC enforced (quarantine or reject) with alignment configured
Subdomains covered (sp= or explicit DMARC on subdomains)
Look-alike domain monitoring enabled (typos + TLD swaps + combos)
Alerting hooked to a real channel (email/Slack/Teams/ticketing)

Check your domain in seconds (free)

Want a quick sanity check right now? Use the AutoPhish DNS Checker to instantly analyze your SPF, DKIM, and DMARC records:

AutoPhish DNS Checker: https://autophish.io/dns-check

If you want ongoing protection, you can also set up continuous monitoring with an AutoPhish subscription—so you’ll get alerts when DNS records change or when look-alike domains are detected.

Final thoughts

Email authentication (SPF/DKIM/DMARC) is one of the rare security moves that improves both protection and deliverability. Add look-alike monitoring, and you cover the two biggest impersonation vectors: spoofing your domain and spoofing your brand.

SPF, DKIM, DMARC & Domain Permutations: The Email Security Basics Attackers Exploit