Time to talk about the SMTP plumbing & those nasty vent traps!

DMARC stands for “Domain-based Message Authentication, Reporting & Conformance.” DMARC is protocol that uses SPF and DKIM to determine the authenticity of an email. SPF (Sender Policy Framework) is a DNS entry and protocol which provides a list of SMTP servers that are considered “permitted”  to send email for a domain. There are 2 “From” addresses in an email message: the envelope From (Return-Path) and header From. SPF verifies the former, however a regular user does not see “Return-Path” and “could” falsely assumes the domain from the header “From” as the sender domain.

SPF is really different from DNS “MX” records, which are also DNS entries, that in the reverse sense, tell sending email servers what IP address/s are to be “contacted” to submit emails for a particular domain. Think of it as “who is the” postman for a particular neighborhood, whereby you call that person/s up and say “hey, I have letter for somebody in your block, can you take that for me and give it to them?”

DKIM on the other hand is a way to “validate” that emails have not been tampered with once they left the domain sending the email. DKIM  is like a “stamp” or “watermark” if you want to think of it that way. Besides validating that an email was not tampered with, DKIM validates the domain in the “From:” header; and one can easily conclude its significance when considering spoofing. A message may have multiple DKIM signatures, every server it passes through may add its own signature, but only the one matching the domain in “From:” is worth considering.

Also, we need to point out that DMARC is perhaps the one “main” thing which makes DKIM signatures quite useful. DKIM signatures are not mandatory and a fake/invalid signature is equivalent to no signature.

DMARC is a policy reporting system that acts when both SPF and/or DKIM fail in order to help inform senders might be spoofing or phishing in ways that enable email SPAM.

Your DMARC record is published alongside your domain DNS records (SPF, A record, CNAME, DKIM, etc.). Unlike SPF and DKIM, a properly configured DMARC policy can tell a receiving server whether or not to accept an email from a particular sender. It is important to note that not all receiving servers will perform a DMARC check before accepting a message, but many of the major ISPs and enterprises do and its implementation is growing rapidly.

Some of the benefits of DMARC

  1. Publishing a DMARC record protects your company brand by preventing “spoofers  bad guys”  from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
  2. Using or ingestion of DMARC reports increases visibility into your email server by letting you know who is sending mail from your domain.
  3. DMARC helps the global email community to establish a consistent policy for dealing with messages that fail to authenticate. This helps the email ecosystem as a whole become more secure and more trustworthy.

What can you do to deploy DMARC on CommuniGate Pro?

CommuniGate Pro has built in features for DMARC and we also have provided some tools to help you get up and running quickly. We also have the best support for the platform by the people that code it! So, when in doubt or when you need some tips or tricks, you can also reach out to the team.

First you can start by setting up DKIM on your CommuniGate Pro platform by following the tips here:

DKIM with CommuniGate Pro

CommuniGate versions 6.2.x have DMARC built-in….see about “Check SPF records” in <Setup tips SPF & DMARC>

We also are providing a script for easy setup and performance of the DMARC features if required in older versions:

CommuniGate Pro script repository

Additional Resources