7

How many emails can I put in one dmarc record? Is the following invalid because there are three mailto attributes? All the examples I see online have two addresses at most.

"v=DMARC1; p=reject; rua=mailto:pm@dom.com, mailto:dmarc@dom.com, mailto: ex@dom.com"
1
  • Looks like you have a problem in your syntax. The spaces after the ',' separating the rua URIs are giving me an error. – Andres Canella Oct 28 '16 at 16:22
9

A few comments.

  1. dmarc.org RUA comment

    If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish.

  2. DNS TXT records are composed of a sequence of strings. "All printable ASCII characters are permitted in the attribute value." (en.wikipedia.org/wiki/TXT_record#Attribute_values) Then, according to the RFC, you can have an arbitrary number of strings, each string might be limited to 255 characters but you can concatenate as many strings as you want.

    a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. If a published record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example:

    IN TXT "v=spf1 .... first" "second string..."

    MUST be treated as equivalent to

    IN TXT "v=spf1 .... firstsecond string..."

    (IETF specification on TXT record concatenation)

(That might be the SPF RFC, but it holds true for all TXT records and happens to be the most concise wording on the topic.)

  1. Then there's the next limit. From your URL:

    Note that any DNS response which exceeds 512 bytes is slightly undesirable, since in the absence of EDNS0 (which the vast majority of -- but not all -- implementations honor these days), responses which exceed 512 bytes will signal truncation and prompt a retry via TCP. It's optimal to stay within 512 bytes if possible.

There's more discussion here. Why DNS through UDP has a 512 bytes limit?

  1. And finally, the last limit, again from your URL (because I can't find it in any RFC):

    I don't believe there is any arbitrary limitation on the number of "string"s in a TXT record, but the RDATA itself may not exceed 65535 bytes in total, which is comprised of both the length-bytes and payloads of all "string"s contained therein. That 64K limit is a general restriction on DNS records of all types, not specific to TXT records.

2
  • Welcome to Server Fault! As we're a Q&A site, and not a forum, please formulate your responses as an answer to the question posed, not as responses to another answer. Once you have sufficient reputation you will be able to comment on other questions and answers. – womble Oct 9 '17 at 5:40
  • Thanks. I just realized ThisClark was also the original poster, so I just re-formatted as though responding to original post. – Weylin Piegorsch Oct 10 '17 at 8:33
7

There does not appear to be a limit to the number of emails you can use in the dmarc rua attribute. However, the size limit of a TXT record in DNS is 255 characters, according to Max. Number of char in a TXT Record so the upper bound on number of emails is limited by that.

I successfully used four emails in my dmarc record, but a better practice is to use one service account and set email forwarding from there. This prevents the need to update DNS records every time an employee changes jobs for example.

2
  • Just one more thing to note about this, If you're using multiple emails with a different domain name, that you follow section 7.1 in the RFC 7489. There's additional steps that you have to take to implement it properly. But having a forwarder would alleviate this concern as well. – Henry Apr 14 '16 at 17:27
  • RFC 7489, section 7.1 - tools.ietf.org/html/rfc7489#section-7.1 – ThisClark Apr 14 '16 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.