# Protect your brand from impersonation with anti-spoofing

> Protect your brand from impersonation with anti-spoofing by aligning SPF and DKIM, enforcing DMARC carefully, and recording response evidence.

Protect your brand from exact-domain email impersonation by configuring SPF and DKIM for every legitimate sender, then using DMARC reports to verify alignment before enforcement. Begin with DMARC monitoring, resolve legitimate failures, and progress to quarantine and reject only when production evidence supports each stage. DMARC reduces spoofing that uses your visible domain. It does not stop lookalike domains, display-name abuse, or guarantee inbox placement.

## Quick takeaways

- SPF authorizes hosts to use a domain during SMTP, while DKIM verifies a domain's cryptographic signature.
- DMARC passes when SPF or DKIM passes and its authenticated domain aligns with the visible From domain.
- A `p=none` DMARC policy collects aggregate-report evidence before enforcement.
- A public DNS result does not prove that an application signs production mail or uses the intended return-path domain.
- The safe DMARC progression is monitor first, then quarantine, then reject.
- DMARC policy requests receiver handling for failed mail, but each receiver applies its own local policy.

## Scope and prerequisites

This guide covers impersonation that uses your organization's exact visible From domain. DMARC is the anti-spoofing control, supported by SPF and DKIM. For related phishing, transport, and message-security controls, use the [email security learning center](/learning).

Choose one production domain and inventory every system that sends as that domain. Include employee mail, transactional applications, support platforms, marketing systems, security gateways, and services that send on your behalf. For each path, record the visible From domain, SMTP return-path domain, DKIM signing domain, DNS-zone owner, application owner, and test recipient.

You need access to the authoritative DNS zone, each sender's authentication settings, and a mailbox that can receive DMARC aggregate reports. [RFC 9989 defines DMARC policy discovery, alignment, and reporting](https://www.rfc-editor.org/rfc/rfc9989.html.html). SPF and DKIM are inputs to DMARC, so preserve their existing records during the rollout.

Define a rollback condition before enforcement. If a legitimate production-path message fails after a policy change, restore the previous known-safe policy while you investigate the sender configuration. Keep a copy of the current DMARC record before editing it.

> Do not advance to `p=quarantine` or `p=reject` because a public DNS lookup looks correct. DNS cannot prove that every production application uses the intended return-path domain or DKIM signing domain.

## Choose the implementation approach

Use monitoring when you cannot yet account for every source that sends with the domain. A `p=none` policy asks receivers to send aggregate reports without requesting quarantine or rejection of failing mail. Use those reports to compare observed sources with your inventory and investigate authentication or alignment failures.

Use quarantine after report evidence shows that legitimate production paths have an aligned SPF or DKIM pass. Quarantine is an intermediate enforcement stage. It gives you another evidence window before requesting the strictest policy.

Use reject when the evidence remains stable and every remaining failure has an explanation. DMARC receivers can consider the domain owner's policy, but [RFC 9989 states that receiver handling remains a local policy decision](https://www.rfc-editor.org/rfc/rfc9989.html.html). A reject policy cannot guarantee that every failed message is rejected or that every passing message reaches the inbox.

The authentication controls have separate jobs:

- [RFC 7208 defines SPF](https://www.rfc-editor.org/rfc/rfc7208.html) as a DNS-published mechanism for authorizing hosts to use a domain during SMTP.
- [RFC 6376 defines DKIM](https://www.rfc-editor.org/rfc/rfc6376.html) signatures and DNS lookup of the public key used to verify them.
- DMARC evaluates whether a passing SPF domain or DKIM signing domain aligns with the visible From domain. One aligned pass can produce a DMARC pass.
- Lookalike domains and display-name impersonation need separate detection, reporting, and receiver-response procedures. The [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware/phishing-guidance) describes phishing as a broader threat than one authentication control can eliminate.

## How to configure DMARC anti-spoofing controls

### 1. Inventory each production sending path

Create one entry for every application or provider that can send as `yourdomain.com`. Keep paths separate when they use different return paths, DKIM selectors, signing domains, or routing gateways.

For each source, retain a recent redacted message header and the expected sender configuration. Do not place private keys, API tokens, customer addresses, or unredacted headers in tickets or shared documentation.

### 2. Configure aligned SPF and DKIM for each sender

Publish the SPF authorization required by each sender, but preserve the domain's existing SPF record. SPF permits one `v=spf1` record at a domain. Publishing a second SPF record can cause an SPF evaluation error.

Enable DKIM in every sending system and publish the exact selector record it generates. The selector and public-key value are account-specific. Obtain them from the sender that signs the mail. Do not invent a selector or reuse a record value from another account.

A DMARC record shape is below. It is illustrative only. Do not publish it unchanged.

```text
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
```

The `rua` mailbox receives aggregate reports. Confirm that your organization controls and reviews it. If reports go to a mailbox under another domain, RFC 9989 defines an external reporting authorization process.

### 3. Publish a monitoring DMARC record

Publish one DMARC TXT record at `_dmarc.yourdomain.com` with `p=none` and a valid aggregate-report destination. Compare the new record with the current record before making a change. Do not replace a working policy with the illustrative record.

Document whether the record applies to the organizational domain, a specific subdomain, or both. A subdomain can publish its own DMARC record and policy, so its sending paths may require separate evidence.

![Flow showing an anti-spoofing rollout from sender inventory through DMARC monitoring, remediation, quarantine, and reject](/images/editorial/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing-policy-rollout.webp "1200x829")

*Source: Palisade.*

### 4. Collect reports and repair legitimate failures

Allow aggregate reports to accumulate, then group results by sending source, visible From domain, SPF result and domain, DKIM result and signing domain. Compare each reported source with the sending-path inventory.

Investigate every failure before escalating policy. Common causes include an omitted sender, an SPF domain that does not align, a DKIM signature from an unrelated domain, or forwarding that changes the SMTP path.

Aggregate reports identify reported use of the domain and authentication results. They do not prove the content of every message, a receiver's private filtering decision, or activity at receivers that do not send reports.

### 5. Advance the DMARC policy after evidence supports it

Move from monitoring to quarantine when legitimate production paths have an aligned SPF or DKIM pass and unexpected sources have been investigated. Continue reviewing aggregate reports after the policy change.

Move from quarantine to reject only when the same evidence remains stable. Use a narrower rollout when a domain has many independent owners or uncertain senders. The safe progression is monitor first, then quarantine, then reject.

![DMARC evidence and response record showing the fields to capture during an impersonation review](/images/editorial/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing-dmarc-evidence-response-record.webp "1200x754")

*Source: Palisade.*

## Maintain an impersonation evidence and response record

Use this Palisade-authored framework to keep the technical evidence and operational response connected. The record does not claim that DMARC will remove a lookalike domain, force a mailbox provider's decision, or guarantee a takedown.

Record these fields for each incident or control review:

- Protected brand domains: the exact domains and subdomains covered by the review.
- Observed spoof or lookalike identifier: the visible From domain, display name, lookalike domain, URL, or other redacted identifier.
- Evidence source and time: the DMARC aggregate report, redacted delivered header, public DNS lookup, customer report, employee report, or provider case, with UTC time.
- DNS and authentication status: the observed DMARC, SPF, DKIM, and alignment result relevant to the domain.
- Customer or employee impact scope: confirmed recipients, reported exposure, or `unknown` when evidence does not establish scope.
- Owner and escalation: the person or team responsible for the technical change, investigation, or communications response.
- Reporting or takedown channel: the applicable registrar, hosting provider, mailbox provider, abuse process, or law-enforcement channel where appropriate.
- Follow-up date: the next date to review evidence, policy status, and any external case.

A compact fictional and redacted example:

```yaml
protected_brand_domains:
  - yourdomain.com
observed_identifier: "yourdornain.com"
evidence_source_time: "employee report with redacted message header, 2026-08-12T14:00:00Z"
dns_authentication_status: "yourdomain.com has DMARC p=quarantine; lookalike domain is outside DMARC control"
impact_scope: "unknown"
owner_escalation: "security operations, registrar abuse review"
reporting_takedown_channel: "registrar abuse form"
follow_up_date: "2026-08-14"
```

Technical anti-spoofing controls protect domains you control. Reporting and takedown actions address external infrastructure or content and depend on the receiving organization, provider, registrar, or other party's process and decision.

## How to validate the setup

Validate the DMARC anti-spoofing setup at four separate layers. A passing result at one layer does not replace another.

- DNS: Query the authoritative DNS server and a public resolver for `_dmarc.yourdomain.com`. Confirm that one intended DMARC record is returned.
- Sender state: Confirm that each production sender has its intended SPF authorization or DKIM signing configuration. A sender's verified status is useful evidence, but it is not a delivered-message result.
- Message: Send a new message through every production path and inspect the receiver-added `Authentication-Results` header. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). Record the visible From domain and the SPF or DKIM domain that passed.
- DMARC reporting: Compare aggregate reports with the inventory. Each expected source needs an understood authentication and alignment result before strict enforcement.

For the DNS layer, [inspect the published DMARC record](/tools/dmarc) before changing the policy. A public record check cannot confirm a sender's private configuration, prove a delivered message authenticated, monitor later DNS drift, or reveal a receiver's private filtering decision.

## Troubleshooting

### A DMARC record is published but a legitimate sender fails

Inspect a new delivered message from the exact production path. Compare the visible From domain with the `smtp.mailfrom` SPF domain and the DKIM `d=` domain in the receiver's authentication results. A passing SPF or DKIM result that does not align with the visible From domain does not produce that aligned DMARC pass.

### SPF passes for some mail but fails after adding a sender

Check that the domain has one combined `v=spf1` record. Merge the authorized mechanisms required by legitimate senders into that existing record according to their current documentation. Do not publish a second SPF record.

### DKIM passes but DMARC still fails

Compare the DKIM `d=` domain with the visible From domain. DKIM can be cryptographically valid while remaining unaligned for DMARC. Confirm that the sender uses the intended signing domain and selector.

### A lookalike domain is still sending phishing mail

DMARC at `yourdomain.com` cannot control a separate registered domain. Preserve the evidence, record the relevant reporting or takedown channel, and use the provider's or registrar's abuse process where applicable. Continue enforcing DMARC on domains you control because it reduces exact-domain impersonation, but do not describe that control as proof of lookalike removal.

### A receiver still accepts mail that fails DMARC

DMARC policy is a request to receivers, not a guarantee of a specific filtering outcome. Confirm that the visible From domain and authentication evidence match the policy you published, then use the receiver's own reporting or support channel if you need to investigate its decision.

## Check the public DMARC record before enforcing policy

Run the protected domain through the [DMARC checker](/tools/dmarc) to inspect its public DMARC record before moving from monitoring to quarantine or reject. Compare that record with aggregate-report evidence and a newly delivered production message.

[Check the DMARC record](/tools/dmarc)

The checker sees public DNS only. It cannot identify every production sender, repair alignment, prove a receiver's decision, or guarantee that impersonation attempts will stop. For teams that need to analyze aggregate-report data across recurring sender changes, Palisade is agent-first DMARC software that identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing)

For a broader response plan, see [How to Stop Email Spoofing and Protect Your Brand](/learning/what-is-email-spoofing-and-how-can-you-prevent-it).

## Sources and further reading

- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html.html)
- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html)
- [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware/phishing-guidance)

## Frequently asked questions

### Does DMARC stop all brand impersonation?

No. DMARC helps receivers identify mail that claims to come from a domain you control but fails aligned SPF and DKIM checks. It does not control lookalike domains, display-name impersonation, compromised accounts, or a receiver's private filtering decision.

### Should I start DMARC with reject?

No. Start with `p=none` so aggregate reports can identify legitimate senders and alignment failures. Advance to quarantine and then reject only after report and delivered-message evidence supports each stage.

### Does a passing DMARC lookup prove my email is protected?

No. A DNS lookup confirms the public record that resolves at the time of the check. It does not prove that every sender uses aligned SPF or DKIM, that a receiver honors the requested policy, or that future messages will authenticate.

### Can SPF alone protect my brand from spoofing?

No. SPF evaluates the SMTP return-path domain, which can differ from the visible From domain. DMARC requires alignment, and an aligned DKIM pass can also satisfy DMARC when SPF does not.

### Can I report a lookalike domain for takedown?

Yes, when you have relevant evidence and the registrar, hosting provider, mailbox provider, or other party offers an applicable abuse process. Reporting does not guarantee removal or a particular response time. Keep a dated record of the evidence, channel, case reference where available, owner, and follow-up date.