With the addition to SpamTitan of support for DKIM singing you can now avail of the DMARC. DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email-validation system designed to detect and prevent email spoofing.  It is a DNS TXT record that you use to create an overall policy governing SPF and DKIM.


Create the record

Once SPF and DKIM are in place, you configure DMARC by adding policies to your domain's DNS records in the form of TXT records (just like with SPF).  


Here are common tags used in DMARC TXT records:


                                                                                                                                                      

Tag NameRequiredPurposeSample
      

v

      
requiredProtocol versionv=DMARC1
      

p

      
requiredPolicy for domainp=quarantine
      

pct

      
optional% of messages subjected to filteringpct=20
      

rua

      
optionalReporting URI of aggregate reportsrua=mailto:aggrep@example.com
      

sp

      
optionalPolicy for subdomains of the domainsp=reject
      

aspf

      
optionalAlignment mode for SPFaspf=r



Only the v (version) and p (policy) tags are required. Three possible policy settings, or message dispositions, are available:

  • none - Take no action. Log affected messages on the daily report only.
  • quarantine - Mark affected messages as spam.
  • reject - Cancel the message at the SMTP layer.


Alignment mode refers to the precision with which sender records are compared to SPF and DKIM signatures, with the two possible values being relaxed or strict. represented by "r" and "s" respectively. In short, relaxed allows partial matches, such as subdomains of a given domain, while strict requires an exact match.


Make sure to include your email address with the optional rua tag to receive the daily reports.


Here are some example DMARC TXT records (_dmarc.your_domain.com IN TXT) you can modify for your own use. Of course, replace "your_domain.com" and "postmaster@your_domain.com" with your actual domain and email address.

  


Example Records:


In this TXT record, if a message claims to be from your domain.com and fails the DMARC checks, no action is taken. Instead, all of these messages appear on the daily aggregate report sent to "postmaster@your_domain.com."

  "v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com"  



In this TXT record, if a message claims to be from your domain.com and fails the DMARC checks, quarantine it 5% of the time. Then email daily aggregate reports to "postmaster@your_domain.com."

 

 "v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com"  



In this TXT record, if a message claims to be from "your_domain.com" and fails the DMARC checks, reject it 100% of the time. Then email daily aggregate reports to "postmaster@your_domain.com" and "dmarc@your_domain.com."

 

 "v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com"




Deploy slowly

We strongly recommend ramping up DMARC use slowly by employing these policies in this order. First, monitor your traffic and look for anomalies in the reports, such as messages that are not yet being signed or are perhaps being spoofed. Then, when you're comfortable with the results, change the TXT record policy setting from "none" to "quarantine." Once again, review the results, this time in both your spam catch and in the daily DMARC reports. Finally, once you're absolutely sure all of your messages are signed, change the policy setting to "reject" to make full use of DMARC. Revisit reports to ensure your results are acceptable.

Similarly, the optional pct tag can be used to stage and sample your DMARC deployment. Since 100% is the default, passing "pct=20" in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is especially useful once you elect to quarantine and reject mail. Start with a lower percent and increase it every few days.

A conservative deployment cycle would resemble:


  1. Monitor all
  2. Quarantine 1%
  3. Quarantine 5%
  4. Quarantine 10%
  5. Quarantine 25%
  6. Quarantine 50%
  7. Quarantine all
  8. Reject 1%
  9. Reject 5%
  10. Reject 10%
  11. Reject 25%
  12. Reject 50%
  13. Reject all


Attempt to remove the percentages as quickly as possible to complete the deployment.


As always, review your daily reports.


Optional DMARC tags
The optional DMARC tags below allow email senders to give more specific instructions on what to do with mail that does not authenticate, removing the guesswork for receivers.

  • rua: Indicates where aggregate DMARC reports should be sent to. Senders designate the destination address in the following format: rua=mailto:domain@example.com.
  • ruf: Indicates where forensic DMARC reports should be sent to. Senders designate the destination address in the following format: ruf=mailto:domain@example.com.

The following optional tags have a default value that will be assumed if the tag is excluded. The list of tags with an assumed default value are:

  • adkim: Indicates strict or relaxed DKIM identifier alignment. The default is relaxed.
  • aspf: Indicates strict or relaxed SPF identifier alignment. The default is relaxed.
  • rf: Format for message failure reports. The default is Authentication Failure Reporting Format, or “AFRF.”
  • ri: The number of seconds elapsed between sending aggregate reports to the sender. The default value is 86,400 seconds or a day.
  • pct: Percentage of messages to which the DMARC policy is to be applied. This parameter provides a way to gradually implement and test the impact of the policy.
  • fo: Dictates what type of authentication and/or alignment vulnerabilities are reported back to the Domain Owner.
  • There are four values to the latter fo: tag:
  • 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned “pass” result. (Default)
  • 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned “pass” result.
  • d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
  • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

While the default is “fo=0,” Return Path advises clients to use fo:1 to generate the most comprehensive failure reports, providing that much more granular visibility into the email channel.

Below is an example DMARC record. Based on what you have learned so far, try deciphering each tag:

v=DMARC1; p=reject; fo=1; rua=mailto:domain@example.com; ruf=mailto:domain@example.com; rf=afrf; pct=100