Let's Be DMARC Compliant

[email protected]

Meet GoDMARC, To save your domain from spoofing and phishing attacks.

In recent times, Spammers have found Email to be a convenient mode to spoof and criminals have found spoofing to be a proven way to exploit user's trust of well-known brands. Simply inserting the logo of a well-known brand into an email gives it instant legitimacy to many user's eyes.

Users find it difficult to differentiate between a real message and a fake one, and often large mailbox providers find it difficult to choose between which Emails to deliver and which one to retract. Senders remain oblivious of the problems with their authentication practises, because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail) deployment, proceed very slowly and cautiously because of the lack of feedback. In other words, it means they have no authentication process to monitor progress and debug problems.

With the help of DMARC (Domain-based Message Authentication, Reporting and Conformance) email senders and receivers work together to secure emails, to protect user's trust and to save brand goodwill from swindling.

At its most essential, DMARC makes it easier for email senders and receivers to determine whether a given message is from a legitimate 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.

No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of ‘example.com’ use DMARC to protect that domain, it would not affect ‘example.net’ (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activities, there are other attack vectors that DMARC does not address. For example, DMARC does not address cousin domain attacks (i.e. sending from a domain that looks like the target being abused - e.g. exampl3.com vs. example.com), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

A DMARC policy allows a sender to indicate that their messages are authenticated by SPF and/or DKIM and tells a receiver what to do if neither of those authentication methods passes – such as quarantine or reject the message. DMARC removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.

End users and companies suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify mail ‘from'. 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 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 (None, 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 (None, 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.

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 webmail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone 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 on how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

After placing the DMARC Record in Domain's 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.

After placing the DMARC Record in Domain's 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.

If you find more entries in the report than the emails you sent, 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 guesswork. You have to consider the reports include authentication results about email messages:

  • coming directly from your infrastructure (your IPs, likely an SPF pass with alignment)
  • Emails relayed from third party applications for Email Marketing, Accounting, HR, CRM etc..
  • coming from your infrastructure via auto email forwarding
  • Phishing Attacks !!! Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send.

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.

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.

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.

It's at the sole discretion of the receiver whether to share the forensic/failure reports with the sender or not. 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.

Not every receiver participates in DMARC reporting (RUA & RUF).

DMARC data is reported on a 24-hour UTC midnight to midnight window, and large environments in particular can take a long time to collate and send the prior day’s data.

By using DMARC you can only protect a domain that you own, from being used in phishing attempts.

If you have received a phishing email from a domain that you do not own then it is the responsibility of the domain owner to implement DMARC and protect its users from being targeted.

By using DMARC you can only protect a domain that you own, from being used in phishing attempts.

If you have received a phishing email from a domain that you do not own then it is the responsibility of the domain owner to implement DMARC and protect its users from being targeted.

CEO Fraud: An Acquisitive Email Scam CEO fraud attacks are dangerous versions of phishing attacks that often use the authority of a company’s CEO to achieve it’s – malicious – goal. By impersonating a CEO, the attacker directs a fake email to an employee (usually from the finance department), typically demanding the employee to make a deposit to the bank account of the hacker. To minimize skepticism and scrutiny, the attacker will create a sense of urgency in the fake email.

The reason why CEO fraud attacks are considered as incredibly dangerous is due to the fact that the attacker relies on the authority of the CEO in order to trick employees into transferring money into their account or providing extremely sensitive data. An email from the CEO will certainly grab employees’ attention, and most employees won’t question the CEO’s order. This increases the chances of employees seeing the email and immediately following through on whatever they were instructed to do. This has become a prolific problem, resulting in losses of millions of dollars for firms of all sizes.

CEO fraud attacks, How does it work?

There are two main ways in which a CEO fraud attack can occur:

  1. Email spoofing attack
  2. Business Email Compromise BEC attack

Email spoofing involves tactics like name spoofing, in which the scammer will use the name of your CEO but a different email address. The email address used can be extremely similar to the targeted company’s domain with some transposition in letter order. By only checking the name or not spotting the differences in the sender’s address, it can lead the recipient into trouble.

DMARC can be in one of three different policies, each one telling your recipients how to treat your emails.

A DMARC record can be set to be in one of three different policies as indicated by the "p=" below:

  1. v=DMARC1; p=none;
  2. v=DMARC1; p=quarantine;
  3. v=DMARC1; p=reject;

P=NONE

Typically, when you implement DMARC for the first time you will start with a policy of p=none. This policy means that you are in ‘reporting-only’ mode and you don't want any policy to be applied to your emails if they fail DMARC. During this stage, you are simply gaining visibility into how your domain is being used around the world and what services are sending emails on your behalf. At this stage, you simply identify your legitimate sending services and configure each one with SPF and DKIM so that they send DMARC compliant emails.

P=QUARANTINE

Once you are confident that your sending services are fully configured you can change your DMARC policy from 'p=none'; to ‘p=quarantine'. This means that from this point onwards, any email that fails DMARC will have this policy applied to them, which means that they will be sent to the spam folder of the recipient email server.

P=REJECT

If you do not encounter any issues during the p=quarantine stage and only spoofing emails are being quarantined you can change the policy once more from ‘p=quarantine’; to ‘p=reject';. At this stage, you are telling recipients to reject any emails that fail DMARC. This means that end recipients will never receive the emails, they will simply be rejected at the SMTP level and will not be found. This is the strongest level of protection which means that no one will be able to spoof your domain. Any emails that do not originate from your legitimate sending services will be rejected as they will fail DMARC.

Strict alignment means that the Return-Path domain or the signing domain “d=” must be an exact match with the domain in the “From” address. Relaxed alignment means that the Return-Path domain or the signing domain “d=” can be a subdomain of the “From” address and vice versa.

GoDMARC is a SaaS solution & Managed Services which empowers enterprises to easily deploy DMARC services. It's designed specifically for the fulfillment of the requirements including Authentication of emails, Robust reporting, Diminish false positives, Stops phishing delivery successfully, Diminish complexity, and more. When combined with Managed Services customers easily attain the strictest level of DMARC (Reject) in a short period. Using GoDMARC, Enterprises gain complete visibility into email authentication status & Gaps of SPF & DKIM. GoDMARC Dashboard segregates Aggregate reports into four easy to understand categories of DMARC Pass & Fail Compliance.