DMARC (Domain-based Message Authentication, Reporting & Conformance) is a specification designed to support the...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
implementation and effectiveness of two existing antispam protocols, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
DKIM and SPF help separate legitimate email from spam, which benefits both the sender and the recipient.
The DMARC specification, released in October 2011, was developed by a group of organizations including major email providers such as AOL, Gmail, Hotmail, and Yahoo Mail, financial institutions such as Bank of America and PayPal, and social sites such as Facebook and LinkedIn.
DKIM and SPF help separate legitimate email from spam, benefiting both the sender and recipient. Both protocols have been available for several years and have been implemented in a variety of both public domain and commercial email products.
Both SPF and DKIM protect against email with a source address that may indicate the mail came from a legitimate sender, such as a bank or government source, but actually came from an attacker. The protocols can be used individually, or both can be deployed for additional protection.
Although both protocols have been deployed widely, their value has been diminished because in order for either of the protocols to be useful, message recipients need to be aware that the protocol is in use.
The DMARC initiative solves this problem by specifying that both protocols must be in use and communicates specifics on how the protocols are to be used. DMARC also provides a way for recipients to report back to senders the results of verification checks on emails that purport to come from that sender.
SPF verifies an incoming email’s actual source by checking the message’s source IP address against a list of email servers maintained by the owner of the domain indicated in the "from" address. For example, if an email claims to originate from service@Mybank.com, the message’s source IP address is checked against a list of IP addresses of Mybank’s email servers. If the source IP doesn’t indicate one of those servers, the message is treated as spam; the email did not come from Mybank. If IP addresses do match, the recipient can be confident that their bank sent the email.
To implement SPF email protection, service providers add new DNS records listing the IP addresses of every server that legitimately sends email. If Mybank outsources its email, the solution provider should create DNS records listing the IP addresses of the outsource service provider’s servers that support the Mybank account.
In cases when an email from a sender that does not implement SPF arrives at a destination that does implement the protocol, it is possible for the receiving email service to determine the sender has not implemented the protocol. The receiver’s DNS check will find no records and thereby determine the sender did not implement SPF; but the receiver will have no way to send back warnings if additional spam filters detect suspicious content.
DKIM uses public-key encryption to provide a way for recipients to verify an email’s actual source. A site that implements DKIM places its public key in its DNS entry. For each outgoing email message, the site computes a hash of the message header including the "from" address. It then encrypts the hash with its private key, places the encrypted hash in the email header and sends the email.
The recipient retrieves the sender’s public key, computes its own hash of the header, then decrypts the encrypted hash using the sender’s public key. If the computed and decrypted hashes match, the message is legitimate. A spammer could compute and encrypt a hash, using the spammer’s own private key, but when decrypted with the indicated sender’s public key, the hashes will not match, and the message will be marked as spam.
Both SPF and DKIM are effective only when both sender and receiver implement the same protocol. Even in cases where both do implement the same protocol, these protocols provide no way for receivers to feed back information to senders. So, for example, it would be valuable to a bank to be informed about a rash of phishing email purporting to come from the bank. SPF and DKIM provide no mechanism to make this possible. DMARC provides a feedback mechanism.
The DMARC specification defines a DNS TXT record that specifies that DMARC is in use. DMARC eliminates uncertainty about whether SPF or DKIM is in use by requiring both.
A receiver first checks the DNS domain of the sender indicated by the email’s “from” address. If there is no DMARC record, the sender has not implemented DMARC. The email must then be evaluated based on its contents to determine if it is spam.
If there is a DMARC record, the receiver first executes the DKIM verification procedure and then the SPF procedure guided by policies specified in the DMARC record. For example, a strict and relaxed mode is defined for both protocols. If the relaxed mode is indicated, an email with a “from” address indicating a subdomain will be considered valid if it verifies with the upper-level domain. In strict mode, the domains must match exactly.
Senders also specify in their DMARC DNS record how they want messages that fail validity checks to be handled. They can choose to specify that no action be taken, that failing messages are to be quarantined by the receiver, or that they be rejected.
In the DNS record, senders also indicate an email address where the results of -- both successful and failed -- validity checks are to be sent. Aggregate reports are sent periodically, but a report of validation failure can be sent immediately, enabling senders to detect bursts of spam as quickly as possible.
While DMARC provides a way to overcome some of the difficulties blocking the full effectiveness of SPF and DKIM, it does not offer foolproof protection from spam and phishing attempts. For example, if an attacker replaces the actual “from” address with mail@Mybank.com, DMARC will detect that the mail did not come from Mybank. If the “from” address indicates mail@Mybank.abc.com, the receiver will attempt to validate against abc.com, a domain owned by the attacker. DMARC will offer no protection in this situation. Individuals must still be vigilant and exercise care when responding to email.
About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.