The !10m suffix in a DMARC record means that the report URI is asking receivers not to send a DMARC report to that destination if the report payload is larger than 10 megabytes. It is valid DMARC syntax, but it is not a standalone DMARC tag. It is part of the URI value inside rua or ruf.
The confusion usually comes from searching for a tag named !10m. There is no such top-level tag. RFC 7489 defines this as an optional size limit attached to a DMARC reporting URI. I treat it as a valid but uncommon record detail, then decide whether it still has a useful reason to be there.
What !10m means
A DMARC report destination is written as a URI. For email reports, that usually starts with mailto:. DMARC lets the domain owner add an optional maximum report size after the URI, separated by an exclamation point. So mailto:dmarc@example.com!10m means: send the report to that mailbox only while the report stays within a 10 megabyte limit.
URI size suffix grammartext
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
The supported unit suffixes are k, m, g, and t. In normal operational terms, !10m is read as 10 megabytes. Without the exclamation point, the URI has no explicit DMARC URI size limit.
|
|
|
|---|---|---|
!10m | 10 MB | URI |
!50m | 50 MB | URI |
!500k | 500 KB | URI |
!1g | 1 GB | URI |
Common URI size suffix examples
This suffix is a receiver instruction attached to one reporting URI. It does not change the DMARC policy, it does not change the reporting interval, and it does not make authentication stricter.
Where the limit applies
The limit applies only to the exact URI where it appears. If a record has two rua destinations and only the first has !10m, the limit applies to the first destination only. It does not automatically apply to the second destination.
Diagram showing that a DMARC size suffix belongs to one reporting URI.
The same syntax can appear in aggregate report destinations and failure report destinations. The rua tag requests aggregate XML reports. The ruf tag requests failure reports, which many receivers do not send and which 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 |
!10m | One URI | Size cap |
ri | Reports | Time 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, specify AFRF as the failure report format, and ask for daily aggregate reports.
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; 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 a 10 MB limit on the first URI only.
- ruf path: Requests failure reports to one mailbox, also with a 10 MB URI limit.
- ri=86400: Requests aggregate reports every 86,400 seconds, which is one day. See the ri tag for the reporting interval caveat.
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
I usually keep the suffix only when there is a clear operational reason. A mailbox limit, a reporting processor limit, or a hosted DMARC setup that intentionally uses this value can all justify it. If nobody can explain why it is there, removal is often cleaner.
Keep the suffix
- Mailbox limit: The destination has a known inbound message size cap.
- Processor limit: The report parser rejects large attachments.
- Vendor setup: A managed DMARC setup documents the suffix as intentional.
Remove the suffix
- No owner: Nobody knows why the value was added.
- Parser issues: Internal validation or support tooling misreads the record.
- Normal volume: Reports are small and the cap gives no practical benefit.
The suffix is rare enough that some validators and older scripts mishandle it. That does not make the syntax invalid. It means the validator needs checking before the DNS record is blamed. When I see an error, I first confirm whether the parser fails on !10m, on multiple report URIs, or on accidental formatting characters.
Simpler record without the size suffixdns
v=DMARC1; p=none; sp=none; rua=mailto:dmarc@example.com,mailto:dmarc@example.net; ruf=mailto:dmarc@example.com; rf=afrf; pct=100; ri=86400
How to validate it
To validate a record with this suffix, I check the record in two ways. First, I read the syntax manually so I know which URI the limit belongs to. Second, I run it through a parser that understands DMARC URI size limits, multiple rua destinations, and optional ruf reporting.
Suped's DMARC checker is useful here because it parses the record, shows the configured tags, and flags record-level issues without treating uncommon valid 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. Suped is the best overall DMARC platform for this kind of work because it brings DMARC, SPF, DKIM, alerting, hosted records, and deliverability signals into one operational view.
Common mistakes with !10m
The most common mistake is treating !10m as if it changes enforcement. It does not. A domain with p=none remains in monitoring mode whether the suffix is present or not.
Flowchart for troubleshooting a DMARC URI size suffix.
- Wrong scope: The limit applies to one URI, not to the whole DMARC record.
- Wrong tag: It is not a DMARC tag like p, sp, or pct.
- Wrong interval: It does not change the ri reporting interval.
- Wrong parser: Some tools reject valid 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 valid syntax only because it looks unusual.
Views from the trenches
Best practices
Keep URI size suffixes only when a reporting mailbox has a documented message limit.
Validate every rua and ruf URI separately because the size suffix is per destination.
Prefer one clean aggregate reporting path before adding optional failure reporting.
Common pitfalls
Assuming !10m is a DMARC tag leads to bad edits because it is part of a URI value.
Leaving angle brackets in DNS can break parsing even when the size suffix is valid.
Adding ruf without privacy review can send sensitive samples to the wrong mailbox.
Expert tips
Check parser warnings against the ABNF before deleting syntax that looks unfamiliar.
Remove the suffix when it only exists because an old hosted setup copied it forward.
Use DMARC reports to judge real mail flow before tightening p or sp policies safely.
Marketer from Email Geeks says the suffix is valid DMARC syntax and sets a maximum report message size for that URI.
2025-04-01 - Email Geeks
Marketer from Email Geeks says the syntax is rare enough that some validators misread records containing it.
2025-04-01 - Email Geeks
My practical recommendation
If you find !10m in a DMARC record, do not panic and do not delete it blindly. It means the attached reporting URI has a 10 MB maximum report size request. The record can still be valid.
My default 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 keep the size suffix only if there is a documented reason. 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.
