Email security

DMARC, SPF, DKIM & BIMI: Stop Email Spoofing of Your Domain

Email authentication stops spoofing of your exact domain — but not the lookalike domains that send most brand-impersonation phishing.

Updated 2026-06-17 · 5 min read

Email authentication stops one specific attack

If an attacker sends mail that appears to come from [email protected] — your exact domain — email authentication can stop it. Configured correctly, SPF, DKIM, and DMARC let receiving mail servers reject or quarantine messages that forge your domain in the From address. That closes the door on direct domain spoofing, one of the oldest and most damaging phishing techniques.

There is one big limitation, and it is the reason this article exists: these controls protect your exact domain only. They do nothing about a lookalike domain like yourbank-secure.com or yourbаnk.com (with a Cyrillic "а"). That mail is perfectly authenticated — on the attacker's domain. Authentication and lookalike defense are two different jobs. Get both, or you are only half-protected.

SPF: which servers may send for you

Sender Policy Framework (SPF) is a DNS TXT record listing the IP addresses and hosts authorized to send mail using your domain. A receiving server looks up the record, checks the connecting IP against it, and gets a pass or fail.

A record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

The -all at the end means "anything not listed should fail." SPF checks the envelope sender (the bounce address), not the From header a human reads — which is exactly why SPF alone cannot stop spoofing of the visible From address. That gap is what DMARC closes.

DKIM: a signature on every message

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to each message. Your sending platform signs outgoing mail with a private key; the matching public key lives in a DNS TXT record at a selector like selector1._domainkey.yourbank.com. The receiver fetches the public key, verifies the signature, and confirms the message was not altered in transit and genuinely came from a holder of the private key.

DKIM survives forwarding better than SPF and proves message integrity. On its own, though, it still does not require that the signing domain match the From address a reader sees.

DMARC: tying it together and enforcing a policy

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the control that makes SPF and DKIM mean something to the visible From address. It is a DNS TXT record at _dmarc.yourbank.com. DMARC requires alignment: the domain that passed SPF or DKIM must match the From domain. It then sets a policy for what receivers should do on failure, and requests reports so you can see who is sending as you.

A full enforcement record:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

The policy tag p= is the lever. Roll it out in three stages — never jump straight to reject:

  1. **p=none** — monitor only. Delivery is unaffected; the rua aggregate reports show every source sending as your domain, including legitimate ones you forgot about.
  2. **p=quarantine** — failing mail goes to spam. Move here once your real senders are aligned and passing.
  3. **p=reject** — failing mail is refused outright. This is the goal state and the only policy that fully stops exact-domain spoofing.

The rua address receives daily aggregate XML reports — feed them into a DMARC reporting tool so the data is readable. Most failed rollouts skip the monitoring phase, break a legitimate mail stream, and get rolled back. Patience at p=none is what makes p=reject safe.

BIMI: your logo in the inbox

Brand Indicators for Message Identification (BIMI) lets your verified logo appear next to authenticated mail in supporting mailbox providers — a visible trust signal and a small deterrent against impersonation. BIMI is a DNS TXT record at default._bimi.yourbank.com pointing to an SVG logo and, usually, a certificate.

Two prerequisites matter. First, BIMI requires DMARC at enforcementp=quarantine or p=reject; p=none does not qualify. Second, most major providers require a Verified Mark Certificate (VMC), which generally requires a registered trademark for the logo. Some providers also accept a Common Mark Certificate (CMC) under narrower terms. BIMI is a reward for doing DMARC properly, not a shortcut around it.

What DMARC can't stop: lookalike domains

Here is the part security teams most often miss. Everything above protects yourbank.com. None of it touches an attacker who registers a different domain that merely resembles yours:

  • Cousin domainsyourbank-support.com, secure-yourbank.com
  • Typosquatsyourbnak.com, yuorbank.com
  • Homoglyphsyourbаnk.com using a Cyrillic or Greek character that looks identical
  • Alternate TLDsyourbank.co, yourbank.app

The attacker controls these domains, so they can publish their own valid SPF, DKIM, and DMARC records. Their phishing passes authentication — on their domain. Your DMARC policy is irrelevant to mail that never claims to be from your domain in the first place. Most brand-impersonation phishing works exactly this way, which is why a hardened DMARC posture and a steady stream of lookalike attacks can coexist.

DMARC at p=reject stops spoofing of your exact domain. It does nothing about lookalike domains — those require continuous monitoring of registrations and certificates, plus takedown.

Stopping lookalikes is a different control entirely: watching domain registrations, DNS, and certificate-transparency logs for new lookalikes as they appear, then taking them down before they are weaponized. Brandfence does this passively — detecting lookalike domains from CT logs, DNS, and new registrations, then driving human-reviewed takedowns — so the gap DMARC leaves is covered.

Deployment checklist

  1. Publish an SPF record listing every legitimate sender; end it with -all.
  2. Enable DKIM signing on every sending platform and publish each selector's public key.
  3. Publish DMARC at p=none with a working rua address and feed the reports into a reporting tool.
  4. Review aggregate reports; fix any legitimate source failing SPF or DKIM alignment.
  5. Move DMARC to p=quarantine, then to p=reject once reports are clean.
  6. Once at enforcement, add BIMI with a VMC tied to your registered trademark if you want your logo in the inbox.
  7. Stand up continuous lookalike-domain monitoring and a takedown process — the control DMARC cannot provide.

Protect your brand beyond your own domain

Brandfence watches certificate-transparency logs, DNS, and new registrations for lookalike domains impersonating your brand in email and on the web, then drives evidence-backed, human-reviewed takedowns. Get a free brand exposure report.

Frequently asked questions

What is the difference between SPF, DKIM, and DMARC?
SPF lists which servers may send mail for your domain, DKIM cryptographically signs each message, and DMARC ties both to the visible From address and tells receivers what to do when checks fail. You need all three working together for real protection.
Does DMARC stop all phishing that uses my brand?
No. DMARC only stops attackers who spoof your exact domain. Phishing sent from lookalike or cousin domains like acmebank-secure.com passes authentication on its own domain and is unaffected by your DMARC policy.
Should I start DMARC at p=reject?
No. Start at p=none to monitor your real mail streams without affecting delivery, fix any legitimate sources that fail alignment, then ramp to p=quarantine and finally p=reject once reports are clean.
Do I need a trademark for BIMI?
For enforcement at most major providers, yes. A Verified Mark Certificate generally requires a registered trademark for your logo, though some providers also accept a Common Mark Certificate under narrower conditions.
Free exposure report

See what's impersonating your brand

Send us a domain. We run a passive sweep — permutations, certificate logs, DNS — and send back what we find, free. No signup, no sales call to start.

Get a free exposure report