[{"data":1,"prerenderedAt":144},["ShallowReactive",2],{"publication:en:P165":3},{"meta":4,"copy":16,"relatedArticles":132,"terms":133,"term":134,"resourceParent":139,"glossaryParent":142},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15},"P165","\u002Fglossary\u002Fdmarc","term","what is DMARC","What is DMARC? Alignment, policy and what it cannot prove","What is DMARC? Alignment, policy and reporting","Understand how DMARC relates SPF or DKIM to the visible From domain, what policies and aggregate reports mean, and why a pass does not guarantee inbox delivery.",[13,14],"\u002Fservices\u002Femail-domains","\u002Fblog\u002Fspf-dkim-dmarc-explained","2026-10-30",{"intro":17,"sections":18,"checklistTitle":80,"checklist":81,"faq":87,"sources":97,"links":103,"cta":127},"DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It connects the domain in an email's visible From address to a passing, aligned SPF or DKIM result and lets the domain owner publish a handling policy. DMARC is not encryption, a guarantee of inbox delivery or proof that a genuine account has not been compromised.",[19,44,53,62,67,75],{"title":20,"paragraphs":21,"table":24},"What DMARC evaluates and what alignment means",[22,23],"Email has several identities. The address a person sees in From is not necessarily the envelope identity evaluated by SPF or the domain associated with a DKIM signature. DMARC checks whether a successful authentication result relates to the visible From domain under the applicable alignment rules.","A passing aligned SPF result or a passing aligned DKIM result can satisfy DMARC. A message does not universally have to pass both mechanisms. Equally, an SPF or DKIM pass on an unrelated identity is not by itself a DMARC pass. Read the authentication identity, result and alignment together rather than relying on the word pass in isolation.",{"caption":25,"headers":26,"rows":30},"Illustrative authentication outcomes, not real messages",[27,28,29],"SPF route","DKIM route","DMARC interpretation",[31,35,38,41],[32,33,34],"Passes and aligns","Fails or is unavailable","Can pass through the aligned SPF result",[36,32,37],"Fails or does not align","Can pass through the aligned DKIM result",[39,39,40],"Passes without alignment","These passes do not satisfy DMARC alignment",[42,42,43],"Fails","No passing aligned route is established",{"title":45,"paragraphs":46,"sources":49},"How domain policy relates to receiver handling",[47,48],"A domain owner can request monitoring, quarantine or rejection handling through its DMARC policy. The receiver evaluates the message and applies its own handling, which can also involve other checks or local policy. A published record is a policy signal, not a record of the final decision for every message.","Monitoring is useful for gathering evidence before a stronger policy, but it does not validate a business sender automatically. Enforcement should follow an inventory of legitimate sources and agreed acceptance checks, including systems that send only periodically. A deadline or copied DNS example is not evidence that those systems are ready.",[50],{"label":51,"url":52},"RFC 9989: DMARC, May 2026","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9989.html",{"title":54,"paragraphs":55,"sources":58},"What aggregate reports add, and what they leave out",[56,57],"Aggregate reporting can summarize observed authentication outcomes for sources and reporting periods. The data helps an authorized team relate sending infrastructure to business systems or an investigation. Counts, source addresses and reported handling need context; unfamiliar infrastructure is not automatically a malicious or approved sender.","A report is not a complete mailbox audit or an inbox-placement record. Reporting coverage and timing can vary, and a successful authentication result does not establish that a person opened the message or that the request was honest. Keep the report window, receiver context and business sender mapping beside the conclusion.",[59],{"label":60,"url":61},"RFC 9990: DMARC aggregate reporting","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9990.html",{"title":63,"paragraphs":64},"The current standard and implementation differences",[65,66],"RFC 9989, published in May 2026, supersedes RFC 7489 for the DMARC protocol; RFC 9990 describes aggregate reporting. Old tutorials and provider interfaces can retain legacy terminology. Do not treat the older pct tag as a current guaranteed staging mechanism merely because an old example contains it.","Use the relevant provider's current implementation guidance alongside the standard. The safe sequence still begins with actual senders, message evidence and authority to change policy. This entry explains the mechanism; it is not a production record to paste into DNS or an instruction to enable rejection for an unmapped domain.",{"title":68,"paragraphs":69,"example":72},"What DMARC does not solve",[70,71],"A lookalike domain or a forged display name can impersonate a business without using the protected domain in the same way. A compromised legitimate mailbox or authorized application can send authenticated mail. The technical result therefore does not settle whether an invoice, password request or bank-detail change is legitimate.","Separate domain authentication from account security, recipient filtering, content, reputation and business verification. If a suspicious message may involve a compromised account or a payment already made, use the appropriate incident or financial response. Publishing a stronger domain policy does not replace that work.",{"title":73,"text":74},"Illustrative decision","An invoicing platform passes DKIM for its own domain but does not align with the business From domain in the tested route. The result points to a configuration question, not proof that the invoice is fraudulent. Confirm ownership and supported configuration before changing policy.",{"title":76,"paragraphs":77},"How a business can use the definition",[78,79],"Ask which domain the test message displays, which identities were authenticated and which result supplied alignment. Use evidence from the trusted receiving system; an arbitrary authentication header inside a message is not automatically trustworthy. Keep examples redacted and do not share complete private mail threads or credentials in an enquiry.","CyberFixCrew is an Israeli cybersecurity company serving worldwide businesses, with a focus on websites, mail and digital infrastructure. Our related setup service scopes the sender inventory, implementation and verification separately from this definition. Country-specific legal requirements and provider feature availability need their own assessment.","Questions to ask about a DMARC result",[82,83,84,85,86],"Which visible From domain is being evaluated?","Which authenticated identity passed and aligned?","What reporting window and receiver does the evidence cover?","Does the conclusion concern policy, handling or actual delivery?","Have account compromise and lookalike-domain scenarios been considered separately?",[88,91,94],{"question":89,"answer":90},"Do SPF and DKIM both have to pass for DMARC?","A passing aligned SPF route or a passing aligned DKIM route can satisfy DMARC. A pass without the required alignment is not enough, so inspect the identities as well as the result labels.",{"question":92,"answer":93},"Does a reject policy guarantee that no fake email reaches anyone?","No, receiver handling and other impersonation routes remain relevant. A similar domain, display name or compromised legitimate account needs separate controls and investigation.",{"question":95,"answer":96},"Does DMARC pass mean delivery to the inbox?","No, authentication, receiver handling and inbox placement are different observations. Aggregate reports do not provide a complete inbox-placement history.",[98,99,100],{"label":51,"url":52},{"label":60,"url":61},{"label":101,"url":102},"RFC 8601: Authentication-Results and trust boundaries","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8601.html",[104,107,110,113,115,118,121,124],{"path":105,"label":106},"\u002Fglossary","Browse the business cybersecurity glossary",{"path":108,"label":109},"\u002Fservices\u002Fdmarc-spf-dkim","Scope DMARC, SPF and DKIM implementation",{"path":111,"label":112},"\u002Fblog\u002Femail-spoofing-domain","Investigate apparent domain impersonation",{"path":14,"label":114},"Compare the three authentication mechanisms",{"path":116,"label":117},"\u002Fblog\u002Femail-spam-diagnosis","Diagnose delivery and spam placement",{"path":119,"label":120},"\u002Fresearch\u002Fmethodology","Understand our evidence distinctions",{"path":122,"label":123},"\u002Fblog\u002Fdmarc-none-to-reject","Plan a monitoring-to-enforcement decision",{"path":125,"label":126},"\u002Fblog\u002Fdmarc-report-reading","Interpret source groups and report coverage",{"title":128,"description":129,"button":130,"type":131},"Clarify the authentication question for your domain","Describe the domain, platform and symptom. Do not send passwords or private message contents in the form.","Discuss email authentication","check",[],[],{"name":135,"aliases":136},"DMARC",[137,138],"Domain-based Message Authentication, Reporting, and Conformance","email alignment",{"path":140,"label":141},"\u002Fresources","Website security resources and templates",{"path":105,"label":143},"Cybersecurity glossary for small businesses",1794134057473]