FAQ

From DMARC Wiki
Revision as of 03:41, 9 July 2015 by Dmarcadmin (talk | contribs) (Have added anchors to match the old FAQ.html page)
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:

If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?

The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

If only a few Receivers have implemented DMARC, why should I adopt it?

There are a number of reasons you should adopt DMARC as a sender:

  • The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
  • Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
  • As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
  • As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

How can I tell if DMARC is making a difference?

A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

  • Every IP address using your domain to send email
  • A count of messages from each of those IP addresses
  • What was done with these messages per the DMARC policy shown
  • SPF results for these messages
  • DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the Products and Services resources page.

For details of the XML report format, see Appendix C of the DMARC Specification (RFC7489).

Can I implement DMARC gradually without impacting the rest of my mailflow?

Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

Why are there more entries in the reports than the mail I send?

If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

  • coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
  • coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
  • coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
  • that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

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.

Does DMARC “p=none” affect the way my emails get delivered?

No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

When can I expect to receive my first aggregate report?

Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email. 

_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"

A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record: 

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"

Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. 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.

Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?

When you query a DMARC record you often see results like this: 

$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted. 

_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"

If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

Do I want to receive Failure Reports (ruf=)?

Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, every time a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but every email that spoofs your domain will be rejected too and you are asking to get a copy. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports. 

_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"

Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running. 

_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

My organization uses third-parties senders, how can I get them DMARC compliant?

There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.

  1. Integrate externally: The third party sender uses its own mail servers to send your emails.
    1. Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
    2. Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
  2. Integrate internally: Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
  3. Do not integrate and tell them not to spoof: Ask the third party sender to use their own domain in the From: header and if replies are required, either have them to alias this email back to you, or have them set the Reply-To: header to one of your email address. NOTE: In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings.

I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?

To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

DMARC Record: 

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"

Report Authorization Record: 

example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"

Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

What steps should I follow to implement DMARC on my corporate email domain?

Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.

  1. It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. NOTE: Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet.
  2. Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
  3. If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
  4. Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
  5. Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
  6. Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
  7. Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
  8. Whitelist in your DMARC filter all the mailing lists your employees are using
  9. Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
  10. Be mindful there are at least two cases where DMARC is likely to reject emails:
    1. Email forwarding
    2. Mailing lists
  11. Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
  12. Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
  13. Get all third party providers to be DMARC compliant (see this FAQ)
  14. You are ready to move to p=quarantine and/or p=reject
  15. Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, et cetera

How can I put DMARC records on many domains at once?

Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting. 

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"

Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

As a marketing firm, how can I send DMARC-compliant mail for my customers?

There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

My mail is going to the spam folder now, is DMARC the problem?

In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the Authentication-Results header. It may look like: 

Authentication-Results: mail.example.com;
    spf=pass smtp.mailfrom=member@example.com;
    dkim=pass header.d=example.com;
    dmarc=pass d=example.com

This header indicates that the server mail.example.com performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

What changes in the draft submitted to the IETF affect me as a sender?

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 version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the specification page.

  • 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. {6.1}
  • Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
  • The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. 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}
  • DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
  • The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. 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}
  • Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {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}
  • 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}

I have domains that do not send emails, how can I protect them?

The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed.

First create a DMARC record on your main domain (example.com) for all your parked domains: 

_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"

If example.net is a parked domain you can then protect it this way: 

_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"

The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes: 

_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"

This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for example.net at the mailboxes at example.com you must create a Report Authorization Record: 

example.net._report._dmarc.example.com IN TXT "v=DMARC1;"

If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting: 

*._report._dmarc.example.com IN TXT "v=DMARC1;"

However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.


<a name="s_22">

Why are messages I send on behalf of visitors to my website being blocked?

This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the From: header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the From: header, and the Reply-To: header is set to the website visitor’s address, but the actual address used in the From: header clearly indicates that your website is the origin of the message. 

From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"


<a name="s_23">

Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?

Please see the item Is DMARC.org blocking email messages?

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