In a nutshell, DMARC allows a domain owner and sender of email message to ask mailbox providers not to deliver unauthorized messages that appear to have been sent from the same domain. This helps in the prevention of phishing schemes.
Technically speaking, DMARC - which stands for Domain-based Message Authentication, Reporting & Conformance - is a system that builds on the DKIM and SPF authentication protocols to help receiving servers (e.g. Gmail, Yahoo!, Hotmail, etc.) know what to do when a message cannot be authenticated, and send reports back to the sender about the messages that are being received (so the sender can gauge the extent of the phishing problem, if there is one).
Although not yet an official Internet standard, DMARC is already used by Google (Gmail) and Yahoo! Mail and is being implemented by other large email receivers. You can find more about at www.dmarc.org and by reading our White Paper: DMARC catches the big Phish.
The system is quite simple in theory. The sender will need to implement SPF and/or DKIM authentication with the same domain used as the FROM address (see implementing SPF authentication for messages sent with your MailUp account). The DMARC "test" consists of checking that the two domains (the domain used for authentication and the one used in the FROM address) match, at least at the organizational level (e.g. news.mailup.com and marketing.mailup.com are not the same, but they match at the organizational level).
A message must fail both SPF and DKIM authentication checks to also fail the DMARC test. A single check failure using either one of the two authentication methods allows the message to pass DMARC.
A message could authenticate, but still fail the DMARC test if there is no "alignment" between the domains, as described above.
A new record in the DNS of the domain used in the FROM address - the DMARC record - will instruct the receiving server on what to do if the DMARC test fails (accept, discard, reject, quarantine).
Before DMARC, the receiving server had to decide what to do in that circumstance, potentially making an incorrect decision. If authentication fails should messages be rejected or not? Before DMARC, there was no clear indication for the receiving server on what to do. That's the first benefit of using DMARC: it's the sender that can instruct the receiver on how to handle messages that don't authenticate.
Another benefit of implementing DMARC consists of detailed reports that are aggregated and periodically sent to the sender, indicating which messages were rejected and why.
Image courtesy of www.dmarc.org
DMARC was created as part of an initiative by PayPal and Gmail to combat phishing, which is the illegal practice of attempting to collect confindential information (e.g. user name, password, etc.) by pretending to be someone that you are not. It started with PayPal and Gmail because financial institutions like PayPal are the typical target of phishing schemes, and Gmail is one of the largest providers of email boxes.
DMARC has been endorsed by many major players such as Microsoft, Yahoo!, AOL, Bank of America, Facebook, Comcast, Fidelity, Linkedin, Cloudmark, ReturnPath. As of June, 2012, Google (Gmail) and Yahoo! Mail have implemented the DMARC specifications. Other ISPs have adopted them and are in the process of implementing them.
Its main objective remains to limit the fraudulent use of the sender's domain (e.g. for phishing). For example, if hackers were able to obtain a company's client list and then tried to send those recipients an email pretending to be that company (e.g. to try to obtain user names and passwords) with a DMARC policy active, the receiving servers would be able to reject the messages (they would never get to the recipients' inbox). The only option for the hackers would be to use a different sender (a FROM address with a different domain).
Note that DMARC has nothing to do with determining whether a message is SPAM, but rather on whether the message is consistent with ("aligned") with the authentication method used (e.g. SPF or DKIM). Implementing DMARC, therefore, will not help you with SPAM filters.
To read more about phishing and DMARC, see our White Paper: DMARC catches the big Phish.
There is no cost. It's just a matter of adding a record to your DNS. Your IT department can help you do so, or you can contact our technical support team and we can assist you with it.
Yes, when you add the Private Labeling feature to your account, you are able to customize the envelope-sender used by your MailUp account.
In order to minimize the risk of a substantial amount of messages possibly being rejected due to a faulty implementation of DMARC, we recommend a phased implementation of the system. Specifically:
As mentioned above, as of May, 2012, only Gmail has implemented the DMARC specificatoins and is sending aggregate reports. Note that the email addresses to which the reports are sent can be on any domain, not necessarily the domain used by the FROM address.
There's something to be careful about when implementing a strict DMARC policy: if the policy instructs the sender to reject 100% of the messages that are not authenticated, emails sent from your domain, but which do not authenticate (e.g. because their are sent through a different email provider that uses a different envelope-sender), would be rejected.
Applied to your MailUp account, this would mean that you could register a third-level domain (e.g. news.mycompany.com) and use it for your FROM address, for the envelope-sender, and for SPF and DMARC, and use a different domain for your regular, company email (with this second one used for messages that are sent through providers that may not authenticate).
Of course, this means that you would not protect your company against phishing (or other fraudulent activity) performed on the domain for which DMARC is not implemented.
Any company that wishes to prevent spoofing/phishing of their domain should implement a strict DMARC policy. Since all non-aligned messages are rejected, SPAM sent using that domain would not go through either. Since SPAM sent using your company domain (even if it's not phishing/spoofing) can negatively impact your company image, DMARC can help protect your brand.
If your company is not a well-known brand, and there are no concerns with phishing, then implementing a strict DMARC policy may not be necessary, although you could implement it as a monitoring system (with "p=none", see above) to discover any unauthorized use of your domain for email sending.
If instead you operate in a business where confidential information is exchanged, using a strict DMARC policy becomes extremely important as a new and effective tool to protect both your customers and your company.
How do you know whether your messages are correctly configured for DMARC? One way is to set up your DMARK policy for "monitoring" only and see what kind of reports you receive back. Another way is to use a free service that has been setup by our partners at ReturnPath. You simply need to send a blank email to firstname.lastname@example.org and they will analyze it and send a report back to the FROM address.
MailUp allows you to send messages that are strictly aligned as per the DMARC specifications. This is not the case with all email service providers. Specifically, you need to be able to customize the envelope-sender to align it with the domain in your FROM address, and there are some email service providers that do not have the ability to offer you this option.
MailUp's flexible infrastructure allows you to fully customize your sender profile, including the envelope-sender, thus providing full support for DMARC.