FAQ

From DMARC Wiki
Revision as of 21:39, 8 July 2015 by Dmarcadmin (talk | contribs) (A single-page FAQ listing)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Frequently Asked Questions

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the public DMARC discussion lists. If you don’t see an answer to your question in these collections, you may want to ask your question there.

Contents

General Questions

What is DMARC, and how does it combat phishing?

DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the sender, and what to do if it isn’t. This makes it easier to identify spam and phishing messages, and keep them out of peoples’ inboxes.

DMARC is a proposed standard that allows email senders and receivers to cooperate in sharing information about the email they send to each other. This information helps senders improve the mail authentication infrastructure so that all their mail can be authenticated. It also gives the legitimate owner of an Internet domain a way to request that illegitimate messages – spoofed spam, phishing – be put directly in the spam folder or rejected outright.

Why is DMARC needed?

End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:

  • These mechanisms all work in isolation from each other
  • Each receiver makes unique decisions about how to evaluate the results
  • The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:

  • Domain owners to:
    • Signal that they are using email authentication (SPF, DKIM)
    • Provide an email address to gather feedback about messages using their domain – legitimate or not
    • A policy to apply to messages that fail authentication (report, quarantine, reject)
  • Email receivers to:
    • Be certain a given sending domain is using email authentication
    • Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
    • Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
    • Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

Don’t Receivers use SPF and DKIM results already?

Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

What happens if a sender uses DMARC and ADSP?

ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

What is the difference between the "Mail From" and "From Header", aren't they the same?

In email, like in real mail, there is the concept of an envelope containing the message.

  • The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
  • The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

What is the rationale for choosing ZIP for the aggregate reports?

At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

What does a "quarantine" policy mean in a DMARC record?

Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

Why not introduce a new DNS Record type for DMARC?

There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: DNS Scoped Data Through Attribute Leaves).

Why doesn't (major mailbox provider) publish a DMARC record?

Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

IP Addresses are in various reports, is that a privacy issue?

Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?

The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use this link.

NOTE: The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the specification page.

  • Throughout the spec, "forensic report" has been changed to "failure report."
  • Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
  • It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
  • There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
  • A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
  • Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
  • Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
  • There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
  • The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
  • Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
  • Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
  • Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
  • Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
  • Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
  • The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
  • Acknowledgements were added as a new section. {Appendix E}

Do I need to be a Member of DMARC.org to be protected by DMARC?

No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

Is DMARC.org blocking email messages?

No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the "From:" header - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.


End User Questions

How does DMARC help the End User / Consumer?

The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

Do I have to do anything for DMARC to work?

End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

  • Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
  • Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.


The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

Can I use DMARC to protect messages I send?

DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

How can I tell if my mailbox provider, bank, school, etc is using DMARC?

The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our Resources page for a link to this, and any additional sites that have come to our attention.

How can I find a mailbox provider that uses DMARC?

The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our Resources page for a link to this, and any additional sites that have come to our attention.

How can I tell if a message passed DMARC?

The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

Why isn’t the “Email this article to a friend” button working on website X?

There could be many reasons, depending on how the website in question has implemented this feature. One way commonly used in the past is to simply use your (the site visitor’s) email address and impersonate your email service provider. Unfortunately this is also one of the favorite tactics of spammers, and so a number of blocking mechanisms have been put in place to protect your email address from misuse and filter out the spam. In this case, these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email, so if the website you are using implements this feature as described above, and your email address is in a domain that asserts a DMARC policy, the email may never be delivered. The operator of the website may see DMARC given as the reason for the message being blocked, but the real problem is that the website is not authorized by your mail administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your friend using your favorite personal email program. If you’d like to help improve the website in question, write to them and suggest they stop impersonating site visitors this way, and instead send such messages using an email address of their own. (You can refer them to FAQ Why are messages I send on behalf of visitors to my website being blocked for more information.)

Receiver Questions

My users often forward their emails to another mailbox, how do I keep DMARC valid?

DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

Is there special handling required to receive DMARC email from mailing lists?

Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

I need to implement aggregate reports, what do they look like?

You should refer to the current DMARC specification for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the latest specification.

Please note that the SPF and DKIM results in the auth_results are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the policy_evaluated section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: acme.org!example.com!1335571200!1335657599.zip 

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>acme.com</org_name>
    <email>noreply-dmarc-support@acme.com</email>
    <extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
    <report_id>9391651994964116463</report_id>
    <date_range>
      <begin>1335571200</begin>
      <end>1335657599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>72.150.241.94</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Sender Questions

Why should a Sender care about DMARC?

Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:

  • Collect statistics about messages using their domain from DMARC receivers
  • See how much of this traffic is passing/failing email authentication checks
  • Request that messages using their domain that fail authentication be quarantined or rejected
  • Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?

DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

I operate a mailing list and I want to interoperate with DMARC, what should I do?

Updated 11-April-2014. DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of DMARC for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.
Pros: Receiving systems can validate the DKIM signature of the message author, if one was present.
Cons: Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.
2. Add an Original Authentication Results (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.
Pros: Would allow the recipient to see whether or not the message validated as submitted to the list operator.
Cons: This is not a short term solution. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
No receivers implementing DMARC are currently known to make use of OAR from external sources.
3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.
A. Replace From: address
  • Change the RFC5322.From address to an address within the mailing list's domain
user@example.com => address@mailinglistdomain.com
  • Add DKIM signature using the mailing list's domain
Pros: Messages from the list could pass SPF, DKIM, and DMARC
Cons:Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.
B. Replace From: address, set Reply-To: to message author
  • Change the RFC5322.From address to an address within the mailing list's domain
user@example.com => address@mailinglistdomain.com
  • Set or change the RFC5322.ReplyTo address to the message author
  • Add DKIM signature using the mailing list's domain
Pros: Messages from the list could pass SPF, DKIM, and DMARC
Cons: Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
C. Replace From: address and forward replies
  • Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
  • user@example.com => unique-address@mailinglistdomain.com
  • Add DKIM signature using the mailing list's domain
  • If replies are sent to the unique address, forward them to the associated message author.
Pros:Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.
Cons: List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...


Additional information is available from a number of other sources:

What if miscreants use the display field of the From: to fake my brand/domain?

This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like: 

From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com>

Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

Retrieved from "https://dmarc.org/w/index.php?title=FAQ&oldid=2"