DMARC What it Does

DMARC is the Domain-based Message Authentication, Reporting, and Conformance technology used to secure internet web domains by providing validation mechanisms that allow for receivers of email from the DMARC protected domain to determine the authenticity of the email being received.  What this means is that it helps protect end users from receiving spoofed emails, whereby an attacker sends an email via SMTP impersonating or spoofing the sender’s email address.  With effective configuration of DMARC, the message is validated against the identifying domain’s encryption keys as to genuineness.  Impostor emails can be automatically blocked or filtered, thereby protecting potential receivers from being tricked into clicking on an apparently legitimate message.   Effective use of DMARC enables the receiver to determine if the relaying email server IP is legitimately connected to the published IP address for the domain using DMARC.  In order to implement DMARC for a domain, SPF and DKIM configurations need to be added to DNS.  DKIM may not be available on non-enterprise hosting services, such as Godaddy’s Office 365 outsourced email service.  An SPF record is a DNS entry record that identifies the allowed mail servers that are permitted to send email on behalf of the domain.  For example, my SPF record is” v=spf1 include:spf.protection.outlook.com -all”.  This helps receiving mail servers know to reject any email originating from an email relay server other than spf.protection.outlook.com.  Unfortunately, my hosting plan doesn’t presently allow for DKIM so I am unable to make my own domain DMARC compliant.  This is less of an issue for blogs, but much more important for shipping carriers, online fax/email service companies, and the like that send out emails of a nature that have file attachments sent to recipients that the receiver may be induced to open.

When a message is being relayed via SMTP, if DMARC has been enabled, along with the required SPF and DKIM dependent configurations, the message can be blocked from being sent completely (reject), sent automatically to the receiving user’s spam folder (quarantine), or delivered without any alteration (none).  Configuring DMARC with the none setting is similar to a police office that keeps her bullet proof jacket in the trunk of her squad car.  Why bother?  If you are trouble shooting and attempting to learn more about what specific messages are having problems, you may want to set DMARC to the none setting temporarily so those messages can be examined in further detail.

Configuring DMARC for your domain involves adding the following record customized as required to your domain’s controlling DNS server.

“v=DMARC1; p=quarantine; rua=mailto:dmarc@mydomain.com; ruf=mailto:dmarc@mydomain.com;”

• v=DMARC1 denotes the version of DMARC this record conforms to. If this isn’t set exactly to the current version of DMARC, DMARC1, messages will be discarded.
• p=quarantine – This is the Requested Mail receiver policy.   The options for this include: (source: https://tools.ietf.org/html/rfc7489#page-15 )  This is important in that using quarantine will automatically have messages from your domain that are actually spoofed messages by pass most corporate email systems, sending the message to the junk mail folder.  Using reject may result in undesirable outcomes, so I recommend quarantine as a reasonable safeguard to protect others against spoofing of your domain.

  • none: The Domain Owner requests no specific action be taken regarding delivery of messages.

  • quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean “place into spam folder”, “scrutinize with additional intensity”, and/or “flag as suspicious”.

  • reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.

• rua=mailto:dmarc@mydomain.com – This is where aggregate feedback messages are sent that can include summary comma delimited information for review by the domain holder.
• ruf=mailto:dmarc@mydomain.com – This is the address where feedback on DMARC violations are sent on a per instance basis when an email fails to meet DMARC validation requirements.  Many administrators may want to use separate emails for these, since the volume of messages sent to the ruf email is a magnitude of significance higher than the rua email contact.

A DMARC record for a domain can be retrieved using one of many free online tools such as https://stopemailfraud.proofpoint.com/dmarc/?lookup=

I encourage you to directly check out your own organization as well as other important domains to see if they are using DMARC to help block fraudulent emails by either sending them to the SPAM folder automatically or by completely protecting messages that fail DMARC authentication from being relayed.  If all of our shipping carriers, electronic billing services providers, faxing and online contract signing services implemented DMARC effectively, much of the phishing emails that purport to be shipping documents or invoices that infect end users could be automatically blocked or sent to the junk mail folder if these service providers implement DMARC securely.