Getting Started With DMARC Digests: Configure, Read, and Use RUA Reports

DMARC digests give you the evidence needed to protect a sending domain without accidentally blocking legitimate mail. By receiving and reviewing DMARC aggregate reports before changing policy, you can identify every authorized sender, fix alignment problems, and spot impersonation attempts.

What are DMARC digests?

“DMARC digests” is an informal name for the recurring summary reports generated by participating mailbox providers after they evaluate mail that claims to come from your domain. The formal name is DMARC aggregate reports, and the reporting destination is usually configured with the rua tag in your DMARC DNS record.

A digest is not a delivery log from your email provider. It is feedback from receiving organizations: mailbox providers, corporate mail gateways, and other systems that received messages using your domain in the visible From: header. Each report summarizes a reporting period, commonly a day, and groups mail by source IP address and authentication outcome.

That distinction matters. Your transactional email provider may tell you that an API request returned HTTP 202 Accepted, or that its SMTP relay returned 250 2.0.0 Ok. Those responses generally mean the provider accepted the message for processing; they do not prove that every recipient mailbox accepted the message or that DMARC passed. DMARC digests add an independent view from the receiving side.

The reports are machine-readable XML, normally delivered as email attachments. You may receive them as .xml, .xml.gz, or sometimes as compressed archives, depending on the reporting organization. A single report can look intimidating because it includes timestamps, source IPs, message counts, SPF results, DKIM results, policy information, and disposition data. Fortunately, the first goal is not to read every XML element. It is to answer a short list of operational questions:

1. Which systems are sending mail that uses our domain in From:?
2. Which of those systems pass DMARC?
3. Are failures caused by SPF, DKIM, alignment, forwarding, or unauthorized use?
4. Could a stricter DMARC policy disrupt any legitimate message stream?
5. Are impersonation attempts increasing, changing source networks, or targeting a particular subdomain?

DMARC itself is a domain-level authentication and policy mechanism. It evaluates whether the visible From: domain aligns with an authenticated SPF identity, an authenticated DKIM identity, or both. A message can pass DMARC when either SPF or DKIM passes and aligns with the From: domain under the domain’s configured alignment mode.

Why DMARC digests matter for transactional email

Transactional email is often more distributed than a team realizes. A company may send password resets through an application email API, invoices through billing software, support notifications through a help desk, account alerts through a monitoring service, and employee mail through a workspace provider. All of those streams may use the same organizational domain.

Without DMARC digests, an organization commonly discovers a forgotten sender only after it publishes p=quarantine or p=reject and important mail starts landing in spam or failing. With reports, you can build the sender inventory first.

The reports expose gaps between intent and implementation

A team may believe that all application mail is sent through one transactional provider. The data might reveal a second source: a legacy application using a cloud VM, a CRM export tool, or a third-party platform with an unconfigured custom domain. A source is not automatically malicious merely because it is unfamiliar, but it requires investigation before you enforce a stronger policy.

The inverse is also valuable. A report can show thousands of messages from an unknown IP range failing both SPF and DKIM while using your domain in From:. That is a strong signal of spoofing or an unauthorized system. A monitoring policy does not block it, but the reports show you what a later quarantine or reject policy is designed to address.

DMARC is now part of normal sending hygiene

DMARC is no longer only a security project for large brands. Gmail’s sender requirements state that bulk senders sending more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC; Google permits a DMARC policy of p=none for that requirement. Even if your volumes are lower, authentication and alignment support more predictable delivery and reduce the chance that others can impersonate your domain.

For developers, the practical lesson is simple: treat DMARC reporting as observability for email identity. Application logs tell you that your service attempted a send. Provider event webhooks may tell you about acceptance, bounces, or complaints. DMARC aggregate reports tell you how recipient-side systems evaluated the sender identity at scale.

The authentication concepts behind a DMARC digest

Before configuring reports, separate the three mechanisms that appear in them.

SPF validates an SMTP envelope identity

Sender Policy Framework, or SPF, publishes which services are permitted to send mail for a domain used in the SMTP envelope sender, also called MAIL FROM, Return-Path, or bounce domain. A typical SPF record is a DNS TXT record such as:

example.com. TXT "v=spf1 include:spf.transactional-provider.example -all"

The exact include: mechanism is provider-specific. Do not copy a generic include value into production. Use the value documented by the service that actually sends your mail, and ensure you have only one SPF TXT record for a given domain.

SPF can pass while DMARC fails. For DMARC purposes, the SPF-authenticated domain must also align with the visible From: domain. Under relaxed alignment, bounce.mail.example.com can align with example.com because they share the same organizational domain. Under strict alignment, the domains must match exactly.

DKIM validates a signed message identity

DomainKeys Identified Mail, or DKIM, signs selected headers and body content using a private key held by the sending system. The recipient retrieves a public key from DNS using the selector and domain in the DKIM-Signature header.

A DKIM DNS record often resembles this:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Again, the selector name and public key must come from your sender or key-management process. DKIM passes DMARC only when the signing domain in d= aligns with the visible From: domain. For example, a message with From: receipts@example.com and d=example.com is aligned. A message signed with d=provider.example may have a valid DKIM signature but will not provide aligned DKIM for example.com.

DKIM is especially important in transactional email because it usually survives ordinary forwarding better than SPF. A forwarder can change the SMTP path and cause SPF to fail, while a correctly preserved DKIM signature can still validate.

DMARC adds alignment and a published policy

DMARC checks the domain in the RFC 5322 From: header—the address recipients see. It then asks whether SPF or DKIM passed and aligned with that visible domain. The domain owner publishes a DNS TXT record at _dmarc.

A minimal monitoring record is:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The required version tag is v=DMARC1. The p tag tells receivers the requested handling for mail that fails DMARC. The rua tag asks receivers to send aggregate feedback to the specified URI, usually a mailto: address.

DMARC policy is a request, not a magical global enforcement switch. Receivers make their own delivery decisions and may apply local anti-abuse signals. Still, the policy gives participating receivers a clear domain-owner preference and lets you request reporting data to measure the consequences of stronger enforcement.

Set up a mailbox for DMARC aggregate reports

Use a dedicated mailbox or a reporting service rather than a personal inbox. Aggregate reports can arrive from many reporting organizations, are usually compressed attachments, and can become noisy as your email volume and recipient diversity increase.

A simple first-party destination might be:

rua=mailto:dmarc-reports@example.com

Create the mailbox before publishing the record. It should be monitored by someone responsible for email authentication, deliverability, or security—not merely created and forgotten. If your mail system supports it, consider routing the reports to a shared mailbox, ticket queue, archive, or automated parser.

Choose direct delivery or a reporting platform

You have two reasonable approaches.

Direct mailbox delivery is useful when you are starting out, have modest volume, and want to understand the raw data. It keeps the report destination under your domain and avoids third-party report-destination authorization. The drawback is that someone or something must parse attachments and turn them into an actionable view.

A DMARC reporting platform receives and parses aggregate XML, groups sources, resolves IP ownership, tracks trends, and often provides workflow features. This can be useful when you manage multiple domains, send at scale, or need a shared operational view. If you select this route, confirm exactly which rua value and any authorization DNS record the platform requires.

Do not assume every mailbox provider sends a report every day. DMARC reporting is requested by the domain owner, but report generation and delivery remain receiver behavior. Some receivers report regularly; some report selectively; some may aggregate data differently. An absence of a report from one receiver is not proof that it received no mail.

Be cautious with report attachments

DMARC reports are data files received over email. Treat them as untrusted input even when they appear to come from familiar organizations. Do not enable macros, execute attached files, or build an ingestion pipeline that blindly trusts attachment names or XML content.

A safe ingestion process should:

• Restrict accepted file types and sizes.
• Decompress archives with resource limits to reduce archive-bomb risk.
• Validate XML safely and disable dangerous external entity processing.
• Keep the original attachment and metadata for auditability.
• Normalize source IP addresses and domains before enrichment.
• Separate report parsing from systems that hold production credentials.

Publish your first DMARC record

For most organizations beginning DMARC monitoring, start with p=none. This asks receivers to send reports but does not request quarantine or rejection for DMARC failures.

Use this baseline record, replacing example.com with your own domain:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DNS dashboards present record names differently. If your DNS provider automatically appends the zone name, enter _dmarc rather than _dmarc.example.com. If it expects a fully qualified record name, use _dmarc.example.com. Check the provider’s conventions and validate the result after publishing.

Add useful tags deliberately

A more explicit monitoring record can be:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

These tags mean:

• v=DMARC1: identifies the record as a DMARC record.
• p=none: requests monitoring only for mail that fails DMARC.
• rua=mailto:...: requests aggregate reports at that address.
• adkim=r: uses relaxed DKIM alignment. This is the default if omitted.
• aspf=r: uses relaxed SPF alignment. This is also the default if omitted.
• pct=100: asks that the policy apply to 100% of messages. This is the default if omitted.

Relaxed alignment is usually the right starting point. It allows a subdomain of your organizational domain to align. For example, mail.example.com can align with example.com under relaxed mode. Strict alignment, specified with adkim=s or aspf=s, requires exact domain matches and can break legitimate configurations unless every sender is intentionally designed for it.

You may also see sp used for subdomain policy:

_dmarc.example.com. TXT "v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@example.com"

The sp tag states a requested policy for subdomains that do not publish their own DMARC record. It is useful when subdomain behavior needs separate treatment, but it is not necessary for a first monitoring deployment.

Verify the published DNS record

After DNS propagation, query the record from a terminal:

dig +short TXT _dmarc.example.com

On Windows, you can use:

nslookup -type=TXT _dmarc.example.com

You can also inspect the record with tools such as MXToolbox. Confirm that there is one valid DMARC record at the expected hostname, that it begins with v=DMARC1, and that the rua address is spelled correctly.

A DNS lookup may display quoted strings or split a long TXT value across multiple strings. That is normal DNS presentation behavior; resolvers concatenate the strings. What matters is the final logical value of the record.

How external DMARC report destinations work

Using a reporting address on your own domain is the simplest option. For example, dmarc-reports@example.com is an internal destination for a DMARC record at _dmarc.example.com because both use the same organizational domain.

An external destination is different:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@reports.example.net"

Here, reports.example.net is not within the example.com organizational domain. DMARC includes a destination-authorization mechanism to prevent someone from directing large volumes of reports to an unrelated third party.

The receiving destination domain must publish an authorization record. The conventional form is:

example.com._report._dmarc.reports.example.net. TXT "v=DMARC1"

In this example, the operator of reports.example.net authorizes it to receive aggregate reports about example.com. If you use a DMARC analytics provider, the provider should give you the exact hostname and value to publish. Do not improvise this record: report-destination authorization is sensitive to the source policy domain and destination domain.

A common symptom of missing authorization is that the DMARC record looks valid but aggregate reports never arrive at the external address. Another common mistake is publishing the authorization record in the wrong DNS zone. The authorization record belongs under the destination domain’s DNS, not under the policy domain alone.

If you operate both domains, you can publish and verify the record yourself. If a vendor operates the destination domain, its service should already have the destination-side authorization capability or provide setup instructions. Ask the vendor whether it supports aggregate reports only, whether it retains raw XML, and how it protects report data, which can include source IP addresses and sending-domain information.

What you will receive in a DMARC digest

Aggregate reports generally contain a metadata section, published-policy information, and one or more message records. A simplified example looks like this:

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>dmarc-noreply@receiver.example</email>
    <date_range>
      <begin>1761955200</begin>
      <end>1762041600</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>120</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The timestamp values in date_range are Unix epoch times in UTC. The report covers a period, not necessarily a calendar day in your local time zone. When comparing reports, normalize dates to UTC and be aware that a receiver may submit a report later than the period it describes.

Read the high-value fields first

Start with these fields:

• source_ip: the source address observed by the reporting receiver. This is often your provider’s outbound IP, but it may also reveal an internal server, a forwarding path, or an unauthorized sender.
• count: how many messages fit this group. Prioritize large counts first because they have the greatest impact.
• header_from: the visible domain used in the message From: header. This is the domain DMARC protects.
• policy_evaluated: the receiver’s DMARC evaluation outcome, including SPF and DKIM alignment results and the applied disposition.
• auth_results: underlying SPF and DKIM authentication results, including the domains used for each mechanism.
• disposition: the action the receiver reports applying, such as none, quarantine, or reject.

Do not confuse the count with a precise count of unique recipients, unique emails, or successful inbox placements. It is the number of messages in that record grouping for that reporting receiver and time period. It is excellent for prioritization and trend analysis, but it is not a complete replacement for delivery events, bounce logs, or provider analytics.

Understand pass, fail, and alignment

A message normally passes DMARC if at least one mechanism passes and aligns:

This table explains a frequent surprise: SPF and DKIM may both show a technical pass, yet DMARC may still fail if neither authenticated domain aligns with the visible From: domain.

For example, imagine a service sends From: alerts@example.com, uses MAIL FROM bounce@provider.example, and signs DKIM with d=provider.example. SPF might pass for provider.example, and DKIM might pass for provider.example, but neither aligns with example.com. The fix is typically to configure a custom bounce domain, an aligned DKIM signing domain, or both through the sending provider.

A practical workflow for reviewing DMARC digests

Do not rush from a new p=none record to enforcement after a single clean-looking report. The purpose of monitoring is to capture recurring mail, infrequent billing cycles, seasonal campaigns, manually triggered exports, and disaster-recovery paths.

A practical initial monitoring period is often several weeks, with longer observation for domains that have numerous vendors or irregular sending patterns. The right duration depends on your organization, but the decision should be based on evidence rather than an arbitrary date.

Step 1: Build a sender inventory

Create a table with these columns:

Enrich source IPs carefully. IP reputation and ownership databases can help identify an ASN or cloud provider, but an IP address alone does not prove who owns a particular email stream. Confirm against internal configuration, provider account settings, message headers, and vendor documentation.

Step 2: Classify every source

Classify each source into one of three buckets:

1. Authorized and aligned: expected source, DMARC passes. Keep monitoring for changes.
2. Authorized but failing: known service, but SPF or DKIM is not aligned. Fix configuration before enforcement.
3. Unauthorized or unknown: no legitimate business owner can confirm it. Preserve evidence, monitor volume, and prepare for policy enforcement.

Do not add unknown IP addresses to SPF merely to make a report go green. SPF is an authorization statement. Adding an unverified server can turn an investigation finding into a permanent security gap.

Step 3: Fix alignment at the source

For an authorized transactional provider, the ideal configuration is typically:

• A visible From: address at a domain you control, such as notifications@example.com.
• DKIM signatures using your domain or an aligned subdomain, such as d=example.com or d=mail.example.com under relaxed alignment.
• An aligned custom return-path or bounce domain for SPF where the provider supports it.
• DNS records published exactly as the provider requests.
• A test message reviewed in a real mailbox for Authentication-Results headers.

Whether you send via an HTTP endpoint or an SMTP relay, these identity requirements are the same. Your application should make the From: domain an intentional configuration value, not an arbitrary user-provided string. If your email infrastructure supports both REST API and SMTP relay delivery, use the same authenticated sender domain across both paths where possible. For implementation details, consult your provider’s email API reference and setup guides.

Step 4: Verify with test messages and headers

Send test mail to a mailbox you control and inspect the full message headers. Look for an Authentication-Results: header showing results similar to:

spf=pass smtp.mailfrom=bounce.example.com
dkim=pass header.d=example.com
dmarc=pass header.from=example.com

The exact header format varies by recipient system. What matters is that dmarc=pass is present and the authenticated domain supplying the pass is aligned with the visible From: domain.

Tools such as mail-tester.com can help inspect a test message for common authentication and content issues. MXToolbox can help inspect public DNS records. These tools are useful checks, but they do not replace aggregate reports because a single test message cannot represent every sending service, IP pool, routing path, or recipient environment.

Move from monitoring to enforcement safely

DMARC policy has three common values:

p=none
p=quarantine
p=reject

p=none requests monitoring only. p=quarantine asks receivers to treat failing mail suspiciously, often by placing it in spam or junk. p=reject asks receivers to reject mail that fails DMARC during SMTP handling.

The goal is not to reach p=reject as quickly as possible. The goal is to reach a policy that protects the domain without disrupting legitimate communication.

A staged enforcement plan

A cautious sequence looks like this:

1. Publish p=none with an aggregate-report destination.
2. Inventory all high-volume and low-volume senders from the reports.
3. Correct SPF/DKIM alignment for every legitimate stream that uses the protected domain.
4. Confirm fixes through message headers and later aggregate reports.
5. Move to p=quarantine; pct=25 if your operational risk supports a gradual rollout.
6. Increase pct as monitoring remains clean: 50, then 75, then 100.
7. Move to p=reject only after you have sustained confidence that legitimate mail passes.

For example:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Later, after validation:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

The pct tag is a rollout control, not a substitute for fixing known failures. It can reduce blast radius while you validate a transition, but it does not provide a clean guarantee that a particular message will or will not receive the requested policy treatment.

Watch for indirect mail flows

Forwarding, mailing lists, ticketing systems, and security gateways can change mail after it is sent. SPF is particularly vulnerable to forwarding because the forwarder’s IP may not be authorized by the original sender’s SPF record. DKIM can survive forwarding when signed content remains unchanged, but mailing lists sometimes modify the subject line, footer, or body and invalidate DKIM.

This is why a healthy DMARC deployment should ensure that legitimate direct mail has aligned DKIM, not only aligned SPF. It is also why a report showing SPF failure does not automatically mean your own sending infrastructure is broken. Examine whether DKIM passed and aligned, whether the source is a known forwarder, and whether the report volume is material.

Common DMARC digest problems and how to troubleshoot them

“I published rua, but no reports arrive”

First, verify the DNS record with dig or nslookup. Check that the record is at _dmarc.example.com, begins with v=DMARC1, and has a syntactically valid rua=mailto: URI.

Then confirm that the reporting mailbox can receive external email and does not reject compressed attachments. Review spam and quarantine folders. If the destination is external, validate the destination-authorization DNS record. Finally, remember that reports are receiver-generated; you may need real mail volume and time before reports begin to appear.

“SPF passes, but DMARC fails”

Inspect the SPF domain in the report or in message headers. It may be the provider’s return-path domain instead of your visible From: domain. Configure a custom bounce domain if your provider supports one, or rely on aligned DKIM while you evaluate whether aligned SPF is needed for your architecture.

Do not change the visible From: address to a provider-owned domain just to make alignment pass. That can weaken brand consistency, complicate replies, and make later migration harder. Prefer authenticating a domain you control.

“DKIM passes, but DMARC fails”

A valid signature may use an unaligned d= domain. Check the DKIM result’s domain value. If it is a provider domain, look for the provider’s custom DKIM or domain-authentication setup. This commonly requires publishing one or more CNAME or TXT records supplied by the provider.

Also check whether the sending system is rewriting the message after signing it. Modifying signed headers or body content can cause DKIM to fail at receivers. Common causes include downstream gateways that add footers, mailing-list processors, or incorrectly ordered signing and transformation steps.

“Reports show an unknown IP address”

Do not immediately assume compromise, and do not immediately authorize it. Identify the volume, header_from domain, SPF result, DKIM result, and policy evaluation. Compare it with known vendors, old infrastructure, and application logs.

If no owner can verify the source, treat it as unauthorized. A monitoring policy gives you visibility; a stricter policy is what reduces the value of this kind of spoofing to attackers. Keep an eye on whether the source is isolated or recurring, whether it targets a specific subdomain, and whether its volume changes after policy changes.

“My provider says delivery succeeded, but DMARC reports show failures”

The two systems are reporting different stages. An HTTP 2xx result or SMTP 250 result from your provider generally indicates acceptance by that provider. A DMARC result represents recipient-side authentication evaluation. Both can be true: the provider accepted and sent the message, while a receiver later found that the visible From: domain did not align with SPF or DKIM.

Use provider delivery events, message IDs, raw headers, and DMARC reports together. They form a more complete chain: application request, provider acceptance, recipient-side authentication, and recipient outcome.

Operating DMARC reporting as an ongoing practice

DMARC is not a one-time DNS task. Sending systems change: engineers introduce new services, vendors modify IP pools, domains are acquired or retired, and teams create subdomains for new products. A strict policy can remain healthy only if sender identity is part of normal change management.

Add DMARC checks to deployment and vendor onboarding

When a new application, SaaS tool, or provider needs to send as your domain, require answers to these questions before launch:

• What will the visible From: domain be?
• Which domain appears in the SMTP envelope sender or return path?
• Which domain appears in the DKIM d= value?
• Does the provider support custom DKIM and a custom bounce domain?
• Which DNS records are required, and who will publish them?
• How will the team verify dmarc=pass using actual received headers?
• Who owns ongoing monitoring if the service changes?

This process is especially useful for teams that use multiple sending paths. A product may send high-volume receipts through an API while a legacy job sends alerts through SMTP. Both should be documented, authenticated, and visible in reports.

Track meaningful metrics, not only a pass percentage

A high DMARC pass rate is desirable, but it can hide important issues. Track the distribution of sources and failures, not just a single percentage.

Useful operational metrics include:

• Total aligned DMARC pass volume by sending stream.
• Authorized-but-failing volume by vendor or application owner.
• Unknown-source volume using the primary domain and each important subdomain.
• Number of new sending IPs or DKIM domains per week.
• Volume of mail receiving quarantine or reject disposition after policy changes.
• Time to investigate and resolve a new unauthorized source.

A 99.9% pass rate may still be unacceptable if the failing 0.1% contains password-reset or invoice mail. Conversely, a small amount of spoofing might be expected under p=none and becomes less consequential once enforcement is safely in place. Context matters.

Keep DNS ownership clear

Many DMARC incidents are ownership problems rather than technical mysteries. The security team owns the policy, engineering owns an application, marketing owns a campaign platform, and IT owns DNS. No one owns the end-to-end identity relationship.

Document the authoritative DNS account, the mailbox or platform receiving reports, the domain owner for each sending stream, and the approval process for adding sending services. When a vendor is retired, remove its DNS authentication records only after confirming no legitimate traffic remains.

FAQ

What is the difference between DMARC digests and DMARC forensic reports?

DMARC digests usually mean aggregate (rua) reports: periodic XML summaries grouped by source and result. Forensic or failure reports are per-message reports associated with ruf, but they are much less consistently generated and can raise privacy concerns. For most teams, aggregate reporting is the practical starting point.

How long does it take to receive DMARC aggregate reports?

Many reports arrive daily, but timing varies by receiver. After publishing a valid record and sending real mail, allow several days before assuming a setup problem. If you use an external rua destination, verify destination authorization as well.

Can a message pass DMARC if SPF fails?

Yes. DMARC can pass when DKIM passes and aligns with the visible From: domain, even if SPF fails. The reverse is also true: aligned SPF can produce a DMARC pass when DKIM fails.

Should I start with p=reject?

Usually no. Start with p=none, collect digests, identify legitimate senders, and fix alignment first. Move through quarantine and reject only when the report data shows that essential mail is consistently passing.

Do DMARC reports prove an email reached the inbox?

No. Aggregate reports describe authentication and policy evaluation from reporting receivers. They do not guarantee inbox placement, open rates, or recipient-level delivery. Combine them with provider delivery events, bounce data, complaint data, and message-header testing.