{ "id": "e327f86d-b243-4482-a89f-a757fd97e1ce", "created_at": "2026-04-06T00:07:12.127986Z", "updated_at": "2026-04-10T03:20:52.115289Z", "deleted_at": null, "sha1_hash": "11b50e452ad88d8c74df7be759d3d02473323c58", "title": "Overview – dmarc.org", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 135862, "plain_text": "Overview – dmarc.org\r\nArchived: 2026-04-05 16:13:07 UTC\r\nBackground\r\nEmail authentication technologies SPF and DKIM were developed over a decade ago in order to provide greater\r\nassurance on the identity of the sender of a message. Adoption of these technologies has steadily increased but the\r\nproblem of fraudulent and deceptive emails has not abated. It would seem that if senders used these technologies,\r\nthen email receivers would easily be able to differentiate the fraudulent messages from the ones that properly\r\nauthenticated to the domain. Unfortunately, it has not worked out that way for a number of reasons.\r\nMany senders have a complex email environment with many systems sending email, often including 3rd\r\nparty service providers. Ensuring that every message can be authenticated using SPF or DKIM is a\r\ncomplex task, particularly given that these environments are in a perpetual state of flux.\r\nIf a domain owner sends a mix of messages, some of which can be authenticated and others that can’t, then\r\nemail receivers are forced to discern between the legitimate messages that don’t authenticate and the\r\nfraudulent messages that also don’t authenticate. By nature, spam algorithms are error prone and need to\r\nconstantly evolve to respond to the changing tactics of spammers. The result is that some fraudulent\r\nmessages will inevitably make their way to the end user’s inbox.\r\nSenders get very poor feedback on their mail authentication deployments. Unless messages bounce back to\r\nthe sender, there is no way to determine how many legitimate messages are being sent that can’t be\r\nauthenticated or even the scope of the fraudulent emails that are spoofing the sender’s domain. This makes\r\ntroubleshooting mail authentication issues very hard, particularly in complex mail environments.\r\nEven if a sender has buttoned down their mail authentication infrastructure and all of their legitimate\r\nmessages can be authenticated, email receivers are wary to reject unauthenticated messages because they\r\ncannot be sure that there is not some stream of legitimate messages that are going unsigned.\r\nThe only way these problems can be addressed is when senders and receivers share information with each other.\r\nReceivers supply senders with information about their mail authentication infrastructure while senders tell\r\nreceivers what to do when a message is received that does not authenticate.\r\nIn 2007, PayPal pioneered this approach and worked out a system with Yahoo! Mail and later Gmail to collaborate\r\nin this fashion. The results were extremely effective, leading to a significant decrease in suspected fraudulent\r\nemail purported to be from PayPal being accepted by these receivers.\r\nThe goal of DMARC is to build on this system of senders and receivers collaborating to improve mail\r\nauthentication practices of senders and enable receivers to reject unauthenticated messages.\r\nDMARC and the Email Authentication Process\r\nDMARC is designed to fit into an organization’s existing inbound email authentication process. The way it works\r\nis to help email receivers determine if the purported message “aligns” with what the receiver knows about the\r\nhttps://dmarc.org/overview\r\nPage 1 of 4\n\nsender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, assuming\r\nthat a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:\r\nIn the above example, testing for alignment according to DMARC is applied at the same point where ADSP would\r\nbe applied in the flow. All other tests remain unaffected.\r\nAt a high level, DMARC is designed to satisfy the following requirements:\r\nMinimize false positives.\r\nProvide robust authentication reporting.\r\nAssert sender policy at receivers.\r\nReduce successful phishing delivery.\r\nWork at Internet scale.\r\nMinimize complexity.\r\nIt is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy\r\nFramework (SPF) specifications that are currently being developed within the IETF. DMARC is designed to\r\nreplace ADSP by adding support for:\r\nwildcarding or subdomain policies,\r\nnon-existent subdomains,\r\nslow rollout (e.g. percent experiments)\r\nSPF\r\nquarantining mail\r\nAnatomy of a DMARC resource record in the DNS\r\nhttps://dmarc.org/overview\r\nPage 2 of 4\n\nDMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email\r\nreceiver should do with non-aligned mail it receives.\r\nConsider an example DMARC TXT RR for the domain “sender.dmarcdomain.com” that reads:\r\n\"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com\"\r\nIn this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in\r\na specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration,\r\nit could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the\r\nmessage, but consider quarantining it.\r\nDMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The\r\nfollowing chart illustrates some of the available tags:\r\nTag Name Purpose Sample\r\nv Protocol version v=DMARC1\r\npct Percentage of messages subjected to filtering pct=20\r\nruf Reporting URI for forensic reports ruf=mailto:authfail@example.com\r\nrua Reporting URI of aggregate reports rua=mailto:aggrep@example.com\r\np Policy for organizational domain p=quarantine\r\nsp Policy for subdomains of the OD sp=reject\r\nadkim Alignment mode for DKIM adkim=s\r\naspf Alignment mode for SPF aspf=r\r\nNOTE: The examples in this chart are illustrative only and should not be relied upon in lieu of the specification.\r\nPlease refer to the specification page for the most up-to-date and accurate version.\r\nHow Senders Deploy DMARC in 5-Easy Steps\r\nDMARC has been designed based on real-world experience by some of the world’s largest email senders and\r\nreceivers deploying SPF and DKIM. The specification takes into account the fact that it is nearly impossible for an\r\norganization to flip a switch to production. There are a number of built-in methods for “throttling” the DMARC\r\nprocessing so that all parties can ease into full deployment over time.\r\n1. Deploy DKIM \u0026 SPF. You have to cover the basics, first.\r\n2. Ensure that your mailers are correctly aligning the appropriate identifiers.\r\n3. Publish a DMARC record with the “none” flag set for the policies, which requests data reports.\r\n4. Analyze the data and modify your mail streams as appropriate.\r\n5. Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.\r\nhttps://dmarc.org/overview\r\nPage 3 of 4\n\nSource: https://dmarc.org/overview\r\nhttps://dmarc.org/overview\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://dmarc.org/overview" ], "report_names": [ "overview" ], "threat_actors": [], "ts_created_at": 1775434032, "ts_updated_at": 1775791252, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/11b50e452ad88d8c74df7be759d3d02473323c58.pdf", "text": "https://archive.orkl.eu/11b50e452ad88d8c74df7be759d3d02473323c58.txt", "img": "https://archive.orkl.eu/11b50e452ad88d8c74df7be759d3d02473323c58.jpg" } }