Phishing Detection Beyond DMARC

DMARC is necessary and not sufficient. SPF, DKIM, and DMARC stop one specific thing — someone spoofing your exact domain — and most modern phishing simply does not bother. It comes from a lookalike domain, a spoofed display name, a freshly registered sender, or a compromised legitimate account, and it sails past authentication because it is not pretending to be your domain at all. Detecting it means scoring the signals authentication ignores. This guide ships that layered approach.

Phishing maps to MITRE ATT&CK T1566 — Phishing. The durable end-state defense is phishing-resistant authentication (YubiKeys), so a harvested credential is worthless — but detection at the gateway catches the message before it reaches the user.

Why isn’t DMARC enough?

DMARC, built on SPF and DKIM, answers exactly one question: is this mail that claims to be from yourcompany.com actually authorized to use yourcompany.com? Enforced at reject, it shuts down direct domain spoofing — a real and worthwhile win. But it says nothing about a message from yourcompany-support.com, or one whose display name reads “CEO” from a Gmail address, or one from a partner’s compromised-but-legitimate mailbox. Those all pass authentication because they are not spoofing your domain.

That gap is where phishing lives now, and especially where business email compromise (BEC) operates — plausible messages, often with no malicious payload, engineered to move money or data. Catching them requires detection beyond the authentication layer.

What does phishing that passes DMARC look like?

None of these is caught by SPF/DKIM/DMARC, and several (BEC) have nothing for a content scanner to flag. The detection is sender reputation and behavioral signals, combined.

How to detect phishing beyond DMARC

Score inbound mail on the gateway signals authentication misses. Lookalike-domain and display-name impersonation are the highest-value:

index=email sourcetype=mail:gateway action=delivered
| eval sender_domain = lower(replace(from_address,"^[^@]+@",""))
| eval dom_distance = levenshtein(sender_domain, "yourcompany.com")
| lookup exec_names display_name OUTPUT is_exec
| where (dom_distance > 0 AND dom_distance <= 2)
   OR (is_exec="true" AND NOT match(sender_domain, "yourcompany\.com$"))
   OR (domain_age_days < 14)
| table _time, from_address, display_name, subject, dom_distance, domain_age_days

A sender domain one or two edits away from yours, an executive display name from outside your domain, or a sender domain registered in the last two weeks each warrants scrutiny. Combine them into a score and alert on the high end, rather than blocking on any single signal.

What DMARC alignment actually checks

Before going past DMARC it is worth being precise about what it does, because “we have DMARC” covers three quite different states.

DMARC passes when either SPF or DKIM passes and is aligned — meaning the domain that authenticated matches the domain in the From: header the user actually sees. Alignment is the whole mechanism. SPF on its own authenticates the envelope sender, which the recipient never sees, so an attacker can pass SPF for their own domain while displaying yours. Alignment is what connects the authenticated identity to the displayed one.

That distinction has a practical consequence:

• SPF alignment breaks on forwarding. When a message is forwarded, it arrives from the forwarder’s IP, and SPF fails. This is why auto-forwarding rules and mailing lists cause DMARC failures for legitimate mail.
• DKIM alignment survives forwarding, because the signature travels with the message — unless the message is modified. Mailing lists that prepend a subject tag or append a footer break the signature.
• ARC exists to patch the gap, letting intermediaries vouch for authentication results that were valid before they modified the message. Support is uneven, so it helps rather than solves.

The takeaway for a rollout: DKIM alignment is the durable one, and a domain relying on SPF alone for DMARC will generate failures for legitimate forwarded mail and encourage somebody to weaken the policy to stop the complaints.

Read your aggregate (RUA) reports before enforcing. They are the only view of who sends as your domain, and every rollout finds at least one forgotten legitimate sender — a marketing platform, a ticketing system, a payroll provider. Moving to p=reject without that inventory is how a company stops receiving its own invoices. Failure (RUF) reports are largely unavailable now for privacy reasons; plan around aggregate data.

Why edit distance misses most lookalikes

The analytic above uses Levenshtein distance, which catches one lookalike family and misses several. Worth knowing which, because the gaps are where the real campaigns operate.

Four cheap additions close most of that:

• Substring match on your brand token. Any registrable domain containing your brand and not owned by you is worth scoring, regardless of edit distance. This catches the entire combosquat family, which is the most common shape in practice.
• Alert on xn-- sender domains. Internationalised domains encode to punycode with that prefix. Legitimate correspondents using IDNs exist and are rare and enumerable in most organisations, which makes this a near-zero-false-positive rule for a whole attack class.
• Check whether your domain appears as a label rather than the registrable domain. Anything matching yourcompany.com. followed by more labels is deception by construction.
• Score against your partner and supplier domains too. Invoice fraud impersonates the supplier, not you, and a detection anchored only on your own domain never sees it. Your accounts-payable vendor list is the input, and it is usually already maintained.

Certificate Transparency is the early warning

The best signal for a lookalike domain arrives before any mail does.

Effectively every domain intended to serve a convincing phishing page gets a TLS certificate, and every publicly-trusted certificate is published to Certificate Transparency logs. Monitoring those logs for your brand tokens gives you notice at the point the attacker is preparing the campaign rather than at the point they send it.

Why this outperforms domain-registration monitoring:

• It is free and public. No registrar data agreements, no WHOIS access problems.
• It is fast. Certificates appear in logs within minutes of issuance.
• It arrives at the right moment. Registration can precede use by months; a certificate usually means the infrastructure is being stood up now.
• It catches subdomains too, including a lookalike hosted under someone else’s compromised domain, which registration monitoring never sees.

The workflow is short: watch CT for your brand tokens and close variants, review the hits, and push the confirmed ones straight into your gateway’s block list and your takedown process. A domain blocked before the campaign launches costs an attacker the whole setup.

The BEC signals that live in your mailbox, not your gateway

Everything above assumes the phish arrives from outside. The most damaging variant does not: the message comes from a real, compromised account, sometimes inside your own tenant, and no sender-reputation signal applies because the sender’s reputation is genuinely good.

The signals move from the gateway to the mail platform’s audit log:

• Inbox rule creation is the single highest-fidelity signal of account takeover. An attacker’s first action after taking a mailbox is almost always a rule that deletes or diverts replies, so the real owner never sees the responses to messages sent in their name. In Microsoft 365 this surfaces as New-InboxRule and Set-InboxRule; rules that move to RSS Feeds, Deleted Items, or an obscure folder, or that forward externally, are worth an immediate alert. Legitimate users create rules, and they rarely create rules that hide entire conversations.
• External auto-forwarding, which should be disabled by policy and alerted on when configured.
• Sign-in anomalies paired with a rule change. Either alone is medium confidence; an unusual sign-in followed within minutes by a mailbox rule is an account takeover with very little doubt.
• Thread hijacking — a reply into a genuine existing conversation, from the genuine participant’s account, with an attacker’s payload or payment request. This is the hardest phish to detect and the most convincing to receive, because every contextual cue a user is taught to check is authentic.
• Mailbox permission grants and OAuth application consents, which establish access that survives a password reset.

Thread hijacking is the case where detection realistically loses and process has to hold. Which is the argument for the control below.

Out-of-band verification is the control that actually stops BEC, and it only works with one specific detail right: verification must use a contact route you already held, never a number or address supplied in the message. An attacker who can write the email can write the phone number underneath it. A policy that says “call to confirm” without saying “call the number in your own records” is regularly satisfied by calling the attacker.

Why the MFA type decides whether the phish works

“Deploy MFA” has stopped being sufficient advice, because the common forms no longer stop a competent credential phish.

Adversary-in-the-middle phishing kits proxy the real login page. The victim sees genuine content, enters their password, and completes the MFA challenge — and the proxy relays all of it to the real service and captures the resulting session cookie. One-time codes and push approvals both fall to this, because both are things the user can be induced to supply to a convincing page.

FIDO2 and WebAuthn resist it structurally. The authenticator signs a challenge bound to the origin, so a credential created for your real domain simply will not produce a valid assertion for the attacker’s proxy domain. It is not that the user is warned; it is that the cryptography does not function off-origin. That is the property worth paying for, and it is why hardware security keys belong in the control set rather than another one-time-code app.

One honest caveat: a stolen session token after successful authentication bypasses the login entirely, whatever authenticator issued it. Mitigate with short session lifetimes, device compliance requirements, token-binding protections where your identity provider offers them, and continuous evaluation that re-checks conditions mid-session rather than only at sign-in.

How to test your phishing detection

With your security team’s authorization (and a controlled phishing-simulation platform):

1. Send test messages from a registered lookalike domain and confirm the analytic scores them.
2. Send a display-name-spoof test from an external address and confirm it flags.
3. Send a benign message from a legitimate new vendor and confirm enrichment keeps the false positives low.
4. Confirm DMARC-at-reject blocks an exact-domain spoof outright (the layer below).

How to defend against phishing

• User reporting + rapid takedown of lookalike domains closes the loop, and the takedown request is worth pre-drafting so it goes out in minutes rather than after somebody works out which registrar and abuse address to contact.
• Out-of-band verification policy for any payment or data-change request, using a contact route from your own records rather than one supplied in the message. This is the single control that holds against thread hijacking, where every authenticity cue a user is trained to check is genuine because the account really is the counterparty’s.
• Monitor for your registered lookalikes proactively, before they are weaponized.
• Defensively register the obvious variants — common typos, the hyphenated forms, the adjacent TLDs. It is cheap, it is permanent, and it removes the shapes an attacker would reach for first.
• Make reporting a phish faster than deleting one. A one-click report button in the mail client produces a stream of user-flagged messages that consistently outperforms gateway scoring on the novel campaigns, because a person noticing something is wrong is a signal no rule encodes. Close the loop by telling reporters what happened — a reporting programme that never responds stops receiving reports within a quarter.
• Publish the payment-verification rule as a protection, not a hurdle. Staff who understand that the callback protects them personally comply with it; staff who experience it as bureaucracy route around it under pressure, which is exactly when BEC arrives.

Common phishing-detection mistakes

• Stopping at DMARC. It only covers exact-domain spoofing.
• Single-signal blocking. Young domains and common names over-fire alone.
• Ignoring payload-free BEC. Content scanning sees nothing; score the sender/behavior.
• No phishing-resistant MFA. A harvested password stays useful without it.
• Relying on SPF alignment for DMARC. It breaks on every forwarded message, generating failures for legitimate mail and pressure to weaken the policy. DKIM alignment is the durable one.
• Enforcing p=reject before reading aggregate reports. Every rollout discovers a forgotten legitimate sender, and finding it after enforcement means your own invoices stopped arriving.
• Edit distance as the only lookalike check. It misses combosquats, homoglyphs, and subdomain deception — which is most of what real campaigns use.
• Scoring only against your own domain. Invoice fraud impersonates your supplier, and a detection anchored on your brand never sees it.
• Not monitoring Certificate Transparency. It is free, public, and gives notice while the attacker is still building the site rather than after they send.
• No alert on inbox-rule creation. It is the highest-fidelity account-takeover signal there is, and it lives in the mail platform’s audit log rather than the gateway.
• Out-of-band verification using the contact details in the message. Whoever wrote the email wrote the phone number, so the callback reaches the attacker.
• Treating one-time codes and push approvals as phishing-resistant. Proxy kits relay both. Origin-bound FIDO2 credentials are the ones that structurally cannot be replayed.
• Ignoring post-authentication token theft. A stolen session cookie skips the login entirely, whatever authenticator issued it.

Phishing detection beyond DMARC checklist

1. Enforce DMARC at p=reject (with SPF and DKIM) as the base layer.
2. Score senders on lookalike/homoglyph domain similarity to you and partners.
3. Flag executive display names arriving from outside your domain.
4. Flag newly-registered sender domains and mismatched reply-to.
5. Combine signals into a risk score; route the high end to review.
6. Sandbox links/attachments and banner external/first-contact senders.
7. Deploy phishing-resistant MFA so harvested credentials are useless.
8. Enable user reporting, lookalike-domain monitoring, and rapid takedown.
9. Read aggregate DMARC reports and inventory every legitimate sender before enforcing reject.
10. Add substring, punycode (xn--), and subdomain-deception checks alongside edit distance, and score against partner domains as well as your own.
11. Monitor Certificate Transparency for your brand tokens and feed confirmed hits straight into the gateway block list.
12. Alert on inbox-rule creation, external auto-forwarding, mailbox permission grants, and OAuth consents in your mail platform’s audit log.
13. Write the out-of-band verification policy to require a contact route from your own records.
14. Move to origin-bound FIDO2 credentials, and pair them with short sessions and device compliance so a stolen token has limited value.

Item 12 is the one most often absent, and it covers the case the gateway structurally cannot: a phish sent from a genuinely legitimate account inside your own tenant. No sender-reputation signal applies, because the sender’s reputation is real. The mailbox audit log is where that intrusion is visible, and inbox-rule creation is the action attackers take first and users take rarely.

The takeaway

Phishing detection beyond DMARC means scoring the signals authentication ignores — lookalike domains, display-name spoofing, newly-registered senders, and BEC behavior — and layering that with sandboxing and phishing-resistant MFA. DMARC is the floor, not the ceiling. Continue with YubiKey deployment and OAuth misconfiguration review. Stolen credentials get replayed at scale next, so pair this with credential stuffing detection, or follow the phishing-to-encryption path into ransomware early-warning detection and browse the full Detection Engineering pillar.