Why isn’t your DMARC aggregate report arriving?

You set up DMARC, verified your DNS records, and waited for the reports. They never came. You’re not paranoid — this is a known gap in email security monitoring.

DMARC aggregate reports are sent to a designated email address, but they only arrive if your policy includes a reporting mechanism. If your policy uses sp=none, reporting is effectively disabled. No reports, no visibility, no way to track misuse of your domain.

Understanding this behavior isn’t just technical trivia — it’s essential. Without aggregate reports, you’re flying blind on email spoofing attempts, even when your DNS records look correct.

Key takeaways

  • Setting sp=none in your DMARC policy disables all aggregate reports, even if reporting addresses are properly configured.
  • DMARC reports only arrive when p=quarantine or p=reject is set, or when sp is set to quarantine or reject.
  • Even with valid DNS records, no reports are generated if the policy strictly disables reporting via sp=none.

What does sp=none mean in your DMARC record?

The sp=none setting in your DMARC record means you’ve chosen not to receive aggregate reports from email receivers. No reports will be sent to your designated reporting address, even if emails fail authentication. This is a deliberate opt-out—commonly used during testing or when monitoring isn’t a priority—but it leaves you blind to issues like spoofing or misconfigured senders.

Why sp=none is used (and why it’s risky)

Let’s be clear: sp=none isn’t a mistake. It’s a configuration choice. Some organizations use it initially while setting up DMARC, or when they don’t want to process large volumes of report data. But this setting means you won’t get visibility into how your domain is being used across the internet.

Without aggregate reports, you won’t know if unauthorized senders are using your domain. You won’t detect policy violations from third-party vendors. And you won’t see spikes in failed authentication that could signal a phishing campaign targeting your brand. This lack of visibility makes it harder to improve email deliverability over time.

How to fix it if you’re missing reports

If you expected DMARC aggregate reports but aren’t receiving them, check your policy. If sp=none is set, change it to sp=reject (or sp=quarantine) to start collecting data. You’ll need to update your DNS record and wait 48–72 hours for changes to propagate across receivers.

Once reporting begins, use tools to parse the data. The raw XML can be hard to read. Services like dmarc.org provide guidance on interpreting reports, and some third-party tools can parse them for you. You can also use a MailTester inbox placement test to simulate delivery and spot issues before they hurt your sender reputation.

How DMARC aggregate reporting actually works

If you’ve set sp=quarantine or sp=reject in your DMARC record, receiving mail servers are required to send aggregate reports (RUA) to the email address listed in your DNS record. Without that policy, no reports are sent—meaning you get no visibility into who is sending email on your behalf, whether your authentication is working, or if spoofing attempts are coming through. This is why sp=none is a common reason for DMARC reports not being delivered: the policy signals "no enforcement," so there’s no obligation to report.

What’s included in a DMARC aggregate report?

When a receiver does send a report—typically once per day—it includes a snapshot of the email traffic tied to your domain over the previous 24 hours. It shows the source IP address, whether SPF and DKIM passed or failed, if the message was accepted or blocked, and how many messages were processed. This data helps you identify unauthorized senders, misconfigured systems, or third-party tools sending mail on your behalf without proper authentication.

Why your DMARC reports might not be arriving

The most likely reason you're not receiving reports is because your DMARC policy is set to sp=none. Under RFC 7483, receivers are only required to send aggregate reports when you enforce a policy like sp=quarantine or sp=reject. If you're not enforcing anything, there's no incentive for receivers to send the data.

You don’t need to remove sp=none entirely—this is often useful during setup—but you should add a reporting-only policy like sp=quarantine temporarily to start collecting data. This helps you verify that your authentication (SPF, DKIM, DMARC) is consistent and catch issues early before they impact deliverability.

According to the IETF’s DMARC specification, the RUA tag in your DNS record must be a valid email address, and receivers will attempt delivery only if your policy enforces action on failed authentication. It’s normal for some receivers—especially smaller or less standardized ones—not to participate, but the data you do collect still provides a reliable view of major sending sources.

Use tools like inbox placement testing to validate how your emails are landing post-DMARC setup, and verify your sender infrastructure with a real-time email checker to ensure alignment. If you suspect misdelivery or spoofing, start with proper reporting. You can’t fix what you don’t see.

How to check if sp=none is blocking your reports

If your DMARC aggregate reports aren’t arriving, one likely reason is the sp=none setting in your DMARC policy. This directive disables enforcement for subdomains and, crucially, blocks report generation by design. No reports will be sent unless you change sp=none to sp=reject or sp=quarantine. Check your DNS TXT record to confirm.

Validate your DMARC record

  • Open a public DNS lookup tool like MXToolbox or use the built-in DNS checker in MailTester’s email checker.
  • Enter your domain name and select the TXT record query.
  • Look for the DNS TXT record starting with v=DMARC1;.

Check for the sp=none directive

  • Scan the policy section in the TXT record for sp=none.
  • If present, reports from subdomains are intentionally disabled.
  • Only change this setting if you’re ready to enforce policies on subdomains—otherwise, keep sp=none and accept no reporting.
  • Updates take up to 48 hours to propagate via DNS.

You can verify the correct structure of a DMARC record using the official DMARC specification (Section 6.1), which details how sp and p settings interact.

Setting sp=none isn’t a mistake—it’s a deliberate choice to avoid report load during early DMARC setup. But it means you’ll never see aggregate data unless you update your policy.

Let’s be clear: you can’t fix a missing report by checking your mailbox. If sp=none is active, no reports will be sent—regardless of your mail server configuration. This is by construction, not a delivery failure.

Don’t confuse sp=none with p=none. The former controls subdomain policy enforcement; the latter controls the main domain. If you're monitoring reporting, ensure both are set appropriately. You should only disable reporting when you're not ready to act on findings.

Fixing the issue: how to enable DMARC reporting

If your DMARC aggregate report isn’t being delivered, it’s likely because your policy uses sp=none. This setting tells receivers to take no action on unauthorized mail, but also disables reporting. To fix it, change sp=quarantine or sp=reject in your DNS record, ensure your rua= address is valid and receives mail, and verify the change using DNS tools. Once done, your reports should start flowing within 48 hours, per industry standards.

Update your DMARC policy

  1. Edit your DMARC DNS record to replace sp=none with sp=quarantine or sp=reject. The sp=none setting disables reporting because it signals that you don’t want receivers to act on unauthenticated messages, which includes sending aggregate reports back to you.
  2. Use a DNS validator tool to confirm the change. Tools like DNSChecker.org or MXToolbox let you query your domain’s records in real time. This step ensures your new policy is published and accessible.
  3. Wait 24–48 hours for DNS propagation. Most ISPs and email providers check your DMARC record every few hours, so changes may take time to take effect across the network.

Validate your reporting address and delivery

  1. Confirm your rua= address is correct and active. The address must be a real, monitored inbox—preferably a dedicated one. Use MailTester’s email checker to test if the address is valid and can receive mail.
  2. Check inbox rules and spam folders. Some email providers treat DMARC reports as low-priority. Ensure the reporting email isn't routed to spam or auto-deleted. Test with a synthetic report if your provider allows.
  3. Simulate reporting behavior using a tool like DMARCian or Dmarc.org’s guidance on testing. While no tool reproduces real-world reporting, these help catch misconfigurations early.

Once the policy is active and the reporting address is functional, you should start receiving aggregate reports. Monitoring these helps improve sender reputation, detect impersonation attempts, and confirm that email authentication is working as intended.

What risks come from leaving sp=none in place?

If your DMARC policy includes sp=none, you’re effectively opting out of receiving aggregate reports that show how your domain is being used across the internet. This means you lose visibility into unauthorized senders, phishing attempts, and misconfigurations—making it harder to detect attacks or fix broken workflows. Without reports, you can’t verify whether your domain is being spoofed, even if it’s already under active abuse. Let’s be clear: you’re not protecting your domain if you’re not monitoring it.

Unseen threats: attacks and misconfigurations go undetected

When sp=none is active, you miss out on DMARC aggregate reports that detail who’s sending emails on your behalf. These reports show patterns of unauthorized use—like a spoofed email from @yourcompany.com appearing in a phishing campaign. Without them, you won’t know if attackers are using your domain until a customer reports it. This delays response time and increases risk, especially in industries where data breaches and brand spoofing are common.

You also lose visibility into internal or third-party systems that might be misconfigured. For instance, a forgotten CRM or a compromised vendor tool could be sending mail from your domain. These errors often fly under the radar with sp=none because there’s no feedback loop. You’re essentially blind to what’s happening in your outbound email ecosystem.

Security posture suffers in high-compliance environments

In regulated sectors—finance, healthcare, government—DMARC reporting is often part of compliance frameworks like SOC 2 or ISO 27001. Leaving sp=none can signal a lack of oversight, even if your domain is technically protected. Auditors expect organizations to monitor their brand’s email usage and respond to anomalies. When you don’t receive reports, you can’t demonstrate due diligence.

According to the DMARC specification (RFC 7483), setting sp=none disables reporting for subdomains. That’s a deliberate design choice—but one that trades visibility for convenience. It doesn’t eliminate risk. If you need to know whether your domain is being forged, you must enable reporting. You can test your current setup with a real inbox placement test or verify suspicious addresses through our email checker to detect potential abuse early.

Leaving sp=none isn’t a security policy—it’s a configuration oversight. Fixing it isn’t about punishing senders; it’s about building visibility into your domain’s email activity.

How to verify your domain’s DMARC configuration

You can verify your domain’s DMARC configuration by checking your DNS records for issues like sp=none, missing rua tags, or syntax errors using a tool like MailTester’s real-time verification API. This helps you confirm whether your DMARC policy is correctly set up and capable of generating aggregate reports. Without a proper rua address and a non-sp=none policy, you won’t receive reports — which is why validation matters.

Why sp=none blocks report delivery

When your DMARC policy includes sp=none, it tells receivers to take no action on unauthenticated messages. This means they won’t send aggregate reports to your rua address, even if you’ve set one up. The absence of reports isn’t a failure of the domain — it’s a direct result of your policy setting.

Many domains default to sp=none during initial setup, hoping to avoid false positives. But this prevents you from gathering any feedback on email traffic. You’ll see no data from recipients' mail servers, making it impossible to refine your authentication strategy over time.

Check your record before assuming it works

DMARC records are easy to get wrong — a missing semicolon, an invalid email address in rua, or even a typo in fo can break enforcement. These issues aren’t always obvious from a DNS lookup alone.

Let’s use MailTester’s real-time verification API to check your domain’s DMARC record. It validates the full syntax, checks for known issues like sp=none, and confirms whether your rua tag is correctly formatted and reachable. You don’t need to wait for a report to know if your configuration works.

Unlike third-party report generators that depend on external servers to deliver data, MailTester evaluates the record as it exists in DNS. It gives you immediate feedback on the policy state: whether it’s enforcing, monitoring, or completely passive.

For example, if you’re using DMARC to protect a high-volume sending domain, you need to know right away if your policy allows for reporting. Without that, you’re blind to spoofing attempts or misconfigured authentication. Real-time validation avoids the guesswork.

Learn how to test your domain’s DMARC settings in real time with MailTester’s verification API. It works with any domain, any record, and requires no setup. For broader scanning, the bulk verification tool supports checking multiple domains at once.

DMARC reporting: best practices for ongoing monitoring

If your DMARC aggregate report isn’t being delivered, check your sp=none setting—it disables reporting completely. To receive reports and enforce basic alignment checks, change sp=quarantine or sp=reject. Use a dedicated inbox, review reports weekly, and validate sender authentication for new sources. This keeps threats out and ensures you’re not blind to credential abuse.

Enable reporting with proper policy settings

  • Set sp=quarantine or sp=reject in your DMARC record—sp=none disables reporting entirely, even for aggregate data.
  • Only with sp set to quarantine or reject will receiving domains send DMARC aggregate reports to your specified email address.
  • Use RFC 7483 as a reference—this defines how DMARC policies apply to both aggregate and forensic reporting.

Monitor reports consistently and systematically

  • Route all aggregate reports to a monitored inbox—never rely on general staff emails. A missed report can mean prolonged exposure to spoofing.
  • Review reports weekly. Look for sudden spikes in failure rates, especially from unclaimed domains or unexpected IP addresses.
  • Use tools like inbox placement testing to validate whether your messages land in inboxes or get filtered, even when authentication is correct.
  • Keep a log of new or changing email sources. Even internal departments can become exploited if no one reviews sending behavior.
  • Check alignment results—spf=pass and dkim=pass don’t guarantee deliverability if the domain alignment is broken.
Consistent monitoring turns raw data into actionable insight. Without review, even a perfectly configured DMARC policy is blind.

Don’t wait for a breach. Proactive review of DMARC reports helps you spot anomalies early. Use real-time email verification to clean your list before sending—tools like the MailTester email checker can confirm addresses are valid and not spoofed. Combine that with weekly report checks, and you’re not just securing your domain—you’re reducing risk across your entire email ecosystem.

Does sp=none affect email deliverability or sender reputation?

Setting sp=none doesn’t directly hurt deliverability or sender reputation, but it leaves your domain blind to authentication issues. Without a policy to reject or quarantine forged emails, malicious actors can spoof your address, and you won’t know. Over time, unchecked spoofing can erode domain reputation, especially if mailboxes flag your messages as fraudulent.

Why sp=none delays detection of real problems

DMARC’s purpose isn’t just to block bad mail—it’s to help you see who’s sending as your domain. When sp=none, you receive aggregate reports but no enforcement. That means even if someone spoofs your address, your inbox isn’t protected, and you miss warnings about misconfigurations or compromised accounts. This lack of visibility makes it harder to fix issues before they impact deliverability.

For example, if SPF or DKIM fails across multiple messages and you’re not getting aligned reports, you might not realize your outbound mail is being rejected. That’s time lost catching problems that degrade your sender reputation. The longer you go without data, the more likely your domain’s trust score drops—especially if major providers see patterns of failed authentication.

Let’s be clear: sp=none isn’t a failure. It’s a starting point. But leaving it at that means you’re not using DMARC’s full value. As the IETF’s DMARC specification notes, “The policy can be set to none to allow monitoring without taking action.” That’s useful during setup—but not a long-term strategy.

Over time, unaddressed authentication failures lead to a reputation penalty. Even if you’re sending legitimate email, receiving systems may correlate failed authentication across your domain with spam behavior. Tools like MailTester help reduce that risk by catching invalid or high-risk addresses before they get sent—even if your domain policy is still in monitoring mode.

The real threat isn’t the setting itself, but the complacency it can encourage. No alerts, no enforcement, no visibility—just silence. Eventually, reputation suffers in ways you can’t always track. That’s why even during testing, it’s better to set a policy like sp=quarantine or sp=reject, even if only on a small subset of traffic.

Real-world fix: updating your DMARC record for full visibility

If you’re getting no DMARC aggregate reports, your sp=none setting is likely blocking them. Change it to sp=quarantine in your DMARC TXT record. This allows reporting to be sent, giving you visibility into email traffic and potential spoofing attempts. It’s a simple fix, but it takes effect only after DNS propagation.

Step-by-step: Fixing DMARC reporting with sp=quarantine

  1. Log into your DNS provider’s dashboard. Check your domain’s DNS records via your hosting provider, registrar, or cloud DNS service (like Cloudflare, AWS Route 53, or Google Domains).
  2. Locate your DMARC TXT record. It typically starts with _dmarc.yourdomain.com. Ensure it’s correctly formatted as a TXT record with valid syntax.
  3. Update the sp=none policy. Change sp=none to sp=quarantine or sp=reject if you want stronger enforcement. The sp=none setting disables reporting, which is why you’re receiving no aggregate data.
  4. Save the changes. DNS record updates can take 5 to 15 minutes to propagate globally. Do not assume the change is live immediately.
  5. Verify the new record with a DNS checker. Use MailTester’s DNS checker to confirm the updated DMARC record is properly published and readable across the internet.

Why this matters: Reporting visibility and control

Your domain’s DMARC policy controls not just enforcement, but visibility. When sp=none is set, receivers are not required to send reports—even if they detect issues. This means you’re blind to email traffic that might be spoofing your domain. As the IETF DMARC specification states, setting sp to a non-none value enables the reporting mechanism necessary for monitoring.

While sp=quarantine helps reduce spoofing by marking suspicious emails as suspicious, sp=reject blocks them outright. Start with quarantine if you’re new to DMARC enforcement. Monitor incoming reports for a few days to assess sender behavior before moving to stricter policies.

You can test how your policy affects deliverability using MailTester’s inbox placement tester. This lets you see how real inboxes receive your messages after policy changes, helping you avoid accidental blocklists or delivery issues.

Final takeaway: reporting is a core part of email security

Even if your DMARC policy uses sp=none and doesn’t enforce rejection, enabling reporting gives you visibility into who’s impersonating your domain. This data helps detect phishing attempts and account takeover risks before they scale.

Setting sp=none disables all aggregate reports. Use it only during testing or when you’ve explicitly opted out of reporting. Leaving it permanently active means you're blind to abuse targeting your domain—no matter how strict your policy.

Use tools like MailTester to validate your DMARC record and ensure your domain is properly monitored. Real-time verification helps confirm that both delivery and security configurations are working as intended.

Sources

Keep reading

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

Frequently asked questions

Can I get DMARC reports if sp=none is set?

No. The sp=none directive explicitly disables aggregate reporting. Reports will not be sent, even if a reporting address is listed.

How do I know if my DMARC policy includes sp=none?

Check your DNS TXT record for the DMARC policy. Look for sp=none in the value. Use a public DNS checker or MailTester’s tool to verify.

What happens if I keep sp=none in my DMARC record?

You won't receive any aggregate reports, losing insights into email authentication and potential misuse of your domain.

Does sp=none affect how my emails are delivered?

No. sp=none only affects reporting. It does not change how receivers handle your messages—delivery depends on SPF, DKIM, and policy enforcement.

Can I enable reporting without enforcing DMARC?

Yes. Use sp=quarantine to enable reports while allowing messages to pass. This gives visibility without blocking legitimate emails.

How often should I review DMARC reports?

Review them at least once per week to catch anomalies like new senders, authentication failures, or suspicious patterns.

Is there a way to simulate DMARC reporting?

Not exactly. But you can test your policy with tools like MailTester and use dummy sender domains to trigger report generation in controlled environments.

Why is my domain sending email but not getting reports?

The most common cause is sp=none. You may also have an invalid or unreachable reporting address in the rua tag.

Can I use a disposable email for DMARC reporting?

Avoid it. Disposable addresses may not deliver reports or may fail to receive them. Use a dedicated, monitored inbox instead.

What does a good DMARC record look like?

A properly configured record includes a valid policy (sp=quarantine or sp=reject), a working rua email address, and correct syntax in the DNS TXT record.

How long does it take for DMARC reporting to start after changing sp=none?

After DNS propagation (typically 5–15 minutes), receiving servers begin sending reports to the specified address if the policy now enables reporting.

Does DMARC reporting help with spam filters?

It doesn’t directly affect spam filters. But consistent authentication compliance and report visibility help maintain sender reputation, which impacts inbox placement.