DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication protocol. It builds on the widely deployed SPF and DKIM protocols, also adds a reporting function that allows senders and receivers to improve and monitor protection of the domain from fraudulent email, making secure email communication possible.
The Spammers often ‘forge’ or ‘fake’ the ‘From addresses’ in the emails, and make it appear as it comes from your domain. To prevent this type of abuse using your domain, and to let the other recipient domains know about your outgoing domain policies, you can publish a DMARC record, using which the email services which use the DMARC standards can handle the unauthenticated emails. This also helps in controlling Email Backscatter and Phishing activities using your domain and helps protect your domain’s reputation.
Before publishing DMARC #
A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and instructs the receivers about the action, if both the SPF and DKIM checks fail, like Quarantine or reject the message. DMARC helps the receiver to handle the failed messages better, and hence limits or removes the end recipient’s exposure to such spoofed emails using the Domain. DMARC also provides a way for the email receiver to report back to the sender about emails that pass and/or fail DMARC evaluation.
The DMARC policy will be effective, only if you send all the emails using your own domains. Email sent on behalf of your domain, via third party services will appear unauthenticated, and may be rejected based on your DMARC policy published. To authorize the emails via third party providers, you need to share the DKIM key to be included in the headers, or the emails should be sent via the SMTP servers which already has the authorized DKIM Keys and SPF records published.
You need to configure the SPF Records and DKIM Keys for your domains before you publish the DMARC Policy. The DMARC policy is based on SPF and DKIM Keys, to ensure email authenticity. An email using your domain’s email address, which fails the SPF test and/ or the DKIM test, will trigger the DMARC policy.
Publishing DMARC Policy #
To publish the DMARC policy, you need to create a TXT record in your DNS in the following format.
Name of the TXT Record:
_dmarc.yourdomain.com where yourdomain.com has to be replaced with your domain name.
TXT Record Value:
“v=DMARC1; p=none; rua=mailto:admin@yourdomain.com”
The p=none is the basic policy that is recommended. You can later change it to p=quarantine and then to p=reject.
Rollout DMARC Policy in a Phased Manner #
We highly recommend to rollout DMARC policy in a phased manner. To roll out in a phased manner, you will change the parameter ‘p’ from none to quarantine and finally to reject. Similarly, during Phase 2 or (Quranantine phase) and Phase 3 (Reject phase), you can make use of the optional parameter ‘pct’ to control the percentage of emails that are being quarantined or rejected.
Phase 1: Monitor Reports and Traffic #
“v=DMARC1; p=none; rua=mailto:admin@yourdomain.com”
You can set the policy to p=none in this phase. This sends you the reports of violation to the email address specified in the policy. The reports provide you information about the anomalies in emails, about the source of the emails that do not get Signed, or the emails that appear to be Spoofed. You can review the sources, and maybe include the valid IP addresses in your SPF records or configure the source with DKIM if they’re legitimate. Once you find the reports with only valid spoofed emails, you can change the policy to Quarantine.
Phase 2: Quarantine Emails and Analyze #
“v=DMARC1; p=quarantine; rua=mailto:admin@yourdomain.com”
You can set the policy to p=quarantine in this phase. This sends you the reports of the violation to the email address specified in the policy, and also sends such emails to Quarantine. You can monitor the emails in the Quarantine and approve or reject emails from the Quarantine. You can revisit your reports and also monitor the Quarantine emails.
You can also make use of the ‘pct‘ parameter in the DMARC TXT record template, to specify the percentage of emails to be affected by the policy in phase 2, and slowly increase the percentage to 100% to make the deployment to be complete. The important aspect is to ensure that you monitor the email reports regularly to ensure that valid emails do not get rejected or affected.
“v=DMARC1; p=quarantine; pct=20; rua=mailto:admin@yourdomain.com”
In the above example, only 20% of the emails that appear spoofed will be quarantined, and the rest of the email details will be included only in the reports.
Once you change the TXT record to the above example and remove the pct parameter, all the emails that do not pass the DMARC policy will be rejected.
Once you are confident that only spoofed emails will be rejected and all valid emails are signed, you can change the policy to ‘Reject’ to completely roll out DMARC.
Phase 3: Reject Spoofed emails #
“v=DMARC1; p=reject; rua=mailto:admin@yourdomain.com”
You can set the policy to p=reject in this phase. The emails that are spoofed using your domain name, will be rejected after you make this change. You can keep track of the rejected emails, via the reports you receive via email to the email address provided in the TXT record.
