AI Clicks
Email securityDMARCSPFDKIM

DMARC p=reject: The 10-Minute Setup That Stops Email Spoofing

AIClicks Research · October 6, 2026

Right now, anyone on the internet can send an email that claims to be from your domain. Not a lookalike — your exact domain, in the From header, passing casual inspection. This is how CEO fraud, invoice scams, and phishing campaigns work at scale.

DMARC at p=reject is the fix. It tells every receiving mail server on earth: if an email claiming to be from my domain fails authentication, reject it outright. No quarantine folder, no spam folder — rejected.

The setup takes about 10 minutes of actual work (plus a monitoring period we'll explain). Here's the exact process, in the right order, with the mistakes that break legitimate mail — so you don't make them.

What DMARC actually does

DMARC (Domain-based Message Authentication, Reporting, and Conformance) doesn't authenticate email by itself. It coordinates two existing mechanisms — SPF and DKIM — and adds a policy layer on top.

SPF (Sender Policy Framework) is a DNS record listing which servers are allowed to send mail for your domain. When a server receives mail claiming to be from you, it checks whether the sending IP is on your list.

DKIM (DomainKeys Identified Mail) is cryptographic: your mail server signs outgoing messages with a private key, and receivers verify the signature against a public key you publish in DNS. It survives forwarding better than SPF.

DMARC ties them together: it requires that at least one of SPF or DKIM passes *and aligns* with your domain, and it tells receivers what to do when neither does — nothing (p=none), quarantine (p=quarantine), or reject (p=reject). It also gives you aggregate reports showing who's sending mail as you — including attackers.

Step 1: Know your starting point (2 minutes)

Before touching DNS, scan your domain to see what exists. You need to know: is there an SPF record? What does it authorize? Is DKIM configured? Is there a DMARC record already, and what's its policy?

Run a free email security check — it tests SPF, DKIM (across common selectors), DMARC, BIMI, and MTA-STS in one pass. Write down the results. If you already have p=reject, you're done; go celebrate.

Critical: inventory every service that sends mail as your domain before you start. Your mail provider, newsletter tool, CRM, transactional email service, HR system, support desk — all of them. Miss one and p=reject will eat its emails.

Step 2: Publish SPF (3 minutes)

SPF is a TXT record at your domain root. A typical starting record looks like: v=spf1 include:_spf.google.com include:mailgun.org ~all (yours will differ — use your providers' documented includes).

Three rules that prevent 90% of SPF breakage. First, count your DNS lookups: SPF allows a maximum of 10, and each 'include' can trigger several. Exceed it and SPF fails permanently. Flatten includes where possible. Second, start with ~all (softfail) not -all (hard fail) while you're setting up — you can tighten later. Third, never use +all (it authorizes the entire internet).

If you don't send mail from your root domain at all, publish v=spf1 -all — an explicit 'nobody sends as us.' Attackers love spoofing non-sending domains precisely because nobody bothers to protect them.

Step 3: Enable DKIM (3 minutes)

DKIM requires two halves: enable signing in your mail provider's admin panel, then publish the public key as a TXT record at a selector subdomain (e.g., google._domainkey.yourdomain.com). Every major provider — Google Workspace, Microsoft 365, Mailgun, SendGrid, SES — has a one-click 'enable DKIM' that gives you the DNS record to publish.

DKIM's advantage over SPF: it survives forwarding. When someone auto-forwards your email, SPF usually breaks (the forwarder's IP isn't in your record) but the DKIM signature stays valid. This is why DMARC needs only one of the two to pass — together they cover forwarding and direct delivery.

Rotate keys annually. Most providers make this a button click; stale multi-year-old keys are a needless risk.

Step 4: DMARC at p=none — monitor first (2 minutes to publish, 2 weeks to watch)

Publish a DMARC TXT record at _dmarc.yourdomain.com. Start permissive: v=DMARC1; p=none; rua=mailto:[email protected]. The p=none policy changes nothing about delivery — but the rua address starts receiving aggregate reports from Gmail, Outlook, Yahoo, and everyone else showing every server sending mail as your domain.

Read those reports for two weeks. You're looking for: legitimate senders you forgot (add them to SPF/DKIM), and illegitimate senders (spoofers — note their volume, then ignore them; p=reject will handle them soon). Tools that parse DMARC XML reports into dashboards make this dramatically easier than raw XML.

This monitoring phase is the step everyone wants to skip and nobody should. Going straight to p=reject without it is how companies silently lose order confirmations and password resets.

Step 5: Tighten to p=reject

Once reports show all legitimate mail authenticating cleanly for two weeks, move to p=quarantine for a week (failures go to spam — a safety net), then to p=reject: v=DMARC1; p=reject; rua=mailto:[email protected].

At p=reject, unauthenticated mail claiming to be from your domain is refused at SMTP time. Spoofing stops working. Phishing campaigns using your brand collapse to lookalike domains (which your brand protection monitoring should catch separately).

Keep the rua mailbox and review reports monthly. New SaaS tool, new marketing platform, acquisition with their own mail infra — every change to your sending ecosystem should be verified against DMARC reports before it becomes a deliverability incident.

The mistakes that break legitimate mail

Exceeding 10 SPF DNS lookups — the most common silent killer. Audit with a lookup counter; flatten nested includes. Forgetting subdomains — DMARC applies to subdomains via the sp= tag; set sp=reject too, or attackers just spoof mail.yourdomain.com instead. Misaligned DKIM — signing with d=mailgun.org instead of your domain doesn't satisfy DMARC alignment; configure custom DKIM domains in your providers. And the classic: someone in marketing signs up for a new email tool, sends a campaign, and wonders why open rates are zero — because p=reject ate every message.

The defense against all of these is the same: the p=none monitoring phase, plus ongoing report review. DMARC done right is set-and-monitor, not set-and-forget.

How AIClicks helps

Email security checker

Free one-click check of SPF, DKIM, DMARC, BIMI, and MTA-STS — your before/after verification.

Try free →

Full site scan

Email authentication is one module of the complete security report.

Try free →

Monitoring

Alerts when your SPF, DKIM, or DMARC records change or break.

Try free →

FAQ

Will DMARC p=reject break my newsletters?

Only if the newsletter provider isn't authenticated. Add every legitimate sender to SPF and configure DKIM for them during the p=none monitoring phase — before you enforce.

How long does the full rollout take?

About 10 minutes of DNS work, then 2–3 weeks of monitoring at p=none, a week at p=quarantine, then p=reject. The calendar time matters more than the work time.

Do I need DMARC if I don't send email from my domain?

Yes — especially then. Non-sending domains are prime spoofing targets because nobody monitors them. Publish v=spf1 -all and a p=reject DMARC record.

What's the difference between p=quarantine and p=reject?

Quarantine sends failures to spam/junk (recoverable if you made a mistake); reject refuses them at SMTP time (nothing delivered). Quarantine is the safe intermediate step.

Does DMARC stop all phishing?

No — it stops exact-domain spoofing. Attackers pivot to lookalike domains (paypa1.com), which is a brand protection problem, not a DMARC problem. You need both.

Google and Yahoo require this now?

For bulk senders (5,000+ messages/day to their users): yes, since February 2024. They require SPF, DKIM, and DMARC alignment. Non-compliant mail gets rejected or spam-filtered.

The bottom line

DMARC at p=reject is one of the highest-ROI security controls in existence: minutes of work, and exact-domain spoofing stops permanently. The only reason more domains don't have it is the (justified) fear of breaking legitimate mail — which the p=none monitoring phase eliminates.

Scan your domain now to see where you stand. If you're already at p=reject, verify it's actually working. If you're not, the 10-minute setup plus two weeks of monitoring is all that stands between you and spoof-proof email.

Check your email authentication free

SPF, DKIM, DMARC, BIMI, MTA-STS in one scan — no signup.

Scan my domain

More from the blog

Why Your Website Gets Zero AI Citations (And How to Fix It)

ChatGPT, Perplexity, and Google AI Overviews cite a tiny fraction of the web. Here's how AI citation actually works, why most sites are invisible, and a 30-day plan to change that.

Security Headers: The 6 That Matter Most (And How to Fix Them)

Six HTTP response headers block entire classes of attacks — clickjacking, XSS, SSL stripping, MIME sniffing — with a few lines of server config. Here's what each one does, with copy-paste snippets for Nginx and Apache.

How to Write an llms.txt File (Free Generator + Examples)

llms.txt is a markdown file at your domain root that tells AI systems what your site is and which pages matter. Here's the exact spec, a complete annotated example, the five mistakes that make most llms.txt files useless, and a free generator.

All articles · RSS feed