Strategies, techniques and best practice

Discover the MailUp resources that teach you about email marketing strategies and techniques and provide practical advice for relevant campaigns.

Implementing a DMARC Policy with MailUp

What is DMARC?

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.

How does DMARC work?

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.  

DMARC author to recipient flow

Image courtesy of www.dmarc.org



Why it was created

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.

How much does DMARC cost?

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.

Does MailUp support DMARC?

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:
  • Create a new mailbox (e.g. bounce@myCompany.com) on the same domain used as the FROM address (e.g. you use news@myCompany.com as the FROM address in your newsletters).
  • Open a support ticket indicating the POP server, username and password to retrieve messages from the new mailbox.
  • This new mailbox will become your envelope-sender
  • Insert in the DNS records for that domain an SPF record (see implementing SPF authentication for messages sent with your MailUp account)
  • Insert in the same DNS records, the DMARC record. It can change depending on what you want your DMARC policy to be. For example, your DMARC policy could be:  “v=DMARC1; p=none; rua=mailto:dmarc-feedback@mycompany.com; ruf=mailto:auth-reports@mycompany.com” The policy listed above tells the receiving server not to do anything with the messages being observed (“p=none”, where “p” stands for policy), but rather to “monitor” them and send back aggregate (“rua”) and forensic (“ruf”) reports (more detailed reports). This allows you, the sender, to verify that your SPF configuration is correct and that legitimate messages that you are sending are correctly getting authenticated. It also allows you to find out whether there are unauthorized messages that are being sent using your domain (e.g. by a hacker). Note that the email addresses that receive the aggregate and detailed reports (“rua” and “ruf”) can be on any domain. They do not need to be on the domain used for the authentication. They are for reporting purposes only.
  • One you have verified that all legitimate messages are correctly getting authenticated (the reports show “accept” for all of them), you can switch from a monitoring to an active filtering mode by changing the “p” parameter (the policy). The DMARC policy could become: “v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@mycompany.com; ruf=mailto:auth-reports@mycompany.com” In this scenario, the messages that are not aligned (i.e. they do not authenticate) are not rejected, but rather “quarantined”.
  • You can use another parameter to indicate the percentage of non-aligned messages that should be rejected with a DMARC policy structured as follows: “v=DMARC1; p=reject; rua=mailto:dmarc-feedback@mycompany.com; ruf=mailto:auth-reports@mycompany.com; pct=10” … where “pct=10” indicates that the policy of “reject” will be applied to 10% of the messages that fail to authenticate (“pct” stands for percentage).
  • Once you are sure that everything is working properly, you can change the policy so that 100% of the messages that fail to authenticate (i.e. are “not-aligned” in the DMARC definition) will be rejected. “v=DMARC1; p=reject; rua=mailto:dmarc-feedback@mycompany.com; ruf=mailto:auth-reports@mycompany.com”

DMARC reports

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.

Domains and Rejected Emails

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. To get around this project, either make sure that all emails go through the same SMTP servers, or use the strict DMARC policy only for the domain used for your bulk messages, and different domain for company emails. 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.

Who should use DMARC?

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.

DMARC Configuration Testing

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 checkmyauth@auth.returnpath.net and they will analyze it and send a report back to the FROM address.

Frequently asked questions on DMARC

I’m still confused: what are the advantages of using DMARC?

There are several advantages:
  • You can receive reports that can help you find out if somebody is sending unauthorized email from your domain (e.g. as part of a phishing scam).
  • You can gradually implement it.
  • When you implement it in strict mode ( = rejection of 100% of the messages that fail the DMARC test), it can help you substantially reduce successful phishing attacks against many of your customers (those that have an email account with the large mailbox providers that support DMARC).
Do I need to implement both SPF and DKIM authentication? No, only one of the two is needed. A check for both authentication methods is performed, but only one “pass” is needed.Only a failure of both tests will yield a failure under DMARC

MailUp and DMARC: next steps

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. DMARC white paperTake advantage of this important new tool to make sure that legitimate messages are received, while unauthorized ones don’t hurt either you or your customers.
  • OVS
  • LoveTheSign
  • Yamaha
  • Banca Popolare di Milano