The number is obtainable. It is simply harder to get right than it looks, and almost every way of getting it wrong makes it bigger — which is the direction that sells alarm.

Start with the most widely deployed include there is:

google.com        v=spf1 include:_spf.google.com ~all

_spf.google.com   v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17
                  ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56
                  ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56
                  ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all

Resolved August 2026. Provider ranges change without notice — resolve your own rather than trusting any number printed in an article, including this one.

The IPv4 half is school arithmetic. A /16 is 2¹⁶ = 65,536 addresses, a /17 is 32,768. Together: 98,304 addresses entitled to send mail carrying that domain.

Then there is the IPv6 half, and this is where a count that looked easy starts lying. Six blocks. We will come back to them.

That was a simple record — one include, two IPv4 literals, no dynamic mechanisms. Here are the four ways the count goes wrong on everything else.

Rule 1: ip4: and ip6: are not the whole record

Some mechanisms do not carry addresses. They carry instructions for finding addresses, executed at the moment a message arrives.

_spf.salesforce.com   v=spf1 exists:%{i}._spf.mta.salesforce.com -all

Count the ip4: mechanisms in that record: zero. A tool that counts literals will report that this provider authorizes nothing at all — a number that is not merely imprecise but backwards.

What the record actually says is this. exists: builds a domain name out of the connecting IP address (%{i} is the macro for it), looks up an A record at that name, and authorizes the sender if one exists (RFC 7208 §5.7). Authorization is a per-address question, answered by a DNS zone you have no way to list. I tried it with a documentation address — 192.0.2.1._spf.mta.salesforce.com returns NXDOMAIN, so that one is not authorized — but establishing the full set would mean asking the question 4.3 billion times.

a, mx and ptr have the same shape: resolved at evaluation time, against records that can change between one message and the next. (ptr is a special case — RFC 7208 §5.5 is titled “ptr” (do not use) and says the mechanism should not be published. If you find one in your own record, that is a finding in itself.)

So an honest count does two things at once: it totals the literals, and it declares the mechanisms it could not enumerate. What comes out is a floor, never a total. A number that quietly omits the third kind is not a measurement.

Rule 2: IPv4 and IPv6 do not add up

Back to those six IPv6 blocks. Take a bigger example — Microsoft 365’s sending infrastructure, which publishes both families:

spf.protection.outlook.com
  v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15
         ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17
         ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49
         ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51
         ip6:2a01:111:f403:f000::/52 -all

The IPv4 side totals 458,752 addresses. Now the IPv6 side: a single /48 holds 2⁸⁰ addresses, and the five blocks together come to roughly 2.19 × 10²⁴.

Add the two halves and you get 2.19 × 10²⁴ — the same figure. The 458,752 IPv4 addresses do not survive the rounding; they are eighteen orders of magnitude too small to appear. A combined total is not a big number, it is the IPv6 number wearing a disguise, and the part an operator can actually reason about has been erased to produce it.

So: count IPv4 addresses, count IPv6 blocks, and never publish one figure for both. Anyone who tells you your SPF authorizes seventy-nine quintillion addresses has added the two families together and is quoting you the size of IPv6.

Rule 3: overlapping ranges have to be merged first

Three distinct traps live here, and all three inflate.

Ranges that are written separately but are one range. Look again at the Microsoft record above. It publishes six IPv4 literals, but 52.100.0.0/15, 52.102.0.0/16 and 52.103.0.0/17 sit back to back: together they are the single unbroken run 52.100.0.0–52.103.127.255, 229,376 addresses. There are six literals and four contiguous blocks. Report “six ranges” and you have counted the punctuation rather than the surface.

The same provider counted twice. sendgrid.net already ends with include:ab.sendgrid.net. A domain that publishes both includes — an easy thing to end up with when two setup guides are followed a year apart — inherits that second record along both paths. Sum the literals naively and you get 238,592 addresses. Merge the intervals first and the true figure is 237,056: the difference, 1,536, is exactly the sub-record counted a second time.

Host bits that are not where you think. RFC 7208 §5.6 says only the high-order bits of a prefix are compared, so any bits below the prefix length in the published literal are simply irrelevant. Microsoft’s record for _spf-b.microsoft.com contains ip4:207.46.22.98/29. That does not authorize eight addresses starting at .98. It authorizes 207.46.22.96 through 207.46.22.103 — including .96 and .97, and excluding .104. Take the literal at face value and every interval is misaligned at both ends, which quietly wrecks the merging in the previous paragraph.

Two different figures are at stake here and they are worth keeping apart. Ranges that merely sit next to each other inflate the count of blocks while leaving the address total correct — that is the Microsoft case. A provider inherited twice inflates the addresses themselves — that is the SendGrid one. Misread host bits corrupt both.

What the three have in common is direction. Every one of them makes the figure larger, so a count that skips the merge step is not neutral-but-rough; it is systematically biased towards alarm.

Rule 4: zero and “I don’t know” are different numbers

example.com   v=spf1 -all

That record authorizes exactly zero addresses, and that is a real, useful, defensible fact: it is what a domain that sends no mail should publish.

Now consider an include: that failed to resolve, or a branch abandoned because the record was already at the ten-lookup limit (RFC 7208 §4.6.4). The addresses behind it are not zero. They are unknown, and the honest output is a blank, not a digit.

The distinction sounds pedantic until you notice which way it fails. Rendered as 0, an unknown reads as good news — the most permissive record in your estate, displayed as the tightest. If a tool cannot tell you when it failed to look, its zeros are worthless everywhere else too.

The better question: how many of them have ever sent anything?

The authorized surface is a permissions list, and on its own it says nothing about what is actually in use. The interesting figure is the overlap with reality, and DMARC aggregate reports supply the other half: every report lists the source addresses that sent mail carrying your domain (RFC 9990 §3.1).

Cross the two sets and you get two useful numbers:

• authorized ∩ observed — the addresses that genuinely send your mail;
• authorized − observed — the dead weight: addresses you vouch for that have not sent a message in months.

Dead weight is almost always archaeology. The ESP you migrated away from and never removed. A mail server decommissioned two office moves ago. A monitoring appliance that stopped mailing when someone turned off its alerts. None of these announce themselves; the include: keeps resolving, the record keeps validating, and the addresses keep being authorized.

Two disciplines make that number honest, and both matter more than the arithmetic:

No reports is not zero senders. If nothing arrived in the observation window, you have learned nothing about usage. Telling someone who configured reporting last week that none of their 98,304 authorized addresses sends mail would be absurd, and a tool that does it is subtracting from data it does not have. The correct output is silence about usage, not a large and frightening number.

Count distinct sources, not messages. The question is how many authorized addresses are alive, so a server that sent a million messages counts once. Weighting by volume produces a big figure with no relationship to the surface it is supposed to describe.

A wide SPF record is not, by itself, a mistake

This needs saying plainly, because the genre this article belongs to usually ends by implying the opposite.

Google’s 98,304 addresses are not carelessness. They are the size of a mail platform that delivers for millions of organisations, and any provider operating at that scale will authorize a comparable range. Nothing has gone wrong.

Nor is the figure a score. There is no threshold above which a record becomes bad, no benchmark to sit under, and it does not belong behind a red light. It is a measurement — the same category as the number of hosts on your network, which is worth knowing and meaningless as a grade.

It is also worth being precise about what the surface exposes. An authorized address is not an open door: it is a machine whose mail your domain will vouch for. The risk it represents is conditional — it matters if one of those machines is compromised, or if a range is released back to a cloud provider and re-leased to someone else. That is a real concern, and it is exactly why provenance beats size. A record authorizing 98,304 addresses belonging to one provider you actively use is in better shape than one authorizing 3,000 across six vendors, four of which you stopped paying two years ago.

What to actually do with the number

Remove providers you no longer use. This is the one intervention that is always correct, costs nothing, and shrinks both the surface and the lookup count. It requires no judgement call — only the list, and someone willing to say which entries are still real. Start with the dead weight.

Give heavy senders their own subdomain. Marketing and transactional mail sent from mail.example.com, with its own SPF record, keeps the corporate domain’s record small and separately auditable. Your ESP’s ranges then sit behind a name whose only job is bulk mail, and a compromise of that surface does not carry the weight of your primary domain.

Do not reach for flattening. Replacing include:_spf.google.com with the literal ranges it resolves to today does reduce your lookup count, and it is the standard advice for records that have hit the limit of ten. But it converts a live reference into a snapshot, and the provider carries on changing the ranges behind your back. When they add a range, your mail from it starts failing. When they release one — back to the cloud pool, on to another tenant — your record goes on authorizing addresses that now belong to a stranger. That second case is precisely the risk the phrase “attack surface” was invented to describe, and flattening manufactures it. It deserves an article of its own, but the short version is that it trades a limit you can measure for a liability you cannot see.

Counting the surface takes an afternoon and a resolver. Knowing how much of it is still alive takes DMARC reports over a long enough window to catch your quarterly senders, and that is the half no record inspection can give you. Sentinely does both — it measures the authorized surface, declares the parts it could not enumerate rather than rounding them to zero, and crosses the result against the sources your reports actually show, which is where the dead weight becomes visible. If the security framing is what brought you here, that side of it lives here.

Most published lists of reasons for this are unordered, which is the one thing such a list must not be. The checks have a natural sequence — each one makes the next meaningful — and doing them out of order means proving the same thing twice while the actual cause sits further down. Here is the sequence. Two questions come before it, because for a good share of readers the answer is that nothing is broken.

Two questions that may end this early

Has it been 48 hours?

Aggregate reports are not emitted as mail flows. Each report covers a reporting period, and RFC 9990 (§3.1.1.4) says the period will typically be a single UTC day beginning at 00:00 UTC. Generation and delivery happen after the period closes.

So if you published at 16:00 on Tuesday, the first period that includes your record ends at 00:00 UTC on Wednesday, and the report is built and sent some time after that. Twenty-four to forty-eight hours is the normal wait, and large receivers vary within it.

Two things stretch that window:

• DNS caching. If the name _dmarc.example.com previously did not exist, resolvers cached its absence, not just its contents. Negative caching (RFC 2308) uses a lifetime derived from the zone’s SOA record, and a receiver that looked an hour before you published will not look again until it expires. Check your SOA minimum before assuming something is wrong.
• You cannot ask for faster. The ri= tag used to request a shorter reporting interval. RFC 9989 removed it (Appendix C.5.2), and the IANA registry now lists ri as historic. Publishing ri=3600 changes nothing — it is an unknown tag, and unknown tags are ignored.

Does the domain actually send mail?

A receiver learns that you want reports only when it looks up your policy, and it looks up your policy only when it has received a message with your domain in From: (RFC 9990 §3.4).

No mail, no lookup, no report. If the domain is parked, or serves only a website, or was registered last month and has not sent anything yet, silence is the correct outcome and no amount of DNS work will change it. A domain that sends a handful of messages a day is a softer version of the same thing: you will get reports only from the receivers that both saw your mail and run a reporting programme, so a thin week is not evidence of a broken record.

If you are past both of these, work down the list.

The six causes, in the order to check them

1. There is no DMARC record where receivers look.
2. The record is there, but receivers discard it — most often a missing semicolon.
3. The record is valid and has no rua= tag, or has one that is not a usable URI.
4. The rua= is valid and is not yours — the reports exist, and go elsewhere.
5. It is too early — covered above.
6. They are arriving — and the problem is downstream.

One command settles the first four:

dig +short TXT _dmarc.example.com

1. No record where receivers look

Policy discovery starts at the name formed by prepending _dmarc to the domain in the From: header (RFC 9989 §4.10.1). Not the apex, not www, not a CNAME to your provider’s marketing page.

The failure that produces the most confusion is a DNS panel that appends the zone for you. You typed _dmarc.example.com into the name field, the panel appended .example.com, and the record now lives at _dmarc.example.com.example.com, where nobody will ever look. The dig above returns nothing and the panel shows a record that looks perfect. Trust dig, not the panel.

There is a subtler version. If the mail is sent from a subdomain — From: noreply@mail.example.com — discovery looks at _dmarc.mail.example.com first, and only if there is no valid record there does it walk up to the organizational domain (RFC 9989 §4.10). Both outcomes are normal. What matters for your empty dashboard is that in the second case, the record that applies is the parent’s, and the reports for that mail go to the parent’s rua. Come back to this if you are watching a subdomain.

2. The record is there and receivers discard it

Three ways a published record is thrown away before anyone reads your rua:

More than one record. If a query returns multiple DMARC policy records for the same name, all of them are discarded (RFC 9989 §4.10). This is the standard aftermath of a vendor migration: the old record was never deleted and the new one was added beside it. dig +short shows both. Two correct records are worse than one.

v= is not first, or is not exactly DMARC1. The version tag must come first, and its value is case-sensitive. If it is absent, not first, or spelled differently, the entire record must be ignored (RFC 9989 §4.7). v=dmarc1 is not a DMARC record.

A missing semicolon. This one deserves its own section, because it is invisible and because of how it fails.

One character: the missing semicolon

These two records differ by a single ;:

v=DMARC1; p=none rua=mailto:dmarc@example.com

v=DMARC1; p=none; rua=mailto:dmarc@example.com

At a glance in a DNS panel they are indistinguishable. The first one gets you no reports at all, and here is the mechanism, because it is not what most people assume.

The grammar in RFC 9989 §4.8 defines a tag value as any printable character except the semicolon. A space qualifies. So does =. A receiver parsing the first record does not stop at the space: it reads the value of p as none rua=mailto:dmarc@example.com.

Two things are now true at once, and it is the second that hurts:

• p holds a value that is not none, quarantine or reject, so it is not valid;
• there is no rua tag in the record at all — it was swallowed into the value of p.

RFC 9989 §4.10.1 treats an invalid p gently, but the leniency has a condition. If a rua tag is present with at least one syntactically valid URI, the receiver behaves as though the record said p=none and carries on — which keeps reporting alive. Otherwise it “applies no DMARC processing to this message.”

The missing semicolon deletes exactly the tag that would have rescued it. That is why this typo is silent rather than noisy: it does not weaken your policy, it removes your reporting.

The same shape of error, less common, is a record whose tags are in the wrong order — p=none; v=DMARC1; rua=… — which fails on the version rule above.

And the reassuring counterpart, so you do not spend an afternoon on the wrong thing: a stray fragment that is not a tag=value pair is not fatal. RFC 9989 §4.8 says syntax errors in the rest of the record are discarded in favour of defaults or ignored outright. Untidy, worth cleaning, not the reason your dashboard is empty.

3. No usable rua=

The tag is optional in the standard, and its absence is unambiguous: with no rua, receivers must not generate aggregate reports for the domain (RFC 9989 §4.7). A record can be perfectly valid, enforce p=reject, and tell you nothing.

Three ways the tag is present but unusable:

• An address instead of a URI. rua=dmarc@example.com is not a DMARC reporting URI — a URI needs a scheme. It must be rua=mailto:dmarc@example.com. The omission is easy to make and hard to see, because an address without a scheme looks completely reasonable to a human reader.
• https: only. Receivers are required to support mailto:; support for anything else is optional, and URIs in schemes a receiver does not support must be ignored (RFC 9989 §4.7). An HTTPS-only rua is a bet on each receiver.
• The old size limit. The !10m suffix is now obsolete syntax that reporters are told to ignore (RFC 9989 §4.8). Harmless if it is already there; pointless to add.

4. The rua= is valid, and it is not yours

This is the cause that survives every check above, and the one almost nobody looks for.

A syntax validator will confirm that rua=mailto:dmarc@reports.vendor.example is a well-formed reporting URI, because it is. What no validator can know is whether that address is yours. Only you know that. So the record passes every test, the tool you are paying for stays empty, and nothing anywhere reports an error — because from the protocol’s point of view nothing is wrong. The reports are being generated, on schedule, every day. They are going somewhere else.

Where the other address usually comes from:

• a previous DMARC vendor, after the subscription lapsed — cancelling a contract does not edit your DNS;
• the agency or MSP that configured the domain years ago, pointing at their own aggregation account;
• an internal mailbox on a mail system that has since been decommissioned.

The check is to read the list yourself rather than trust a green tick. Run the dig above and read the rua= value for what it is: a comma-separated list of destinations. Ask, for each entry, who receives mail at that address today? If you cannot answer for one of them, you have found it.

Two things worth knowing before you edit:

Being one of several is normal, so the fix is usually to add, not to replace. Every valid destination in the list gets its own copy; there is no primary. If you are moving between tools, run both for a week and compare, then remove the old one.

If you are watching a subdomain, check the parent too. Per the walk described in cause 1, mail from a subdomain with no _dmarc record of its own is covered by the organizational domain’s record — so its reports arrive at the parent’s rua while the subdomain’s dashboard stays empty. Nothing is misconfigured; you are reading the wrong shelf.

Two causes that are not in the record at all

The destination is on another domain and has not agreed to it

If the rua address sits under a different organizational domain from the one publishing the policy, receivers must confirm that the destination consented before sending anything (RFC 9990 §4). The reason is obvious once stated: without it, anyone could publish a record aiming a flood of reports at a victim.

The check is a DNS lookup the receiver performs. It takes the host from your rua URI, prepends _report._dmarc, and prepends the domain the policy came from. So a policy at example.com asking for rua=mailto:dmarc@reports.example.net produces a TXT query for

example.com._report._dmarc.reports.example.net

and the answer must parse as a DMARC record with v=DMARC1 first. If that record is missing, the URI must be ignored by the receiver generating the report (RFC 9990 §4). Silence again, with nothing broken anywhere you would think to look.

Three practical consequences:

• The record goes in the destination’s zone, not yours. If your reports go to a third-party service, it is their record to publish, and most publish a wildcard — *._report._dmarc.<their domain> — which covers every customer at once. If your reports go to a mailbox on a second domain you own, nobody else is going to publish it for you.
• Same organizational domain, no verification needed. A policy at _dmarc.mail.example.com sending to dmarc@example.com does not trigger this at all.
• The destination has the last word. The confirming record may itself carry a rua, which overrides the one in your policy, restricted to the same host (RFC 9990 §4). Rare, but it is another way reports legitimately end up somewhere you did not choose.

The mailbox is eating them

A report is an ordinary email with an attachment: an XML file that should be gzip-compressed, carried as application/gzip or text/xml, with a filename built as receiver!policy-domain!begin-timestamp!end-timestamp.xml.gz (RFC 9990 §3.5.2).

The subject line is fixed by the standard, which gives you something to search for:

Subject: Report Domain: example.com
    Submitter: mx.example.net
    Report-ID: 1755820800-example.com@example.net

Search the entire mailbox — spam, quarantine and archive included — for Report Domain:. If messages turn up, everything above is fine and your problem is downstream. If nothing turns up anywhere, the earlier causes are still in play.

What eats them, in rough order of frequency: attachment policies that strip or block compressed files; a rule that files them somewhere nobody looks; a shared mailbox whose quarantine nobody reviews; and an rua address that does not actually accept mail, which produces bounces you never see because they go to the receiver, not to you.

One detail that saves an argument with your mail team: report traffic is itself DMARC-authenticated — RFC 9990 §3.5.2 requires these streams to produce an aligned pass. When reports land in quarantine, that is a local filtering decision, not an authentication failure.

They arrive, and the dashboard is still empty

If you found the messages, the remaining causes are all downstream of delivery.

You are looking at the wrong domain. A separate report is generated for each policy domain encountered in the period (RFC 9990 §3.1). Open one of the XML files and read policy_published/domain: that is the shelf the data was filed under. If it says example.com and you are looking at mail.example.com, see cause 4.

Duplicates were removed, correctly. When a generator re-sends a report it must reuse the original filename, and the Report-ID exists so consumers can recognise and ignore duplicates (RFC 9990 §3.5.2). A report that arrived twice appearing once is the system working.

Ingest is on a schedule. Reports are fetched and parsed in batches, not the instant they land. If the first one arrived twenty minutes ago, give it an hour before opening a ticket.

While you wait for a first report, you do not have to wait to learn anything. A report summarises a day of mail; a single message’s headers tell you what one receiver concluded about one message, right now. If you can send yourself a test message, paste its headers into our email header analyzer — it reads the receiver’s own declarations, needs no account, and keeps nothing.

And once the reports do arrive, the thing worth watching is not only that your record still parses, but that its rua still names you. That check is what Sentinely does continuously, which is the difference between finding out today and finding out at the next audit.

Almost certainly not. What you are looking at is the word fail used for two different things, and the tools that show you a single “failure rate” usually merge them. One of the two means a message was blocked. The other means a message was delivered normally, by a receiver that was perfectly happy with it. Telling them apart takes about a minute per row, and the rest of this article is that minute.

Two different things called “fail”

A DMARC aggregate report (the format is specified in RFC 9990) is not a list of messages. It is a list of groups: each <record> covers a batch of messages that arrived from the same source IP with the same authentication outcome, and <count> says how many messages that batch represents. Any percentage you see anywhere is weighted by that number.

Inside each record there are three layers, and they answer three different questions.

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>fwd.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

<auth_results> — did the protocols verify at all? These are the raw outcomes, uninterpreted. Here SPF returned pass, but look at the domain it passed for: fwd.example.net, not example.com. DKIM verified a signature carrying d=example.com.

<policy_evaluated>/<spf> and /<dkim> — did they verify and line up with the From: domain? This is the DMARC view, and it has only two values: pass or fail. SPF verified for someone else’s domain, so from DMARC’s point of view it is fail. DKIM verified for your domain, so it is pass.

<policy_evaluated>/<disposition> — what did the receiver actually do? Three values: none (delivered), quarantine, reject.

The record above contains the word fail, and nothing whatsoever went wrong. DMARC passes when at least one aligned method passes — the aligned DKIM signature was enough — so the message was authenticated, delivered, and correct. If your dashboard charts an “SPF pass rate” and you watch that number, this record will worry you every single day for no reason.

The rule

Here is the whole thing, and it is worth keeping somewhere you can paste it.

A group of messages in an aggregate report is a real failure if and only if:

(A) the receiver blocked it — disposition is quarantine or reject; or

(B) it was delivered (disposition is none), the policy in force for that report was p=none, and both raw results in <auth_results> are exactly fail.

Everything else belongs in your volume, not in your failures.

Case (A) needs no interpretation. The receiver made a decision and told you about it. It does not matter what the raw results were and it does not matter what your policy says: if disposition is quarantine or reject, mail of yours did not reach an inbox, and that deserves attention whether the cause is an attacker or a misconfigured vendor.

Case (B) is the one nobody writes down. The message was delivered, both protocols failed outright, and the only reason it landed in an inbox is that you have not asked anyone to stop it yet. That is latent spoofing: it looks harmless today and becomes a blocked message the day you move to enforcement.

Two details in case (B) are easy to get wrong.

The policy that matters is the one in that report, not the one in your DNS today. Each report carries the policy the receiver saw, in <policy_published>/<p>, and it describes a window that has already closed — usually the previous day. If you changed your record on Tuesday, Monday’s reports still describe Monday’s policy. Read p from the report you are holding.

Only the exact value fail counts. RFC 9990 allows several other values in <auth_results> — none, neutral, policy, temperror, permerror, and for SPF also softfail — and none of them is proof of anything. A temperror means the receiver could not complete the check. A softfail means your own record asked for indecision. Treating those as failures is how a monitoring tool invents problems that do not exist.

Why case (B) requires p=none exactly

This is the part that gets skipped, and skipping it inverts the meaning of the row.

Suppose your domain is already at p=quarantine, and a report shows a batch that failed both methods and was still delivered, disposition=none. Under a naive reading that is worse — the spoofing got through anyway. It is the opposite. You asked the receiver to quarantine that mail, and the receiver chose not to. RFC 9989 is explicit that final handling is always the receiver’s local decision; the protocol expresses a preference, not a command. A delivered message on an enforcing domain therefore means an override was applied: a local allowlist, a trusted-forwarder rule, or — on records that still carry the legacy pct tag, which RFC 9989 removed — a sampling decision.

Enforcement exists on that domain. The receiver looked at your policy and made an exception to it. That is a different situation from “no enforcement exists yet”, and it is not latent spoofing.

The same reasoning covers the third case: if you do not know which policy was published, case (B) does not apply at all. You cannot conclude “delivered only because enforcement was missing” without knowing whether enforcement was there.

Sometimes the receiver tells you why

When a receiver applies an override, it may say so. <policy_evaluated> can carry one or more <reason> elements, and RFC 9990 defines five types: local_policy, mailing_list, other, policy_test_mode, and trusted_forwarder. Some reporters add a free-text <comment> as well.

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>mailing_list</type>
  </reason>
</policy_evaluated>

That is a receiver telling you, in the report, that it recognised a mailing list and decided not to hold your policy against it. It is the most useful field in the format, and it is optional — most records will not have it, but when it is there it saves you the investigation. Reporters also move more slowly than the specification: until 2026 the reference was RFC 7489, whose list of reasons also included forwarded and sampled_out, and you will still see both in the wild.

The three ordinary explanations

Most of the alarming volume comes from three situations.

Automatic forwarding. A user forwards their mail elsewhere, or an old alias still points offsite. The forwarding server sends from its own IP, which is not in your SPF record, so SPF no longer aligns with your domain. If the forwarder passes the message through untouched, the DKIM signature survives, DMARC passes on DKIM, and the message is delivered. In the report: <spf>fail</spf>, <dkim>pass</dkim>, disposition none. What to do: nothing. This is precisely what having two authentication methods is for.

Mailing lists. A list adds a subject prefix or a footer, which invalidates the DKIM signature over the modified body, and rewrites the envelope sender to its own domain, which moves SPF away from yours. Both methods fail alignment, and the message is delivered anyway because the receiver recognises the pattern. In the report: both fail, disposition none, sometimes with <reason><type>mailing_list</type>. What to do: nothing. The mechanism designed to carry authentication across this kind of rewrite is ARC (RFC 8617), and implementing it is the list’s job, not yours.

A vendor signing with its own domain. Your invoicing platform, CRM or newsletter tool sends on your behalf and signs with d=vendor.example, not d=example.com. Look at <auth_results>: the DKIM result is pass, but <domain> is the vendor’s. Raw success, no alignment, so <policy_evaluated>/<dkim> is fail. This one needs action — not urgent action, but real action. Ask the vendor for DKIM signing under your own domain (almost always a CNAME pointing at a selector they give you) and, if they send with an envelope sender in your domain, make sure their include: is in your SPF record. Until then that traffic has no aligned identifier at all, and it is exactly the traffic that will break on the day you enforce.

The records that are neither

There is a fourth shape, and it fits neither bucket cleanly: SPF fail, and no <dkim> element at all, because nothing signed the message.

The rule above does not count these as failures, deliberately. A missing DKIM element is not a DKIM failure — it is the absence of evidence on that side, and absence of evidence is not proof. But these records are not “fine” either, and they deserve their own queue, because on a domain at p=none there are exactly two explanations and they look identical in the report:

1. someone is forging your domain, or
2. a legitimate sender of yours has no authentication at all — a form plugin on a small VPS, a monitoring script, a departmental application nobody remembers deploying.

The report cannot tell you which. The source IP usually can. Work through this list before you raise your policy, because these are the messages that will start disappearing the moment you do.

When it really is spoofing

The signals, in the order they are worth checking:

• The source IP has no relationship to you. Not your provider, not your office, not a vendor you can name. This is the strongest signal there is, and the only one that stands on its own.
• Nothing passes, raw. No aligned DKIM signature, and no SPF pass for any domain you recognise.
• The sending infrastructure does not look like a mail system. No usable reverse DNS, hosting ranges rather than mail ranges, a source that appears once and never returns.
• <header_from> is your domain while everything else belongs to someone else. That is the definition of the attack DMARC was built to describe.

There are deliberately no thresholds here. “More than X% from a single IP” is the kind of number that gets copied from article to article and tells you nothing about your own domain: a legitimate email service provider concentrates enormous volume on very few addresses. Judge sources, not percentages.

What to do with the number

Do not raise your policy to make a number go down. It is the wrong number, and raising the policy will not do what you expect it to.

Work in this order instead. Identify every source in your reports until none is unexplained — that is the real work, and on a domain of any age it takes weeks, not an afternoon. Fix alignment for the legitimate ones, starting with the vendors signing under their own domain. Then move the policy, and not before.

And know what happens to your dashboard when you do. A batch of latent spoofing at p=none is case (B): delivered, counted as a failure. At p=reject that same batch becomes case (A): rejected, still counted as a failure. Your failure count does not have to fall for enforcement to be working — the mail stopped reaching inboxes, which was the entire point. What should fall is the volume you cannot explain.

Aggregate reports summarise; they never contain the message itself. When one specific message is bothering you and you want to know what the receiving server actually concluded about it, paste its headers into our email header analyzer: it reads the receiver’s own declarations, needs no account, and keeps nothing.