What are some common terms I might hear when working with Agari?

Threat Feed: A service provided by Agari to send un-whitelisted URIs parsed from RUF (forensic) data to a phishing analysis + take-down vendor. This service allows potential phishing URIs to be analyzed faster than relying on other methods of phish reporting (such as user submitted reports) because the URIs are sent for analysis in near real time.

“Take Down” Service: Security vendors partnered with Agari and contracted by the domain owner to analyze potentially malicious URIs and the websites they lead to. The take down service uses relationships with ISPs, web hosts, and DNS providers to “take down” sites they positively identify as phishing and/or malware hosting sites.

Phish: A type of malicious email that attempts to deceive the end user by masquerading as known brand or entity, like a bank, social network, or e-commerce site. The goal of a phish is generally to trick a user into clicking on a link which will ultimately lead them to divulge confidential personal information and/or download malware onto their personal computer.

False Positive: Legitimate email which is rejected or marked for quarantine. In traditional spam fighting this occurs due to over aggressive spam filter settings or poor emailing practices on the part of the email sender. In DMARC enforcement this occurs when authentication fails for reasons which are out of the email sender's control, like forwarding or errors at the email receiver.

Forwarded Message: A message which was originally sent to one email address, but is subsequently directed to a different address when delivery to the original address is attempted. In terms of the Agari service and DMARC enforcement, forwarding refers to server-side forwarding, when the forward happens automatically by the email server. This is different than an end user clicking “Forward” in their email client, which is essentially the same as sending a new email. There are different reasons one might set up automatic forwarding, one common use being a college alumni email address. Often times the act of forwarding will cause changes to the message which break authentication and can lead to false positives.

RFC (Request For Comments): A type of standards document published by the Internet Engineering Task Force (IETF). The information contained in an RFC outline the standard methods, procedures, and protocols used for systems to interact on the Internet.

SPF (Sender Policy Framework): A DNS-based technology which allows a domain owner to specify a limited set of IP addresses from which email purporting to be from that domain may be sent.

• Note that the domain authenticated by SPF is not the “header From” domain which is visible in most email clients. SPF authenticates the envelope domain, also called the MailFrom domain, described in RFC 5321. This domain typically appears in the “Return-Path:” message header.

DKIM (DomainKeys Identified Mail): A message-signing technology making use of private/public key encryption technologies. DKIM allows a sender to insert a digital signature into each email as a message header. The signature covers selected message headers and usually the entire message body, including attachments. Email receivers can decode and verify the signature using a DNS-based public key.

• Note that the domain signing a message with DKIM is not the “header From” domain which is visible in most email clients. The DKIM signing domain is indicated by a field in the DKIM signature called the signing domain, indicated by a “d=”.

DMARC (Domain-based Message Authentication, Reporting, & Conformance): A DNS-based technology allowing domain owners to assert a policy for unauthenticated email from their domain and receive feedback on message authentication rates. DMARC policy and feedback are based on the underlying SPF and DKIM authentication mechanisms.

• Note that DMARC policy and feedback apply to the “header From” domain which is visible in most email clients, thus helping reduce the risk of phishing for that domain. DMARC adds an “identifier alignment” check to ensure the the identifiers used for SPF and DKIM authentication have a valid relationship to the header From domain.

DMARC Policy: This is the action that a domain owner requests email receivers to take on unauthenticated messages with their domain in the header From address. A domain owner specifies the domain’s DMARC policy in the “p=” field of the DMARC record.

• Reject: A reject policy (‘p=reject’) requests that receivers reject any unauthenticated messages during the SMTP conversation. Rejected messages will never be available to the recipient.

• Quarantine: A quarantine policy (‘p=quarantine’) requests that receivers place unauthenticated messages in the recipient’s spam folder or other quarantined area where the message may be reviewed with suspicion.

• None: A policy of none (‘p=none’) tells a receiver to take no special action on unauthenticated messages, but send DMARC data to the specified reporting addresses in the domain’s DMARC record. As such a None policy is often referred to as a "Monitor-only" policy.

• Receiver Override: The DMARC specification allows a receiver to selectively override a reject policy when they decide that a message should be delivered due to their local policy. These messages may still be rejected or quarantined if further evaluation by the receiver indicates that is the appropriate action, but this is not reflected in the DMARC data Agari receives. Reasons that a receiver might choose to override a reject policy include if they believe authentication was broken due to forwarding or mailing list expansion, or they want to further evaluate messages failing authentication from a source with an otherwise good reputation.

Identifier Alignment: A concept introduced by the DMARC specification enabling email authentication technologies to better protect against phishing. Identifier alignment forces the domains authenticated by SPF (the MailFrom domain) and DKIM (the DKIM signing domain) to have a relationship to the “header From” domain which is more typically visible to a user in email clients. In “strict” alignment mode the domains must be an exact match. In “relaxed” alignment mode the domains can be different sub-domains of the same organizational domain.

• Header From domain: This is the domain portion of the email address that is most commonly visible to end users in the “From:” field displayed in an email client. It is not the display name which is also commonly displayed in the same “From:” field. For example, the following may be displayed in an email client “From: Agari <donotreply@agari.com>”. In this example “Agari” is the display name, while “agari.com” is the header From domain.

• MailFrom domain: This identifier is used by the SPF authentication mechanism. It is the domain portion of the email address that is commonly found in the “Return-Path” message header. When a message is undeliverable, bounce messages are sent to this address. It is sometimes called the bounce address, the envelope address, or the 5321 MailFrom. End users will not see this email address in a typical mail client unless they choose to view detailed message headers or full message source.

• DKIM signing domain: This identifier is used by the DKIM authentication mechanism. It is the domain designated by the ‘d=’ tag in the DKIM signature. The DKIM public key used to decode the DKIM signature in a message is discovered from a DNS lookup that combines this ‘d=’ domain with the DKIM selector (‘s=’), also in the DKIM signature.

• DMARC-DKIM: This is the combination of the raw DKIM authentication result and DMARC identifier alignment. The DKIM signing domain (d=) must be in DMARC alignment with the header From domain per the DMARC specification AND the DKIM authentication check must "pass" in order for the DMARC-DKIM result to be "pass".

• DMARC-SPF: This is the combination of the raw SPF authentication result and DMARC identifier alignment. The envelope domain (also called the MailFrom domain) must be in DMARC alignment with the header From domain per the DMARC specification AND the SPF authentication check must “pass” in order for the DMARC-SPF result to be "pass".

• Authenticated: If either DMARC-SPF or DMARC-DKIM has passed the message is considered to be authenticated.

• Unauthenticated: If neither DMARC-SPF nor DMARC-DKIM has passed the message is considered to be unauthenticated. These messages fail the DMARC test and are subject to the policy specified in the domain's DMARC record and/or by the Agari Email Trust Network.

FBR (Feedback Report) or RUF data: The near real time failure reports Agari receives from some data partners, providing feedback on individual messages which failed one or both forms of authentication. These are displayed in the Agari Customer Protect Portal "Failure Samples" area.

“A” record (host address resource record): A DNS record type that maps a DNS domain name to and IP address (or multiple IP addresses).

Example: agari.com. A 50.57.232.127

CNAME record (canonical name resource record): A DNS record type that acts as an alias or pointer to a different location in DNS.

Example: _dmarc.alt.agari.com. CNAME _dmarc.agari.com.

_dmarc.agari.com. TXT "v=DMARC1;p=none;rua=mailto:d@rua.agari.com"

MX record (mail exchanger resource record): A DNS record type that identifies the inbound receiving email servers for a domain.

Example: agari.com. MX 1 aspmx.l.google.com.

NS record (name server record): A DNS record type that identifies the authoritative servers responsible for resolving DNS records for the domain.

Example: agari.com. NS ns1.agari.com.

TXT record (text resource record): A DNS record type that allows arbitrary text to be associated with a domain name.

Example: agari.com. TXT “Some text string related to agari.com here.”

DMARC record: A DNS TXT record which uses a format specified in the DMARC draft specification to define a domain’s DMARC policy and data reporting addresses. A domain’s DMARC record is located in DNS at _dmarc.DOMAIN as a TXT record.

SPF record: A DNS TXT record (or an SPF record type) which uses a format specified in RFC 7208 to designate the set of IP addresses which are permitted to send mail using the domain in the MailFrom address.

• Note that there is also a SPF DNS resource record type which can be used instead of a TXT record to publish a domain’s SPF record, but this is far less commonly used than the TXT record.

DKIM public key: A DNS TXT record that uses a format defined in RFC 6376 to publish a public DKIM key used to decrypt and verify the signature in a message’s DKIM header. A domain’s DKIM public key is located at selector._domainkey.domain-name, where the selector and domain name are specified as part of the DKIM signature.