SPF, DKIM, and DMARC: Your Email Security, Seen from the Outside

TL;DR: SPF lists which servers may send mail for your domain, DKIM cryptographically signs each message, and DMARC tells receivers what to do when those checks fail or do not align with the visible From address. All three live in public DNS records, so anyone, including an attacker choosing a spoofing target, can read your email security posture from the outside in seconds.

Email authentication has an unusual property for a security control: it is fully public. Your SPF, DKIM, and DMARC configuration sits in DNS TXT records that anyone can query. That transparency cuts both ways. It is what lets receiving mail servers verify your messages, and it is what lets an attacker evaluate, before sending a single email, whether a message forged in your domain's name will land in inboxes or be rejected at the gate.

Why can anyone see your email security?

Because DNS is a public directory, and email authentication lives entirely inside it. A handful of DNS queries reveals whether SPF exists and how strict it is, whether DMARC exists and what policy it enforces, and which provider handles your mail. This is standard reconnaissance, the same way an attacker profiles everything else visible on your website. The difference with email is that a weak configuration is not just visible, it is directly usable: a domain without enforcement is a ready-made phishing asset, and attackers select for exactly that.

What does SPF actually do?

SPF (Sender Policy Framework) is a TXT record at your domain apex beginning with v=spf1. It lists the servers and services authorized to send mail using your domain in the envelope sender, and receiving servers check the connecting IP against that list. The record ends with a terminator that sets policy for everyone else:

• -all (hard fail): unauthorized senders should be rejected. This is the goal.
• ~all (soft fail): unauthorized mail is accepted but marked. Common, and weak on its own.
• ?all (neutral): expresses no opinion, which is barely better than no record.
• +all: explicitly authorizes the entire internet to send as your domain. This is a critical misconfiguration, not a formality.

SPF also has a structural blind spot: it validates the envelope sender (the Return-Path), not the From address a human actually reads. And it has a hard limit: an SPF evaluation may trigger at most ten DNS lookups, so records that accumulate include statements over years can silently break with a permanent error, which receivers treat as a failed check.

What does DKIM add that SPF cannot?

DKIM (DomainKeys Identified Mail) signs outbound messages with a private key, and publishes the matching public key in DNS at selector._domainkey.yourdomain. Receivers verify the signature to confirm the message came from an authorized system and was not modified in transit. Where SPF breaks when mail is forwarded, because the forwarding server's IP is not on your list, DKIM survives forwarding: the signature travels inside the message itself.

DKIM has its own failure modes. Keys get published during a provider setup and forgotten, and a record whose public key has been emptied means the key was revoked and every signature made with it now fails. More fundamentally, a valid DKIM signature only proves that some domain signed the message. It says nothing about whether that domain is the one displayed in the From header. That gap is what alignment closes.

How does DMARC tie the two together?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain, and it supplies the two pieces SPF and DKIM are missing: alignment and policy.

Alignment requires that the domain a check validated matches the domain in the visible From header. SPF alignment means the envelope sender's domain matches the From domain; DKIM alignment means the signature's d= domain matches it. Without alignment, a message can pass SPF for the attacker's own envelope domain while displaying your domain in the From line. DMARC fails any message where neither check aligns.

Policy tells receivers what to do with failures:

• p=none: deliver anyway, just send reports. Right for the first weeks of a rollout, wrong forever.
• p=quarantine: send failing mail to spam.
• p=reject: refuse it outright. This is the destination, and it blocks the overwhelming majority of exact-domain spoofing.

The rua tag tells receivers where to send aggregate reports. Without it you are not only unprotected, you are blind: spoofing campaigns can run for months with no evidence ever reaching you.

How do the three protocols divide the work?

Which misconfigurations show up most often?

Scanning domains from the outside, the same handful of problems appears again and again:

• Permanent monitoring mode. DMARC deployed at p=none as a first step, then never revisited. It generates reports and enforces nothing.
• Missing alignment on third-party senders. A marketing or support platform sends "as" your domain but uses its own envelope domain and its own DKIM identity. The mail passes raw SPF and DKIM yet fails DMARC alignment, so it gets quarantined once you enforce, or the platform is left out of your records entirely.
• Too-permissive SPF. A +all terminator, or include chains that sprawl past the ten-lookup limit, or ranges so broad they authorize an entire shared cloud provider, where any tenant can send "authenticated" mail as you.
• Multiple SPF records. Publishing two v=spf1 records at the same name is a permanent error. Receivers treat it as no valid SPF at all.
• Subdomain gaps. DMARC applies to subdomains through a separate sp= default. A locked-down apex with forgotten subdomains invites spoofing of billing.yourdomain or mail.yourdomain instead.

What happens when spoofing succeeds?

The consequences are concrete. Customers and partners receive invoices, password resets, and payment-change requests that authenticate visually as you, which is the core mechanic of business email compromise. Your domain's sending reputation absorbs the abuse, so legitimate mail starts landing in spam. And cleanup is slow, because the damage happened in other people's inboxes.

Authentication is also only half of the posture. Even fully authenticated mail can cross the internet in plaintext if the mail exchangers do not offer STARTTLS, and opportunistic encryption can be stripped by an active attacker unless MTA-STS or DANE makes it mandatory. TLS-RPT closes the loop with delivery-failure reports. The same outside-in discipline applies to your web endpoints, where TLS and certificate misconfigurations are just as visible as your DNS records.

How do you check your own domain?

You can query the records manually: a TXT lookup on your apex for SPF, on _dmarc.yourdomain for DMARC, and on any DKIM selector your providers use. Interpreting the results is the harder part, because the failure modes above hide in valid-looking records. OnScanner checks SPF, DKIM across a wide set of common selectors, and DMARC, along with MX, STARTTLS, MTA-STS, TLS-RPT, DANE, and BIMI, as part of every scan, and grades the result with the specific issue named. Since records drift, a new sending platform, a migration, a rotated key, scheduled monitoring catches the regression when it happens rather than after a spoofing campaign does.

Frequently asked questions

Is p=none ever the right DMARC policy?

Yes, briefly. p=none is the correct starting point while you collect aggregate reports and discover every legitimate service sending mail as your domain, because jumping straight to reject can break invoices, notifications, and marketing sends. It becomes a misconfiguration when it never graduates: months of monitoring with no move toward quarantine and then reject means you have documentation of spoofing rather than protection from it.

Do SPF, DKIM, and DMARC encrypt my email?

No. They authenticate the sender and detect tampering; they do not encrypt anything. Transport encryption is negotiated separately through STARTTLS and made enforceable with MTA-STS or DANE. A domain can have perfect authentication while its mail still crosses the internet in plaintext, so a complete outside-in assessment checks both the authentication records and the encryption posture of the mail exchangers.

Why did DMARC enforcement break a legitimate service?

Because that service is failing alignment. The usual causes: it sends with its own envelope domain and does not DKIM-sign with yours, or a DKIM key was rotated on one side only. The fix is configuring the service correctly, usually the custom return-path and DKIM records the provider supplies, not weakening your policy. Aggregate reports show exactly which sources are failing and why.