Frequently Asked 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 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, what should I do?

DMARC introduces the concept of aligned identifiers. It means the domain in the from header must match the d= in the DKIM signature and the domain in the mail from envelope.

You have a few solutions:

• operate as a strict forwarder, where the message is not changed and the validity of the DKIM signature is preserved
• introduce an "Original Authentication Results" header to indicate you have performed the authentication and you are validating it
• take ownership of the email, by removing the DKIM signature and putting your own as well as changing the from header in the email to contain an email address within your mailing list domain.

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:

• Announcement in official GMail blog
• Q&A at about.com

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. For more information on the report format, see Appendix E of the DMARC specification.

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 emails:

• 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.

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.

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.

We would like to publish a list of companies known to have implemented DMARC, but as more companies adopt DMARC it would be difficult to keep accurate.

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.

We would like to publish a list of companies known to have implemented DMARC, but as more companies adopt DMARC it would be difficult to keep accurate.

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.