Why DMARC exists

SPF and DKIM each solve a piece of the spoofing problem. Neither solves it completely. DMARC is the layer that ties them together and tells receivers what to do when they fail.

You need to be precise about what each layer actually authenticates, because that is where every DMARC misunderstanding starts.

What SPF actually checks

SPF authenticates the SMTP envelope sender — the MAIL FROM address the sending server presents during the SMTP conversation. A receiver looks up the SPF record for the envelope domain, checks whether the connecting IP is permitted, and produces a pass or fail.

The address a user sees in their mail client — the From: header — is not what SPF looked at. The two can be completely different domains. A spammer can pass SPF for bounces.shadyplatform.com while displaying ceo@isidoregroup.com in the From: header, and nothing in SPF stops that.

What DKIM actually checks

DKIM authenticates the integrity of a signed message. The sending server uses a private key to sign a set of headers and the body, then publishes the public key in DNS. A receiver verifies the signature.

DKIM proves the message has not been altered and that whoever holds the private key signed it. It does not, by itself, prove anything about the From: header. A spammer can sign a message with a DKIM key for mailer.shadyplatform.com and display ceo@isidoregroup.com in From:. The signature still validates.

The gap

Both authentication layers operate on identifiers the end user never sees. The address the user sees — and the one they trust — is the From: header. Nothing in SPF or DKIM, on their own, requires that identifier to match anything the sender authenticated.

That is the gap DMARC closes.

Identifier alignment

DMARC introduces a single rule: the domain authenticated by SPF or DKIM must align with the domain shown in the From: header. If neither aligns, the message fails DMARC — regardless of whether SPF or DKIM individually passed.

This is identifier alignment, and it is the entire point of DMARC.

A message from ceo@isidoregroup.com passes DMARC only if:

• SPF aligned — the envelope MAIL FROM domain is isidoregroup.com (or a subdomain, depending on alignment mode) and SPF passes, or
• DKIM aligned — the message has a valid DKIM signature where the d= tag is isidoregroup.com (or a subdomain) and the signature verifies.

Either alignment is enough. DMARC pass requires one, not both.

What the receiver does with a DMARC fail

The DMARC record at _dmarc.isidoregroup.com tells the receiver what to do when alignment fails. Three policy levels:

• p=none — observe and report, but deliver the message normally.
• p=quarantine — deliver to spam or junk.
• p=reject — refuse the message at SMTP time.

You choose the level. The receiver enforces it. The reports flow back to whatever address you put in the rua= tag.

This is the operational model: you publish a policy, receivers enforce it, and you watch the reports to confirm legitimate mail is not being caught by accident.

Why this matters for the kind of phishing we see

Almost every credential-harvest phish that lands in a client’s inbox spoofs the From: header of someone the recipient trusts — the CEO, the controller, a known vendor. SPF and DKIM, deployed without DMARC, give the receiver no basis to reject those messages, because the spammer is not claiming to be the envelope domain or the DKIM signing domain. They are claiming to be the display address.

With p=reject on isidoregroup.com, that message never lands. The receiver compares the From: domain to the authenticated identifiers, finds no alignment, applies the policy, and rejects at SMTP time. The recipient never sees the phish.

That is the outcome the rest of this module teaches you to operate.

Where Cathedra sits in this

DmarcRecordCheck.php reads the TXT record at _dmarc.{domain} and reports on three things in this order:

1. Does a DMARC record exist? If not, status=error, severity=high. Finding: “No DMARC record found at _dmarc.{domain}. Phishing protection is absent.”
2. What is the policy level? Pass at p=reject, warning at p=quarantine, warning (high severity) at p=none.
3. Is there a coverage and reporting setup that lets you operate the policy over time? pct= and rua=.

The next five lessons walk through each of those mechanics. The remediation lesson at the end of the module shows the staged rollout in GoDaddy.

What you should remember

• SPF authenticates the envelope sender. DKIM authenticates the message. Neither, on its own, authenticates the From: header the user sees.
• DMARC closes the gap through identifier alignment — the From: domain must match the SPF or DKIM authenticated domain.
• DMARC pass requires only one of SPF-aligned or DKIM-aligned. Either is sufficient.
• The DMARC record at _dmarc.{domain} tells receivers what to do when alignment fails: nothing (p=none), quarantine, or reject.
• Cathedra reports an error when DMARC is missing. The next lessons cover the exact findings for each policy level and tag.

---

Cathedra alignment: foundational — context for every finding produced by DmarcRecordCheck.php