# What is DMARC?

> DMARC tells receivers what to do when SPF or DKIM fail, and whether the From domain aligns. EmailPal sets p=reject on sending domains so unauthenticated mail claiming to be you is not delivered.

Source: https://emailpal.io/help/what-is-dmarc

## In one sentence

DMARC is a DNS policy at `_dmarc.yourdomain.com` that says: if this message fails authentication, monitor it (`p=none`), quarantine it, or reject it.

## What EmailPal sets

`p=reject`.

That is stricter than the `p=none` many "start here" blog posts recommend. Those posts are writing for a corporate domain that still has legacy senders. A cold-email domain EmailPal hosts should not have random SaaS tools sending as it. Reject is the correct policy. Longer explanation: [Why DMARC is p=reject](/help/why-dmarc-is-p-reject).

## Alignment

DMARC is not "SPF passed somewhere." The domain in the visible From header has to align with the SPF domain or the DKIM `d=` domain. That is why we sign and send as the same domain you see in From.

## Reports

If you receive XML DMARC reports, they are receivers telling you who tried to send as your domain. On an EmailPal domain, unexpected sources are the thing `p=reject` is blocking. You do not need to "fix" EmailPal because a report arrived.

## FAQs

### Should I start at p=none for four weeks?

Not on an EmailPal sending domain. There is no second marketing ESP to discover. `p=none` on a cold domain just lets spoofed mail through while you "monitor."

### Does p=reject hurt deliverability?

It hurts *spoofed* mail. Legitimate mail we send is aligned and signed. See [Google and Yahoo sender requirements](/help/google-yahoo-sender-requirements).

## Need more help?

[How to set up DNS records (MX, SPF, DKIM, DMARC)](/help/how-to-set-up-dns-records-mx-spf-dkim-dmarc).