100% Inbox Delivery

HomeBlog › Protect Your Email: How to Stop Spoofing with DMARC and Why p=reject Matters

Protect Your Email: How to Stop Spoofing with DMARC and Why p=reject Matters

Published March 14, 2025 · Updated August 17, 2026 · Email Security

Email spoofing — where a scammer forges your domain to send convincing phishing mail — can wreck customer trust and drag your real messages into spam. The fix is a DNS policy called DMARC, and the single setting that actually stops the fraud is p=reject. Here is how DMARC protects your domain and why that one value matters so much.

How spoofing happens (and how DMARC stops it)

Anyone can put [email protected] in the "From" line of an email — the protocol was never built to prevent it. DMARC closes that hole by tying your domain to two authentication checks, SPF and DKIM, and then telling receiving servers what to do when a message fails them. No valid authentication, no delivery.

The three DMARC policy levels

PolicyWhat it doesProtection
p=noneMonitor onlyNone — just reports
p=quarantineSend fails to spamPartial
p=rejectBlock fails outrightFull
Why p=reject matters: Only reject actually stops a spoofed email from reaching your customers. none watches, quarantine hides, but reject slams the door. Start at none to check nothing legitimate breaks, then move to reject once your real mail passes cleanly.

How to set up DMARC safely

  1. Publish valid SPF and DKIM records first — DMARC relies on them.
  2. Add a DMARC TXT record at _dmarc.yourdomain.com, starting with p=none and a rua= report address.
  3. Review the reports for a few weeks to confirm all your legitimate senders pass.
  4. Tighten to p=quarantine, then p=reject for full protection.

What a real spoofing attack looks like

A common pattern: an attacker forges your domain in the "From" field, sends a convincing invoice or payment-change request to one of your customers or a finance contact, and if it lands (no DMARC enforcement), the recipient has no technical reason to doubt it came from you — this is the core mechanic behind most business email compromise (BEC) fraud, and it is exactly what p=reject blocks at the receiving server before it ever reaches an inbox.

Reading your DMARC aggregate reports

Reports arrive as XML (most senders use a free parsing tool rather than reading raw XML) and show, per sending source, how many messages passed or failed SPF and DKIM — the practical use is spotting a legitimate service you forgot to authenticate before you tighten policy, so nothing of yours gets blocked when you move to reject.

Related reading:
Email Authentication Tools - SPF, DKIM, DMARC Generator · SMTP Solutions Redefined: SmadavUpdate's New Role with SendUnlimitedEmail · test your deliverability
Authentication done for you

SPF, DKIM & DMARC configured automatically

Send from a dedicated SMTP server with authentication set up for you — so your domain is protected and your mail lands in the inbox. From $39.99/mo.

Check your email authentication →See pricing

Frequently asked questions

What does p=reject do in DMARC?

It tells receiving mail servers to block any message that fails SPF and DKIM authentication for your domain — stopping spoofed phishing mail before it reaches recipients.

Is DMARC enough to stop spoofing?

DMARC at p=reject, backed by correct SPF and DKIM, is the effective defence. Without those two passing, DMARC has nothing to enforce.

Will p=reject block my real emails?

Only if a legitimate sender is not authenticated. That is why you start at p=none, confirm all your senders pass via the reports, then move to reject.