Updated on June 11, 2026: We refreshed the guidance for the DMARCbis RFCs. RFC 9989, RFC 9990, and RFC 9991 now replace the old RFC 7489 DMARC text, so !10m should be treated as obsolete URI size-limit syntax that parsers tolerate and report generators ignore. We also clarified how the suffix relates to rua, ruf, fo, aggregate reporting, and failure reporting.
The !10m suffix in a DMARC record means a legacy reporting URI includes an old request not to send a report to that destination if the report message is larger than 10 megabytes. Under RFC 9989, it is not an active current 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, which makes it a legacy cleanup clue rather than a policy setting.
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 used to mean: send the report to that mailbox only while the report message stays within a 10 megabyte limit.
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" ]
The old unit suffixes are k, m, g, and t. In current operational terms, !10m is old 10 MB cap notation, not a current report-size control. Without the exclamation point, the URI has no obsolete DMARC URI size suffix to clean up.
|
|
|
|---|---|---|
!10m | 10 MB | Obsolete size value |
!50m | 50 MB | Obsolete size value |
!500k | 500 KB | Obsolete size value |
!1g | 1 GB | Obsolete size value |
Common URI size suffix examples
This suffix is attached to one reporting URI. It does not change the DMARC policy, the reporting interval, SPF or DKIM domain matching, 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.
- RFC 9990 separates aggregate XML reporting details from the main DMARC protocol.
- RFC 9991 separates failure reporting details, including how ruf and fo work together.
For new records, do not add !10m. If an inherited record already has it, treat it as obsolete syntax to clean up during the next controlled DNS change. The urgent work is still authentication coverage, report flow, and policy staging.
Where the suffix sits
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. Many receivers do not send ruf reports, and those reports can contain sensitive message details. For a deeper breakdown, compare ruf and rua before adding both to a production domain.
|
|
|
|---|---|---|
rua | Aggregate | Report path |
ruf | Failure | Report path |
fo | Failure | Failure options |
!10m | One URI | Obsolete size value |
ri | Aggregate reports | Interval hint |
How nearby DMARC values differ
How to read this record
A record like this is syntactically trying to do several things at once: monitor the domain, monitor subdomains, request aggregate reports, request failure reports, set failure reporting options, specify AFRF as the failure report format, and ask for daily aggregate reports. It also includes a legacy report-size suffix that current DMARCbis report generators should ignore.
Example 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 receiver enforcement for mail using the organizational domain.
- sp=none: requests the same non-enforcing policy for subdomains.
- rua path: sends aggregate reports to two mailboxes, with an obsolete 10 MB suffix on the first URI only.
- ruf path: requests failure reports to one mailbox, also with an obsolete 10 MB URI suffix.
- fo=1: requests failure reports when any underlying authentication mechanism fails to produce the needed DMARC pass result.
- ri=86400: requests aggregate reports every 86,400 seconds, which is one day. It is a requested interval, not a guarantee.
Do not publish angle brackets around a DMARC URI in DNS. If a copied example shows <mailto:...>, treat that as formatting from the place where it was copied, not as DNS syntax.
Should you keep it
For new or actively managed records, remove the suffix unless a legacy receiver or reporting path still depends on it. A mailbox cap or report processor cap explains why it was added under older RFC 7489 practice, but RFC 9989 no longer treats it as an active instruction.
Keep during migration
- A legacy mailbox limit is documented and the record cannot be changed yet.
- A legacy report parser still expects the suffix during a migration window.
- A managed DMARC setup documents the value and has a scheduled cleanup path.
Remove from clean records
- Nobody owns the value or can explain why it was added.
- Internal validation or support tooling misreads the obsolete syntax.
- Reports are small and the cap gives no current DMARCbis benefit.
The suffix is rare enough that some validators and older scripts mishandle it. That does not automatically make the whole record invalid. Under current DMARCbis, a parser can treat !10m as obsolete URI syntax and ignore the size value. When an error appears, first confirm whether the parser fails on !10m, on multiple report URIs, or on accidental formatting characters.
Cleaner record without the obsolete suffixdns
v=DMARC1; p=none; sp=none; rua=mailto:dmarc@example.com,mailto:dmarc@example.net; ruf=mailto:dmarc@example.com; fo=1; rf=afrf; pct=100; ri=86400
How to validate it
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, run it through a parser that understands RFC 9989 obsolete URI syntax, multiple rua destinations, optional ruf reporting, and fo failure options.
Suped's DMARC checker parses the record, shows the configured tags, and flags record-level issues without treating uncommon legacy syntax as automatically wrong.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A one-off check answers whether the DNS record is valid. Ongoing DMARC monitoring answers the better operational question: whether legitimate sources are authenticating, whether unknown sources are using the domain, and whether reports are actually arriving.
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. That keeps DNS changes, report processing, alerts, hosted records, and deliverability signals visible in one Suped product workflow.
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 pct.
- Outdated assumption: RFC 9989 treats the old report-size value as obsolete.
- Wrong interval: it does not change the ri reporting interval.
- Wrong parser: some tools reject old but tolerated records when the URI grammar is incomplete.
- Wrong record: accidental brackets, spaces, or copied markup can create the real error.
If you are cleaning up a record, use a full DMARC tag list to separate real tags from URI modifiers. That keeps the cleanup focused and avoids removing tolerated syntax only because it looks unusual.
Views from the trenches
Best practices
Treat !10m as obsolete DMARCbis URI syntax and verify parser behavior before editing.
Validate every rua and ruf URI separately because any suffix is tied to one destination.
Prefer one clean aggregate reporting path before adding optional failure reports or fo settings.
Common pitfalls
Assuming !10m still controls report size under RFC 9989 leads to stale DNS choices.
Leaving angle brackets in DNS can break parsing even when the obsolete suffix is tolerated.
Adding ruf without privacy review can send sensitive failed message details to the wrong place.
Expert tips
Compare parser warnings with RFC 9989 before deleting any syntax that looks unfamiliar.
Remove the suffix when it only exists because an older hosted setup copied it forward.
Use aggregate reports to verify real mail flow before tightening p, sp, or np policies.
Marketer from Email Geeks said in 2025 that the suffix was used as a maximum report size on one URI.
2025-04-01 - Email Geeks
Marketer from Email Geeks said the syntax was rare enough that some validators misread records containing it.
2025-04-01 - Email Geeks
Practical recommendation
If you find !10m in a DMARC record, do not delete it blindly. It means the attached reporting URI carries a legacy 10 MB maximum report size request. The record can still parse, but current DMARCbis report generators should ignore the size value.
A safe cleanup workflow is simple: confirm the suffix belongs to a valid rua or ruf URI, remove copied formatting characters, verify that all report destinations are intentional, and remove the size suffix during the next controlled DNS change unless a documented migration reason exists. If the domain is moving toward enforcement, the bigger priority is making sure every legitimate sender passes SPF or DKIM with the right domain match before changing policy.
Suped's product helps with the practical parts: validating the DNS record, monitoring report flow, detecting authentication issues, alerting on new failures, and managing hosted DMARC or hosted SPF when DNS access is slow or shared across teams.
