NordVPN Promotion

Home / Blogs

What Does It Mean to Deploy DMARC?

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

The IETF’s DMARC working group is thinking about a maintenance update to the DMARC spec, fixing bits that are unclear and perhaps changing it where what mail servers do doesn’t exactly agree with what it says. Someone noted that a lot of mailers claim to have “deployed DMARC,” and it’s not at all clear what that really means.

Deploying DMARC seems to mean any subset of these:

1a. Publish a DMARC record

Publishing a DMARC record just means to put a record in the DNS that has a name like _dmarc.bigbank.example and has contents that are in DMARC syntax.

1b. Publish a DMARC record with a restrictive policy

The record contains p=quarantine or p=reject.

2a. Evaluate DMARC status of incoming messages

For an incoming message, see if there’s a DMARC record that matches the From: address, if so check if the message has passes, SPF and/or DKIM, and determine whether the message passes or fails DMARC. The mail server would generally add an Authentication-Results: header to the message to show what it did.

2b. Use that status to manage message disposition

If the status is DMARC failure and the policy is quarantine or reject, do something appropriate. (I’m being deliberately vague here since it’s up to each receiver to decide how to treat each sender’s DMARC policy.)

3. Collect reports

Publish a DMARC record with rua and ruf mailto: addresses and receive mail at those addresses. Since the reports are intended to be processed automatically and there can be a lot of them, systems will generally feed them to scripts that extract the interesting parts into a database and produce reports, but there’s nothing in the spec that requires doing anything beyond receiving them. There are services that will do the collecting and analysis if you don’t want to collect and extract yourself.

4a. Send aggregate reports

Save the results from item 2a and use them to send aggregate reports to domains who ask for them.

4b. Send failure reports

Use the results from item 2a to send failure reports to domains who ask for them.

The DMARC spec has a section Minimum Implementations which says that a minimum implementation has to do all of these things, except it can just send or just receive reports. In practice, that doesn’t seem to match what people actually do.

Bulk senders often do items 1b and 3, without necessarily doing anything special on their incoming mail. Lots of mail systems do items 1a or 1b and 2a and 2b but don’t send reports. Hardly anyone sends failure reports since they send copies of messages to people who may or may not have had anything to do with the message in the first place, a privacy disaster waiting to happen.

I’ve suggested that we could write a DMARC deployment guide that describes the parts of DMARC, the ways they interact and in what sequence it’s useful to deploy them. If you’d find that useful, leave a comment.

By John Levine, Author, Consultant & Speaker

Filed Under

Comments

A deployment guide would be really helpful. Todd Knarr  –  Jun 1, 2019 10:28 PM

A deployment guide would be really helpful. The setup isn’t technically hard, but it takes experience to judge which parts are useful for what kinds of organizations.

On failure reports, I lean towards not sending them but not because of any privacy concerns. It’s more that those reports are really only useful to a domain owner who intends to take some action against senders trying to impersonate them, and I don’t know of any domains that dedicate resources to that.

As the person that brought this up Jim Fenton  –  Jun 4, 2019 9:02 PM

As the person that brought this up on the DMARC mailing list, thanks for bringing this forward.

A deployment guide would be very helpful, but I’m not sure it necessarily answers the “what is DMARC” question. It may not be possible to keep people from saying that they “deployed DMARC” but it might be good to include some more specific terminology that can be used, like “publish DMARC policy”, “observe DMARC policies”, and “send periodic DMARC reports on request”.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

Cybersecurity

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

NordVPN Promotion