What is DMARC?
DMARC is an acronym for “Authentication, Reporting and Compliance Domain-Based Message,” is a standardization proposal to guarantee the authenticity of an e-mail, and has been very well accepted and widely adopted, including by significant players such as Google and Microsoft.
In October 2015, Google committed to adopt and implement stricter DMARC policies, making it unfeasible for e-mail marketing tools to use e-mail from the domain @gmail.com as the sender.
DMARC is based on SPF and DKIM, which are two widely distributed protection and security mechanisms and adds a unique reporting function that allows monitoring e-mail behavior.
With the correct DMARC setup, it is much simpler and more efficient to determine if a message is legitimately sent from a purported sender; but not just this: DMARC allows you to define what to do if the message is not from the sender.
Before DMARC, senders remained mostly unaware of the problems because there was no practical way to obtain return information.
Whoever deployed the SPF and DKIM, it took time to spot the problems.
DMARC addresses these issues by helping email senders, and recipients work together for better-secure email, protecting users and brands from painfully high out-of-pocket abuse.
How does it work in practice?
Those who send and receive email and have the DMARC set up share all the technical information about the email they send to each other.
This shared information helps senders using DMARC to improve their authentication infrastructure so that all their email can be authenticated and verified.
It also gives the legitimate owner of an Internet domain a way to request that illegitimate messages – counterfeit spam, phishing – be placed directly into the spam folder immediately.
The DMARC policy allows a sender to indicate that messages are protected by SPF and DKIM and tells the recipient what to do if none of these authentications methods work – to trash or reject the message, for example.
What kind of protections does the DMARC configuration offer?
In short, DMARC is designed to protect against domain spoofing straightforwardly.
When a message is sent by an unauthorized sender (if it is sent by a malicious person, or even an unauthorized employee or who do not participate in the department of the company that owns or operates the domain), DMARC can be used to detect unauthorized activity and messages that are improperly sent to be blocked or discarded when they are received at the destination.
The configuration does not protect against other malicious activities. For example, DMARC does not address prime domain attacks (i.e., sending a domain that looks like the target being abused – for instance, exampl3.com vs. example.com), or changing the display name.
Actual application example:
A domain owner who has deployed email authentication can start using DMARC in “monitor mode” to collect data from participating recipients. Because the data show whether traffic is passing authentication checks, they can change their policy to request that the failure messages be quarantined, for example.
If a consistent amount of false e-mail is detected, they may adopt a policy of telling remitters to reject messages.
DMARC – configuration
Prerequisites for creating a DMARC record
For your submissions to be adequately authenticated with the DMARC record, your domain must have validated SPF and DKIM settings in all services where you will use your domain for submissions.
Please note that the email will receive the reports must also be configured. Ideally, it should be from the same domain as the sender.
Creating the DMARC Entry
DMARC uses TXT entries from your DNS.
Hosting services generally provide a specific area, a configuration panel for registering this type of information, called DNS Manager.
And there you will do the DMARC setup.
Below is a table with the most commonly used configuration tags.
Do not panic.
You will understand what it is for:
|pct||Percentage of filtered messages||pct=20|
|street||Address that will receive daily report||street=mailto:firstname.lastname@example.org|
|sp||Policies for subdomains||sp=reject|
|aspf||Alignment mode for SPF||aspf=r|
DMARC Input Examples
In the examples below we will use only 3 FLAGS:
p: to define the policy
street: to define where to send the reports and
v: to inform the version of DMARC we are using
In this example of TXT to DMARC input, if the provider receives a message from your domain and it arrives at the DMARC check, no action will be taken.
However, all these messages will appear in your daily report sent to the registered e-mail. In this example, “email@example.com.”
In this example of DMARC, if the provider receives a message from your domain and it arrives at the DMARC check, the message will be quarantined.
And after, they will be informed in their daily report in the registered email.
In this last example, if the provider receives a message from your domain and it arrives at the DMARC check, the message will be 100% rejected. After, they will be informed in their daily report in the two registered emails: “firstname.lastname@example.org” and “email@example.com.”