Overview
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a foundational protocol in modern email security that provides best in breed protection against email spoofing and phishing attacks. Domain owners can use a DMARC policy to specify how failing messages should be treated by the receiver. This DMARC feature is pivotal to maintaining the integrity of email communications.
DMARC Policy Modes
DMARC policy allows a domain owner to instruct how DMARC failing messages should be treated. These instructions include three primary modes:
- Report Only – Signified by p=none; in the DMARC record, this mode instructs receivers to simply report DMARC authentication performance to the destinations listed in the rua section of policy.
- Quarantine – Signified by p=quarantine; in the DMARC record, this mode instructs receivers to treat the received message with caution, which may result in quarantining a failing message at the receiving email gateway, flagging as suspicious, or delivering the message to the recipients SPAM folder.
- Reject – Signified by p=reject; in the DMARC record, this mode is the most stringent policy and provides the best protection against email spoofing by instructing the receiving system to reject DMARC failing messages.
You can read more about the DMARC policy modes and configuration specifics in the DMARC RFC https://datatracker.ietf.org/doc/html/rfc7489
DMARC Implementation Path
Most organizations embarking on their DMARC journey begin in a report only mode, to obtain visibility into email senders without impacting message delivery. During this phase, senders failing DMARC are identified in the DMARC reports and steps are taken to work with message senders to see future messages are sent in a DMARC compliant way.
After gaining confidence that all authorized senders are passing DMARC authentication, an organization may strengthen their email security posture by advancing to a DMARC quarantine or DMARC reject policy.
It is at this point that many organizations ask, what is the difference?
DMARC Quarantine vs. DMARC Reject
A DMARC quarantine policy informs receivers to treat DMARC failed messages with caution. In this case, the DMARC failed message is delivered to the receiving domain through a SMTP conversation but may be further filtered by downstream policies dependent upon receiving email infrastructure configuration. This could mean the message is quarantined at the receiving email gateway, delivered to the recipient’s SPAM folder, or otherwise depending upon the receiving organization. Given these conditions, this leaves ample opportunity for a phishing email to be actioned by a recipient either directly or through additional social engineering attacks, such as vishing.
A DMARC reject policy is the most stringent policy and provides the best protection against email spoofing by instructing the receiving email system to reject DMARC failing messages. This generally occurs as part of the SMTP conversation whereby the receiving system may outwardly reject the message or accept the message and silently discard. Exactly how the message is treated is dependent upon the receiver’s DMARC implementation, and results in some nuanced behaviors particularly as it relates to providing failure notices to senders.
DMARC Reject and Failure Notices
In the case where a receiving email system rejects a failed message silently, the sending system has no indication that the message is rejected. The SMTP response would appear as follows, or similar:
Sent (Ok: queued as 123AA456BB)
When a failed message is outwardly rejected, such is the case with Google Gmail receiving systems, the following is provided as the SMTP response:
550-5.7.26 Unauthenticated email from <<domain name>> is not accepted due to 550-5.7.26 domain’s DMARC policy.
This failure response provided during the SMTP conversation provides the sending system with a clear indication the email was not delivered. The sending system may use this to provide the email sender with a failure notice, or not, depending on the senders DMARC implementation.
DMARC Failure Notices
Some sending systems who receive a SMTP failure response may provide the sender with a failure notice. This information provides the email sender with transparency into the SMTP conversation and allows them to act on a failed message. While this is valuable from a user-based email system, it could generate a tremendous amount of backscatter if, for example, failure notifications were sent by an improperly configured bulk-sender.
We generally see failure notifications provided to senders only in user based sending systems, such as your Outlook client sending messages through Microsoft Exchange Online email infrastructure. DMARC Failure notices should be considered during DMARC reject implementation planning, as there is a training and awareness component for end-users. Make specific note of the “From” address specific to your email sending system to help your users avoid advanced phishing schemes that may aim to impersonate DMARC reject failure notices.
See the following screenshot for an example failure notice:
Conclusion
A DMARC reject policy provides best in breed protection against email spoofing. The DMARC journey is one that should start with obtaining visibility into email senders to confirm configurations are adequate and allow you to advance into a DMARC enforcement position without impacting legitimate email delivery. Advancing to a DMARC reject policy may include a short-stop on DMARC quarantine to mitigate risk of failures, but a DMARC reject policy should remain your target. In all cases, DMARC reports should be routinely monitored for failing messages sent by legitimate senders to quickly launch required corrective actions.
spfXio.com provides one stop shopping for DMARC, DKIM, and SPF management. Our managed services accelerate your DMARC journey and provide ongoing visibility into the health of your email authentication configurations.
Book a demo today to learn more, or start a free 30-Day spfXio.com trial now!