# DMARC: fake email protection

> How DMARC protects your domain from spoofing, how alignment and DMARC quarantine work, what new domains should do, full record syntax, and common edge cases.

[DMARC](https://verifiedinbox.ai/docs/glossary.md#dmarc) (Domain-based Message Authentication, Reporting, and Conformance, defined in [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489)) is the public setting on your [domain](https://verifiedinbox.ai/docs/glossary.md#domain) that tells inboxes what to do when an email claims to come from you, and where to send daily reports about who is using your domain.

Without DMARC, each receiving mail provider has to guess how to handle messages that fail [SPF](https://verifiedinbox.ai/docs/spf.md) or [DKIM](https://verifiedinbox.ai/docs/dkim.md). DMARC puts you in control: instead of trying to filter out bad mail after the fact, you give every inbox a clear rule to **filter in legitimate mail** from your domain and quarantine or block fakes.

Inboxes will only display your [BIMI](https://verifiedinbox.ai/docs/bimi.md) logo and blue verified checkmark when your DMARC policy is set to **enforcement**: either `p=quarantine` (at `100%`) or `p=reject`.

## Why DMARC matters

- **Stops spoofing and phishing:** Protects your customers and team from attackers forging `@yourcompany.com` in the `From:` line (such as fake invoices or password-reset scams).
- **Full visibility (including "Shadow IT"):** Receiving servers (Gmail, Yahoo, Outlook, Apple Mail) email you daily XML summaries showing every IP address and service sending mail as your domain, and whether each one passed SPF and DKIM.
- **Better deliverability and compliance:** Gmail and Yahoo require DMARC for bulk senders (5,000+ messages per day), and an enforced DMARC policy is required for [VMC](https://verifiedinbox.ai/docs/glossary.md#vmc) and [CMC](https://verifiedinbox.ai/docs/glossary.md#cmc) mark certificates.

## How DMARC and alignment work

DMARC builds on top of [SPF](https://verifiedinbox.ai/docs/spf.md) and [DKIM](https://verifiedinbox.ai/docs/dkim.md). You must set up SPF and/or DKIM before enforcing DMARC.

### The "at least one aligned pass" rule

To pass DMARC, an email must pass **at least one** of these two checks:

1. **SPF authentication + SPF [alignment](https://verifiedinbox.ai/docs/glossary.md#alignment):** The sending server passes SPF, **and** the envelope `Return-Path` (`MAIL FROM`) domain matches the visible `From:` header domain.
2. **DKIM authentication + DKIM [alignment](https://verifiedinbox.ai/docs/glossary.md#alignment):** The message has a valid `DKIM-Signature`, **and** the signing domain (`d=`) matches the visible `From:` header domain.

A message only fails DMARC if **both** aligned SPF and aligned DKIM fail. This is why setting up both SPF and DKIM is best practice: when a recipient auto-forwards your email to another inbox, SPF usually fails (because the forwarder's IP is not in your SPF record), but your DKIM signature survives and the message still passes DMARC.

### Relaxed vs. strict alignment (`aspf` and `adkim`)

DMARC supports two alignment modes for comparing the `From:` domain (`yourcompany.com`) against the SPF `Return-Path` domain or DKIM `d=` domain:

| Check | Relaxed alignment (`r`, default) | Strict alignment (`s`) |
|---|---|---|
| **SPF (`aspf`)** | The `Return-Path` domain can be the exact `From:` domain **or any subdomain** of your [organizational domain](https://verifiedinbox.ai/docs/glossary.md#organizational-domain) (for example `pm-bounces.yourcompany.com` aligns with `yourcompany.com`). | The `Return-Path` domain must match the `From:` domain **character for character**. |
| **DKIM (`adkim`)** | The DKIM `d=` domain can be the exact `From:` domain **or any subdomain** of your organizational domain. | The DKIM `d=` domain must match the `From:` domain **character for character**. |

**Keep relaxed alignment (`r`, the default) unless you have a specific reason not to.** Many email providers (Postmark, Amazon SES, Resend, SendGrid) use a custom subdomain for the `Return-Path` bounce address; setting `aspf=s` will cause those messages to fail SPF alignment. Only use strict alignment (`s`) if untrusted third parties operate subdomains under your main domain.

## Before you begin

1. **Turn on SPF and DKIM first.** If you enforce DMARC before SPF or DKIM is authenticating your mail, your own messages will be sent to spam or rejected. On an active domain, Google Workspace recommends letting SPF and DKIM run for at least 48 hours before tightening DMARC.
2. **Create a dedicated mailbox or group for DMARC reports (`rua=`).** Active domains receive multiple XML report emails every day (large domains can receive hundreds). Use a dedicated address such as `dmarc@yourcompany.com` (or a DMARC reporting service) rather than your personal inbox. The mailbox must exist and your domain must be able to receive email, or the reports are lost. In the VerifiedInbox **Email security** step, every suggested record uses the address in your current record, or `dmarc@` your main domain; choose **Use a different address** to change it in all of them at once.

### How VerifiedInbox uses DMARC

- The **Email security** step asks who sends email from your domain. **Not yet** and **Only from our mailbox** get the blocking record right away; **From several tools** gets the four-stage rollout below.
- To continue past that step, DMARC must be published in watch mode (`p=none`) or stronger, with a report address. You don't have to wait for the whole rollout.
- By the **DNS** step, DMARC must be at enforcement (`p=quarantine` at `100%` or `p=reject`). We check again right before ordering your certificate.
- Suggested records keep the extra tags of your current record (such as `ruf`, strict `adkim` or `aspf`). We remove `sp=none` and say so, because BIMI requires your subdomains to be protected too.

## New domains without DMARC

If your domain is brand new, sends no email yet, or only uses a single mailbox provider with no third-party mailing tools, **you do not need a multi-week rollout**:

1. Configure [SPF](https://verifiedinbox.ai/docs/spf.md) and [DKIM](https://verifiedinbox.ai/docs/dkim.md) for your mailbox provider.
2. Publish a strict DMARC enforcement record right away at `_dmarc`:

```text
v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com
```

Because no unauthenticated services are sending mail from your domain, going straight to `p=reject` protects your brand immediately and satisfies the DMARC requirement for your [BIMI](https://verifiedinbox.ai/docs/bimi.md) inbox logo on day one.

If your domain **already sends business email every day** across multiple tools (newsletters, CRM, billing, helpdesk) and currently has no DMARC record, follow the staged rollout below so you do not accidentally filter your own messages.

## How DMARC quarantine works, how to configure it, and how to troubleshoot

### What quarantine does

Your DMARC policy (`p=`) has three possible settings:

- `p=none` **(Monitor only):** Takes no action on failing mail; delivers messages normally and sends daily XML reports to your `rua=` address so you can see who is sending as your domain.
- `p=quarantine` **(Send fakes to spam):** Instructs Gmail, Outlook, Yahoo, and other inboxes to move any email that fails DMARC into the recipient's **spam or junk folder** instead of the primary inbox.
  - Unlike `p=none`, `p=quarantine` actively protects recipients from fake emails.
  - Unlike `p=reject`, a legitimate message sent from a misconfigured tool is still recoverable from the recipient's spam folder while you fix that sender's SPF or DKIM settings.
  - Once `p=quarantine` applies to 100% of messages (when `pct` is omitted or set to `pct=100`), **your domain meets the DMARC enforcement requirement for [BIMI](https://verifiedinbox.ai/docs/bimi.md) and your [VMC](https://verifiedinbox.ai/docs/glossary.md#vmc) or [CMC](https://verifiedinbox.ai/docs/glossary.md#cmc) certificate.**
- `p=reject` **(Block fakes outright):** Instructs receiving servers to drop failing messages at the SMTP door before they ever reach the inbox or spam folder. This is the strongest protection for your brand.

### Configuring a safe rollout to quarantine and reject

For active domains, tighten DMARC in four stages ([safe DMARC rollout](https://verifiedinbox.ai/docs/glossary.md#dmarc-rollout)):

#### Stage 1: Watch

| Field | Value |
|---|---|
| **Host (name)** | `_dmarc` |
| **Record value** | `v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com` |
| **Suggested time** | 14 days |
| **What happens** | No mail is filtered. Daily reports reveal every service sending as your domain. |

#### Stage 2: Quarantine 25%

| Field | Value |
|---|---|
| **Host (name)** | `_dmarc` |
| **Record value** | `v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com` |
| **Suggested time** | ~7 days |
| **What happens** | One quarter of unauthenticated messages go to spam. Note: `pct` below `100` does not yet qualify for BIMI. |

#### Stage 3: Quarantine 100%

| Field | Value |
|---|---|
| **Host (name)** | `_dmarc` |
| **Record value** | `v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com` |
| **Suggested time** | ~7 days |
| **What happens** | All failing messages go to spam. **Qualifies for BIMI and your inbox logo.** |

#### Stage 4: Reject all (recommended)

| Field | Value |
|---|---|
| **Host (name)** | `_dmarc` |
| **Record value** | `v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com` |
| **Suggested time** | Ongoing (keep `rua=` active) |
| **What happens** | Failing messages are blocked at the server door. High-volume senders can optionally step through `p=reject; pct=25` and `pct=50` before `pct=100`. |

### Reading DMARC reports and troubleshooting quarantine issues

As daily `rua=` reports arrive (or when you test a message during quarantine), every sender falls into one of three buckets:

1. **Known, aligned sources:** Services you use where DKIM and/or SPF pass and align with your domain. No action needed.
2. **Unconfigured legitimate sources ("Shadow IT"):** A tool your team uses (such as a helpdesk, billing system, or marketing platform) that is sending as `@yourcompany.com` without aligned DKIM or SPF.
   - **Fix DKIM first:** Enable custom domain DKIM signing in that tool's dashboard so its `DKIM-Signature` uses `d=yourcompany.com` (rather than a shared domain like `d=sendgrid.info`).
   - **Fix SPF alignment:** Add the provider's `include:` to your [SPF record](https://verifiedinbox.ai/docs/spf.md) and configure their custom `Return-Path` subdomain so the bounce domain aligns with `yourcompany.com`.
3. **Forwarded mail and spoofers:**
   - If DKIM passes and aligns while SPF fails, the email was almost certainly **auto-forwarded** by a recipient; DMARC still passes.
   - Unknown IPs where both SPF and DKIM fail in small numbers (or obvious spam campaigns) are the exact spoofers DMARC is designed to quarantine and block.

If legitimate emails land in spam after you enable `p=quarantine`, open a message in Gmail via **More → Show original** (or send a test email from the VerifiedInbox **Email security** or **Go live** step) to inspect the `Authentication-Results` header. If you need time from another department to add a DKIM key, you can temporarily lower `pct=25` or step back to `p=none`, then return to `p=quarantine` or `p=reject` once fixed.

Keep monitoring your `rua=` reports even after reaching `p=reject`: if someone later adopts a new email tool without configuring DKIM, `p=reject` will block that tool's emails until you authorize it.

## Technical reference: DMARC syntax and example records

A DMARC record is published as a single [TXT record](https://verifiedinbox.ai/docs/glossary.md#txt-record) at `_dmarc.<yourdomain.com>`. Tags are separated by semicolons (`;`). **`v=DMARC1` must be the first tag, and `p=` must be the second tag**; all other tags may appear in any order.

### Tags

| Tag | Allowed values | Meaning |
|---|---|---|
| `v` *(required, first)* | `DMARC1` | Protocol version. Must always be `v=DMARC1`. |
| `p` *(required, second)* | `none`, `quarantine`, `reject` | Policy for the domain itself. BIMI requires `quarantine` or `reject`. |
| `sp` *(optional)* | `none`, `quarantine`, `reject` | Policy for [subdomains](https://verifiedinbox.ai/docs/glossary.md#subdomain). Inherits `p` if omitted. **For BIMI, never set `sp=none`.** |
| `pct` *(optional)* | `1` to `100` (default `100`) | Percentage of failing messages the policy applies to. **BIMI requires `100` (or omitting `pct`).** |
| `rua` *(recommended)* | `mailto:address@domain` | Where daily aggregate XML reports are sent. Separate multiple addresses with commas, each prefixed with `mailto:`. |
| `ruf` *(optional)* | `mailto:address@domain` | Where message-level failure (forensic) reports are sent. Not supported by Gmail or most major providers for privacy reasons. |
| `adkim` *(optional)* | `r` (default) or `s` | DKIM [alignment](https://verifiedinbox.ai/docs/glossary.md#alignment) mode: `r` (relaxed, allows subdomains) or `s` (strict, exact domain match). |
| `aspf` *(optional)* | `r` (default) or `s` | SPF alignment mode: `r` (relaxed, allows subdomains) or `s` (strict, exact domain match). |
| `fo` *(optional)* | `0` (default), `1`, `d`, `s` | Forensic reporting trigger options when `ruf` is used. |
| `ri` *(optional)* | Seconds (default `86400`) | Requested interval between aggregate report batches (24 hours by default). |

### Example records

**Stage 1 monitoring (with two report recipients):**

```text
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com, mailto:postmaster@yourcompany.com
```

**Standard enforcement with quarantine (BIMI-ready):**

```text
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com
```

**Strict enforcement for the domain and all subdomains (recommended target state):**

```text
v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc@yourcompany.com
```

## Common issues & edge cases

- **Sending `rua=` reports to a different domain without External Report Authorization.** By default, receiving servers only send `rua=` reports to addresses on the **same** domain as the DMARC record (for example `mailto:dmarc@yourcompany.com` for `yourcompany.com`). If you send reports to an external domain (such as `mailto:reports@dmarc-vendor.com`), the external domain must publish a DNS TXT record at `yourcompany.com._report._dmarc.dmarc-vendor.com` with the value `v=DMARC1`. Without that authorization record, receivers silently drop your `rua=` address.
- **Omitting `mailto:` on a second `rua=` address.** When listing multiple report addresses, every address needs its own `mailto:` prefix, separated by a comma: `rua=mailto:dmarc@yourcompany.com, mailto:ops@yourcompany.com`. Writing `rua=mailto:dmarc@yourcompany.com, ops@yourcompany.com` is a syntax error.
- **Using strict SPF alignment (`aspf=s`) with a provider that uses a return-path subdomain.** Many providers (Postmark, Amazon SES, Resend, SendGrid) send bounces to a subdomain like `pm-bounces.yourcompany.com`. Under `aspf=s`, that subdomain does not match `yourcompany.com` and SPF alignment fails. Leave `aspf=r` (the default) so subdomains align properly.
- **Leaving `p=none` in place.** `v=DMARC1; p=none` only monitors; inboxes will not display a [BIMI](https://verifiedinbox.ai/docs/bimi.md) logo until `p=quarantine` (with `pct=100`) or `p=reject` is live.
- **Setting `pct` below `100` or `sp=none`.** The BIMI specification requires `pct=100` (or no `pct` tag) on your domain and forbids `sp=none` on the [organizational domain](https://verifiedinbox.ai/docs/glossary.md#organizational-domain). If you omit `sp=`, subdomains automatically inherit your `p=quarantine` or `p=reject` policy.
- **Two `_dmarc` TXT records.** A domain may only have **one** TXT record starting with `v=DMARC1` at `_dmarc`. If two `_dmarc` records exist, receivers ignore DMARC altogether.
- **Putting `p=` anywhere other than right after `v=DMARC1;`.** The DMARC specification requires `v=DMARC1` to be the first tag and `p=...` (or `sp=...`) to follow immediately as the second tag.
- **Duplicated domain name in the Host field.** Some DNS providers automatically append `.yourcompany.com` to whatever you type in the Host field. If you enter `_dmarc.yourcompany.com`, it may create `_dmarc.yourcompany.com.yourcompany.com`. VerifiedInbox checks your [authoritative nameservers](https://verifiedinbox.ai/docs/glossary.md#authoritative-dns) directly and warns you if this happens.