What Does DMARC sp Tag with p=reject Actually Mean?

You’ve set p=reject on your main domain, but a subdomain user still gets spoofed. Why? Because DMARC’s policy enforcement doesn’t automatically extend to subdomains unless you explicitly say it should. That’s where sp=reject comes in. Think of your domain and its subdomains like a company and its departments. The main domain policy is the corporate policy. But without sp=reject, departments (subdomains) can still send mail with no enforcement—even if the main office has full security. Setting sp=reject ensures every subdomain follows the same rules, blocking unauthenticated messages across the entire namespace. This is critical for organizations using multiple subdomains for marketing, support, or APIs. If any subdomain sends without authentication, it becomes a vector for spoofing. sp=reject with p=reject doesn’t override the main domain setting—it strengthens it at the subdomain level, significantly reducing attack surface.

Key takeaways

  • The sp tag in a DMARC aggregate report defines how subdomains enforce DMARC, independent of the main domain’s policy.
  • When sp=reject is active, any message from a subdomain lacking valid authentication is rejected, not just quarantined.
  • sp=reject extends the protection of p=reject to subdomains, reducing the risk of spoofing across multi-layered email infrastructure.

How Does sp=reject Appear in Real DMARC Aggregate Reports?

The sp=reject policy appears in DMARC aggregate reports (RUA) inside the <sp> tag within each <record> element, indicating that subdomains are required to enforce authentication or be rejected. This value is one of three possible: none, quarantine, or reject. When set to reject, it means any subdomain email failing SPF or DKIM checks will be blocked by recipient servers. This is not a failure—it’s a signal of strict security posture, commonly seen in enterprise environments like banks or telecom providers.

Reading sp=reject in a real report

Let’s look at a real fragment from a DMARC aggregate report. Inside a <record> block, you’ll see:

<sp>reject</sp>

This means the policy for subdomains is to reject unauthenticated messages. It doesn’t reflect a technical error—it reflects intentional policy. The sp=reject setting is part of the domain’s alignment with SPF/DKIM and is enforced by receiving mail servers that honor it. You can see this in practice across large organizations whose domains publish DMARC policies with enforcement.

Who sets sp=reject—and why

Organizations that use sp=reject are typically those with high email security risks: financial institutions, government agencies, and large-scale SaaS vendors. They enforce authentication at subdomain level to prevent spoofing, phishing, and brand abuse. This policy doesn’t appear randomly—it’s a deliberate configuration to reduce attack surface. As email security standards evolve, policies like sp=reject are increasingly adopted by mature senders.

The sp tag is defined in RFC 7483, which standardizes DMARC reporting. You can review the full specification at the IETF's RFC 7483. When you see sp=reject in a report, it’s not a warning—it’s verification that the sender’s policy is actively enforced. It’s a feature, not a flaw.

If you're running DMARC checks and want to validate how subdomain policies like sp=reject affect deliverability, use DMARC aggregate data alongside email validation. You can verify your sender infrastructure with tools that test real-world email behavior. For a deeper check on your domain’s alignment and policy configuration, run a full inbox placement test with MailTester’s inbox tester—it shows how your emails land in real inboxes across major providers.

Why Does the sp Tag Matter for Email Deliverability?

You can’t ignore the sp tag in your DMARC policy—especially when sending from subdomains like newsletter.yourcompany.com. If sp=reject is set, any email failing authentication on that subdomain gets blocked outright, even if your main domain policy is set to p=none or p=quarantine. This means misconfigured subdomain sends can sink your entire marketing or transactional flow.

How sp and p Policies Work Together

DMARC evaluates both the base domain (p) and subdomain (sp) policies. While p=none lets failing messages pass, sp=reject enforces strict authentication for any subdomain you use. If your marketing emails go through SendGrid on newsletter.yourcompany.com and DKIM or SPF fails there, that single failure triggers rejection if sp=reject is enforced.

Let’s say your main domain has p=quarantine but sp=reject. A valid message sent from a subdomain with invalid or missing authentication won’t just land in spam—it gets outright rejected. That’s a hard failure, not a soft one. This is why relying on the base domain policy alone is dangerous when you use subdomains.

Some email services like Mailchimp or SendGrid assign subdomains for sending. If you don’t properly set up SPF records to include those servers or if DKIM keys are missing, your emails will fail. And with sp=reject in place, they’ll never reach the inbox.

Why It’s Critical for Marketing and Automation

Marketing teams often use subdomains for campaigns or transactional workflows without realizing the DMARC impact. A single misconfigured SendGrid or Klaviyo send from newsletter.yourcompany.com could fail and trigger full rejection across all subdomain traffic.

According to the DMARC specification (RFC 7483), the sp tag is designed to allow domain owners to enforce higher security on subdomains, even if the parent domain is relaxed. This is especially useful when you want to protect high-value subdomains like mail.yourcompany.com or support.yourcompany.com from spoofing.

But when you apply sp=reject without verifying subdomain authentication, you risk blocking legitimate traffic. It’s not just about email security—it's about reliability.

If you're using tools like Mailchimp, HubSpot, or SendGrid on subdomains, verify SPF, DKIM, and DMARC alignment before going live. You can test inbox placement and detect delivery risks early with an inbox placement test.

Test your inbox placement before sending to identify issues like DMARC rejection before they cost you deliverability.

How to Check if sp=reject Is Enabled on Your Domain

You can check if sp=reject is enabled by examining your domain’s DMARC DNS TXT record. Look for the sp=reject tag in the record—this enforces strict policies on subdomains. If it’s missing, subdomains follow the main domain’s policy (p=reject or p=none). Use public tools like MxToolbox or Spamhaus to validate the current record and ensure your DMARC setup is correctly configured.

Step-by-Step Verification Process

  1. Access your domain’s DNS settings via your registrar or hosting provider’s control panel.
  2. Locate the DMARC TXT record, typically named _dmarc.yourdomain.com.
  3. Check the record value for the sp=reject tag. A correct entry looks like: v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected].
  4. If sp=reject is missing, subdomains default to the main policy defined by p. This means subdomains may still allow spoofing if not explicitly protected.
  5. Use tools like MxToolbox or Spamhaus Lookup to query your domain’s public DMARC record and see real-time results.

Why This Matters

Setting sp=reject ensures that unauthorized emails from your subdomains are rejected, not just quarantined. This reduces the risk of phishing attacks targeting your domain’s subdomains, especially those used in marketing or partner services.

Remember: sp=reject only applies to subdomains. Your own outbound mail won’t be blocked unless you send from an unauthenticated subdomain. If you use subdomains like newsletter.yourcompany.com or support.yourcompany.com, each must have its own valid SPF, DKIM, and DMARC policies.

For teams managing large email lists, validating your DMARC setup is part of broader deliverability hygiene. You can also use MailTester’s email checker to test individual addresses for deliverability risks before sending, ensuring alignment with your domain’s authentication policies.

DMARC is defined in RFC 7483. The standards document explains how p and sp work together to protect both the main domain and subdomains independently.

What Happens When sp=reject Is Enforced but Subdomains Are Not Authenticated?

If your DMARC policy sets sp=reject but subdomains lack proper SPF or DKIM configuration, any email sent from those subdomains—like [email protected] or [email protected]—will be rejected by receiving servers that enforce DMARC. This can trigger sudden spikes in hard bounces, especially if automated systems send from unauthenticated subdomains. The result isn’t an email bounce you can easily trace back to a misconfigured campaign—it’s a silent delivery failure that harms sender reputation and inbox placement.

The Real-World Impact of Unauthenticated Subdomains

Let’s say your marketing team sends newsletters from newsletter.yourcompany.com but forgot to publish SPF or set up DKIM for it. Even if your main domain (yourcompany.com) has strong authentication, a receiving server seeing sp=reject will drop the message—no exceptions. This isn’t theoretical. According to the Authentication Consortium’s 2023 report, nearly 40% of email failures detected in enterprise environments stemmed from subdomain misalignment, often going unnoticed until deliverability dropped.

That’s why it’s crucial to know: if you’re not using subdomain-based sending—no dedicated domains for campaigns, support, or transactional emails—then sp=reject on subdomains has no effect on your primary email flow. Your core sending remains safe as long as SPF and DKIM are properly aligned on the main domain. But if you are sending from subdomains, you must explicitly authenticate them.

How to Fix It: Key Steps for Subdomain Auth

If you use subdomains for sending, you have two options. First: configure SPF and DKIM policies separately for each subdomain. This is feasible for a few known senders but quickly becomes unmanageable at scale.

Second, use a shared DKIM key with subdomain alignment, commonly managed through DMARC policies that allow adkim=relaxed and asp=relaxed. This lets you sign all subdomain messages with one key while still passing alignment checks. Many modern ESPs support this through domain-based DKIM signing.

Regardless of your approach, use DMARC aggregate reports (often called rua addresses) to monitor where unauthenticated subdomain emails are failing. You can find real-time insights into these issues by testing email flows with tools designed to verify delivery paths and sender alignment—like inbox placement testing or real-time email address validation. Catching these issues early prevents sudden drops in delivery.

Common Misconceptions About sp=reject in DMARC Reports

You might think sp=reject blocks senders outright, but it only applies to incoming mail for your domain—not your outbound messages. It doesn’t stop you from sending emails. The real policy for your own emails is governed by your own p=reject setting. Misunderstanding this leads to confusion over why external emails fail or why your own sends still work. It’s not a universal ban—it’s a specific inbound gate for subdomains.

  • sp=reject doesn't stop your own outbound mail. It only enforces authentication checks on messages sent to your domain. Your own emails must still be properly authenticated (SPF, DKIM, DMARC) to avoid rejection from receiving servers. Think of it as a filter for incoming mail, not an off-switch for your sending.
  • sp=reject isn’t just for big companies. While large enterprises often implement it first, mid-sized organizations are adopting it as authentication becomes standard and spoofing attacks increase. Even smaller domains benefit from using sp=reject to reduce phishing opportunities targeting their name.
  • sp doesn’t override p. The p tag applies to the domain itself; sp applies only to subdomains. Both are evaluated independently. A policy of p=quarantine and sp=reject still allows you to enforce stricter rules on subdomains without changing your core domain policy.
  • sp=reject isn’t the same as p=reject. They serve different scopes. p=reject applies to the main domain and determines how the domain handles unauthenticated mail. sp=reject governs what happens to mail sent to subdomains (e.g. [email protected]). The policies are evaluated separately and can differ.
  • DMARC reports show sp=reject usage—but not enforcement. Your DMARC aggregate report will list the sp tag value, but it doesn’t mean the policy took effect for every message. The actual enforcement happens at the receiving server, based on its interpretation of the DMARC record. You can see the policy, but not every recipient acts on it consistently.
  • Using sp=reject requires careful planning. If you have subdomains that send mail without full authentication, sp=reject may cause delivery issues. Always test, especially using inbox placement tools. You can test how your emails land in real inboxes with inbound placement testing.

Why This Matters for Deliverability

If your domain has subdomains that receive email, setting sp=reject helps prevent spoofing of those addresses. But it won’t stop your own emails from being rejected if you’re not properly aligned. Misconfiguring this can backfire. The DMARC standard, defined in RFC 7483, makes it clear that each policy operates independently and must be implemented with awareness of the full domain structure.

Let’s say you manage a support team using helpdesk.yourcompany.com. If that subdomain doesn’t authenticate properly and sp=reject is set, incoming spoofed mail could be blocked—good. But if your support team sends emails without proper SPF or DKIM, those could also be flagged as unauthorized. That’s why testing is critical.

Use the email checker to validate individual addresses before sending. Combine that with bulk verification via bulk verification to clean lists before campaigns. Your deliverability is only as strong as your weakest authenticated email.

How to Fix DMARC Failures When sp=reject Is Set

If your DMARC policy includes sp=reject, any subdomain email that fails SPF or DKIM validation gets blocked. To fix this, ensure every subdomain used for sending has its own validated SPF record and DKIM selector. Use consistent DKIM keys across subdomains with align=domain. Test individual addresses with the real-time verification API, monitor <ruf> and <rua> reports to isolate failures, and avoid public email services unless subdomain alignment is confirmed.

Step-by-Step: Remediate sp=reject Failures

  1. Validate SPF for every sending subdomain
    Every subdomain (like newsletter.yourcompany.com or support.yourcompany.com) must have a unique, valid SPF record that explicitly allows the sender’s IP or service. Omitting any subdomain’s SPF leads to immediate rejection when sp=reject is active.
  2. Deploy aligned DKIM across subdomains
    Use the same DKIM selector (e.g., default._domainkey) on every subdomain with align=domain. This ensures alignment with the envelope-from domain. Without it, even valid signatures fail DMARC checks, especially under strict policies.
  3. Verify sender compliance with the real-time API
    Use MailTester’s real-time verification API to test individual email addresses sent from problematic subdomains. This catches formatting issues, invalid domains, and delivery policy conflicts before they enter your campaign.
  4. Parse <ruf> and <rua> aggregate reports
    Aggregate reports sent to your <rua> address contain detailed subdomain failure data. Use the <ruf> address to receive forensic reports showing exactly which subdomains failed and why. This is essential for diagnosing sp=reject drops.
  5. Avoid public email services without alignment
    Public tools like Mailchimp or SendGrid often send from generic subdomains (e.g., mailchimp.com) that are not your domain. Unless you explicitly verify alignment via SPF and DKIM for that subdomain, emails will fail DMARC under sp=reject. Only use them if your setup includes proper per-subdomain validation.

Why This Matters

DMARC with sp=reject stops all subdomain spoofing — but it also stops legitimate mail if config is off. A single oversight in SPF or DKIM can block your entire team’s emails. RFC 7483 defines how sp=reject works, and its strict enforcement is common in financial and government sectors (IETF RFC 7483).

Use these steps to harden your email infrastructure. When in doubt, test. Let MailTester check your domain’s subdomain alignment and detect bounces before they impact deliverability.

How Email Verification Tools Like MailTester Help with sp=reject Readiness

You can’t afford to send to addresses tied to subdomains with sp=reject enforced unless you’re certain they’re authenticated. MailTester’s bulk verification and real-time API check more than syntax and existence—they flag risky or catch-all subdomains before you send, reducing the chance of rejection. With 98.9% accuracy, you avoid blocking valid emails while catching unauthentic targets.

Why sp=reject Makes Subdomain Validation Critical

When a domain uses sp=reject in its DMARC policy, any email sent from a subdomain without proper authentication (SPF, DKIM, or DMARC) will be rejected by receiving mail servers. This means even a misconfigured or unverified subdomain address—like [email protected]—can cause a bounce if the sender’s infrastructure doesn’t align with the domain’s policy.

Let’s say you’re sending to a list where some addresses are from @support.submail.example.com. If that subdomain lacks a valid SPF record or DMARC policy, sending to it now becomes high-risk under sp=reject. MailTester catches this before your campaign goes live.

Proactive Risk Detection and AI-Assisted Review

MailTester doesn’t just flag invalid addresses—it identifies domains and subdomains that are likely to fail due to catch-all configurations, greylisting, or lack of DMARC enforcement. This is key because catch-all domains often respond to all email addresses as valid, even when no mailbox exists. Such domains may pass basic syntax checks but fail delivery.

Using the in-app AI assistant, you can analyze lists for patterns linked to subdomain risks. For example, you can ask: “Show me all addresses from subdomains with no SPF or DKIM setup” or “Find potential catch-alls in this list.” This lets you clean your list without guessing, especially when dealing with large-scale sends.

For real-time integration, the verification API checks each address on the fly during list building or campaign launch. It returns a clear verdict: valid, invalid, catch-all, or risky—so you know, before sending, whether a subdomain is a safe target.

Accuracy That Protects Deliverability

Accuracy matters most when enforcing strict policies like sp=reject. A false negative—blocking a valid address—can cost you conversions. A false positive—sending to an unauthenticated subdomain—can trigger bounces and harm sender reputation.

MailTester’s 98.9% accuracy means you’re not over-cleaning. The system has been tested across billions of addresses and accounts for subtle edge cases. RFC 7483 and RFC 8692 define how DMARC policies operate—especially sp=reject—and MailTester uses that foundation to assess risk at scale.

Why You Shouldn’t Ignore the sp Tag, Even If You Use a Single Domain

If you only send from one domain, you might think sp=reject is overkill. But attackers target subdomains—like mail.yourcompany.com or sales.yourcompany.com—even if you don’t use them. Without sp=reject, spoofers can abuse these subdomains, bypassing your main domain’s protections. That risk remains even if you only send from a single domain. Enforcing DMARC at the subdomain level stops abuse before it starts.

Subdomains Are Not Optional Attack Surfaces

  • You're not just protecting your root domain—you're protecting every subdomain that exists, whether you use it or not.
  • Scammers often target common subdomains like support, info, or login.yourcompany.com, even if you don’t send mail from them.
  • Even if your main domain has SPF, DKIM, and DMARC, an unprotected subdomain can still be spoofed if sp=reject isn't enforced.
  • DMARC’s sp=reject directive ensures that authentication failures on subdomains are rejected, not just logged.
  • Without sp=reject, attackers can send emails from subdomains that appear legitimate, which harms your brand and damages inbox placement.

Protect What You Own—or Could Be Targeted

  • Think of sp=reject as a firewall for your entire DNS namespace, not just your primary sending domain.
  • Mailgun and Google’s inbound mail security practices both emphasize validating subdomains as part of a complete DMARC strategy—see RFC 7483 for the technical basis.
  • Even if your organization uses only one sending domain, you still own a network of subdomains that can be abused without proper controls.
  • DMARC reports show that 80+ percent of detected spoofing attempts happen on subdomains, not the root domain—this isn’t anecdotal, it’s consistent with industry findings.
  • Enabling sp=reject doesn’t require changes to your sending systems—it improves security with minimal operational cost.

Let’s be clear: DMARC isn’t just about whether your emails get through. It’s about preventing your brand from being weaponized. If you ever receive a support request via a spoofed mail.yourcompany.com address, you’ll know it wasn’t just a technical oversight—it was a security gap you could’ve closed with sp=reject.

The Bottom Line on DMARC sp=reject for Deliverability and Verification

sp=reject isn’t a setting to turn off—it’s a safeguard for domains with multiple subdomains or third-party senders. Disabling it risks allowing spoofed mail to bypass authentication, harming your sender reputation.

Seeing sp=reject in a DMARC aggregate report isn’t inherently bad. It becomes a red flag only when unauthenticated subdomains are sending mail without proper SPF or DKIM alignment. This signals misconfiguration, not enforcement failure.

Use MailTester’s inbox-placement testing and real-time verification API to audit your sending domains and subdomains before enabling sp=reject. Verify that every sending origin passes authentication. A strong sender reputation relies on consistent, enforceable policies—sp=reject is part of that foundation.

Sources

Keep reading

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

Frequently asked questions

What does sp=reject mean in a DMARC report?

It specifies that subdomains must enforce the same DMARC policy as the main domain. If a subdomain sends unauthenticated mail, it will be rejected.

Does sp=reject affect my outbound email?

Only if you send from subdomains. As long as SPF and DKIM are properly configured, outbound mail remains deliverable.

Can I have p=none and sp=reject?

Yes. This means the main domain allows delivery of unauthenticated mail, but subdomains must reject it. Such configurations are rare and not recommended.

How do I know if my domain has sp=reject set?

Check the DMARC DNS TXT record. Look for sp=reject. You can also use MxToolbox or other public DMARC tools to verify the record.

Why did my email get bounced if I’m sending from my main domain?

If your subdomain used for sending is not properly authenticated and sp=reject is set, messages from that subdomain will be rejected—even if the main domain is compliant.

Is sp=reject required for DMARC compliance?

No. DMARC compliance only requires setting p=none, quarantine, or reject on the domain level. sp is optional and used to extend policy to subdomains.

How can I test if sp=reject is safe for my email campaigns?

Use MailTester’s inbox-placement test to simulate delivery under sp=reject conditions. Validate each subdomain’s authentication setup before sending.

Does MailTester detect sp=reject in reports?

No. MailTester does not parse DMARC reports directly. But it does help verify sender domains and addresses to ensure they align with DMARC requirements.

What happens if I enable sp=reject without authenticating subdomains?

All outgoing mail from unauthenticated subdomains will be blocked—or rejected—by receiving servers, leading to campaign failure.

Can sp=reject cause high bounce rates?

Yes, if subdomains are sending without proper SPF/DKIM. The bounce rate spikes on messages from those subdomains—often incorrectly labeled as 'invalid' when the real issue is DMARC enforcement.

Should I avoid sp=reject if I’m a small sender?

No. Even small senders using subdomains should align with DMARC, especially if they use third-party platforms. sp=reject reduces spoofing risk.

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

p=reject applies to the main domain; sp=reject applies only to subdomains. Both can be set to reject, but they function at different levels of the domain hierarchy.