DNS and authentication
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.
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.
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.