Domain-based Message Authentication, Reporting and Conformance (DMARC) is a mechanism that allows the owner of a sending email domain to tell a receiving system how to treat email that fails certain checks.
This is a semi-technical document that refers to DNS lookups. Setting up a correct DMARC policy should be done properly and is outside the scope of this document.
Note that since DMARC is a DNS-based system and is therefore controlled by the owner of the sending domain, not the actual sender of the email (if those are different).
Why DMARC is needed?
Email is fundamentally just plain text and the protocol largely unchanged from 40 years ago. It initially permitted someone to spoof an email by simply saying, "I am sending this email from ceo@yourcompany.com" and the receiving email system had no way of knowing whether that assertion was true and would therefore simply deliver the email to the recipient who thought the email was from someone it was not.
Email has two main systems to protect emails from being spoofed by an attacker: SPF and DKIM. Spf, initially, was very simple, You would create a DNS record at yourcompany.com which would effectively say only the servers with certain IP addresses are permitted to send emails from yourcompany.com. Receiving email systems would look up this record before accepting emails from yourcompany.com and if the SPF check failed, the email was either put into junk or, more commonly, simply bounced back to the sender. The big problem with SPF is that if you share a set of mail servers with other organisations, your mail servers could send emails for any of those other domains too!
DKIM was a solution to this limitation of SPF. When creating an email, you would perform a signature algorithm over various contents of the email message and attach it as a header to the message envelope. The receiving system would see the signature and then perform the same operation using a public key to ensure it could match the signature. The public key was exposed as another DNS record at yourcompany.com. The benefit here was that only someone possessing the private key could sign emails correctly, even if you were sharing mail servers with other organisations.
The problem with adding any mechanisms to make internet standards better is the desire to keep as much backwards compatability as possible. What is the difference between a signed email and an unsigned email? A single header! So if I send an email without the signature header, the receiving server will simply not verify it so the DKIM system doesn't work to stop a spammer from spamming, it only stops people who are trying to sign it but not able to do it properly i.e. no-one
Using DMARC
DMARC resolves this problem by saying that you as the owner of the domain, as well as specifying permitted mail servers (SPF) and publishing a public key (DKIM) can also specify a set of rules about email received that claims to be from yourcompany.com. This record is called _dmarc.yourcompany.com as a standard and there are rules about how it applies to subdomains like sales.yourcompany.com which we won't discuss here.
DMARC describes something called alignment, which can be provided by SPF or DKIM (or both). Only one is required for DMARC to pass. The SPF alignment check looks to ensure that the "from address" that you would see in the email reader, matches the domain of the "return path" or "bounce" address. Very often this does not align with bulk senders (including SmartSurvey). The DKIM alignment checks that the domain name in at least one of the signatures in the message matches the domain of the "from address".
You don't control whether a message is aligned, that is a job for the person who configures the email sending system, however you can specify various actions to take on any messages that do not pass either the SPF or the DKIM alignment checks.
A typical record might look like this
"v=DMARC1;p=none;pct=100;rua=mailto:dmarcreports@example.com;"
There is only currently one DMARC version but it is a required property in the record. We then have a policy of "none" meaning not to take any action and apply this policy to 100% of all failed emails. Also, send any reports about non-alignment (i.e. DMARC failures) to the email address shown.
A policy of none might seem pointless but when first enabling DMARC, setting the policy to none and sending reports to a DMARC aggregator company would allow you to see when you are reaching the point where most email is aligned and therefore you can change the policy to quarantine (popular and safe -goes to the Junk folder) or reject, which will not deliver the message and (usually) return an error bounce message to the sending server.
You might or might not want to keep the reporting once you have finished testing since it only has value if someone is checking it regularly.