What do DMARC aggregate report fields like source_ip and disposition actually mean?

You’re checking your DMARC aggregate reports, but the fields don’t line up with what you expected. Source_ip shows up as 198.51.100.14, and disposition says "none" — but why? And how does that affect whether your emails land in inboxes or get blocked?

DMARC aggregate reports are XML files sent by mail servers when they receive emails purporting to come from your domain. They tell you who sent what, whether it passed authentication, and whether the mail was accepted, rejected, or quarantined — all without requiring a single bounce.

Understanding fields like source_ip and disposition isn’t just about parsing XML. It’s about diagnosing real sender reputation issues. A single misconfigured IP or a failed authentication chain can appear as repeated reports from a suspicious source.

Key takeaways

  • source_ip indicates the IP address of the mail server that delivered a message claiming to be from your domain, helping identify potential spoofing sources.
  • disposition values (none, quarantine, reject) show how receiving servers handled messages from your domain — critical for spotting authentication failures or policy misconfigurations.
  • DMARC aggregate reports provide actionable data for improving email deliverability and protecting your domain from abuse, but only when you interpret fields like source_ip and disposition correctly.

How does the source_ip field in DMARC reports identify email traffic origins?

The source_ip field in DMARC aggregate reports lists the IP address of the server that attempted to deliver an email using your domain. It’s the primary signal for identifying which systems—whether your own servers, marketing platforms, or third-party services—are sending on your behalf. If you see an IP you don’t recognize, it likely means unauthorized sending or a compromised system.

Mapping Sending Sources with source_ip

Each DMARC report entry includes one or more source_ip entries, allowing you to map traffic back to specific sending sources. For example, if you use SendGrid for marketing emails, you’ll see its IPs in the report—confirming legitimate use. If you see an IP from a country where your business doesn’t operate, that’s a red flag.

Let’s say you run a financial service and your DMARC reports show traffic from an IP in Eastern Europe. That’s not typical. It suggests either a phishing attempt using your domain or an account breach. You can validate legitimacy using tools like MxToolbox’s DNS lookup or RFC 7483, which outlines how DMARC reports are structured.

Spotting Unauthorized or Compromised Senders

Unexpected IPs in source_ip fields don’t always mean fraud—but they do demand investigation. A common scenario: a forgotten CRM integration sending without authentication. Or worse: a credential leak exposing your internal email server.

You can test the integrity of your sender ecosystem with tools like MailTester’s bulk verification or real-time verification API. These help you scrub your list and confirm deliverability, but don’t replace monitoring DMARC reports. The real strength comes from combining both: verify the list’s validity, then watch source_ip patterns over time.

DMARC reports don’t just show who sent—it shows the network path. The source_ip is your first line of defense in spotting anomalies. When you see an unfamiliar IP consistently in reports, investigate that IP’s reputation using Spamhaus or similar services. A history of spam links or high bounce rates can confirm malicious intent.

Why is the count field important in DMARC aggregate reports?

The count field in a DMARC aggregate report tracks how many emails were sent from a specific source IP during the reporting period. High or sudden spikes in count from unexpected IPs can signal misconfigurations, unauthorized access, or phishing campaigns. Monitoring this field helps detect anomalies before they impact sender reputation or user trust.

What high counts from unusual IPs can indicate

When you see a source IP logging unusually high counts—especially if that IP isn’t part of your normal email infrastructure—it’s a red flag. This could mean an email server was misconfigured, credentials were compromised, or a bot is using your domain to send spam. For example, a single IP sending thousands of messages in one hour when your typical volume is under 100 is suspicious.

Let’s say you see an IP listed in your DMARC report that you didn’t authorize. If the count is in the thousands, it’s likely not legitimate. A sudden increase in count, even with a known IP, can indicate a compromised account or a mismanaged third-party sender. That’s why consistent monitoring of the count field lets you catch issues early.

Count as a signal of sender health

Normal email sending should show predictable patterns—steady counts from known IPs over time. Sudden spikes are often tied to automated abuse, like credential stuffing or phishing kits exploiting your domain. The count field is a raw, measurable signal of activity. Correlating it with other data—like source IP reputation from MxToolbox or Spamhaus—strengthens detection.

For instance, an IP with a clean history but a sudden count surge might still be legitimate if it’s a seasonal campaign. But if the IP has a history of spam, the count jump confirms malicious use. The DMARC specification (RFC 7483) uses the count field to provide visibility into sending behavior, which is essential for enforcement and analysis.

Tools like MailTester’s bulk verification can help identify whether the domains in your sending list are still valid and not being abused. Real-time API verification ensures your outbound messages are sent from authorized, clean sources, reducing the risk of being flagged in DMARC reports.

“The count field is a core metric in DMARC reporting because it quantifies the volume of messages tied to a specific source.”

While DMARC aggregate reports don’t replace active monitoring tools, they provide historical data to validate your sending practices. Using tools that align with DMARC standards—like those that help maintain clean sender lists—ensures your reports reflect accurate, trustworthy behavior. This transparency is vital for maintaining inbox placement and long-term deliverability.

What does disposition 'none', 'quarantine', or 'reject' mean in a DMARC report?

Disposition in a DMARC aggregate report tells you how the receiving mail server acted on a message that failed authentication checks. 'None' means the message was delivered normally. 'Quarantine' means it was flagged and sent to spam or a hold folder. 'Reject' means the message was blocked entirely. These values reflect the policy set by the domain’s DMARC record and show how strictly they enforce email authentication.

What each disposition means in practice

Let’s break this down. When a message arrives and the domain has a DMARC policy set to none, the server logs the failure but delivers the email anyway. This is common during DMARC policy rollout — it’s a monitoring phase. You’ll see a lot of 'none' dispositions early on, which is fine. But it means no enforcement is happening yet.

If the policy is set to quarantine, the receiving server considers the email suspicious but doesn’t block it outright. Instead, it often treats it like spam — putting it in the junk folder or applying heavy filtering. This helps reduce the chance that a spoofed email reaches the inbox, but it still allows some delivery, especially if the sender is legitimate.

A reject disposition means the server blocked the message entirely. This happens when SPF or DKIM authentication failed and the domain’s DMARC policy required rejection. It provides the strongest protection against spoofing, but it can disrupt legitimate mail if your authentication setup is misconfigured.

These dispositions come from the DMARC specification (RFC 7483), which defines the behavior that compliant receiving servers should follow. The actual impact depends on both the policy and how well your sending infrastructure aligns with SPF, DKIM, and DMARC.

Use these dispositions to audit your email streams. A high number of failures with 'none' can mean you’re not enforcing security. Too many 'quarantine' or 'reject' events might point to misconfigured sending sources or outdated DNS records. Monitoring this data helps you tighten security without breaking your send flows.

For real-time insight into how your emails are being handled, test your inbox placement and check for authentication flaws. MailTester’s inbox placement tool helps you see how likely a message is to land in spam, while our bulk verification finds invalid or risky email addresses before they harm your sender reputation.

How to interpret a DMARC report with multiple source_ip entries and mixed dispositions

When a DMARC aggregate report shows multiple source_ip entries with differing dispositions—like some marked pass, others fail, or quarantine—it indicates inconsistent email authentication across your sending infrastructure. This isn’t normal. You’re likely sending from a mix of legitimate, verified sources and unauthorized or misconfigured ones. One IP may pass DKIM but fail SPF, leading to a quarantined delivery. Multiple failures across IPs point to systemic issues, such as misconfigured mail servers or incorrect SPF alignment in DNS.

Why mixed dispositions across IPs matter

Each source_ip in a DMARC report represents a unique sender or server. If one IP passes SPF but fails DKIM, the result is a quarantine disposition, meaning the receiving email system may tag your email as suspicious. If you see this pattern consistently—some IPs pass, others fail—it suggests that only part of your email stack is properly authenticated. This can hurt deliverability and increase spam filtering risk over time.

Let’s say your company uses both your primary mail server and a third-party CRM to send emails. If SPF is configured only for the primary server and not the CRM, the CRM’s source_ip will show a fail for SPF. DKIM might pass on one but not the other. The result: a mix of pass, fail, and quarantine dispositions. This is not a rare scenario—it's a common red flag that your outbound email policy needs auditing.

Systemic issues behind consistent failures

Seeing fail or quarantine dispositions across many different source_ips isn’t just about isolated misconfigurations. It signals that your email sending practices aren’t unified. For example, if multiple departments use different tools (like a marketing platform, a support system, or an API-based messaging service), and none properly authenticate, you’ll see widespread failures. This is when DMARC becomes a diagnostic tool: it shows exactly where your email infrastructure is breaking.

A consistent fail across multiple IPs often means the SPF record is too broad, too narrow, or missing entirely for all sending sources. Or DKIM keys are not properly rotated or aligned. In some cases, it points to a forgotten or misconfigured outbound server. RFC 7483, which defines the DMARC specification, notes that aggregates are meant to reveal sender-specific behavior. Use this visibility to audit what’s actually sending your emails.

It’s not enough to know you’re failing. You need to know why. Start by identifying all source_ips in your report and cross-check them against your known sending infrastructure. Then validate SPF alignment, DKIM signing, and DMARC policy enforcement. Tools like MailTester’s bulk verification or API checker can surface similar issues in your email lists—helping you spot bad addresses or unverified senders before they hurt your reputation.

How DMARC disposition affects inbox placement and sender reputation

DMARC disposition tells recipient ISPs how to handle emails that fail authentication. "Reject" means the message is blocked before it lands in the inbox, which protects recipients and maintains sender reputation. "Quarantine" moves suspicious messages to spam, which lowers inbox placement over time if used frequently. If many of your emails are quarantined due to failed authentication, ISPs may lower your sender reputation or add you to blocklists.

Reject disposition: early filtering, better deliverability

When you set DMARC to "reject", any email that fails SPF or DKIM is blocked outright. This is the strictest enforcement and protects your domain from spoofing. Legitimate senders who comply with DMARC see fewer delivery issues because ISPs trust that only authenticated messages get through.

Let’s be clear: DMARC "reject" is not a deliverability tactic—it’s a security enforcement mechanism. But when properly configured, it improves sender reputation by ensuring your brand’s emails are not associated with abuse or spam. ISPs like Gmail and Outlook monitor this behavior closely. When they see consistent "reject" enforcement, your domain is more likely to be trusted, even during periods of high volume or new campaigns.

Quarantine disposition: signal of inconsistency, risk to reputation

Quarantine is less harsh than reject but still signals a problem. When an email fails authentication and is quarantined, it may land in spam folders or be delayed. If this happens often—especially from the same source IP—it raises red flags across multiple ISPs.

For example, if your outbound emails are repeatedly quarantined due to misconfigured SPF or DKIM, ISPs may start treating your domain as high-risk. Over time, this reduces inbox placement scores. Some major email providers use automated systems to track patterns in DMARC reports, and consistent quarantine dispositions from a single IP can lead to reputational damage or even blocklist inclusion.

Use DMARC aggregate reports to identify IPs that trigger quarantines. Check RFC 7489 for the standardized field definitions, including source_ip and disposition. You can verify your domain’s authentication setup in real time using MailTester’s inbox placement testing or verification API.

Don’t ignore DMARC reports just because they’re technical. They’re your first line of defense against spoofed emails and deliverability decline.

How to use DMARC reports to detect unauthorized senders and reduce spoofing risk

You can detect unauthorized senders by regularly reviewing DMARC aggregate reports, focusing on source_ip entries with high count values that lack SPF or DKIM authentication. Any IP not on your authorized list—whether internal, third-party, or shared hosting—should be investigated or blocked to prevent spoofing. This is an industry-standard defense against email-based attacks.

Identify suspicious sender patterns in your DMARC data

  • Scan aggregate reports for source_ip addresses that show high message counts but no valid SPF or DKIM pass results.
  • Prioritize IPs with repeated failures across multiple days—these often indicate automated or compromised systems.
  • Use RFC 7483 as a reference for understanding how DMARC reports structure and report on domain alignment and authentication status.

Validate IPs against your authorized sending infrastructure

  • Compare each suspicious IP with your known sending sources: internal mail servers, marketing platforms like Mailchimp, CRM tools, or shared hosting providers.
  • Look up IPs using public tools like MxToolbox or WHOIS to check if they belong to a known cloud provider or hosting service.
  • If an IP doesn’t match any of your legitimate sources, audit whether it’s a misconfiguration or an actual impersonation attempt.
  • Block unauthorized IPs at the DNS level with strict SPF policies (e.g., using include:_spf.yourdomain.com only for verified senders).
  • Consider using DKIM alignment checks to ensure that even if SPF fails, the message is still validated via DKIM—reducing false positives from legitimate forwarding.
  • For bulk email operations, run your list through a verification tool like MailTester’s bulk verification to remove outdated or invalid addresses before sending.
Unauthorized senders often use IP addresses from cloud providers with weak ownership checks. A high count from a single unknown IP is a red flag.

DMARC reports don’t just protect your domain—they give you a real-time view of who’s trying to send as you. By routinely checking counts per source_ip and cross-referencing them, you close gaps that attackers exploit. The key is consistency: make this part of your weekly security review, not a one-time audit.

How DMARC data helps refine SPF, DKIM, and DMARC policy settings

DMARC aggregate reports reveal which source IPs are triggering 'quarantine' or 'reject' dispositions, helping you audit SPF and DKIM alignment. If a legitimate sender's IP consistently fails, check records for misalignment. Once all valid senders authenticate, gradually tighten your DMARC policy from 'none' to 'quarantine' and finally 'reject'—only after confirming no legitimate email is blocked. Use the report's source_ip count and disposition data as your guide.

Use DMARC reports to validate your authentication setup

  • Check the source_ip count in aggregate reports to identify which IPs are sending emails on your behalf.
  • If a specific source_ip shows frequent disposition=quarantine, verify SPF and DKIM alignment for that sender.
  • Use RFC 7483 to confirm how DMARC interprets policy and disposition outcomes.
  • If SPF fails but DKIM passes, your sender list might be missing from SPF records—update them to include authorized IPs.
  • If both SPF and DKIM fail, the mail is likely unauthorized or misconfigured—trace the sender to its source.

Adjust policies based on validated data

  • Never move from policy=none to quarantine or reject without reviewing all reported source IPs and their disposition outcomes.
  • After confirming all legitimate senders authenticate correctly, test policy=quarantine for a few weeks to monitor inbox placement without blocking emails.
  • Only after confirming no false positives (legitimate emails being quarantined), increase policy to reject to block unauthorized mail.
  • Monitor the reports weekly—new IPs or systems may appear. Treat DMARC not as a one-time fix, but as an ongoing verification loop.
  • Use MailTester's bulk verification to pre-validate sender lists and reduce false fails in reports.
Alignment is not optional—it's how DMARC decides trust. A single misaligned SPF or DKIM can break your reputation, even if your domain is otherwise secure.

Remember: DMARC data isn't about spotting threats. It's about confirming who's allowed to send for you. The source_ip count and disposition field are your audit trail. The more accurate your SPF and DKIM, the cleaner your DMARC policy can become.

How to validate your DMARC configuration using MailTester’s deliverability testing

You can validate your DMARC configuration by testing how your domain’s authentication policies are interpreted across real inboxes in Gmail, Outlook, and Yahoo. MailTester’s inbox-placement testing simulates actual email routing, checking SPF, DKIM, and DMARC results, including the source_ip count and disposition field, before you deploy changes at scale.

Test real-world email routing before deployment

Let’s say you’re tightening your DMARC policy from none to quarantine or reject. Before rolling it out, use MailTester’s inbox-placement test to see how your messages are handled across major ISPs. This reveals whether your configuration is causing legitimate emails to be rejected due to misaligned authentication, even if you’ve set up SPF and DKIM correctly.

The tool checks the source_ip field in DMARC aggregate reports, showing which IPs sent mail for your domain and whether those IPs were authenticated. A rise in unexpected source IPs can flag spoofing or compromised systems. The disposition field—indicating whether messages were accepted, quarantined, or rejected—is also evaluated in real inboxes, giving you a clear signal about how your domain is being treated.

MailTester doesn’t just validate your setup in theory—it tests it in practice. By mimicking real email delivery chains, it identifies how often messages land in spam, get filtered, or fail due to DMARC policy mismatches. This is especially useful for detecting unintended consequences like legitimate transactional emails being blocked when DKIM fails due to content changes.

How the data helps you decide

When you review the results, look for patterns. A high number of disposition=quarantine or reject entries with no apparent reason suggests misconfiguration. If the source_ip count spikes unexpectedly, you might have a poorly managed third-party sender or a forgotten service sending through unauthenticated IPs.

These insights help you refine your alignment between SPF, DKIM, and DMARC records—especially when using multiple senders or services. According to RFC 7483, DMARC is designed to provide a feedback loop for domain owners; MailTester makes that data actionable before it hurts your sender reputation.

For high-volume senders, you can use the inbox placement tester to pre-validate DMARC changes across multiple domains. If you're integrating with tools like SendGrid or Mailchimp, check how your configurations hold up under real ISP scrutiny—especially if you’re using shared IPs.

Use MailTester’s API to automate checks during deployment pipelines, or bulk verify sender IPs and domains ahead of policy rollouts. With 98.9% accuracy, it’s a reliable way to close the loop between policy and real inbox behavior.

What’s the role of email verification in cleaning up sender lists and improving DMARC compliance?

You can improve DMARC compliance by verifying every email address before sending. Invalid or role-based addresses often lack proper DNS records or send from inconsistent identities, triggering authentication failures. By filtering out these addresses with a tool like MailTester, you reduce false positive reports and keep DMARC aggregate data focused on real threats, not noise from dead or misconfigured inboxes.

Why unverified addresses hurt DMARC visibility

DMARC relies on consistent, authenticated email flow. When you send to addresses that don’t exist or are role accounts (like support@ or admin@), the receiving server may reject the message or mark it as unauthorized — even if the sender is legitimate. These failed attempts show up in DMARC reports as fail or quarantine results, inflating the number of perceived threats and making it harder to spot real spoofing attempts.

Many role accounts lack proper SPF or DKIM records. If your sending infrastructure is inconsistent across domains or IPs, those gaps appear in DMARC reports as ambiguous or failing policies. This noise dilutes real signals — like domain impersonation — and makes report analysis less effective. The result? A skewed view of sender health, which can delay response to legitimate abuse.

How verification reduces spoofing signals and sharpens DMARC data

Let’s say you’re sending promotional content to a list of 50,000 addresses. Without verification, 10–20% might be invalid, role-based, or disposable. Even a small subset of these failing authentication can cause repeated DMARC failures, especially if they’re sent from a single sender IP with mismatched records.

Using MailTester to verify your list before sending lets you exclude addresses that won’t authenticate, including those with incomplete DNS configurations or no mailbox. This means only deliverable, properly configured inboxes receive your email. The outcome? Cleaner DMARC reports with fewer false alarms, and a more accurate picture of whether your domain is being spoofed.

For example, RFC 7483 defines how DMARC aggregates data by source IP and disposition. When your list is clean, each source_ip in the report reflects an actual delivery attempt from a valid sender — not a flood of failed messages from invalid addresses. That clarity means you can trust the disposition field to reflect real policy enforcement, not noise.

Start with a free verification to test your list’s health. Use the bulk verification tool to clean your list before campaigns, or integrate the real-time API into your workflows. If you’re unsure about inbox placement, test delivery across major providers to ensure your verified senders land where they should. With accurate data, DMARC becomes a real tool for security, not a source of confusion.

Summary: Mastering DMARC aggregate reports improves inbox placement and sender trust

The source_ip, count, and disposition fields in DMARC aggregate reports reveal what’s actually happening with your email streams. They show which IPs are sending mail on your behalf, the volume of messages, and whether they passed or failed authentication.

Monitoring these fields helps identify unauthorized senders, reduce spoofing risks, and confirm that your SPF, DKIM, and DMARC configurations are working as intended. Over time, consistent alignment across these metrics strengthens your sender reputation and improves inbox placement.

Tools like MailTester allow you to test and verify your email infrastructure in real-world conditions before reaching real recipients. You can validate configurations and catch issues early, reducing the risk of delivery failures and reputation damage.

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 a high count for a source_ip in a DMARC report mean?

A high count indicates many messages were sent from that IP during the reporting period. If the IP is not authorized, it may signal spoofing or misconfigured mail servers.

Can a 'quarantine' disposition in a DMARC report be due to DMARC policy settings?

Yes. The disposition reflects the enforcement level set by the receiving server’s policy. 'Quarantine' means messages are marked as suspicious, not blocked outright.

How often should I review my DMARC aggregate reports?

Review reports weekly during initial DMARC setup; monthly thereafter, especially after changes to email infrastructure or sending practices.

Is DMARC report disposition 'none' safe for sending?

It is safe only during the detection phase. It means no enforcement is applied. Once DMARC is enforced, messages must pass SPF and DKIM to avoid rejection.

Can role addresses affect my DMARC report data?

Yes. Role addresses (like admin@, sales@) often lack proper authentication metadata and may generate false spikes in source_ip count or inconsistent dispositions.

How do greylisted IPs appear in DMARC reports?

Greylisting itself doesn't appear in DMARC reports. However, repeated delivery attempts from greylisted IPs may increase count values, suggesting retries or poor sender reliability.

Can disposable domains cause DMARC disposition issues?

Disposable domains may fail DMARC checks due to missing or misconfigured records. Their use can also indicate risk-prone senders, affecting your sender reputation.

How do catch-all email addresses distort DMARC reports?

Catch-all addresses accept all emails, including those from unauthorized IPs. This can skew count data and increase false positives in DMARC analysis.

What is the most common reason for inconsistent dispositions across source_ip addresses?

Inconsistent authentication (SPF/DKIM) alignment or incomplete SPF record coverage across all sending systems.

Can DMARC reports detect phishing attacks?

Not directly, but they expose unauthorized use of your domain. High counts from unknown IPs with failed authentication flag potential phishing activity for review.