GoDMARC - The User’s DMARC Journey

In recent times, Spammers have found Email to be a convenient mode to spoof and criminals have found spoofing to be a proven way to exploit user's trust of well-known brands. Simply inserting the logo of a well-known brand into an email gives it instant legitimacy to many user's eyes.

Users find it difficult to differentiate between a real message and a fake one, and often large mailbox providers find it difficult to choose between which Emails to deliver and which one to retract. Senders remain oblivious of the problems with their authentication practises, because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail) deployment, proceed very slowly and cautiously because of the lack of feedback. In other words, it means they have no authentication process to monitor progress and debug problems.

With the help of DMARC (Domain-based Message Authentication, Reporting and Conformance) email senders and receivers work together to secure emails, to protect user's trust and to save brand goodwill from swindling.

At its most essential, DMARC makes it easier for email senders and receivers to determine whether a given message is from a legitimate sender and what to do if it isn’t. This makes it easier to identify spam and phishing messages and keep them out of peoples’ inboxes.

DMARC is a proposed standard that allows email senders and receivers to cooperate in sharing information about the email they send to each other. This information helps senders improve the mail authentication infrastructure so that all their mail can be authenticated. It also gives the legitimate owner of an Internet domain a way to request that illegitimate messages – spoofed spam, phishing – be put directly in the spam folder or rejected outright.

No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of ‘example.com’ use DMARC to protect that domain, it would not affect ‘example.net’ (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activities, there are other attack vectors that DMARC does not address. For example, DMARC does not address cousin domain attacks (i.e. sending from a domain that looks like the target being abused - e.g. exampl3.com vs. example.com), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

A DMARC policy allows a sender to indicate that their messages are authenticated by SPF and/or DKIM and tells a receiver what to do if neither of those authentication methods passes – such as quarantine or reject the message. DMARC removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.