Is it okay to use the plus sign in the RUA email address of a DMARC record?
Updated on 5 Oct 2026: We clarified plus-addressed RUA syntax and the checks needed to receive aggregate reports.
Yes. It is okay to use a plus sign in the RUA email address of a DMARC record, provided the receiving mailbox accepts the exact address and any required external reporting authorization is in place.
The plus sign itself is not the problem. In an address like dmarc+rua@example.com, the plus sign sits in the local part of the email address. Many mailbox providers support this pattern as plus addressing (subaddressing), with the tag used for routing or filtering. Google Workspace delivers these address variations to the base mailbox, such as dmarc@example.com, unless routing rules say otherwise.
Valid RUA syntax with a plus sign
A DMARC RUA tag accepts one or more reporting URIs. The common form is a mailto: URI pointing to an email address. A plus sign in the local part is valid in email addressing and in a mailto URI, so this RUA value is technically fine:
Valid plus-addressed DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc+rua@example.com;
A sender that generates DMARC aggregate reports should treat that as a normal destination address. If reports do not arrive, check mailbox routing, spam filtering, attachment handling, and third-party report authorization before blaming the plus sign.
- Syntax: The plus sign is allowed in the email address local part, so it can appear before the at sign in a RUA mailbox.
- Delivery: The mailbox provider must deliver plus-tagged mail to the expected mailbox or route.
- Authorization: If the RUA destination and the DMARC policy domain have different organizational domains, the receiving domain must authorize external reports in DNS.
- Operations: Use a parser to turn aggregate XML reports into authentication results you can review.
Email and DMARC syntax rules
RFC 9989 became the current DMARC specification in May 2026 and obsoletes RFC 7489. RFC 9990 defines aggregate reporting. These specifications keep RUA as a comma-separated list of reporting URIs and do not invalidate plus-tagged destinations.
RFC 6068 defines the mailto URI syntax and permits a literal + in the address local part. The plus sign does not need percent-encoding in mailto:dmarc+rua@example.com. A DNS TXT record also does not apply web form decoding, so the plus sign remains a plus sign rather than becoming a space.
Keep the plus sign literal
Publish the address with the literal +. Encoding it as %2B is also permitted by RFC 6068, but is unnecessary here. Keeping the literal character avoids an extra encoding step. If a DNS form changes the character, confirm the live TXT record after publishing.
Why some validators reject it
Some DMARC record generators and DNS forms are stricter than the protocols they are trying to help with. A form can reject a plus sign because its email validation pattern is too narrow, because it assumes only letters, digits, dots, underscores, and hyphens are allowed, or because the UI applies web form rules to + even though it appears inside a TXT record.
That rejection does not prove the DMARC record is invalid. If the plus sign is the stated reason for rejection, the validator is stricter than the mailto URI syntax. Check the whole record for other errors as well.
What can fail
- Form validation: A web form blocks the plus sign before the record reaches DNS.
- Mailbox routing: The mail provider does not map the tagged address to the expected mailbox.
- Report volume: The mailbox rejects large compressed XML attachments or high message volume.
- External RUA: The reporting destination has a different organizational domain and lacks external report authorization.
What to verify
- DNS output: Query the published TXT record and confirm the plus sign is still present.
- Test message: Send a normal email to the plus address and confirm where it lands.
- Attachment policy: Check whether compressed XML attachments are quarantined or stripped.
- Reporting domain: Check whether the destination domain has authorized external reports.
Separate syntax checks from delivery checks. First, confirm the DMARC record parses. Next, confirm the mailbox receives ordinary mail. Then check real aggregate reports: a normal test message verifies address routing, but does not test XML attachment handling or report generation.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Plus-addressed RUA and RUF examples
The simplest version keeps the reporting address on the same organizational domain as the DMARC record. That avoids the extra external reporting authorization step and makes debugging cleaner.
Same-domain RUA addressdns
v=DMARC1; p=none; rua=mailto:dmarc+rua@example.com;
If you want both aggregate and failure-report destinations, keep in mind that RUA and RUF are different report types. RFC 9990 defines aggregate reporting through RUA. RFC 9991 defines per-message failure reporting through RUF, which many receivers do not send because it can contain sensitive message-level data. The plus sign is still not the issue in this example:
RUA and RUF with plus tagsdns
v=DMARC1; p=none; rua=mailto:dmarc+rua@example.com; ruf=mailto:dmarc+ruf@example.com;
Separate addresses or plus tags let mailbox filters sort RUA and RUF into different folders. Tags alone do not create separate mailboxes or access permissions. The distinction between report types is explained in RUA and RUF.
DMARC aggregate reports delivered to a plus-tagged RUA email address.
Using plus tags to organize reports
Use different plus tags for domains or subdomains that have their own DMARC records. The addresses can share one base mailbox while giving recipient filters distinct values to match.
Different RUA tags sharing one mailboxdns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc+main@example.com;" _dmarc.news.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc+news@example.com;"
Create filters for dmarc+main@example.com and dmarc+news@example.com to label reports or place them in separate folders. Test that each filter preserves the attachments for parsing.
The tag organizes delivery. The XML report identifies the DMARC policy domain; a tag does not select particular messages or change SPF and DKIM checks. When Suped supplies a reporting address, copy it exactly rather than adding or changing a tag.
External RUA authorization
External report authorization is separate from plus addressing. If example.com publishes a DMARC record that sends reports to an address at reports.net, receivers need proof that reports.net agreed to receive those reports.
RFC 9990 requires the authorization check when the destination and the DMARC policy domain have different organizational domains. The receiving domain publishes a DNS TXT authorization record. Without valid authorization, a conforming receiver must ignore that external RUA destination. The plus tag does not change this domain-level check.
External RUA authorization exampledns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc+rua@reports.net;" example.com._report._dmarc.reports.net. TXT "v=DMARC1;"
The first record is published for example.com; the second is published by the operator of reports.net. The authorization owner name uses the domain where the DMARC policy was retrieved and the destination email domain, not the mailbox name or plus tag.
When Suped supplies the reporting address, Suped's hosted DMARC setup identifies the policy record to publish on your domain. External authorization is controlled by the reporting destination's domain. For the DNS authorization pattern, see external DMARC reports.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Google Workspace handling
Google Workspace receives DMARC reports as email attachments; interpreting the XML needs a parser. RFC 9990 recommends GZIP compression (.xml.gz), but reports also arrive as uncompressed XML or in formats used by older implementations. A normal mailbox also has storage limits, attachment policies, routing rules, security scanning, and rate controls. Check these controls if report ingestion fails.
|
|
|
|---|---|---|
Address | Send mail to the tagged address. | Proves routing works. |
TXT | Query the live DNS record. | Proves DNS preserved it. |
Policy | Check attachment rules. | Prevents lost XML files. |
Domain | Compare the destination and policy organizational domains. | Identifies whether external authorization is required. |
Plus-addressed RUA checks before relying on a mailbox
Google Admin console routing settings relevant to plus-addressed mail.
Mailbox versus reporting platform
For a small sender testing a basic DMARC setup, a tagged Google Workspace mailbox can confirm that reports are being requested and received. For ongoing policy decisions, process the machine-readable files with a reliable parser and review authentication failures over time.
Suped's DMARC reporting product collects aggregate XML reports and groups sources with their DMARC, SPF, and DKIM results. Sender-specific fix steps help investigate failed domain matching. Suped's hosted DMARC product keeps policy changes and report monitoring in the same workflow.
Plus-tagged mailbox
- Setup: Quick if the mailbox provider already supports plus tags.
- Cost: Usually no new spend if the mailbox already exists.
- Limit: Reports pile up as XML attachments and do not explain what to fix.
Suped workflow
Setup: Add the reporting address and verify the domain inside the platform.
- Visibility: See sources, pass rates, policy readiness, and failures in one place.
- Fixes: Automated issue detection turns report data into specific next steps.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
How to test a plus-addressed RUA mailbox
Test the RUA address in layers. This keeps the failure point clear and avoids waiting a full reporting cycle before noticing a basic routing problem.
- Create the mailbox: Make sure the base mailbox or alias exists before publishing the DMARC record.
- Test the plus address: Send a normal message to the tagged address and confirm delivery.
- Publish the record: Publish one DMARC TXT record at _dmarc.example.com. Add reporting destinations to that record rather than publishing a second DMARC record.
- Query DNS: Confirm the live TXT value contains the same RUA string you intended.
- Wait for reports: After traffic reaches a receiver that sends aggregate reports, allow at least a daily reporting cycle, then check inbox, quarantine, and delivery logs. DNS caching can delay the change.
- Move to parsing: Once reports arrive, use a parser to review authentication results over time.
DNS query examplesbash
dig TXT _dmarc.example.com +short nslookup -type=TXT _dmarc.example.com
If the record contains multiple reporting addresses, separate them with commas. Keep the mailto: prefix on each destination. Use one rua tag containing the list, not repeated rua tags or multiple DMARC records. More detail on that syntax is covered in multiple RUA URIs.
Multiple plus-tagged RUA destinations in one recorddns
v=DMARC1; p=none; rua=mailto:dmarc+rua@example.com,mailto:archive+rua@example.com;
Both addresses must receive mail, and receivers choose whether to generate reports. Expect reports only after a reporting receiver has observed traffic using your domain; publishing RUA alone does not trigger a test report.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Common mistakes
Most mistakes around tagged RUA records are simple, but they waste time because the symptom is quiet: reports just do not appear.
Do not troubleshoot only the plus sign
If reports are missing, check the whole delivery path. The plus sign is valid, but filters, missing aliases, external RUA authorization, and report attachment handling can all stop reports from landing where you expect.
|
|
|
|---|---|---|
No reports | No receiver report yet. | Wait a reporting cycle. |
Bounces | Base mailbox is missing or tagged-address routing fails. | Confirm the base mailbox and delivery to the exact plus address. |
Some reports | Receivers vary. | Track over time. |
XML unreadable | Manual inbox workflow. | Use parsed reporting. |
Symptoms and likely causes
Another mistake is publishing a DMARC record with no useful reporting destination just to satisfy a checkbox. A record without RUA can still express policy, but it gives you no aggregate visibility. That tradeoff is discussed in this Server Fault thread on missing RUA tags. Keep RUA in place unless there is a clear operational reason not to collect reports.
Recommended setup
A plus-tagged RUA mailbox is acceptable if delivery is tested and reports are processed regularly. Choose the reporting workflow based on review workload and policy decisions, rather than the presence of a plus sign.
A practical setup looks like this: publish a DMARC record at _dmarc.example.com, start with p=none, collect reports long enough to identify legitimate senders, fix sources that fail DMARC domain matching, and then move through quarantine to reject when the data supports it.
When to move past a mailbox
Use report volume and operational need to decide when a plus-tagged inbox is no longer enough.
Low need
Mailbox ok
Basic compliance check, low send volume, no policy move planned.
Medium need
Parser needed
Multiple senders, some failures, policy staging planned.
High need
Platform needed
Business domain, enforcement target, many sources or clients.
If you are creating a record from scratch, Suped's DMARC record generator can help produce the initial TXT value. After that, monitor the reports and remove authentication gaps before enforcement.
Views from the trenches
Best practices
Use a dedicated reporting destination so XML attachments are parsed, grouped, and retained.
Use RUA addresses in the same organizational domain, or confirm external authorization first.
Test the tagged mailbox directly before assuming receivers will deliver aggregate reports.
Common pitfalls
Treating a strict web validator as protocol proof can lead teams to avoid valid addresses.
Pointing reports at a personal inbox creates unread XML piles and missed authentication issues.
Forgetting external RUA authorization makes valid reporting addresses appear broken.
Expert tips
Use plus tags for routing, but use a parser when report data needs real operational value.
Check mailbox security rules because compressed XML files can be quarantined silently.
Route RUA and RUF to separate folders to keep aggregate and message-level reports distinct.
Marketer view
Marketer from Email Geeks says plus addressing can be blocked by some record builders, so the live DNS value and real delivery test matter more than the builder warning.
2024-01-18 - Email Geeks
Expert view
Expert from Email Geeks says the plus sign is a valid email address character, and sophisticated aggregate report senders should handle it correctly.
2024-01-18 - Email Geeks
Frequently asked questions
Yes. RFC 6068 permits a literal plus sign in a mailto address local part, such as dmarc+rua@example.com. Delivery requires the receiving mailbox to accept and route that exact address.
No encoding is needed. RFC 6068 also permits %2B, but a literal plus sign is valid in the RUA mailto URI. Query the live TXT record to confirm the DNS interface preserved it.
If the plus sign is the stated reason, the generator has a validation rule that is stricter than mailto URI syntax. Check the rest of the record, confirm the live TXT value, and test real mailbox delivery.
Yes. Google Workspace supports tagged variations of an existing address. Send a test message to the exact tagged address and check routing, quarantine, and attachment policies.
Yes. RFC 9990 requires external reporting authorization when the destination and the DMARC policy domain have different organizational domains. The receiving domain publishes that DNS authorization; without it, conforming receivers ignore the destination. Changing the plus tag does not change this check.
Use a normal inbox for short testing or a small setup. DMARC aggregate reports are XML files intended for parsing. Suped's product collects and parses them for ongoing monitoring and enforcement work.
