A DMARC reject policy is strong anti-spoofing protection, but it should be the result of verified email authentication—not a DNS change made on faith. With p=reject, receiving servers are asked to refuse messages that claim to be from your domain yet fail aligned SPF and DKIM. That can protect customers and employees from impersonation, while a rushed rollout can block legitimate mail from a forgotten vendor.
What must be true before reject
Every legitimate service that sends as your domain should authenticate with aligned SPF or DKIM, preferably DKIM as well. That includes employee mailbox mail, transactional messages, CRM sequences, helpdesk replies, newsletters, booking tools, and agency-managed systems. You need more than an SPF record that exists: each source must pass in real message headers and match the domain shown to recipients.
Review reports and sender ownership
Use DMARC aggregate reports to distinguish authorized sources, misconfigured sources, and unauthenticated mail. Assign a person or team to each legitimate sender. A source that appears rarely may still be critical—for example, annual renewal notices or password-reset mail. Fix alignment, retire unused tools, and keep an inventory before raising enforcement.
Move through quarantine first
For many small businesses, quarantine is the practical test stage. Start with a policy percentage that fits your confidence, observe reports, and raise it gradually. A staged rollout lets you detect a legitimate exception without jumping immediately to hard rejection. Read when DMARC quarantine makes sense for the safety checks that should come first.
Publish reject carefully
When results are stable, update the existing DMARC TXT record at _dmarc.yourdomain.com to use p=reject. Preserve reporting tags and other intentional settings. Do not publish duplicate DMARC records, and do not change multiple authentication systems at once. Keep a copy of the previous value so you can diagnose an unexpected outcome with evidence instead of memory.
Verify from public DNS and fresh mail
- Check that one public DMARC record is visible.
- Send fresh tests from every important platform.
- Inspect headers for aligned SPF or DKIM and DMARC pass.
- Review aggregate reports during the following days and weeks.
Our DMARC record check guide explains the visible record, and email authentication explained connects SPF, DKIM, and DMARC in plain language.
Reject is not “set and forget”
New senders can be introduced by marketing, finance, IT, or an outside agency. Make authentication review part of vendor onboarding and monitor the public record for changes. A reject policy gives your domain a strong boundary; the ongoing discipline is what keeps legitimate mail safely inside it.
Run Beacon’s free check to review the SPF, DKIM, and DMARC signals visible for your domain before moving to reject.
Check organizational-domain implications
DMARC policy can apply to subdomains unless you define a separate subdomain policy. Consider mail sent from marketing, support, or product subdomains before applying reject at the organizational domain. If a subdomain has different senders or a different owner, document that relationship and set policy deliberately. The same inventory discipline applies wherever customers see your brand in the From address.
Communicate the change internally
Marketing, customer support, finance, and outside agencies may add tools without realizing their email settings are security controls. Tell them how to request a new sender before launching it, and make DNS ownership clear. A short approval process prevents the most common post-reject incident: an otherwise legitimate new tool that was never configured for alignment.
Review enforcement periodically
Revisit reports after major platform changes and on a regular schedule. Reject is a durable policy, but its safety depends on the current sender ecosystem, not the ecosystem that existed on rollout day.