What does the `!10m` tag mean in a DMARC record?
Published 15 Nov 2025
Updated 22 Oct 2026
10 min read
Summarize with
Updated on 22 Oct 2026: We clarified the legacy !10m size limit and added checks for report delivery after DNS cleanup.
The !10m suffix in a DMARC record requested a maximum report size of 10 MiB (10,485,760 bytes) for one reporting destination under RFC 7489. Under RFC 9989, it is not an active DMARC reporting instruction. It can still appear inside the rua or ruf URI value, but report generators should ignore the obsolete size value.
The confusion usually comes from searching for a tag named !10m. There is no such top-level tag. RFC 7489 described this as an optional size limit attached to a DMARC reporting URI. RFC 9989 keeps it only as obs-dmarc-report-size, so parsers can accept older reporting URIs while ignoring the size value.
What !10m means
A DMARC report destination is written as a URI. For email reports, that usually starts with mailto:. Older DMARC syntax let the domain owner add an optional maximum report size after the URI, separated by an exclamation point. So mailto:dmarc@example.com!10m requested delivery to that mailbox only when the report payload did not exceed 10 x 2^20 bytes.
Obsolete URI size suffix grammartext
dmarc-uri = URI obs-dmarc-uri = dmarc-uri obs-dmarc-report-size obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]
Under RFC 7489, a number without a unit meant bytes, while k, m, g, and t used powers of two. That makes !10m equal to 10 MiB (10,485,760 bytes). The m denotes a size unit, not minutes.
|
|
|
|---|---|---|
!10m | 10 MiB (10,485,760 bytes) | Obsolete size value |
!50m | 50 x 2^20 bytes | Obsolete size value |
!500k | 500 x 2^10 bytes | Obsolete size value |
!1g | 1 x 2^30 bytes | Obsolete size value |
Common URI size suffix examples
This suffix is attached to one reporting URI. It does not change the DMARC policy, SPF or DKIM alignment, report scheduling, or whether aggregate or failure reports are requested.
What changed with DMARCbis
- RFC 7489 is no longer the current DMARC reference for this syntax.
- RFC 9989 keeps the old !size pattern only as obsolete URI grammar.
- The pct, rf, and ri tags are historic, so current records should omit them.
- RFC 9990 defines aggregate XML reporting, which typically covers one UTC day. This reporting period is not a guaranteed delivery time.
- RFC 9991 defines failure reporting and how ruf works with fo.
For new records, do not add !10m. If an inherited record already has it, clean up the suffix and any historic pct, rf, or ri tags during the next controlled DNS change. Authentication coverage and report delivery remain the immediate operational checks.
What actually limits DMARC report size
Under RFC 7489, the aggregate report size limit was checked after compression and transport encoding. It did not limit the original emails being reported on. A raw XML file below 10 MiB was therefore not enough to establish that the transmitted report fitted the legacy limit.
Under RFC 9990, aggregate reports are XML attachments that should use GZIP compression. SMTP message size and attachment limits still apply even though the URI size suffix is obsolete. When large reports fail, check the receiving system directly:
- Check the report mailbox's SMTP size limit and attachment filtering, including acceptance of .xml.gz files.
- Check the report processor's upload and decompressed XML limits separately. Removing !10m does not increase either limit.
Where !10m appears in rua and ruf
The suffix sits only on the exact URI where it appears. If a record has two rua destinations and only the first has !10m, only that first URI carries the obsolete size value. It does not carry over to the second destination.
DMARC rua and ruf reporting URI diagram showing !10m as an obsolete per-URI size suffix.
The same URI-list syntax can appear in aggregate report destinations and failure report destinations. The rua tag requests aggregate XML reports under RFC 9990. The ruf tag requests failure reports under RFC 9991, and the fo tag influences which failure cases are requested and is ignored without ruf. Many receivers do not send ruf reports, and those reports can contain sensitive message details. Compare ruf and rua before adding both to a production domain.
|
|
|
|---|---|---|
rua | Aggregate | Aggregate report destinations |
ruf | Failure | Failure report destinations |
fo | Failure | Failure options |
!10m | One URI | Obsolete size value |
ri | Historic tag | Obsolete interval request |
How nearby DMARC values differ
Authorize external report destinations
A different rule applies when a reporting URI uses an external organizational domain. If the DMARC policy for example.com sends aggregate reports to example.net, the report consumer must authorize that relationship in DNS. The !10m suffix has no effect on this check.
External reporting authorization at example.netdns
example.com._report._dmarc.example.net. TXT "v=DMARC1"
Under RFC 9990, a receiver must ignore an external rua URI when the authorization record is missing. RFC 9991 applies the same verification procedure to external ruf destinations. Check every external destination separately when reports stop arriving. A matching wildcard authorization record published by the report consumer also satisfies the check.
The reporting mailbox can exist and accept mail while DMARC reports still fail to arrive. Missing external destination authorization causes the reporting URI to be ignored before delivery is attempted.
How to read a DMARC record containing !10m
This legacy record requests monitoring for the domain and its subdomains, aggregate reports, failure reports, and specific failure conditions. Under RFC 7489, it also requested AFRF failure reports, full policy application, daily aggregate reports, and a 10 MiB payload limit on two URIs. RFC 9989 keeps the core policy and reporting tags but treats !10m as obsolete URI syntax and lists pct, rf, and ri as historic tags.
Assume this is one DNS TXT record at _dmarc.example.com. The line breaks below are for readability; paste the value as one line in the DNS editor.
Legacy DMARC record with !10mdns
v=DMARC1; p=none; sp=none; rua=mailto:dmarc@example.com!10m,mailto:dmarc@example.net; ruf=mailto:dmarc@example.com!10m; fo=1; rf=afrf; pct=100; ri=86400
- v=DMARC1 identifies the TXT record as a DMARC record.
- p=none requests no DMARC-based enforcement. Receivers still apply their own spam and security policies.
- sp=none requests the same policy for subdomains that inherit this record. Because np is absent, this also covers non-existent subdomains.
- The rua tag requests aggregate reports at two mailboxes, with obsolete !10m syntax on the first URI.
- The ruf tag requests failure reports at one mailbox, also with obsolete !10m syntax.
- fo=1 requests a failure report if any underlying authentication mechanism fails to produce an aligned pass result.
- Under RFC 7489, rf=afrf selected AFRF, pct=100 requested full policy application, and ri=86400 requested a one-day reporting interval. All three tags are historic under RFC 9989.
Do not publish angle brackets around a DMARC URI in DNS. If a copied example shows <mailto:...>, treat that as formatting from the source, not as DNS syntax.
Should you remove !10m
Omit the suffix from new records and remove it from actively managed records after checking any documented legacy dependency. If an older report generator still honors the cap, confirm that the destination can accept larger reports before removing it. RFC 9989 no longer treats the cap as an active instruction.
Keep during migration
- A documented legacy report generator still honors the cap.
- The destination still needs a capacity change before accepting larger reports.
- The value has an owner, an expiry condition, and a scheduled cleanup change.
Remove from clean records
- Nobody owns the value or can explain why it was added.
- Internal validation or support tooling misreads the obsolete syntax.
- The cap provides no current DMARCbis behavior.
A validator that rejects the suffix does not establish that the whole record is invalid. An RFC 9989-aware parser can recognize !10m as obsolete URI syntax and ignore the size value. When an error appears, confirm whether the parser fails on the suffix, multiple report URIs, or accidental formatting characters.
Cleaner RFC 9989 recorddns
v=DMARC1; p=none; sp=none; rua=mailto:dmarc@example.com,mailto:dmarc@example.net; ruf=mailto:dmarc@example.com; fo=1
Validate the reporting URI and DNS record
Validate a record with this suffix in two ways. First, read the syntax manually so the URI carrying the obsolete size value is clear. Second, use a parser that understands RFC 9989 obsolete URI syntax, multiple rua destinations, optional ruf reporting, and fo failure options. Also verify DNS authorization for every external reporting domain.
Suped's DMARC checker parses the record and shows the configured tags, which helps separate record syntax errors from obsolete values that need a controlled cleanup.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A one-off check answers whether the DNS record parses. Suped's DMARC monitoring uses received aggregate reports to show authentication results and report arrival. It does not prove that every receiver generated or delivered a report.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For teams that want less manual DNS editing, Suped's Hosted DMARC can manage policy staging and reporting destinations through a controlled workflow, with DNS changes and report delivery reviewed in the same Suped product.
Common mistakes with !10m
The most common mistake is treating !10m as if it changes enforcement or still controls report delivery under current DMARCbis. It does neither. A domain with p=none remains in monitoring mode whether the suffix is present or not.
Flowchart for checking a DMARC record with an obsolete !10m URI size suffix.
- Wrong scope: the suffix belongs to one URI, not to the whole DMARC record.
- Wrong tag: it is not a DMARC tag like p, sp, or rua.
- Outdated assumption: RFC 9989 tells report generators to ignore the old size value.
- Wrong interval: !10m never changed scheduling, and ri is now historic.
- Wrong parser: some tools reject old but tolerated records when their URI grammar is incomplete.
- Wrong record: copied angle brackets, whitespace inside a mailbox address, or malformed comma separation can cause a syntax error. Whitespace around separators is allowed.
If you are cleaning up a record, use a full DMARC tag list to separate active tags, historic tags, and URI modifiers. That keeps the cleanup focused on behavior that current receivers use.
Check report delivery after DNS cleanup
Before editing, save the existing record. Confirm the suffix belongs to a valid rua or ruf URI, remove copied formatting characters, verify external destination authorization, and remove the suffix with any historic pct, rf, or ri tags during a controlled DNS change. After the DNS TTL expires, query the published record again and check subsequent aggregate reports for continued delivery. Before moving toward enforcement, confirm that every legitimate sender passes aligned SPF or DKIM.
Suped's product supports this workflow by validating the published record, monitoring aggregate report delivery, surfacing authentication failures, and managing hosted DMARC changes when DNS access is shared across teams.
