Generate DMARC Policy with p= Tag

Why Your Email Service Needs a DMARC Policy with p= Tag

You send emails every day. But what if those messages never reach the inbox — not because of poor content, but because your domain’s DMARC policy is missing or misconfigured?

Without a DMARC policy that includes the p= tag, your domain offers no clear instructions to email receivers on how to handle messages that fail SPF or DKIM checks. That means spam filters may treat your legitimate emails as suspicious — even if you’re sending from a verified service.

DMARC is the enforcement layer on top of SPF and DKIM. The p= tag tells receivers what to do when a message fails authentication: quarantine, reject, or do nothing. Left undefined, your policy is just a suggestion — not a rule — and attackers will exploit that gap.

Key takeaways

Without a p= tag, DMARC cannot enforce authentication checks, leaving your domain vulnerable to spoofing.
Setting p=reject ensures failed emails are blocked, reducing the risk of phishing and spamming in your name.
Even if SPF and DKIM are correctly configured, DMARC with p= is required to turn those controls into real delivery protection.

What Does the p= Tag Actually Do in a DMARC Record?

The p= tag tells email receivers what to do when an incoming message fails SPF or DKIM authentication. Without it, DMARC only collects reports — it doesn’t enforce any action. Setting p=reject is the strictest and most secure option, meaning unauthorized emails get blocked outright. This is essential for stopping spoofing and phishing attacks.

How the p= Tag Controls Receiver Behavior

When you set the p= tag, you’re telling receiving mail servers how to treat messages that don’t pass your authentication checks. The three possible values are none, quarantine, and reject. none does nothing — it’s just for monitoring. quarantine moves suspicious emails to the spam folder. reject blocks them entirely.

Most security-focused organizations use p=reject because it stops attackers from exploiting your domain even if one email fails authentication. According to the DMARC specification (RFC 7483), enforcing a policy via p= is how DMARC transitions from a reporting tool to an active defense system.

Why p= is Required for Enforcement

If you omit the p= tag, DMARC is effectively useless for blocking bad emails. You’ll still get reports about failed messages, but those won’t prevent delivery. This is a common mistake: setting up DMARC without a policy means you're collecting data without protection.

Let’s say your domain signs emails with SPF and DKIM, but you forget the p=reject part. A threat actor could still send fake emails that appear to come from your domain — the server logs the failure, but no action is taken. This is why p= is a non-negotiable part of DMARC setup.

Once you’ve defined your policy, it’s important to test it. Use MailTester’s inbox placement tool to send test emails and verify that your DMARC record actually blocks unauthorized messages in real-world inboxes.

How to Generate a DMARC Policy with p= Tag Step by Step

Log into your DNS provider’s dashboard, create a TXT record for _dmarc.yourdomain.com, and set its value to v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]. Use real, monitored email addresses for reports, save the record, and wait up to 48 hours for DNS changes to take effect. This blocks unauthenticated emails pretending to be from your domain.

Set Up Your DMARC Record Step by Step

Log into your DNS provider’s control panel — whether it's Cloudflare, GoDaddy, Amazon Route 53, or another platform. You’ll need access to edit DNS records for your domain.
Create a new TXT record with the name _dmarc and your domain (e.g., _dmarc.example.com). This is the standard location for DMARC policies.
Enter the policy string: v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]. The p=reject tag is critical — it tells receiving servers to block messages that fail authentication.
Use valid, monitored email addresses in the rua and ruf fields. These receive aggregate and forensic reports, helping you track spoofing attempts. Avoid using throwaway or unmonitored addresses.
Save the record and wait up to 48 hours for DNS propagation. Changes may update faster, but some providers or networks can take the full time.

Confirm Your DMARC Policy Is Active

After saving, verify your record is properly published using tools like MXToolbox or dmarcian.com. These services check if your DMARC policy is visible and correctly formatted.

The 5 steps described in “Set Up Your DMARC Record Step by Step”, in order.

Once active, it takes time for the policy to fully enforce. During the first few weeks, monitor reports for any legitimate emails being blocked. You can gradually tighten policies as you confirm legitimate senders are properly authenticated via SPF and DKIM.

Need to test if your domain is secure against impersonation? Try MailTester’s inbox placement tool to simulate delivery and check for authentication issues before sending to customers.

Common DMARC Policy Misconfigurations and How to Avoid Them

You’re not protecting your domain if your DMARC policy starts with p=none — it only lets you monitor, not enforce. Skipping the p= tag means no policy enforcement at all, leaving your emails vulnerable. And if your reporting address is wrong or unmonitored, you’ll miss critical alerts. Let’s break down how to avoid these pitfalls.

Start with Monitoring, Not Enforcement

Using p=none is okay during the initial setup phase, but it should never be permanent. It’s a diagnostic mode — you’ll see reports, but no automated blocking of spoofed emails.
Don’t skip p=none altogether. Omitting the p= tag entirely means your DMARC record is ignored by receiving servers. No enforcement, no protection — even if SPF and DKIM pass.
Once you’ve confirmed authentication alignment and reviewed the reports, move to p=quarantine and then to p=reject. The real goal is to reduce phishing and spoofing risk.
Use a dedicated, monitored email address for rua= and ruf= tags. If the address is invalid or not checked, you get no insight into authentication failures. Many admins miss this, leading to silent failures.

Validate Reports and Avoid Silent Failures

Check that your DMARC reporting addresses are valid and actively monitored. A typo or disabled mailbox means no data, even if your policy is set correctly.
Some tools allow you to send test emails and verify how your DMARC policy is being applied. You can test real-world delivery in inboxes with MailTester’s inbox placement tester.
Use RFC 7483 as the reference for DMARC policy syntax. It defines how p=, rua=, and ruf= work in practice.
Consider using a third-party DMARC analyzer like those from dmarcanalyzer.com to validate your full policy configuration.
Before deploying a full p=reject policy, run checks on your sending infrastructure. A misaligned SPF or DKIM record will break delivery — even with a correct DMARC policy. Use email validation tools to catch these issues early.

DMARC is not a magic fix. It only works when correctly implemented and actively monitored.

Don’t assume your policy is active just because it’s on the DNS. A missing or invalid p= tag, or a forgotten reporting address, nullifies the entire setup. Keep it simple: start with monitoring, validate reports, then enforce.

How DMARC Works with SPF and DKIM for Email Authentication

DMARC uses SPF and DKIM as gatekeepers: SPF checks if the sending IP is authorized, DKIM verifies the message wasn’t altered and confirms the sender’s identity. If both pass, DMARC applies the policy set by the p= tag—like quarantine or reject. If either SPF or DKIM fails, DMARC still applies the p= policy unless exceptions are explicitly allowed via sp= or pd=.

SPF and DKIM: The Two Pillars of Authentication

SPF validates the sender’s IP address against a list of authorized origins published in DNS. If your email comes from an IP not listed in the sender’s SPF record, that check fails. DKIM, on the other hand, uses cryptographic signatures attached to the email. It verifies the message hasn’t been tampered with and confirms it was sent from a domain that holds the private key.

Both are required for DMARC to pass. DMARC doesn’t replace them—it depends on them. Without both SPF and DKIM aligned, DMARC has no reliable basis to evaluate legitimacy.

How DMARC Applies the Policy Based on `p=`

When you set a DMARC policy with p=reject, you’re saying: “Only deliver emails that pass both SPF and DKIM.” If either fails, the receiving mail server can reject or quarantine the message. You can start with p=none to monitor traffic before enforcing the policy.

Exceptions exist—like using sp=quarantine for subdomains or enabling adkim=relaxed for DKIM alignment. But they must be intentional. Misconfiguring these tags can lead to legitimate emails being blocked.

DMARC’s effectiveness relies on visibility. It sends aggregate reports to a designated email address, helping you see who’s sending emails on your behalf. If a third-party service (like a CRM or marketing platform) sends emails for you, ensure their SPF and DKIM are properly set to pass DMARC checks. Otherwise, your domain gets flagged.

Before sending at scale, verify all addresses in your list with a tool like MailTester’s email checker to catch invalid or risky addresses that could harm your sender reputation.

How to Validate Your DMARC Record Is Correctly Enforced

You can confirm your DMARC policy is enforced by checking DNS records with a tool like MxToolbox, sending a test email to Gmail or Outlook, and reviewing the message headers for DMARC, SPF, and DKIM authentication results. A pass with p=reject or p=quarantine in the DMARC result means your policy is active and being applied.

Verify your DMARC DNS record using a real lookup tool. Use MxToolbox or MXRoute to query your domain’s TXT records. Ensure the DMARC record includes v=DMARC1;, rua=mailto:[email protected];, and p=reject or p=quarantine. These tools show exactly what public resolvers see, which is what receiving mail servers use.
Send a test email from your domain to a major provider. Use a trusted email service like Gmail, Outlook, or Yahoo to send a message from an address on your domain. This simulates real-world delivery and triggers authentication checks by the recipient’s mail server.
Inspect the full email headers in the recipient’s inbox. In Gmail, click "Show original" to view the raw headers. Look for lines starting with DMARC-Result, SPF, and DKIM-Signature. The DMARC result should show pass and include the policy you set—reject or quarantine.
Confirm policy enforcement by checking the DMARC alignment. DMARC only passes if SPF or DKIM aligns with your domain. If one or both fail, DMARC may still pass if the domain aligns, but policy enforcement depends on that alignment. A failure here often reveals misconfigurations or missing alignment settings.
Use a DMARC report aggregator (optional, but recommended). Set up rua to send aggregate reports to a mailbox or service like Dmarcian or Ubmatrix. These tools parse reports and help identify why messages fail or how often your domain is being spoofed, confirming policy effectiveness.

What to Expect When Policy Enforcement Is Working

If your DMARC record is correctly published and enforced, incoming emails purporting to be from your domain but failing SPF or DKIM will either be rejected or quarantined. This shows up in the headers as reason=spf or reason=dkim, with policy=reject or policy=quarantine. This is how modern email providers defend against spoofing.

Common Pitfalls to Avoid

Never set p=none in production. It only monitors, doesn’t protect.
Ensure SPF and DKIM are properly configured. DMARC won’t enforce without them.
Use sp=none or sp=quarantine only during monitoring phases.

For teams deploying or auditing email policies, checking real-world delivery outcomes is essential. You can test your setup with inbox placement testing, or verify individual email addresses before sending to avoid exposure to invalid destinations.

Real-World DMARC Policy Examples for Different Email Services

You can generate a DMARC policy with p=reject for transactional platforms like SendGrid, p=quarantine for marketing services while monitoring, and p=none for internal systems during setup. This staged approach ensures alignment, reduces false positives, and supports gradual enforcement based on real-world data. As email authentication evolves, policy tuning is an ongoing task, not a one-time setup.

Transactional Platforms: Start Strong with p=reject

For platforms like SendGrid that send transactional emails—password resets, order confirmations, alerts—your DMARC policy should begin with p=reject. This tells receiving servers to block any email pretending to come from your domain if it fails SPF or DKIM. Set rua and ruf to internal mailboxes so you can monitor alignment and detect unauthorized senders before they impact deliverability. The goal is prevention, not detection. You’ll catch spoofing attempts early, and reputation stays clean.

Marketing Platforms: Monitor First, Enforce Later

Marketing services—like Mailchimp or Klaviyo—often use third-party sending infrastructure. These are high-volume, high-risk for misalignment. Start with p=quarantine to allow emails through while marking suspicious ones as spam-like. Use the rua reports to verify that all legitimate senders are properly authenticated. Once you’re confident SPF and DKIM are passing across all sources, you can safely move to p=reject. A well-known industry practice, described in RFC 7483, supports this phased rollout.

Internal Services: Test First, Lock Down Later

For internal email systems—HR, admin, or legacy apps—start with p=none to gather data without blocking. You need to confirm which mail servers are legitimately sending on your behalf. Use the reports to identify unverified sources. Once those are secured and aligned, you can enforce p=reject. This avoids breaking internal workflows. As organizations scale, this step is critical: even small misconfigurations can cause entire departments to lose email access.

If you're validating sender alignment across your list, email verification tools like bulk verification can help you clean your sending list before applying DMARC policy changes.

Why Email Verification Tools Like MailTester Help Enforce DMARC Policies

You can’t fully enforce a DMARC policy with a p=reject tag unless you’re sending only to valid, deliverable email addresses. Tools like MailTester prevent your domain from being exploited by filtering out invalid, catch-all, or disposable addresses before they ever get sent—reducing the risk of your emails being rejected or marked as spam, even after proper DMARC alignment is in place. This ensures your DMARC policy actually works as intended.

Preventing Spoofing Through Cleaner Lists

DMARC protects your domain from being used in spoofing attacks—but only if the emails sent from it are actually valid. If your list contains invalid or unverifiable addresses, DMARC won’t stop malicious actors from exploiting your domain, especially if those addresses are catch-alls that silently accept mail. MailTester’s bulk verification checks thousands of addresses in minutes, flagging those that are syntactically wrong, expired, or non-existent—so you’re not accidentally sending to addresses that undermine your policy.

Stopping Bypass Attempts in Real Time

Even with a strict p=reject policy, attackers can try to bypass it by targeting catch-all or disposable domains. These domains often accept any email, making them ideal for harvesting data or hiding spam. MailTester’s real-time API blocks these domains at the point of entry: it detects disposable email services and catch-all configurations before the send happens. This means your DMARC policy isn’t just enforced—it’s respected in practice, not just in theory.

Once you’ve cleaned your list and enforced strict verification, you still need to know if your messages actually reach inboxes. That’s where inbox placement testing comes in. Test your deliverability with MailTester’s inbox tester, which simulates real-world conditions across major providers like Gmail, Outlook, and Yahoo. If your emails land in spam or are blocked, it’s not just a policy issue—it’s a deliverability one. You can’t fix it without seeing it.

For ongoing security and compliance, integrating MailTester with tools like HubSpot, SendGrid, or Klaviyo ensures that every new address added to your list is automatically verified. This creates a feedback loop that maintains list health and keeps your DMARC policy effective over time. You’re not just setting rules—you’re ensuring they’re followed by the actual data you push.

DMARC is a powerful tool, but its effectiveness hinges on the quality of the data you send. Without verification, even the strictest policy can fail. This is why leading teams use tools like MailTester to verify every address, from the first batch to the final email.

How to Use MailTester to Test Your DMARC-Protected Emails in Real Inboxes

You can test how your DMARC-protected emails perform in real inboxes by sending a campaign through SendGrid or Mailchimp, then using MailTester’s inbox placement test to validate delivery, filtering behavior, and DMARC policy enforcement across Gmail, Outlook, and Yahoo. This confirms whether your sender reputation and authentication settings are respected in practice, not just on paper.

Step-by-step: Validate DMARC policy enforcement in live environments

Send a test campaign through your email service. Use SendGrid, Mailchimp, or another platform that supports SPF, DKIM, and DMARC. Ensure your DMARC record includes p=none or p=quarantine (not p=reject until you’re confident). This setup allows real-world testing without blocking legitimate emails.
Use MailTester’s inbox placement test. Go to MailTester’s inbox placement tester and enter your campaign’s from address. The tool simulates a real transactional or marketing send and routes it through actual inbox providers.
Select inboxes to test: Gmail, Outlook, Yahoo. These represent over 80% of global email usage. The test checks whether your message lands in the inbox, gets flagged as spam, or is delivered to the junk folder. You’ll see which providers respect your DMARC policy, even if they don’t publish logs.
Review results: delivery, filtering, and DMARC compliance. The report shows if your email passed authentication, ended up in spam, or was rejected—directly tied to DMARC policy enforcement. If your p=reject policy is properly configured, you should see rejections or quarantines when spoofing occurs. If not, it may indicate misconfiguration or provider exceptions.
Check the raw message headers. For deeper validation, download the full email headers after the test. Use tools like MXToolbox or RFC 7483 to parse the DMARC report section and verify alignment scores and policy actions.

Why real inbox testing matters for DMARC policy

Even if your DMARC record is correctly published, its real-world enforcement depends on how inbox providers interpret it. Some providers test policies differently. For example, Gmail applies DMARC more strictly than others, especially for authenticated domains. Testing directly in live inboxes gives you empirical proof of policy effectiveness.

Use MailTester’s inbox placement test not just for delivery, but to catch subtle issues—like poor authentication alignment or inconsistent header handling—that can weaken DMARC enforcement. This process ensures your policy is not just declared, but actively followed at scale.

The Trade-Offs of Enforcing p=reject: Deliverability vs. Security

Setting p=reject in your DMARC policy blocks all emails that fail SPF or DKIM checks—great for security, but risky if your sending services aren’t properly authenticated. A single misaligned domain or shared IP can cause legitimate messages to be outright rejected, harming delivery. Start with p=none or p=quarantine to test your alignment and authentication setup before enforcing strict policy.

Why p=reject Can Break Real Deliverability

When you enforce p=reject, any email failing SPF or DKIM—even from your own team—gets blocked. That includes emails sent through third-party services if they’re not using your domain correctly or are operating on shared IPs with misaligned authentication. You’ve probably seen it: a support reply sent from a customer service tool ends up in spam or vanishes entirely because the sending domain doesn’t match the SPF or DKIM signature.

Let’s be clear: this isn’t a flaw in DMARC. It’s a reality of how email systems work. If your sending tool uses a different domain for authentication than the one showing in "From," DMARC sees that as a mismatch—and under p=reject, it stops delivery. This is especially common with marketing platforms, CRMs, or helpdesk tools tied to generic or shared infrastructure.

Test First, Enforce Later

Before flipping to p=reject, use p=none to monitor how many of your outbound messages fail. You’ll see alignment and authentication issues in your DMARC reports—usually within a few days. Tools like MailTester’s inbox placement tester help simulate real-world delivery, so you can see what recipients actually receive, not just what your reports say.

Once you’ve aligned your SPF and DKIM records—especially in multi-domain setups—and confirmed that your sending services are properly configured, move to p=quarantine. This step quarantines failing messages instead of blocking them, giving you time to catch edge cases without breaking your flow. Only after this testing phase should you consider enforcing p=reject.

DMARC isn’t a one-size-fits-all toggle. It’s a guardrail. You don’t want it too loose (p=none), but you also don’t want it too aggressive before your infrastructure is ready. The balance is in the testing phase. RFC 7483, which defines DMARC, stresses that policies should evolve based on observed results—you’re not supposed to start with p=reject on day one. You can find the specification via IETF’s official documentation.

Conclusion: Build a Secure, Deliverable Email Infrastructure With DMARC

A DMARC policy with a properly configured p= tag is not optional—it’s essential for protecting your domain from spoofing and ensuring your emails reach inboxes. Without it, you leave your brand exposed to abuse and risk losing sender reputation.

Next steps for implementation

Begin with p=none to monitor email flows and identify unauthorized senders.
Verify your SPF and DKIM configurations are correctly published and aligned.
Gradually move to p=quarantine, then enforce p=reject only after confirming deliverability.

Before enforcing strict policies, test real inbox delivery and confirm your email list accuracy. Use MailTester to validate senders, detect invalid addresses, and check inbox placement across major providers.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if I don’t include a p= tag in my DMARC record?

The policy is not enforced. Receivers will still receive reports, but they can ignore failing emails. Your domain remains vulnerable to spoofing.

Is p=reject safe to use with third-party email services?

Only after confirming SPF and DKIM are correctly configured for every sending source. Otherwise, legitimate emails may be blocked.

Can I use p=quarantine instead of p=reject?

Yes — it moves failed emails to spam. This is a safer transition step before enforcing p=reject.

How long does it take for a DMARC record to take effect?

DNS propagation typically takes 5 to 48 hours. Monitor your reports during that time to confirm the policy is active.

Do I need to update my DMARC record if I switch email providers?

Yes — ensure the new provider’s sending infrastructure passes SPF and DKIM, and update the DMARC record accordingly.

How do I know if my DMARC policy is working?

Check aggregate reports sent to your rua address. Look for consistent pass rates and alignment across senders.

Can MailTester verify if my domain has a functional DMARC policy?

Not directly, but you can test whether emails sent from your domain reach inboxes — a sign that DMARC enforcement is not blocking them.

What’s the difference between p=none and p=reject?

p=none means no action is taken on non-compliant emails. p=reject means receivers must block them entirely.

Is DMARC required for all domains?

No, but it’s strongly recommended, especially for domains sending email to customers or partners.

Can DMARC prevent all phishing attacks?

It reduces spoofing risk significantly but isn’t a full defense. Combine with DKIM, SPF, and user awareness.

What email services support DMARC enforcement?

Gmail, Outlook, Yahoo, Apple Mail, and most major providers enforce DMARC policies when properly configured.

Why does SendGrid need both SPF and DMARC?

SPF validates the sending IP; DMARC adds policy enforcement. Both are needed for consistent inbox placement.