DMARC Wiki - User contributions [en]

Glossary

2025-05-05T20:40:42Z

Dmarcadmin: /* F */ Add an entry for Failure Reports

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DKIMReplay}}DKIM Replay Attack
:A [[#DKIM|DKIM]] Replay Attack occurs when a message with a valid DKIM signature, presumably where the signer has a good reputation, is sent to a different recipient such that the DKIM signature is still intact and valid. The sender may do this by manipulating the envelope recipient ([https://datatracker.ietf.org/doc/html/rfc5321 RFC5321] "RCPT TO:" address), and they may also change headers that were not covered as part of the DKIM signature, like the "Cc:" header. The sender will typically find a way to send a message with malicious content from a source with good reputation to a mailbox elsewhere that they have access to, retrieve the message with the DKIM signature, and then send it from other sources, like a [https://en.wikipedia.org/wiki/Botnet botnet].

:This type of attack was described in section 8.5 of [https://datatracker.ietf.org/doc/html/rfc4871 RFC4871] in 2007, but it became an issue for large scale mail receivers periodically during 2022. [https://proton.me/blog/dkim-replay-attack-breakdown A blog post from ProtonMail] represents an early report of this trend. This wave of activity has prompted a number of technical proposals, re-activation of the [https://ietf.org IETF]'s [https://datatracker.ietf.org/wg/dkim/about DKIM Working Group], and a great deal of discussion at industry forums like [https://www.m3aawg.org M3AAWG].

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==
;{{anchor|Failure_Reports}}Failure Reports
:'''Failure Reports''' are notifications that an individual email message has failed authentication under DMARC, using the Authentication Failure Reporting Format (AFRF) from [https://datatracker.ietf.org/doc/html/rfc6591 RFC 6591]. This is described in section 7.3 of [https://datatracker.ietf.org/doc/html/rfc7489#page-36 RFC 7489] as a way of, "quickly notifying the Domain Owners when there is an authentication failure." It was also seen as a way to collect information about messages and campaigns impersonating a domain, where the [[#Report_Generator|Report Generator]] was willing to share such details.

:While the reporting format allowed for extensive redaction to suit a [[#Report_Generator|Report Generator]]'s policies, most large operators ceased generating failure reports after the [[#GDPR|GDPR]] went into effect in 2018. This was due to concerns about liability over the potential disclosure of personal information to third parties. However, there is some indication that the format may be in use for the private exchange of authentication failure data, even when a [[#Message_Receiver|Message Receiver]] does not send Failure Reports in response to published DMARC policies.

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==
;{{anchor|GDPR}}General Data Protection Regulation (GDPR)
:The [https://gdpr-info.eu General Data Protection Regulation] (GDPR) is a law of the European Union that defines how the data of individuals can be collected and processed, and under what conditions and controls, within the European Union. However because of the global nature of the Internet, it has had a very large impact on data protection standards and practices in much of the world.

{{anchor|H}}

==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority|MVA}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate|VMC}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2025-05-05T20:30:30Z

Dmarcadmin: /* G */ Add entry for GDPR

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DKIMReplay}}DKIM Replay Attack
:A [[#DKIM|DKIM]] Replay Attack occurs when a message with a valid DKIM signature, presumably where the signer has a good reputation, is sent to a different recipient such that the DKIM signature is still intact and valid. The sender may do this by manipulating the envelope recipient ([https://datatracker.ietf.org/doc/html/rfc5321 RFC5321] "RCPT TO:" address), and they may also change headers that were not covered as part of the DKIM signature, like the "Cc:" header. The sender will typically find a way to send a message with malicious content from a source with good reputation to a mailbox elsewhere that they have access to, retrieve the message with the DKIM signature, and then send it from other sources, like a [https://en.wikipedia.org/wiki/Botnet botnet].

:This type of attack was described in section 8.5 of [https://datatracker.ietf.org/doc/html/rfc4871 RFC4871] in 2007, but it became an issue for large scale mail receivers periodically during 2022. [https://proton.me/blog/dkim-replay-attack-breakdown A blog post from ProtonMail] represents an early report of this trend. This wave of activity has prompted a number of technical proposals, re-activation of the [https://ietf.org IETF]'s [https://datatracker.ietf.org/wg/dkim/about DKIM Working Group], and a great deal of discussion at industry forums like [https://www.m3aawg.org M3AAWG].

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==
;{{anchor|GDPR}}General Data Protection Regulation (GDPR)
:The [https://gdpr-info.eu General Data Protection Regulation] (GDPR) is a law of the European Union that defines how the data of individuals can be collected and processed, and under what conditions and controls, within the European Union. However because of the global nature of the Internet, it has had a very large impact on data protection standards and practices in much of the world.

{{anchor|H}}

==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority|MVA}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate|VMC}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2023-05-22T04:22:52Z

Dmarcadmin: /* D */ Added entry for DKIM Replay

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DKIMReplay}}DKIM Replay Attack
:A [[#DKIM|DKIM]] Replay Attack occurs when a message with a valid DKIM signature, presumably where the signer has a good reputation, is sent to a different recipient such that the DKIM signature is still intact and valid. The sender may do this by manipulating the envelope recipient ([https://datatracker.ietf.org/doc/html/rfc5321 RFC5321] "RCPT TO:" address), and they may also change headers that were not covered as part of the DKIM signature, like the "Cc:" header. The sender will typically find a way to send a message with malicious content from a source with good reputation to a mailbox elsewhere that they have access to, retrieve the message with the DKIM signature, and then send it from other sources, like a [https://en.wikipedia.org/wiki/Botnet botnet].

:This type of attack was described in section 8.5 of [https://datatracker.ietf.org/doc/html/rfc4871 RFC4871] in 2007, but it became an issue for large scale mail receivers periodically during 2022. [https://proton.me/blog/dkim-replay-attack-breakdown A blog post from ProtonMail] represents an early report of this trend. This wave of activity has prompted a number of technical proposals, re-activation of the [https://ietf.org IETF]'s [https://datatracker.ietf.org/wg/dkim/about DKIM Working Group], and a great deal of discussion at industry forums like [https://www.m3aawg.org M3AAWG].

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority|MVA}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate|VMC}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T03:27:44Z

Dmarcadmin: /* V */ Fixing VMC anchor

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority|MVA}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate|VMC}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T03:27:07Z

Dmarcadmin: /* M */ Problem with the MVA anchor

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority|MVA}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T03:13:30Z

Dmarcadmin: /* B */ Typos in the BIMI anchor

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand_Indicators_for_Message_Identification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T03:00:20Z

Dmarcadmin: /* M */ Adding an entry for the Mark Verifying Authority (BIMI)

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Mark_Verifying_Authority}}Mark Verifying Authority (MVA)
:A '''Mark Verifying Authority''' is a role under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification (BIMI)]] specification filled by a participating [https://en.wikipedia.org/wiki/Certificate_authority certificate authority]. When an organization presents the '''MVA''' with an image or logo, and documentation showing they have the right to use the trademark associated with that image, the '''MVA''' will issue a special X.509 certificate known as a [[#Verified_Mark_Certificate|Verified Mark Certificate (VMC)]]. The VMC is used by email receivers to validate an email senders right to use an image or logo before displaying that image alongside email that has passed stringent email authentication checks.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}

==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T02:48:37Z

Dmarcadmin: /* V */ Adding an entry for Verified Mark Certificate (VMC)

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

;{{anchor|Verified_Mark_Certificate}}Verified Mark Certificate (VMC)
:A '''Verified Mark Certificate''' is a type of X.509 certificate meant to prove the right of an email sender to have a particular image or logo displayed with their messages under the [[#Brand_Indicators_for_Message_Identification|Brand Indicators for Message Indentification (BIMI)]] specification. VMCs are issued by a [[Mark_Verifying_Authority|Mark Verifying Authority]] when an image or logo is presented to them along with documentation proving that the applicant has rights to the trademark associated with the image or logo. The VMC is then hosted by a website, possibly operated by the VMA, and referenced in the BIMI policy record in DNS that is associated with the email messages being sent.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group.

{{anchor|W}}

==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T02:34:46Z

Dmarcadmin: /* B */ Tweaking the tense for Blacklist

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be blocked or disallowed access whenever they were encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T02:33:54Z

Dmarcadmin: /* W */ Updating the entry for Whitelist

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist}}Whitelist
:'''Whitelist''' was a commonly used term that referred to a collection of computers, domains, email addresses, ''et cetera'' that would automatically be allowed access whenever they were encountered.

:Many organizations have switched to alternate terms like '''allowlist''' to avoid any bias issues associated with the terms '''whitelist''' and '''blacklist'''. This entry is retained due to the historical usage.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T02:30:24Z

Dmarcadmin: /* A */ Needed an entry for "allowlist"

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Allowlist}}Allowlist
:'''Allowlist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed access whenever they are encountered. ''See also:'' [[#Blocklist|blocklist]].

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2022-01-28T02:27:41Z

Dmarcadmin: /* B */ Added an entry for BIMI. Addressed changes in use of blacklist vs. blocklist.

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Many organizations have switched to alternate terms like '''blocklist''' to avoid any bias issues associated with the terms '''blacklist''' and '''whitelist'''. This entry is retained due to the historical usage.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

;{{anchor|Blocklist}}Blocklist
:'''Blocklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Allowlist|allowlist]].

;{{anchor|Brand Indicators for Message Indentification|BIMI}}Brand Indicators for Message Identification (BIMI)
:'''BIMI''' is an emerging specification to allow the use of sender-specified logos or images alongside messages within participating email clients. BIMI relies on [[#DMARC|DMARC]] and related [[#Email_Authentication|email authentication]] standards to ensure that only messages authorized by the sender will receive this treatment. The logos are expected to be built from trademarked or similarly registered and protected images, and the system includes the concept of a [[#Verified_Mark_Certificate|Verified Mark Certificate]] that can be used to prove the right to use said image.

:More information is available at the website of the [https://bimigroup.org AuthIndicators Working Group], also known as the BIMI Group. The AuthIndicators Working Group originated as a project under DMARC.org in mid-2015, but became an independent project at the end of 2016.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

FAQ

2021-02-19T00:01:38Z

Dmarcadmin: Updated to reference BIMI

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

===Why is DMARC important?===
With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

===How does DMARC work, briefly, and in non-technical terms?===
A DMARC policy allows a sender to indicate that their messages are protected by [[Glossary#SPF|SPF]] and/or [[Glossary#DKIM|DKIM]], and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes 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.

<div id="g_2">

===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://dmarc.org/resources/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">

===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However shortly after publication, the DMARC developers had identified recommendations around email client features like these as an area for future work. At the time, several receivers showed visual indicators for messages under different circumstances. For example, Google’s GMail service offered a setting that would cause a gold key to be displayed next to authenticated messages from certain senders. Meanwhile the "future work" mentioned above began as an initiative under DMARC.org called Authentication Indicators, then became an independent project that is now known as Brand Identifiers for Message Identification or BIMI. More information is available through the following links:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html GMail "gold key" announcement in official blog]
* [https://bimigroup.org/ Brand Indicators for Message Indentification Group]

<div id="s_5">

===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

Glossary

2020-10-28T01:26:05Z

Dmarcadmin: /* S */ Had been referencing the wrong RFC for years (7408 instead of 7208)

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7208 RFC7208] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2017-12-21T01:45:45Z

Dmarcadmin: Adding an entry for (plain/general) phishing and social engineering

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Phishing}}Phishing
:Phishing is an attempt to convince a victim to disclose personal information such as usernames and passwords, credit card details, or other valuable or sensitive information. These attacks can be delivered over email, instant messaging, or other channels but usually feature an attempt to impersonate or [[#spoofing|spoof]] a trusted or trustworthy sender. These trusted parties have included government agencies, financial institutions, IT administrators or help desks, social networking websites, and more. Phishing messages may include a link to a website or an attachment that the user is encouraged to open by employing various [[#Social_Engineering|social engineering]] techniques.

:Many of the attachments delivered through phishing campaigns will also attempt to infect the victim's PC or other device with malware of some kind, or this may be true of the website(s) linked to from the phishing message. The range of malware delivered by phishing campaigns is vast and has included viruses, keyloggers that collect account information, ransomware that encrypts the contents of hard drives, software that sends out spam and phishing email over the victim's Internet connection, and more.

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to [[#Phishing|phishing]] campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Social_Engineering}}Social Engineering
:Social Engineering refers to any number of techniques used to manipulate the target into disclosing information that they shouldn't, usually without realizing that they are doing so. It could be as simple as successfully impersonating a trusted party like a government agent or a co-worker at a large company. This will often be combined with an urgent situation that requires immediate action, without time to think through the implications or seek approval from higher authority. For a more complete description, please visit [https://en.wikipedia.org/wiki/Social_engineering_%28security%29 this Wikipedia page].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between [[#Phishing|phishing]] campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-12-19T18:43:10Z

Dmarcadmin: Fixing wikimarkup for links to #Email_Authentication

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [[#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from. Examples include [[#DKIM|DomainKeys Identified Message]] and [[#SPF|Sender Policy Framework]].

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [[#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [[#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-09-11T02:51:46Z

Dmarcadmin: Correct link spooge in Sender-ID entry; put it firmly in past tense.

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and was published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, but has been declining steadily and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-07-18T17:51:07Z

Dmarcadmin:

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked or disallowed whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

:Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}

==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and has been published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-07-16T17:17:53Z

Dmarcadmin: Added def for wildcard record

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}
==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and has been published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. Some organizations prefer the term '''allowlist''' and '''blocklist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

;{{anchor|Wildcard}}Wildcard DNS Record, or Wildcard Record
:A '''Wildcard''' is something that matches anything. When speaking of [[#DNS|DNS]], a '''wildcard record''' is one that will be returned for any matching query. For example, a wildcard record can be defined or published as ''*.example.com'', and any request that matches will receive that value. So ''apple.example.com'' or ''zebra.example.com'' will match this wildcard, and so will ''_dmarc.example.com'' or ''example.net._report._dmarc.example.com''.
:For more general information on wildcard DNS records, see [https://en.wikipedia.org/wiki/Wildcard_DNS_record this Wikipedia article]. For a more technical treatment refer to [https://tools.ietf.org/html/rfc4592 RFC4592], "The Role of Wildcards in the Domain Name System."

{{anchor|X}}

==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-05-25T01:22:30Z

Dmarcadmin: /* A */ Added entry for ARC

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

;{{anchor|ARC}}Authenticated Received Chain (ARC)
:The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain [[#DMARC|DMARC]] policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website [http://arc-spec.org http://arc-spec.org].

{{anchor|B}}

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}
==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and has been published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''allowlist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

{{anchor|X}}
==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-04-26T14:17:11Z

Dmarcadmin: Adding definition for Cousin Domain

<center>{{alphanumeric TOC|align=center|bottom=yes}}</center>

{{anchor|A}}
==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill differen roles, across different networks, all handling email for several different domains used by different groups within the university.

;{{anchor|Aggregate_Reports}}Aggregate Reports
:When a [[#Domain_Owner|Domain Owner]] publishes a DMARC policy record that includes the <tt>rua</tt> tag with an email address, this requests that Report Generators send what are known as ''aggregate reports'' to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

;{{anchor|Anti-Spam}}Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

{{anchor|B}}
==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

{{anchor|C}}
==C==

;{{anchor|Cousin_Domain}}Cousin Domain
:As commonly used a ''cousin domain'' is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, <tt>exampl3.com</tt> would be a misleading ''cousin domain'' for <tt>example.com</tt>. Fraudsters would register or gain control of <tt>exampl3.com</tt> and use it to send messages impersonating <tt>example.com</tt>, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing ''cousin domains''.

;{{anchor|Cryptographic_Signature}}Cryptographic Signature
:Often called a [https://en.wikipedia.org/wiki/Digital_signature digital signature], they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For [[#DomainKeys|DomainKeys]] or [[#DKIM|DKIM]] this would mean a header in the message that can be checked against a key published under the signing domain in the [[#DNS|DNS]]. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [https://en.wikipedia.org/wiki/S/MIME|Wikipedia] for more information).

{{anchor|D}}

==D==
;{{anchor|Display_Name}}Display Name
:The Display Name, also referred to as the "Friendly From," is half of the From: header defined in [https://tools.ietf.org/html/rfc5322 RFC5322]. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's [https://en.wikipedia.org/wiki/Email_client Mail User Agent] (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

;{{anchor|Display_Name_Attack}}Display Name Attack
:Traditionally there is no provision to make sure the [[#Display_Name|Display Name]] and Address Field portions of the [[#From_Header|From Header]] refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

:DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

;{{anchor|DNS|Domain_Name_System}}Domain Name System (DNS)
:The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from [https://en.wikipedia.org/wiki/Domain_Name_System Wikipedia].

:DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

{{anchor|E}}

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

{{anchor|F}}
==F==

;{{anchor|FUSSP}}Final Ultimate Solution to the Spam Problem (FUSSP)
:'''FUSSP''' is a label sometimes applied to a mechanism whose ability to block [[#spam|spam]] and/or [[#phishing|phishing]] has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

:As phishing has become more common, the alternate phrase '''Final Ultimate Solution for Spam and Phishing''' has been used.

;{{anchor|From_Header}}From Header
:The '''From: Header''' is defined in [https://tools.ietf.org/html/rfc5322 RFC5322] and has two parts - the [[#Display_Name|Display Name]] and the Address Field. The Address Field includes the email address itself, e.g. <tt>user@example.com</tt>, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many [https://en.wikipedia.org/wiki/Email_client email clients] only show the Display Name to the user by default.

{{anchor|G}}

==G==

{{anchor|H}}
==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

:The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

:However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

{{anchor|I}}
==I==

;{{anchor|Identifier_Alignment}}Identifier Alignment
:''Identifier alignment'' is a requirement formulated in [[#DMARC|DMARC]] that imposes extra conditions on the identifiers used by the [[#DKIM|DKIM]] and [[#SPF|SPF]] protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

:For a more complete description of identifier alignment, refer to [https://tools.ietf.org/html/rfc7489#section-3.1 section 3.1] and [https://tools.ietf.org/html/rfc7489#section-10.4 section 10.4] of [https://tools.ietf.org/html/rfc7489 RFC7489]. For examples using real messages, refer to [https://tools.ietf.org/html/rfc7489#appendix-B.1 Appendix B.1] of RFC7489.

;{{anchor|Indirect_Mailflow}}Indirect Mailflow
:This refers to a [[#Mailflow|mailflow]] that passes through some form of [[#Intermediary|intermediary]] - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

;{{anchor|Intermediary}}Intermediary
:Any operator or service that handles an email message it receives from one [[#ADMD|ADMD]] and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

{{anchor|J}}

==J==

{{anchor|K}}
==K==

{{anchor|L}}
==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

{{anchor|M}}
==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

{{anchor|N}}
==N==

{{anchor|O}}
==O==

;{{anchor|Organizational_Domain}}Organizational Domain
:[[#DNS|DNS]] provides a hierarchical relationship between Internet domains. The ''organizational domain'' concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain <tt>example.com</tt>, and uses the sub-domains <tt>mail.example.com</tt> and <tt>news.products.example.com</tt> to send email to their customers. The organizational domain for both of these sub-domains would be <tt>example.com</tt>, because this is the shortest domain that remains within the same organization as <tt>mail.example.com</tt> and <tt>news.products.example.com</tt>. For more information about the organizational domain concept, please refer to [https://tools.ietf.org/html/rfc7489#section-3.2 Section 3.2 of RFC7489].

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

{{anchor|P}}
==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

{{anchor|Q}}
==Q==

{{anchor|R}}
==R==

;{{anchor|Report_Generator}}Report Generator
:A Report Generator is any organization that prepares DMARC [[#Aggregate_Reports|aggregate reports]] or [[#Failure_Reports|failure reports]], and sends them to the address(es) specified in the <tt>rua</tt> and <tt>ruf</tt> tags of a domain's DMARC [[#DNS|DNS]] record. This is usually something done by a [[#Message_Receiver|message receiver]], but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

;{{anchor|Report_Processor}}Report Processor
:This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from [[#Report_Generators|Report Generators]] across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

{{anchor|S}}
==S==

;{{anchor|same-domain phishing}}Same-Domain Phishing
:'''Same-Domain Phishing''' refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the [https://tools.ietf.org/html/rfc5322 RFC5322].From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with [[#DMARC|DMARC]] or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and has been published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Snowshoe Attack}}Snowshoe Attack or Snowshoe Spam
:Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per [https://www.spamhaus.org/news/article/646?article=646 this Spamhaus article] from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other [[#targeted_attack|targeted attack]]s, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

;{{anchor|Spear_Phishing}}Spear Phishing
:'''Spear phishing''' originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

:By 2015 the term is more often used to refer to highly [[#targeted attack|targeted attack]]s where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean [[#spoofing|spoofing]] messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

;{{anchor|spoofing}}Spoofing or Spoofed
:In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and [[#ESP|Email Service Providers]] construct messages on behalf of their clients.

{{anchor|T}}

==T==

;{{anchor|targeted attack}}Targeted Attack
:A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also [[#Snowshoe_Attack|Showshoe Attack]], [[#Spear_Phishing|Spear Phishing]].

{{anchor|U}}

==U==

{{anchor|V}}
==V==

{{anchor|W}}
==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''allowlist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

{{anchor|X}}
==X==

{{anchor|Y}}
==Y==

{{anchor|Z}}
==Z==

<center>{{alphanumeric TOC|align=center|top=yes}}</center>

Glossary

2016-03-22T23:29:44Z

Dmarcadmin: /* D */ Had a typo in the entry for Display Name Attacks

Glossary

2016-03-14T22:03:22Z

Dmarcadmin: /* I */ Adding an entry for Identifier Alignment

Glossary

2016-02-29T23:14:33Z

Dmarcadmin: Breaking out a separate entry for Display Name Attack

Glossary

2016-02-29T22:59:01Z

Dmarcadmin: Added "From Header"

Glossary

2016-02-29T22:05:09Z

Dmarcadmin: Added entry for Display Name

FAQ

2016-02-11T20:17:13Z

Dmarcadmin: Linkrot corrected

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

===Why is DMARC important?===
With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

===How does DMARC work, briefly, and in non-technical terms?===
A DMARC policy allows a sender to indicate that their messages are protected by [[Glossary#SPF|SPF]] and/or [[Glossary#DKIM|DKIM]], and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes 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.

<div id="g_2">

===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://dmarc.org/resources/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">

===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

Glossary

2016-01-27T05:09:52Z

Dmarcadmin: /* S */ same-domain phishing

Glossary

2016-01-26T22:50:54Z

Dmarcadmin: /* S */ fixing links to other glossary entries

Glossary

2016-01-26T22:44:45Z

Dmarcadmin: Add targeted attack

Glossary

2016-01-26T22:36:11Z

Dmarcadmin: /* S */ Adding snowshoe and spear phishing, spoofing

FAQ

2015-11-18T09:11:58Z

Dmarcadmin: Figuring out how links work -- again...

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

===Why is DMARC important?===
With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

===How does DMARC work, briefly, and in non-technical terms?===
A DMARC policy allows a sender to indicate that their messages are protected by [[Glossary#SPF|SPF]] and/or [[Glossary#DKIM|DKIM]], and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes 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.

<div id="g_2">

===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">
===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

FAQ

2015-11-18T09:09:47Z

Dmarcadmin: How does DMARC work

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

===Why is DMARC important?===
With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

===How does DMARC work, briefly, and in non-technical terms?===
A DMARC policy allows a sender to indicate that their messages are protected by [[/wiki/Glossary#SPF|SPF]] and/or [[/wiki/Glossary#DKIM|DKIM]], and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes 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.

<div id="g_2">
===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">
===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

FAQ

2015-11-18T08:57:53Z

Dmarcadmin: Moving the Why Is DMARC Important question here

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

===Why is DMARC important?===
With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

<div id="g_2">
===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">
===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

FAQ

2015-10-12T22:20:51Z

Dmarcadmin: S3, MLM operators - add note about LISTSERV and MailMan

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

<div id="g_2">
===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">
===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Note:''' If you operate the [http://www.lsoft.com/products/listserv.asp LISTSERV] or [http://www.gnu.org/s/mailman/ MailMan] mailing list software, current versions include features to interoperate with DMARC senders. Please consider upgrading your software as part of your solution.''

DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">

===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

Glossary

2015-10-09T06:08:48Z

Dmarcadmin: /* C */

Glossary

2015-10-09T06:08:10Z

Dmarcadmin: /* C */ Miissing curly brace

Glossary

2015-10-09T06:06:50Z

Dmarcadmin: Added a few definitions - Cryptographic Signature, Indirect Mailflow, Intermediary

Glossary

2015-08-10T19:24:58Z

Dmarcadmin: Added Report Generator, Report Processor

Glossary

2015-08-10T14:07:53Z

Dmarcadmin: Added Organizational Domain

Glossary

2015-08-10T13:09:46Z

Dmarcadmin: /* A */ Capitalization issues

Glossary

2015-08-10T13:08:14Z

Dmarcadmin: /* A */ Added Aggregate Reports

FAQ

2015-08-06T19:44:17Z

Dmarcadmin: Checking anchor status

<center>'''<big>Frequently Asked Questions</big>'''</center>

This page has many frequently asked questions, and their answers, about different aspects of email authentication and DMARC. They are organized into four areas: General, End User, Email Receiver (ISP, mailbox provider, domain owner), and Sender (domain or brand owner, email marketer, etc).

Many of these questions were first asked on the [http://dmarc.org/participate/ public DMARC discussion lists]. If you don’t see an answer to your question in these collections, you may want to ask your question there.

__TOC__

<div id="general-questions">
==General Questions==

<div id="g_1">
===What is DMARC, and how does it combat phishing?===
DMARC is a way to make it easier for email senders and receivers to determine whether or not a given message is legitimately from the 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.

===Does DMARC block all types of phishing attacks?===
No. DMARC is only designed to protect against direct domain spoofing. If the owners/operators of <tt>example.com</tt> use DMARC to protect that domain, it would have no effect on <tt>otherdomain.com</tt> or <tt>example.net</tt> (notice the ".net" vs. ".com").

While impersonating a given domain is a common method used for phishing and other malicious activites, 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. <tt>exampl3.com</tt> vs. <tt>example.com</tt>), or display name abuse (i.e. modifying the "From" field to look as if it comes from the target being abused).

===What type of illegitimate email does DMARC address?===
DMARC is designed to protect against direct domain spoofing. When an email is sent by an unauthorized sender (whether it is sent by a malicious actor, or even an unauthorized or non-participating department of the company that owns/operates the domain), DMARC can be used to detect the unauthorized activity and (if so configured) request that those messages be blocked or discarded when they are received.

<div id="g_2">
===Why is DMARC needed?===
End users and companies all suffer from the high volume of spam and phishing on the Internet. Over the years several methods have been introduced to try and identify when mail from (for example) IRS.GOV really is, or really isn’t coming from the IRS. However:
* These mechanisms all work in isolation from each other
* Each receiver makes unique decisions about how to evaluate the results
* The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:
* Domain owners to:
** Signal that they are using email authentication (SPF, DKIM)
** Provide an email address to gather feedback about messages using their domain – legitimate or not
** A policy to apply to messages that fail authentication (report, quarantine, reject)

* Email receivers to:
** Be certain a given sending domain is using email authentication
** Consistently evaluate SPF and DKIM along with what the end user sees in their inbox
** Determine the domain owner’s preference (report, quarantine or reject) for messages that do not pass authentication checks
** Provide the domain owner with feedback about messages using their domain

A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.

<div id="g_3">
===Don’t Receivers use SPF and DKIM results already?===
Companies receiving email from the Internet apply many different methods to analyze incoming messages, including SPF and DKIM as well as spam filters, rate limiters, and many other techniques. But frequently Receiver A is performing one set of checks, while Receiver B makes a different set of checks or treats the messages that fail those checks in a completely different way. So one receiver may treat a message with a little more suspicion if it fails an SPF, while another may subject that failing message to an expensive in-depth analysis to determine if it’s spam or not.

DMARC doesn’t eliminate the need for additional forms of analysis, but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If Receiver A can tell that Sender B is using DMARC, then Receiver A can have more confidence in the decisions they make about messages using Sender B’s domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.

<div id="g_4">
===What happens if a sender uses DMARC and ADSP?===
ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times.

The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, “Issues With ADSP In Operation,” for more information about how experience with ADSP informed work on DMARC.

Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS.

<div id="g_5">
===What is the difference between the "Mail From" and "From Header", aren't they the same?===
In email, like in real mail, there is the concept of an envelope containing the message.
* The envelope will have three pieces of identification information, the host greeting, the "MAIL FROM:" return address and the "RCPT TO:" list of recipient addresses.
* The message content comprises a set of header fields and a body. The body, in turn can be simple text or can be a structured, multi-media "MIME" object of attachments. The set of header fields can be quite extensive, but typically at least include: "Subject:" "Date:" the "To:" and "From:".

The "MAIL FROM" command specifies the address of the recipient for return notices if any problems occur with the delivery of the message, such as non-delivery notices.

The "From:" header field indicates who is the author of the message.

The technical notation for referring to components of email information is: RFC5321.MailFrom and RFC5322.From according to the IETF RFCs where the field is defined and the specific field being referenced.

All this information can be spoofed. DMARC protects the domain name of the RFC5322:From field against spoofing.

<div id="g_6">
===What is the rationale for choosing ZIP for the aggregate reports?===
At least one party was already seeing very large reports with the pre-draft mechanisms that were in place, so it was clear that support for large files would be necessary from the start. It wasn't clear if a report transport mechanism other than email would be up and running in time for the draft to be published.

ZIP handles compression and multiple files (if needed), and it was ready to go - it was already a properly registered MIME application type with IANA. GZIP may be a more appropriate compression format as it can be streamed. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft.

As a precaution measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP. It is common to use regex type filtering rules to reject emails that contain certain types of attachments. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="g_7">
===What does a "quarantine" policy mean in a DMARC record?===
Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery.

<div id="g_8">
===Why not introduce a new DNS Record type for DMARC?===
There has been a lot of discussion of a DMARC DNS record type, but there is no process underway right now to create one.

There are many reasons for that, but the simplest is that a TXT entry is an immediate path to DMARC implementation. A new DNS record type is a much slower path, which requires not only the standard for the new record, but also implementation of it in deployed nameservers.

It is possible that the DMARC community will see value in the use of a dedicated resource record like the one for SPF. That decision will require a lot of discussion. The current DNS TXT entry is not viewed as "experimental", and anyone interested in the protection offered by DMARC should begin by adding the TXT entry for now.

For background information: while the use of a specific DNS record type is more aligned with the spirit of DNS, the introduction of a specific SPF record type has been and is still laborious. The use of underscored attributes in the DNS is a known practice and there is an independent submission to codify it (see: [http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 DNS Scoped Data Through Attribute Leaves]).

<div id="g_9">
===Why doesn't (major mailbox provider) publish a DMARC record?===
Why would someone fake mail from [free email provider] when they could just register an account?

That is a short answer; the situation is a bit more complex. DMARC is a new technology and it is a question of priorities. For email senders, protecting their brand from fake emails is the major objective, so their top priority is to publish a DMARC record and get the most possible enforcement. For receivers (mailbox providers) the top priority is to have users' mailboxes free of incoming fake emails, so they are working on implementing incoming mail filters based on DMARC. These are the priorities that benefit everybody the most.

Certainly mailbox providers could publish a DMARC record with a policy of none to collect reports and analyze their email flows. These reports are likely to be very large, which stresses infrastructure not only at the mailbox provider but at every site generating reports. This would be distracting from the prime objectives cited in the first paragraph.

Furthermore, while a DMARC protected email can survive some forwarding, it does not survive all cases, especially mailing lists. DMARC technology is best-suited for transactional emails and semi-transactional emails. Users that suddenly cannot reach the other members of a mailing list would certainly complain and overload support desks.

Finally, the priority in fighting email scams is for large mailbox providers is to identify their own rogue users. There is no need to try to fake an email when you can have a free mailbox in less than a minute and start behaving badly. It is more important for the email community that major mailbox providers are able to quickly identify their misbehaving users than it is for them to protect their outbound mail flow from fake emails.

However, once they are protecting incoming emails with DMARC, expect them to start protecting outgoing transactional emails like password reset notifications and such.

It is all a question of priorities and what big wins can be obtained first.

<div id="g_10">
===IP Addresses are in various reports, is that a privacy issue?===
Internet Protocol (IP) addresses may be considered personally identifiable information (PII) if they can be used to identify a specific individual. In some jurisdictions, the IP address assigned by your Internet Service Provider (ISP) to your home modem may be considered PII.

The IP addresses in the DMARC reports are those of the originating Message Transfer Agent (MTA). While people can run their own MTA, the vast majority of email is sent via MTAs that act as gateways or relays for email from many individual senders. In this general case, the reported IP addresses would not be considered PII on their own as they are not assigned directly to specific individuals.

<div id="g_11">
===What are the differences between the March 2012 draft and the version publicly circulated as an Internet Draft in March, 2013?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html use this link].

'''NOTE''': The Internet Draft version was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/specification specification page].

* Throughout the spec, "forensic report" has been changed to "failure report."
* Receivers are given some direction about how to handle messages with a missing or malformed RFC5322.From header {4.3}, or no valid identifiers, or multiple identifiers, in that header. {11.1}
* It is now documented that Receivers may limit how many URIs they will send reports to, though they are required to implement at least 2. {6.1}
* There is clarification that a valid DMARC record must at a minimum include both a "v" and "p" tag. {6.2}
* A new tag has been added to the policy record. The "fo" tag allows the domain owner to control the conditions under which per-message failure reports (formerly "forensic reports") are generated. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* Receivers are encouraged to include an Authentication-Results header when a message is delivered despite a published "p=reject" policy. {7}
* Note that DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than "p=none." {7}
* There is clarification that the "pct" or sampling flag in a published policy has a fallback mechanism. So if a policy other than "p=none" is specified, that policy will be applied to the percentage in the "pct" flag and the next less-restrictive policy will be applied to the balance. So for a DMARC record where "p=reject" and "pct=60," 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* The steps for validating an external of "third party" report receiver have been re-ordered and clarified. {8.2}
* Receivers have been given direction about how to respond when changes in a published domain policy are detected during a reporting period. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Suggestions about handling DNS failures were included {9.0}, and DNSSEC failures {15.12}.
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for "mailto:" reporting URIs. Gzip compression is optional for "http:/https:" URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string "DMARC" in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope ("HELP/EHLO" or "MFROM"). The use of a report format version 1.0 is now mandated. {Appendix C}
* Acknowledgements were added as a new section. {Appendix E}

<div id="g_12">
===Do I need to be a Member of DMARC.org to be protected by DMARC?===
No, you don't need to be a member of DMARC.org in order to be protected by DMARC. As a sender, you simply need to begin publishing a DMARC record, and as a receiver you can begin to act on DMARC policy declarations when you're ready. The majority of DMARC deployers are not DMARC.org Members.

DMARC.org Members are simply the initial collaborators that agreed to work together to formalize the DMARC specification. Until the specification is moved into a recognized standards setting organization (eg. the IETF), the DMARC.org Members agreed to shoulder the responsibility for managing the specification and incorporating input from the community at large.

<div id="g_13">
===Is DMARC.org blocking email messages?===
No.

DMARC.org developed the DMARC protocol, whose purpose is to enable identification and blocking of phishing and other messages where a sender uses somebody else's domain for sending email without authorization. We do not control the policy or delivery of email for any domains other than dmarc.org. Nor do we maintain any sort of whitelist that would allow delivery under such circumstances.

Domain owners that choose to use the DMARC protocol may adopt policies that cause email using those domains in the [https://dmarc.org/faq/general-questions#g_5 "From:" header] - but not sent through their systems, or third party systems they have authorized - to stop being delivered. Even if such messages had been allowed previously.

This is not something that DMARC.org has any control over, but we can offer information that may help explain how and why these messages stopped being delivered. It won't be possible to identify the best corrective action until the reason why these messages are being blocked is understood. If you still have questions after reading these items, it would be best to contact the owner of the domain you are trying to use and see what they suggest.

* [https://dmarc.org/overview An overview of DMARC]
* [https://dmarc.org/faq/senders/#s_3 I operate a mailing list and I want to interoperate with DMARC, what should I do?]
* [https://dmarc.org/faq/senders/#s_22 Why are messages I send on behalf of visitors to my website being blocked?]
* [https://dmarc.org/faq/senders/#s_16 What steps should I follow to implement DMARC on my corporate email domain?]
* [https://dmarc.org/faq/senders/#s_14 My organization uses third-parties senders, how can I get them DMARC compliant?]
* [https://dmarc.org/faq/senders/#s_18 As a marketing firm, how can I send DMARC-compliant mail for my customers?]

<div id="end-users">
==End User Questions==

<div id="u_1">
===How does DMARC help the End User / Consumer?===
The short answer is that DMARC helps the end user by making it easier for their mailbox provider (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) to keep spam and phishing messages from ever reaching their inbox.

At the moment this all happens behind the scenes, just as traditional spam filtering is done – the end user only sees the results, which should be fewer fraudulent messages from domains as they adopt DMARC. The DMARC group has noted that future work could address making DMARC results visible to end users, but the first steps are to launch the standard, gain experience with it, and achieve widespread adoption.

<div id="u_2">
===Do I have to do anything for DMARC to work?===
End users don’t have to do anything for DMARC to work; they depend on other parties using DMARC to reduce the number of fraudulent messages that reach their inbox as follows:

* Senders (retailers, banks, schools) need to implement email authentication technologies and publish DMARC policies.
* Receivers (ISPs, broadband providers, free mailbox services) need to implement email authentication technologies and the DMARC policy mechanism.

The good news is that the technologies in question (SPF, DKIM) have been in use for a long time, and most receivers have already implemented them. (They may need to do a little more work to implement DMARC’s policy checks and reporting.) Most senders have implemented at least one of the technologies, and would need to publish DMARC policies.

The key thing for end users to understand is that DMARC is a mechanism that enables senders and receivers to coordinate their efforts in identifying fraudulent messages and preventing them from reaching inboxes. As more parties implement DMARC, sending such messages will become more difficult. But it only protects mailboxes where the receiver or operator has implemented DMARC, and only for those messages where the sender (e.g. example.com) has also implemented DMARC. So concerned end users should feel free to encourage their mailbox providers and the companies that send them email to implement DMARC.

<div id="u_3">
===Can I use DMARC to protect messages I send?===
DMARC is implemented through a number of infrastructure services. If the typical end user is somebody who relies on an email service provided by an ISP, broadband provider, or free mailbox service, then they cannot implement DMARC themselves.

However if an end user is trying to decide on a mailbox provider, or if a small business is trying to decide where to host their domain, they should ask any potential provider whether or not they have implemented DMARC and associated email authentication technologies. (Such small businesses may want to refer to the Sender section of this FAQ.)

In addition to asking the providers, there should be a list of companies known to have implemented DMARC available at DMARC.org.

<div id="u_4">
===How can I tell if my mailbox provider, bank, school, etc is using DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of the organization and “DMARC” and see if they made a public announcement. If you know how to view DNS records (e.g. using the “dig” command), you can also check to see if they publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_5">
===How can I find a mailbox provider that uses DMARC?===
The fastest and most up-to-date way may be to use your favorite search engine – feed it the name of your mailbox provider and “DMARC” and see if the provider has made a public announcement.

There is at least one site trying to build scorecards showing which organizations have adopted email authentication and DMARC. Check our [https://dmarc.org/resources Resources page] for a link to this, and any additional sites that have come to our attention.

<div id="u_6">
===How can I tell if a message passed DMARC?===
The DMARC standard does not specify any indicator that would be present in messages that pass DMARC checks, or that would be visible to an end user viewing their inbox. Unfortunately the only way to infer that a message has passed DMARC is to check that both the sender (e.g. example.com) and receiver (e.g. AOL, Comcast, Hotmail, GMail, Yahoo) have both implemented DMARC.

Please note that this is not a guarantee as the sender may have only published a “monitoring-mode” policy, but gives some indication without a technical discussion of how to check for DMARC records in DNS.

<div id="u_7">
===Why isn’t the “Email this article to a friend” button working on website X?===
There could be many reasons, depending on how the website in question has implemented
this feature. One way commonly used in the past is to simply use your (the site visitor’s)
email address and impersonate your email service provider. Unfortunately this is also one
of the favorite tactics of spammers, and so a number of blocking mechanisms have been put
in place to protect your email address from misuse and filter out the spam. In this case,
these filters will also filter out your emailed article or link.

DMARC is designed to help control the unauthorized use of a domain for sending email,
so if the website you are using implements this feature as described above, and your
email address is in a domain that asserts a DMARC policy, the email may never be
delivered. The operator of the website may see DMARC given as the reason for the message
being blocked, but the real problem is that the website is not authorized by your mail
administrator, the domain owner, to send email on your behalf.

The easiest way to proceed is simply to copy the link or article and send it to your
friend using your favorite personal email program. If you’d like to help improve the
website in question, write to them and suggest they stop impersonating site visitors
this way, and instead send such messages using an email address of their own. (You can
refer them to [[FAQ]] Why are messages I send on behalf of visitors to my website being
blocked for more information.)

<div id="receivers">
==Receiver Questions==

<div id="r_1">
===My users often forward their emails to another mailbox, how do I keep DMARC valid?===
DMARC relies on SPF and DKIM. In the case of forwarding emails, SPF is likely to fail, in a DMARC sense, at the receiver. You are resending from your infrastructure and it is unlikely your sending IP is in the SPF record of the domain contained in the from header of the email. However there is no reason for DKIM to fail. For DKIM not to fail, you must ensure that your mail server does not drastically modify the message. Typically, the only modification that preserves DKIM is to add new email headers to the messages without touching the subject or the body of the message. Headers protected by DKIM should not be modified in any way, and the message should not be converted from one encoding to another.

<div id="r_2">
===Is there special handling required to receive DMARC email from mailing lists?===
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the "Original Authentication Results" header of mailing lists that support this feature.

<div id="r_3">
===I need to implement aggregate reports, what do they look like?===
You should refer to the current [https://dmarc.org/resources/specification DMARC specification] for the report format definition. Here is a sample report with only one record, showing the results for 2 pieces of mail. It was current when this FAQ entry was produced, but it may be out of date by this time - again, please refer to the [https://dmarc.org/resources/specification latest specification].

Please note that the SPF and DKIM results in the <tt>auth_results</tt> are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the <tt>policy_evaluated</tt> section. This report also shows

The filename format is: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension

Example: <tt>acme.org!example.com!1335571200!1335657599.zip</tt>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>acme.com</org_name>
<email>noreply-dmarc-support@acme.com</email>
<extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>72.150.241.94</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
</pre>

<div id="senders">
==Sender Questions==

<div id="s_1">
===Why should a Sender care about DMARC?===
Most domain owners collect logs on messages leaving their email systems, and many will analyze them to determine their delivery rate to particular destinations, observe traffic flow over the business day, etc. But very rarely do they gain insight into messages using their domain from the perspective of an email receiver - including all the fraudulent messages, or messages that are (perhaps incorrectly) labeled as fraudulent. DMARC allows a sender or domain owner to:
* Collect statistics about messages using their domain from DMARC receivers
* See how much of this traffic is passing/failing email authentication checks
* Request that messages using their domain that fail authentication be quarantined or rejected
* Receive data extracted from failed messages such as header information and URIs from the message body, if the receiver provides this service

This provides unparalleled insight into the operation of your own infrastructure, those operated on your behalf by third parties, and the attacks on your domain or brand by bad actors. First and foremost, by adopting email authentication methods and applying them to your entire message stream, you help DMARC compliant receivers better detect bad actors using your domain. This helps protect your brand and the customers you share with these receivers.

But imagine receiving a periodic report that can tell you when, as an example, intermittent DNS problems have caused 10,000 legitimate messages from your messaging infrastructure to be viewed as illegitimate by a major mailbox provider. That may be a small percentage of your message volume that wouldn't stand out, but it's also a lot of angry customers who didn't receive an important message calling your customer service representatives.

If you use a third party to send messages to your customers, these same reports provide another source of data to track how many of your messages they are delivering to particular receivers. Additionally, you will see if these vendors have correctly implemented email authentication, and if not whether your messages were blocked for that reason.

And for those receivers who share failed message reports, a domain owner gains a view of the precise details of how fraudsters are attacking their customers. Detailed information from the message headers, and often any URI strings that are found within the message may be made available within a short time of the message being received, allowing for a dramatic improvement in the phishing site takedown process.

<div id="s_2">
===Will DMARC let me bypass a Receiver's spam filters? Exceed their usual rate limits?===
DMARC specifies a way to be confident whether a given message really came from the source it claims to have come from. It doesn't say anything per se about whether or not that source is trustworthy. So, in general you should expect that messages will still be scanned by a spam filter, and subject to rate limits, etc.

<div id="s_3">
===I operate a mailing list and I want to interoperate with DMARC, what should I do?===
'''''Updated 11-April-2014'''''. DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC] for more details.) Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years.A number of approaches have been proposed:

:1. Operate strictly as a "forwarder," where the RFC5321.RcptTo field is changed to send the message to list members, but the RFC5322 message headers and body are not altered.

::'''Pros''': Receiving systems can validate the DKIM signature of the message author, if one was present.

::'''Cons''': Senders that depend solely on SPF for authentication will still fail. Precludes many customary features of mailing lists, such as "Subject:" tags, list footers/disclaimers, etc.

:2. Add an [http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Original Authentication Results] (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results.

::'''Pros''': Would allow the recipient to see whether or not the message validated as submitted to the list operator.

::'''Cons''': ''This is not a short term solution''. Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012.
::No receivers implementing DMARC are currently known to make use of OAR from external sources.

:3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. Several variations are covered below.

::A. Replace From: address

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''

::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''':Recipients using the Reply feature of their mail client may expect the reply message to be addressed to the message author. If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.
:::If the message author's address is not included somewhere, the recipient would not be able to use the Reply function of their mail client to contact them.

::B. Replace From: address, set Reply-To: to message author

::* Change the RFC5322.From address to an address within the mailing list's domain
:::''user@example.com'' => ''address@mailinglistdomain.com''
::* Set or change the RFC5322.ReplyTo address to the message author
::* Add DKIM signature using the mailing list's domain

:::'''Pros''': Messages from the list could pass SPF, DKIM, and DMARC

:::'''Cons''': Recipients using the Reply feature of their mail clients may expect the reply message to be addressed to the original author.
:::If the list submission address is used, the message recipient may be misdirecting private responses to the mailing list.

::C. Replace From: address and forward replies

::* Change the RFC5322.From address to a unique per-author address within the mailing list's domain.
:::* ''user@example.com'' => ''unique-address@mailinglistdomain.com''
::* Add DKIM signature using the mailing list's domain
::* If replies are sent to the unique address, forward them to the associated message author.

:::'''Pros''':Messages from the list could pass SPF, DKIM, and DMARC. Recipients could use their Reply function to reach the author.

:::'''Cons''': List operator must maintain associations of unique addresses to message authors, and forward messages accordingly.
:::If the reply author's domain publishes restrictive email authentication policies, the message operator may have to take additional steps...

Additional information is available from a number of other sources:

* [http://blog.threadable.com/how-threadable-solved-the-dmarc-problem How Threadable solved the DMARC problem]
* [http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html spamresource.com: Run an email discussion list? Here's how to deal with DMARC]
* [http://onlinegroups.net/blog/2014/04/10/yahoo-dmarc-better-mailing-list-manager/ How OnlineGroups.net used the Yahoo! DMARC crisis to make a better Mailing List Manager]
* [http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance] ''used to develop changes released in MailMan 2.1.16''

<div id="s_4">
===If I implement DMARC, will I get a special icon next to my message in the recipient’s inbox?===
The DMARC standard does not specify any visual indicators that would be displayed to the end user. However the group has identified recommendations around email client features like these as an area for future work. Some individual receivers already show visual indicators for messages under different circumstances. For example, Google’s GMail service offers a setting that will cause a gold key to be displayed next to authenticated messages from certain senders. Features like this may become more widespread as more senders and receivers put email authentication into practice. You can find out more about the GMail “gold key” feature here:

* [http://gmailblog.blogspot.com/2009/07/new-in-labs-super-trustworthy-anti.html Announcement in official GMail blog]
* [http://email.about.com/od/gmailtips/qt/Identify_Authenticated_Senders_and_Avoid_Phishing.htm Q&A at About.com]

<div id="s_5">
===If only a few Receivers have implemented DMARC, why should I adopt it?===
There are a number of reasons you should adopt DMARC as a sender:

* The few receivers who have implemented DMARC at launch time represent a high percentage of Internet email users. If your customers use consumer web mail providers, adopting DMARC would protect them from fraud and abuse. Protecting just these users may alone well justify the effort.
* Most large receivers have implemented some combination of SPF and DKIM even if they haven’t implemented DMARC yet. You must implement SPF and DKIM as a first step to implementing DMARC block policies. Even the non-DMARC receivers will take advantage of these authentication techniques to fight spam and phishing against your brand/domain, you just won’t get the reporting and policy benefits.
* As more senders implement DMARC, it makes implementing DMARC more attractive to the remaining receivers who have not yet done so.
* As more receivers implement DMARC, you will gain more insight through the aggregate reports about how your legitimate email is being processed and evaluated, and what the fraudulent attacks against your brand/domain look like.

<div id="s_6">
===How can I tell if DMARC is making a difference?===
A day or two after a domain owner publishes the simplest monitoring-mode DMARC record in DNS, they will begin to receive reports from DMARC receivers with statistics about email sent to them using the domain owner’s domain. In other words, if you own or operate example.com and publish a DMARC record requesting reports, you will get statistics on all messages that claim to come from your domain from all DMARC receivers. So, you will suddenly be able to see how many fraudulent messages are using your domain, where they’re coming from, and whether or not they would be stopped by a DMARC “quarantine” or “reject” policy. The report from each receiver is an XML file that includes the following fields:

* Every IP address using your domain to send email
* A count of messages from each of those IP addresses
* What was done with these messages per the DMARC policy shown
* SPF results for these messages
* DKIM results for these messages

These reports provide a great deal of insight into the health of your message streams. However the XML report format, while readable, is not very convenient. Domain owners may wish to use one of the report processors listed in the Analytics and Implementation Support section of the [http://dmarc.org/resources/products-and-services/ Products and Services] resources page.

For details of the XML report format, see [https://tools.ietf.org/html/rfc7489#appendix-C Appendix C of the DMARC Specification (RFC7489)].

<div id="s_7">
===Can I implement DMARC gradually without impacting the rest of my mailflow?===
Absolutely. In fact allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification.

You can start with a simple “monitoring-mode” record for a sub-domain or domain, that requests that DMARC receivers send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until they are in place you won’t be able to move beyond this step. As you introduce SPF and DKIM, the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.

When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy – you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.

Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.

The next step would be to implement a “reject” policy – you’re now asking DMARC receivers to not even accept messages that fail the DMARC checks. Again, you can request that this stronger policy only be applied to a small percentage of your messages to start with, and the reports will show the impact. The same gradual increase to 100% can be planned with careful feedback based on these reports.

If you’ve done this with a sub-domain your rollout plan can repeat the process with other sub-domains, and eventually to the top-level domain itself. And if you have other domains, you can then confidently address them as well.

<div id="s_8">
===Why are there more entries in the reports than the mail I send?===
If you find more entries in the report than the emails you sent, well it means you could seriously benefit from DMARC. The reports tell you about all the emails a receiver sees where the From: domain is your domain. All the emails. No more guess work. You have to consider the reports include authentication results about email messages:

* coming directly from your infrastructure (your IPs, likely a SPF pass with alignment)
* coming from third parties on your behalf. It is common for organizations to use third party solutions for things like email marketing, CRM, surveys, …
* coming from your infrastructure via a forwarder (for instance students at education institutes may forward their university email to their favorite mailbox provider)
* that are fake. Did you know your domain name and emails were a target for phishing? If yes, volumes could be much larger than what you send. Some botnets contains millions of machines that can send 1 billion emails a day.

Finally reporting cycles can be different between the reports your mail server sends you about emails you sent and the DMARC aggregate reports.

<div id="s_9">
===What if miscreants use the display field of the From: to fake my brand/domain?===
This is an important issue, but not one in DMARC's scope. It is primarily a user interface issue, which cannot be adequately handled by the kind of interventions DMARC enables. We encourage groups with more experience and control of user interfaces to tackle this.DMARC protects the domain name in the address part of the From:. It does not protect the display field.

This has two main implications. First, email clients should display the address part of the From: to the user. Some companies have come to the conclusion that this doesn't change behavior for typical users; it may be more effective in conjunction with carefully chosen indicators about the reputation of the domain. Second, protecting the domain name separates the real domain's reputation from the reputation of fake domains. If somebody uses a from header like:
<pre>From: "Well-Known Big Bank" <well-known-big-bank@miscreant.example.com></pre>
Regardless of how it is displayed, user reactions will be applied to miscreant.example.com, not to Well-Known Big Bank's actual domain. So DMARC does provide some assistance. In general, the reputation of the domain sending the fake will rapidly degenerate and the mail will be quarantined or rejected based on that reputation. Even if that doesn't happen, the real brand's domain won't lose its ability to send mail based on the miscreant's actions.

<div id="s_10">
===Does DMARC “p=none” affect the way my emails get delivered?===
No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

<div id="s_11">
===When can I expect to receive my first aggregate report?===
Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.com"</pre>
A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:
<pre>_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:aggregate@thirdparty.com"

example.com._report._dmarc.thirdparty.com TXT "v=DMARC1"</pre>
Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

<div id="s_12">
===Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?===
When you query a DMARC record you often see results like this:
<pre>$ host -t TXT _dmarc.dmarc.org
_dmarc.dmarc.org descriptive text "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ nslookup
> set type=TXT
> _dmarc.dmarc.org
Non-authoritative answer:
_dmarc.dmarc.org text = "v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org
"v=DMARC1\; p=none\; pct=100\; rua=mailto:reports@dmarc.org\; ruf=mailto:reports@dmarc.org"</pre>
This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.
<pre>_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"</pre>
If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

<div id="s_13">
===Do I want to receive Failure Reports (ruf=)?===
Not until you have read this answer and made sure you are ready to receive a '''LOT''' of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, ''every time'' a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but '''every email that spoofs your domain will be rejected too and you are asking to get a copy'''. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"</pre>
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
<pre>_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"</pre>

<div id="s_14">
===My organization uses third-parties senders, how can I get them DMARC compliant?===
There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.
#'''Integrate externally''': The third party sender uses its own mail servers to send your emails.
##Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
##Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
#'''Integrate internally''': Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
#'''Do not integrate ''and'' tell them not to spoof''': Ask the third party sender to use their own domain in the <tt>From:</tt> header and if replies are required, either have them to alias this email back to you, or have them set the <tt>Reply-To:</tt> header to one of your email address. '''NOTE''': ''In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings''.

<div id="s_15">
===I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?===
To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

'''DMARC Record''':
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"</pre>

'''Report Authorization Record''':
<pre>example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"</pre>
Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

{{anchor|external-reporting-address}}
===I published a DMARC record with reports going to another domain, but none seem to be received===
To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:
<pre>_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"</pre>
The [https://tools.ietf.org/html/rfc7489 DMARC specification] describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of <tt>otherdomain.com</tt> would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain <tt>example.com</tt>:
<pre>example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"</pre>
Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see [https://dmarc.org/wiki/FAQ#How_can_I_put_DMARC_records_on_many_domains_at_once.3F this FAQ entry] for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for '''any''' domain, which bad actors may try to exploit.

{{anchor|s_16|steps-implementing-dmarc}}
===What steps should I follow to implement DMARC on my corporate email domain?===
Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.
#It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. '''NOTE''': ''Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet''.
#Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
#If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
#Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
#Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
#Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
#Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
#Whitelist in your DMARC filter all the mailing lists your employees are using
#Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
#Be mindful there are at least two cases where DMARC is likely to reject emails:
##Email forwarding
##Mailing lists
#Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
#Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
#Get all third party providers to be DMARC compliant (see this FAQ)
#You are ready to move to p=quarantine and/or p=reject
#Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, ''et cetera''

<div id="s_17">
===How can I put DMARC records on many domains at once?===
Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.
<pre>_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
_dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"</pre>
Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

<div id="s_18">
===As a marketing firm, how can I send DMARC-compliant mail for my customers?===
There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

<div id="s_19">
===My mail is going to the spam folder now, is DMARC the problem?===
In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the <tt>Authentication-Results</tt> header. It may look like:
<pre>Authentication-Results: mail.example.com;
spf=pass smtp.mailfrom=member@example.com;
dkim=pass header.d=example.com;
dmarc=pass d=example.com</pre>
This header indicates that the server <tt>mail.example.com</tt> performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

<div id="s_20">
===What changes in the draft submitted to the IETF affect me as a sender?===
The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use [https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html this link]. '''NOTE''': The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the [https://www.dmarc.org/resources/specification specification page].
* If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish. {6.1}
* Your DMARC record must contain a “p” and “v” tag to be valid. {6.2}
* The new “fo” tag allows you to specify conditions where you want to receive per-message failure reports. It is now possible to only request reports when all authentication methods fail, or in cases where DKIM or SPF fail regardless of domain alignment. {6.2}
* DMARC policies should only override ADSP or SPF policies when the published DMARC policy is something other than “p=none.” {7}
* The “pct” sampling function operates in a “fallback” mode that hadn’t been documented. When “pct” is specified with a policy other than “p=none,” the “pct” value will define the percentage of messages the “p=” policy is applied to and the remaining messages will be treated with the next-lower policy. So for a DMARC record where “p=reject” and “pct=60,” 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. {7.1}
* Senders and report processors should allow for extra reports during periods where they have published a change to their DMARC policy. {8.3}
* Some updates to the AFRF per-message failure reporting format have been made to provide more information about DKIM, DMARC, and SPF. {8.4.1} Observations are also made about potential abuse of DMARC reporting {8.4}
* Aggregate reports are now required to be compressed with gzip instead of using a ZIP archive for “mailto:” reporting URIs. Gzip compression is optional for “http:/https:” URIs. {12.2.1, 12.2.2} Each aggregate report filename must now include an identifier unique to that file, to allow for multiple reports from a Receiver in a given reporting period. {12.2.1}
* Receivers who reject a message due to DMARC policy are asked to include the string “DMARC” in the text of the rejection message during the SMTP transaction. {15.8}
* The XML schema for aggregate reports has been extended to include the RFC5321.MailFrom, the selector used for DKIM authentication, and the SPF domain scope (“HELP/EHLO” or “MFROM”). The use of a report format version 1.0 is now mandated. {Appendix C}

<div id="s_21">
===I have domains that do not send emails, how can I protect them?===
''The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed''.

First create a DMARC record on your main domain (<tt>example.com</tt>) for all your parked domains:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"</pre>
If <tt>example.net</tt> is a parked domain you can then protect it this way:
<pre>_dmarc.example.net IN CNAME _dmarc.parked.example.com
example.net IN TXT "v=spf1 -all"
*.example.net IN TXT "v=spf1 -all"</pre>
The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:
<pre>_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"</pre>
This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for <tt>example.net</tt> at the mailboxes at <tt>example.com</tt> you must create a Report Authorization Record:
<pre>example.net._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:
<pre>*._report._dmarc.example.com IN TXT "v=DMARC1;"</pre>
However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

<div id="s_22">
===Why are messages I send on behalf of visitors to my website being blocked?===
This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the <tt>From:</tt> header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the <tt>From:</tt> header, and the <tt>Reply-To:</tt> header is set to the website visitor’s address, but the actual address used in the <tt>From:</tt> header clearly indicates that your website is the origin of the message.
<pre>From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"</pre>

<div id="s_23">
===Email messages I send are being rejected with “DMARC” in the response. Is DMARC.org blocking these messages?===
Please see the item [https://dmarc.org/wiki/FAQ#Is_DMARC.org_blocking_email_messages.3F Is DMARC.org blocking email messages?]

Glossary

2015-07-28T22:09:16Z

Dmarcadmin: FUSSP

Glossary

2015-07-28T03:23:08Z

Dmarcadmin: /* D */ Definition for DNS; ordering

Glossary

2015-07-22T01:30:32Z

Dmarcadmin: Alphanumeric TOC template is working. Not idea, but better than a dumb look...

Timeline-test

2015-07-22T01:20:57Z

Dmarcadmin:

<center>{{alphanumeric TOC|align=center}}</center>

==Fuel Timeline==
<timeline>
DateFormat=mm/dd/yyyy
Period = from:01/01/1984 till:01/01/2011
Define $now = 09/01/2007
Define $skip = at:end # Force a blank line
Define $dayunknown = 15 # what day to use if it's actually not known
Define $monthunknown = 06 # what month to use if it's not actually known
ImageSize= width:850 height:auto barincrement:25
TimeAxis = orientation:horizontal
PlotArea = right:5 left:5 bottom:60 top:5
Legend = orientation:vertical position:bottom columns:4

Colors =
id:bg value:white
id:m68k1 value:rgb(0.4,0.9,0.8) legend:M680x0
id:m68k2 value:rgb(0.4,1,0.9)
id:mips1 value:rgb(0.75,0.4,1) legend:MIPS
id:mips2 value:rgb(0.85,0.4,0.90)
id:x861 value:rgb(0.60,0.60,1) legend:Itanium
id:x862 value:rgb(0.55,0.55,0.8) legend:X86
id:lightline value:rgb(0.9,0.9,0.9)
id:lighttext value:rgb(0.5,0.5,0.5)

BackgroundColors = canvas:bg
ScaleMajor = gridcolor:lighttext unit:year increment:2 start:01/01/1985

BarData =
barset:terminal
barset:workstationlow
barset:workstationmid
barset:workstationhigh
barset:server
barset:workstationaltixbased
PlotData=
width:15 textcolor:black

barset:terminal
shift:(5,-5) anchor:from fontsize:s
color:m68k1 from:$monthunknown/$dayunknown/1984 till:$monthunknown/$dayunknown/1986 text:"[[SGI IRIS|1000/1200]]"
barset:break
color:m68k2 from:$monthunknown/$dayunknown/1986 till:$monthunknown/$dayunknown/1988 text:"[[SGI IRIS|2000/2200]]"

barset:workstationlow
shift:(5,-5) anchor:from fontsize:s
color:m68k1 from:$monthunknown/$dayunknown/1984 till:$monthunknown/$dayunknown/1986 text:"[[SGI IRIS|1400]]"
barset:break
color:m68k2 from:$monthunknown/$dayunknown/1986 till:$monthunknown/$dayunknown/1987 text:"[[SGI IRIS|2300]]"
barset:break
color:m68k1 from:$monthunknown/$dayunknown/1987 till:$monthunknown/$dayunknown/1988 text:"[[SGI IRIS|3000]]"
barset:break
color:mips1 from:10/$dayunknown/1988 till:$monthunknown/$dayunknown/1992 text:"Personal Iris"
barset:break
color:mips2 from:$monthunknown/$dayunknown/1993 till:$monthunknown/$dayunknown/1996 text:"[[SGI Indy|Indy]]"
barset:break
color:mips1 from:$monthunknown/$dayunknown/1996 till:08/$dayunknown/2001 text:"[[SGI O2|O2]]"
barset:break
color:mips2 from:08/$dayunknown/2001 till:01/$dayunknown/2002 text:"[[SGI O2|O2+]]"

barset:workstationmid
shift:(5,-5) anchor:from fontsize:s
color:mips2 from:$monthunknown/$dayunknown/1986 till:$monthunknown/$dayunknown/1989 text:"Professional Iris"
barset:break
color:mips1 from:$monthunknown/$dayunknown/1990 till:$monthunknown/$dayunknown/1994 text:"[[SGI Indigo|Indigo]]"
barset:break
color:mips2 from:01/$dayunknown/1992 till:12/$dayunknown/1997 text:"[[SGI Crimson|Crimson]]"
barset:break
color:mips1 from:01/$dayunknown/2002 till:12/26/2006 text:"[[SGI Fuel|Fuel]]"

barset:workstationhigh
shift:(5,-5) anchor:from fontsize:s
color:mips1 from:10/$dayunknown/1988 till:12/$dayunknown/1991 text:"PowerSeries"
barset:break
color:mips1 from:$monthunknown/$dayunknown/1992 till:$monthunknown/$dayunknown/1997 text:"[[SGI Indigo² and Challenge M|Indigo²]]"
barset:break
color:mips2 from:$monthunknown/$dayunknown/1997 till:$monthunknown/$dayunknown/2000 text:"[[SGI Octane|Octane]]"
barset:break
color:mips1 from:$monthunknown/$dayunknown/2000 till:06/25/2004 text:"[[SGI Octane2|Octane2]]"
barset:break
color:mips2 from:06/$dayunknown/2003 till:12/25/2006 text:"[[SGI Tezro|Tezro]]"

barset:server
shift:(5,-5) anchor:from fontsize:s
color:mips1 from:$monthunknown/$dayunknown/1992 till:$monthunknown/$dayunknown/1997 text:"[[SGI Indigo² and Challenge M|Challenge M]]"
barset:break
color:mips2 from:$monthunknown/$dayunknown/1996 till:01/$dayunknown/2002 text:"[[SGI Origin 200|Origin 200]]"
barset:break
color:mips1 from:10/09/2001 till:12/31/2003 text:"[[SGI Origin 300|Origin 300]]"
barset:break
color:x861 from:$monthunknown/$dayunknown/2005 till:12/$dayunknown/2006 text:"[[SGI Altix 350|Altix 350]]"
barset:break
color:x862 from:12/$dayunknown/2006 till:end text:"[[SGI Altix 450|Altix 450]], [[SGI Altix XE|Altix XE]]"

barset:workstationaltixbased
shift:(5,-5) anchor:from fontsize:s
color:x862 from:04/26/2005 till:$monthunknown/$dayunknown/2010 text:"[[SGI Prism]]"

</timeline>

==DMARC Timeline==
<timeline>
DateFormat=mm/dd/yyyy
Period = from:01/01/2006 till:12/31/2015
Define $now = 07/01/2015
Define $skip = at:end # Force a blank line
Define $dayunknown = 15
Define $monthunknown = 06
ImageSize= width:800 height:auto barincrement:25
TimeAxis = orientation:horizontal
PlotArea = right:5 left:5 bottom:60 top:5
Legend = orientation:vertical position:bottom columns:4

Colors =
id:bg value:white
id:eBayYahoo value:rgb(0.3,0.9,0.8) legend:eBay1
id:eBayGoogle value:rgb(0.5,0.8,0.8) legend:eBay2
id:MOOCOW value:rgb(0.5,0.1,0.7) legend:MOOCOW
id:DMARC1 value:rgb(0.1,0.8,0.2) legend:DMARC
id:DMARC2 value:rgb(0.3,0.9,0.2) legend:DMARCorg
id:IETF value:rgb(0.3,0.7,0.8) legend:IETF
id:lightline value:rgb(0.9,0.9,0.9)
id:lighttext value:rgb(0.5,0.5,0.9)

BackgroundColors = canvas:bg
ScaleMajor = gridcolor:lighttext unit:year increment:1 start:01/01/2006

BarData =
barset:eBay
barset:MOOCOW
barset:DMARC1
barset:DMARC2
barset:IETF

PlotData=
width:15 textcolor:black

barset:eBay
shift:(5,-5) anchor:from fontsize:s
color:eBayYahoo from:01/15/2006 till:12/25/2007 text:"eBay - Yahoo"
barset:break
color:eBayGoogle from:01/15/2008 till:12/31/2011 text:"eBay - Google - Yahoo"

barset:MOOCOW
shift:(5,-5) anchor:from fontsize:s
color:MOOCOW from:01/01/2010 till:06/$dayunknown/2011 text:"MOOCOW"

barset:DMARC1
shift:(5,-5) anchor:from fontsize:s
color:DMARC1 from:02/15/2011 till:02/$dayunknown/2015 text:"DMARC"

barset:DMARC2
shift:(5,-5) anchor:from fontsize:s
color:DMARC2 from:02/01/2015 till:12/31/2015 text:"DMARC.org"

barset:IETF
shift:(5,-5) anchor:from fontsize:s
color:IETF from:07/01/2014 till:12/31/2015 text:"IETF DMARC WG"

</timeline>

Glossary

2015-07-20T21:28:37Z

Dmarcadmin: Adding blacklist/whitelist, honey pot/spam trap,

__NOTOC__

==A==

;{{anchor|ADMD}}Administrative Management Domain (ADMD)
:The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill differen roles, across different networks, all handling email for several different domains used by different groups within the university.

;Anti-Spam
:Referring to something which identifies and/or filters out messages believed to be spam. ''See also:'' [[#Spam|Spam]]

==B==

;{{anchor|Blacklist|Blocklist}}Blacklist
:'''Blacklist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be blocked whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''blocklist''' to avoid any potential issues associated with the terms '''blacklist''' and '''whitelist'''.

;{{anchor|Blocking_Policy}}Blocking policy
:A common shorthand referring - in an email authentication context - to a [[#DMARC|DMARC]] policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

==C==

==D==

;{{anchor|DK}}DomainKeys (DK)
:'''Domain Keys''', or '''DK''', is a signature-based [[#Email_Authentication|Email Authentication]] technique originally created by Yahoo!. It is documented in [https://tools.ietf.org/html/rfc4870 RFC4870], but note that it has been superseded by [[#DKIM|DKIM]]. More information is available through [https://en.wikipedia.org/wiki/DomainKeys Wikipedia], or from [http://web.archive.org/web/20071018075018/http://antispam.yahoo.com/domainkeys/ Yahoo's description] (via Archive.org).

;{{anchor|DKIM}}DomainKeys Identified Message (DKIM)
:'''Domain Keys Identified Message''', or '''DKIM''', is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the [[#DK|DomainKeys]] and Identified Internet Mail specifications, and has been published as a Standards Track document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4871 RFC4871] in 2007, and updated as [https://tools.ietf.org/html/rfc6376 RFC6376] in 2011. More information is available from [http://dmarc.org DKIM.org] or [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia].

;{{anchor|DMARC}}Domain-based Message Authentication, Reporting, and Conformance (DMARC)
:DMARC is a technical specification that allows [[#Message_Sender|Message Senders]] and [[#Message_Receiver|Message Receivers]] to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the [[#Domain_Owner|Domain Owner]] to indicate they are using [[#Email_Authentication|email authentication]] on the messages they send, optionally requesting that messages that fail to authenticate be blocked. [[#Message_Receiver|Message Receivers]] honor these requests (unless there is a [[#Local_Policy|local policy]] overriding this action), and send reports on all the messages - whether or not they pass [[#Email_Authentication|email authentication]] - to the [[#Domain_Owner|Domain Owner]]. For more information please review the [https://dmarc.org/overview DMARC Overview]. The specification has been published as an Informational document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc7489 RFC7489].

;{{anchor|Domain_Owner}}Domain Owner
:This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the '''Domain Owner''' may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the '''Domain Owner''' is not necessarily the same as the [[#ADMD|ADMD]], [[#Message_Receiver|Message Receiver]], or [[#Message_Sender|Message Sender]] for that domain.

==E==

;{{anchor|Email_Authentication}}Email Authentication
:'''Email Authentication''' refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

;{{anchor|ESP}}Email Service Provider (ESP)
:An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see [https://tools.ietf.org/html/rfc5321 RFC5321]) or in the message headers (see [https://tools.ietf.org/html/rfc5321 RFC5322]). They are sometimes referred to as '''Third Party Senders'''.

==F==

==G==

==H==

;{{anchor|Honey_Pot|honeypot}}Honey Pot
:A '''Honey Pot''' is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term '''spam trap''' is also used to refer to this type of mailbox.

The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A '''honey pot''' operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

==I==

==J==

==K==

==L==

;{{anchor|Local_Policy|Local_Policy_Override}}Local Policy or Local Policy Override
:In the context of DMARC, the term '''Local Policy''' refers to any internal policy or reason a [[#Message_Receiver|Message Receiver]] may have for not enforcing a [[#Blocking_Policy|Blocking Policy]] published by the [[#Domain_Owner|Domain Owner]] for a particular message. It is often indicated as a message like "local policy override" for messages that failed [[#Email_Authentication|Email Authentication]] but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

==M==

;{{anchor|Mailflow}}Mailflow
:A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

;{{anchor|Malicious_Actor}}Malicious Actor
:A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A '''Spammer''' might be referred to as a Malicious Actor; somebody who '''phishes''', or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

;{{anchor|Malicious_Content}}Malicious Content
:Anything in a message that will do harm to the [[#Recipient|Recipient]], or the computer and networks they use, may be referred to as '''Malicious Content'''. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the [[#Recipient|Recipient]] to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. '''Malicious Content''' is often referred to as '''malware'''.

;{{anchor|Message_Receiver}}Message Receiver
:In the transmission of an email message from one '''ADMD''' to another, this is the organization receiving the message on behalf of the intended recipient or end user. The '''Message Receiver''' may do this because the intended recipient utilizes mailbox services offered by the '''Message Receiver''' (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

;{{anchor|Message_Sender}}Message Sender
:In the transmission of an email message from one '''ADMD''' to another, this is the organization sending the message on behalf of the '''Originator''' or end user.

==N==

==O==

;{{anchor|Originator}}Originator
:The '''Originator''' is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the '''ADMD''' providing email services to that party.

==P==

;{{anchor|Policy_Override}}Policy Override
:See [[#Local_Policy|Local Policy]].

==Q==

==R==

;{{anchor|Reputation}}Reputation
:In this context '''Reputation''' refers to various systems whereby a [[#Message_Receiver|Message Receiver]], or a vendor providing a [[#Reputation_Service|Reputation Service]], may track the past actions of an [[#Originator|Originator]] or [[#Message_Sender|Message Sender]] in order to predict the likelihood that a message their receive from this entity in future may be [[#Spam|Spam]] or contain [[#Maclicious_Content|Malicious Content]].

==S==

;{{anchor|SID}}Sender ID (SID)
:'''Sender-ID''' is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the [[#SPF|SPF]] and Microsoft's CallerID specifications, and has been published as an Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4407 RFC4407] in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from [https://en.wikipedia.org/wiki/Sender_ID Wikipedia].

;{{anchor|SPF}}Sender Policy Framework (SPF)
:'''Sender Policy Framework''', originally '''Sender Permitted From''', is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the [https://ietf.org IETF] as [https://tools.ietf.org/html/rfc4408 RFC4408] in 2006, and updated as a Standards Track document as [https://tools.ietf.org/html/rfc7408 RFC7408] in 2014. More information is available from [http://openspf.org OpenSPF.org] or [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia].

;{{anchor|Spam}}Spam
:Uninvited, unsolicited, and unwelcome email messages are commonly referred to as '''Spam'''. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on [https://en.wikipedia.org/wiki/Spamming Wikipedia].

;{{anchor|Spam_Trap|spamtrap}}Spam Trap
:Spam trap is a commonly used term for a [[#Honey_Pot|Honey Pot]].

==T==

==U==

==V==

==W==

;{{anchor|Whitelist|Allowlist}}Whitelist
:'''Whitelist''' is a commonly used term that refers to a collection of computers, domains, email addresses, ''et cetera'' that will automatically be allowed through whenever they are encountered. ''See also:'' [[#Whitelist|whitelist]].

Some organizations prefer the term '''allowlist''' to avoid any potential issues associated with the terms '''whitelist''' and '''blacklist'''.

==X==

==Y==

==Z==

Template:Tl

2015-07-17T16:48:07Z

Dmarcadmin: 34 revisions imported

{{[[Template:{{{1}}}|{{{1}}}]]}}<noinclude>
{{documentation}}

</noinclude>

Template:TOC top

2015-07-17T16:47:43Z

Dmarcadmin: 27 revisions imported

{{#ifeq:{{{primary|}}}|false||__NOTOC__}}<div class="toc plainlinks hlist" {{#ifeq:{{{primary|}}}|false||id="toc"}} style="{{#switch:{{lc:{{{align|}}}}}
|left=float: left; clear: {{{clear|left}}};
|right=float: right; clear: {{{clear|right}}};
|center= margin:auto; clear: {{{clear|none}}};
|#default=clear: {{{clear|left}}};
}}">
<div {{#ifeq:{{{primary|}}}|false|style="text-align:center"|id="toctitle"}}>{{#ifeq:{{{primary|}}}|false|<strong>{{{title|{{MediaWiki:Toc}} }}}</strong>|<h2>{{{title|{{MediaWiki:Toc}} }}}</h2>}}
</div>
<noinclude>
{{TOC bottom}}
{{documentation}}</noinclude>