DMARC without rua... proper format?

Question

Yahoo and Google are now requiring DMARC according to Shopify. I have been setting them up for my clients, but I don't need the aggregate reporting. I only need it so that these companies can verify the legitimate sender if needed. I read that you can remove the rua but want to make sure that the client emails are still accepted. Currently, i have it written as : v=DMARC1; p=none; rua=mailto:dmarc-reports@mydomain, mailto:artist@mydomain Would I instead use v=DMARC1; p=none; mailto:artist@mydomain ??
I am not sure how the verification works with the dmarc. My host adds the _dmarc.mydomain so I don't have to add that.

Answer 1

TL;DR: v=DMARC1; p=none; is syntactically valid but doesn't make any sense in practice.

You are taking the easy way out and it will backfire. It is true that the Google's Feb 1, 2024 requirements regarding DMARC are loose. On the other hand, the next requirement looks like Google would be requiring alignment even with the p=none policy.

• Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none. Learn more
• For direct mail, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.

But that's just the very beginning of using DMARC policies. The p=none is for transition phase where you don't yet know whether the delivery of legitimate would pass an actual DMARC enforcement. You are stating that you don't need the aggregate reporting, but I disagree. Getting and reading the aggregate reports is the only way to gain the knowledge required for smooth email delivery in the next phase. Furthermore, Google & Yahoo might start to enforce that next, too.

You also say that the companies should be able "to verify the legitimate sender if needed". The p=none does not provide that; it says that we are taking a step forward DMARC enforcement, but at this point we don't care how the receiver treats email spoofed from our domain.

Later, when you have at least p=quarantine and your email infrastructure is static and stable you might remove the rua= with the consequence that you wouldn't know if legitimate mail starts to get quarantined. With p=reject you would know that from the rejected messages. However, e.g., Microsoft treats p=reject just like it was p=quarantine.

Answer 2

You will only receive DMARC reports if you set the rua tag, a minimal DMARC record to comply looks like this:

v=DMARC1; p=none;

The tags that can be used for the record are:

• v (required) - The version tag. The only allowed value is "DMARC1". If it's incorrect or the tag is missing, the DMARC record will be ignored.List item
• p (required) - The DMARC policy. Allowed values are "none", "quarantine", or "reject". The default is "none," which takes no action against non-authenticated emails. It only helps collect DMARC reports and gain insight into your current email flows and their authentication status. "quarantine" marks the failed emails as suspicious, while "reject" blocks them.
• rua - Aggregate report sending destination. It's the "mailto:" URI that ESPs use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
• ruf - Forensic (Failure) report sending destination. It's the "mailto:" URI that ESPs use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
• sp - The subdomain policy. The subdomain inherits the domain policy tag (p=) explained above unless specifically defined here. Like the domain policy, the allowed values are "none," "quarantine," or "reject." This option isn't widely used nowadays.
• adkim - The DKIM signature alignment. This tag follows the alignment between the DKIM domain and the parent Header From domain. Allowed values are "r" (relaxed) or "s" (strict). "r" is the default and allows a partial match, while the "s" tag requires the domains to be the same.
• aspf - The SPF alignment. This tag follows the alignment between the SPF domain (the sender) and the Header From domain. Allowed values are "r" (relaxed) or "s" (strict). "r" is the default, and allows a partial match, while the "s" tag requires the domains to be exactly the same.
• fo - Forensic reporting options. Allowed values are "0," "1," "d," and "s." "0" is the default value, which generates a forensic report when both SPF and DKIM fail to produce an aligned pass. If either of the protocol outcome is something other than pass, use "1." "d" generates a report when DKIM is invalid, while "s" does the same for SPF. Define the ruf tag to receive forensic reports.
• rf - The reporting format for failure reports. Allowed values are "afrf" and "iodef". pct The percentage tag. This tag works on domains with "quarantine" or "reject" policy only. It marks the percentage of failed emails a given policy should be applied to. The rest falls under a lower policy. For example, if "pct=70," on a domain with "quarantine" policy, it applies only 70% of the time. The remaining 30% goes under "p=none". Similarly, if "p=reject" and "pct=70," "reject" applies to the 70% of failed emails, and the 30% go into "quarantine."
• ri - Reporting interval. Marks the frequency of received XML reports in seconds. The default is 86400 (once a day). Regardless of the set interval, in most cases, ISPs send the reports at different intervals (usually once a day). v The version tag. The only allowed value is "DMARC1". If it's incorrect or the tag is missing, the DMARC record will be ignored.

Don't forget to use SPF and DKIM otherwise, DMARC will not work.

You should consider using a DMARC processing service to detect any unauthorized usage of your domain and guarantee deliverability in the future.

Please take some time to read a little more about DMARC at https://dmarc.org/