DOCSLIB.ORG

SPF and DKIM • Weeks 3-4: Time to Implement! • Demonstrations on How to Implement DMARC on Windows DNS, BIND and a Cloud-Based DNS Provider

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SPF and DKIM • Weeks 3-4: Time to Implement! • Demonstrations on How to Implement DMARC on Windows DNS, BIND and a Cloud-Based DNS Provider Bootcamp Shehzad Mirza Director of Operations [email protected] [email protected] Bootcamp Plan and upcoming Webinars • Weeks 1-2: Getting Started • Bootcamp Introduction and DMARC Overview • Overview of DMARC, SPF and DKIM • Weeks 3-4: Time to ImpLement! • Demonstrations on how to impLement DMARC on Windows DNS, BIND and a Cloud-based DNS Provider. • Participants shouLd impLement DMARC during these weeks • Weeks 5-6: On Going Management: AnaLyze, Review and Adjust • What to Look for in DMARC reports and what needs to be adjusted before moving to an enforcement poLicy 2 2 Bootcamp Resources • Community Forum – community.globalcyberalliance.org • Bootcamp resource page - dmarc.globalcyberalliance.org/dmarc- bootcamp/ 3 Introduction to SPF and DKIM 4 Sender Policy Framework (SPF) • Defines which mail servers are authorized to send mail for the organization’s domain SPF • uses the “envelope from” to determine Sender PoLicy the sending domain Framework • TXT record on Domain Name Server (DNS) • Can only have one SPF record 6 SPF 7 SPF DNS TXT Record • Basic: Name: <domain> or @ or leave blank Value: "v=spf1 mx -all" • Complex: Name: <domain> Value: "v=spf1 mx a:<additional mail servers> include:<3rd party domain> ip4:<IP address/range> ~all" 8 The TXT record will always begin with this. This defines the version of v=spf1 SPF being used. Currently SPF version 1 is the only available version If this is included, then the incoming mail servers (MXes) of the mx domain are authorized to also send mail for that domain SPF Tags This part should only be included if there are other systems, other a:<domain> than the mail servers, authorized to send mail for the domain. include: Everything considered legitimate by a trusted external domain is <external legitimate for the organization’s domain. domain> ipv4: This should be used if only IP addresses are available ipv6: 9 ptr • Use the source-ip's PTR and a reverse map query exists • The existence (any valid A record) of the specified domain allows the test to pass redirect SPF Tag • Redirects verification to use the SPF (con’t) records of the defined domain exp • defines a DNS name whose TXT record's text may be returned with any failure message • must be at end of policy Macro-expressions - complex and confusing 10 • -alL – Hard FaiL • only the domain’s mail servers (and those in the ‘a’ and ‘include’ sections) are allowed to send SPF ‘all’ tag mail for the domain. All other are prohibited. • ~aLL – Soft FaiL • if email is from a server not on the policy, the message is still accepted but marked as non compliant. • ?aLL • explicitly that nothing can be said about validity. • +aLL • means that any host can send mail for the domain. This shouLd never be used. 11 Example SPF Record • v=spf1 mx include:_spf.google.com -all • v=spf1 mx include:spf.protection.outlook.com –all • v=spf1 include:spf.protection.outlook.com ip4:161.11.10.20 –all 12 Items Needed for SPF • Access to org’s public DNS • Determine if MX records are being used • IP address or domains of systems sending on organization’s behalf • If 3rd party vendors support SPF • what needs to be added to your SPF • Confirm SPF alignment (make sure sending domain is using org’s domain) 13 SPF Alignment Good: From: [email protected] Return-Path: <[email protected]> Received-SPF: pass (google.com: domain of [email protected] designates 2607:f8b0:4864:20::d34 as permitted sender) client-ip=2607:f8b0:4864:20::d34; FaiL: From: [email protected] Return-Path: < [email protected] > Received-SPF: pass (google.com: domain of bounce-mc.us15_71628198.660451- [email protected] designates 205.201.133.58 as permitted sender) client-ip=205.201.133.58; To achieve a passing SPF aLignment, the From: header domain must match the domain used to authenticate SPF (e.g., enveLope “maiL from:” “return-path” domain). 14 SPF Aligntment 15 SHORTFALLS • Recipient server must decide how to handle failed messages • Once implemented, there is no mechanism to determine if the message was rejected or bounced • If used alone, any other domain using the same hosting provider can still forge mail of other domains • 10 domain lookup limit • does not validate the “header from”, but uses the “envelope from” to determine the sending domain 16 10 Domain Lookup Work Around • SPF Flattening • Use IP address instead of domains name • Be extremely careful • Dynamic SPF • Capability provided by various DMARC Vendors 17 DomainKeys Identified Mail (DKIM) Validates a domain’s identity that is associated with a mail message by using authentication in the form of a digital DKIM signature DomainKeys Identified MaiL TXT or CNAME Record on Domain Name Server (DNS) • Can have more than one record 19 Generate DKIM Keys • Two Keys • Private Key • Public Key • Key generation is dependent on: • If you are using an external service for both mail and DNS (i.e. G Suite or 0365) • If the organization has its own email server or gateway 20 DKIM with 3rd Party MaiL Providers and Marketing Systems • The mail provider will provide you with the public key. This public key is then published as a TXT or CNAME record in DNS. • Some cases, the mail provider will supply the full DNS TXT record. • The private key is held by the mail provider and typically not provided to the organization. 21 DKIM with Organizations MaiL Server or Gateway • Some Mail gateways will generate the DKIM Keys (i.e. Cisco Ironport and Mimecast). • Linux - an open source project called opendkim (http://www.opendkim.org/) is available. • contains various tools to assist with creating the DKIM key and for integrating DKIM signing into various mail systems • MS Exchange – dkim-exchange (github) • Another option is to use OpenSSL to generate the DKIM keys. • Private Key: openssL genrsa -out dkim-private.pem 1024 -outform PEM • Public Key: openssL rsa -in dkim-private.pem -out dkim-public.pem -pubout -outform PEM • Move the DKIM Private Key in the location specified by the DKIM installation. • Make sure it is in a foLder with restricted access. 22 DKIM DNS TXT Record name: <selector>._domainkey.<domain> vaLue = "k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMX n3LRGKOD5o6l;" 23 DKIM Record Name • <seLector> • name of the DKIM key in DNS. Any name can be used before the “.”, however it must have“_domainkey” after. • _domainkey - required • <domain> - may not be needed 24 DKIM Tags • k=rsa – defines key algorithm used • p=<key string in public key fiLe generated previously> – defines the public key string • 1024 – most common size • 2048* 25 Items needed for DKIM • Access to public DNS • Define selector • DKIM key generator and signing tool • built-in to mail server or email security gateway • provided by 3rd party email provider • If 3rd party vendors support DKIM • what needs to be added to DNS (TXT or CNAME record) • Confirm DKIM alignment (make sure signing server is using org’s domain) 26 DKIM Alignment Message Header: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalcyberalliance.org; s=gca; h=mime-version:references:in-reply- to:from:date:message-id:subject:to :cc; 27 Shortfalls • Does NOT define what to do if signature is bad or good • No reporting mechanism • Does NOT determine if the sender server is allowed to send outgoing mail for a specific domain • Allows for recipient filters to determine the authenticity of the mail message being sent • recipient server must decide how to handle failed messages. 28 Domain-based Message Authentication, Reporting & Conformance Policy that will define SPF and DKIM (the A or Authentication in DMARC) and must work together using the policy level defined by your DMARC organization (which is the C or Conformance in DMARC), as well as add a reporting feature (the R or Reporting in DMARC). Uses Domain Name Server to define the policy 29 DMARC with SPF and DKIM • Resolves most issues with SPF and DKIM • Domains using the same hosting provider or coming from org mail servers – Implement SPF and DKIM • DMARC will utilize SPF and DKIM checking • DMARC Reports • DMARC indicates what to do with message if either were to fail or pass 30 Next Webinars: DMARC Technical Details and Windows DNS Sept 24th or Oct 1st DMARC Technical Details and BIND Sept 25th or Oct 2nd DMARC Technical Details and Cloud DNS Sept 26th or Oct 3rd Bootcamp Resources • Community Forum – community.globalcyberalliance.org • Bootcamp resource page - dmarc.globalcyberalliance.org/dmarc- bootcamp/ 32 Q&A 33 Thank You! Shehzad Mirza [email protected] [email protected].
Load more

Recommended publications
  • DMARC and Email Authentication
    DMARC and Email Authentication Steve Jones Executive Director DMARC.org Cloud & Messaging Day 2016 Tokyo, Japan November 28th, 2016 What is DMARC.org? • DMARC.org is an independent, non-profit advocate for the use of email authentication • Supported by global industry leaders: Sponsors: Supporters: Copyright © 2016 Trusted Domain Project 2 What Does DMARC Do, Briefly? • DMARC allows the domain owner to signal that fraudulent messages using that domain should be blocked • Mailbox providers use DMARC to detect and block fraudulent messages from reaching your customers • Organizations can use DMARC to perform this filtering on incoming messages – helps protect from some kinds of phishing and “wire transfer fraud” email, also known as Business Email Compromise (BEC) • Encourage your partners/vendors to deploy inbound DMARC filtering for protection when receiving messages • More information available at https://dmarc.org Copyright © 2016 Trusted Domain Project 3 Overview Of Presentation •DMARC Adoption •Case Study - Uber •Technical Challenges •Roadmap Copyright © 2016 Trusted Domain Project 4 DMARC Adoption This section will provide an overview of DMARC adoption since it was introduced, globally and within particular country-specific top-level domains. It will also show how the DMARC policies published by top websites has evolved over the past two years. Copyright © 2016 Trusted Domain Project 5 Deployment & Adoption Highlights 2013: • 60% of 3.3Bn global mailboxes, 80% consumers in US protected • Outlook.com users submitted 50% fewer phishing
    [Show full text]
  • DMARC — Defeating E-Mail Abuse
    CERT-EU Security Whitepaper 17-001 DMARC — Defeating E-Mail Abuse Christos Koutroumpas ver. 1.3 February 9, 2017 TLP: WHITE 1 Preface E-mail is one of the most valuable and broadly used means of communication and most orga- nizations strongly depend on it. The Simple Mail Transport Protocol (SMTP) – the Internet’s underlying email protocol – was adopted in the eighties and is still in use after 35 years. When it was designed, the need for security was not so obvious, and therefore security was not incor- porated in the design of this protocol. As a result, the protocol is susceptible to a wide range of attacks. Spear-phishing campaigns in particular can be more successful by spoofing (altering) the originator e-mail address to imper- sonate a trusted or trustworthy organization or person. This can lead to luring the recipient into giving away credentials or infecting his/her computer by executing malware delivered through the e-mail. While raising user awareness on how to avoid e-mail fraud is recommended, the Verizon Data Breach Investigations Report indicates that more needs to be done. The DBIR report reveals that 30% of all phishing e-mail messages were opened by the recipients and with 12% clicked on the content and executed malicious code. The median time for the first user of a phishing campaign to open the malicious email is 1 minute, 40 seconds. The median time to the first click on the attachment was 3 minutes, 45 seconds. These statistics highlight the risk for an organization on the receiving end of spear-phishing e-mails.
    [Show full text]
  • XEP-0347: Internet of Things - Discovery
    XEP-0347: Internet of Things - Discovery Peter Waher mailto:peterwaher@hotmail:com xmpp:peter:waher@jabber:org http://www:linkedin:com/in/peterwaher Ronny Klauck mailto:rklauck@informatik:tu-cottbus:de xmpp:TBD http://www-rnks:informatik:tu-cottbus:de/~rklauck 2018-11-03 Version 0.5.1 Status Type Short Name Deferred Standards Track iot-discovery This specification describes an architecture based on the XMPP protocol whereby Things can be in- stalled and safely discovered by their owners and connected into networks of Things. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • DHS Mandates DMARC for Email Security
    Agari U.S. Federal Government DMARC Adoption: DHS Mandates DMARC for Email Security Executive Summary On October 16, 2017, the U.S. Department of Homeland Security issued a Binding Operational Directive (BOD) 18-01 that mandates the implementation of specific security standards to strengthen email and 82% of all Federal domains have no web site security. As part of this directive, all federal agencies that operate DMARC policy .gov email domains must implement a DMARC monitoring policy (p=none) within 90 days. Furthermore, all federal agencies must move to a reject policy (p=reject) by 1 year. Based on Agari research of public DNS records, 82% percent of all US Federal Government domains do not have a DMARC policy, leaving their constituents unprotected from phishing and other forms of email attacks 86% of Federal that impersonate their agency email domains. Cybercriminals exploit this domains that use DMARC choose Agari 1 vulnerability by sending billions of phishing emails per year claiming to be from these government agencies. 1 Includes all domains that send aggregate data to a 3rd party DMARC vendor. 1 | www.agari.com Email Abuse on Federal Agency Domains Phishing continues to be a pervasive threat in the United States and around the world.The impact of these threats has been felt specifically by government agencies. Beyond the high-profile targeted attacks that have made headlines, criminals are executing phishing attacks leveraging the brand name of agencies. Indeed, over the last six months, Agari has seen an amplification of attacks against our Federal customers. As the following chart indicates, on the email-sending and defensive domains that we monitor, 25% of email volume was malicious or failing authentication.
    [Show full text]
  • A Survey of DNSSEC Deployment in the US R&E Community
    A survey of DNSSEC deployment in the U.S. R&E community Shumon Huque; University of Pennsylvania Bill Owens; NySERNET Joint Techs Conference, Stanford University, July 16th 2012 http://events.internet2.edu/2012/jt-stanford/ 1 Abstract: DNSSEC (DNS Security Extensions) is a system to verify the authenticity of DNS data using public key signatures. Although a small number of institutions in the R&E community have been at the forefront of DNSSEC deployment, the adoption rate in the larger community is still quite low. This talk will present some results of an ongoing project to survey the status of DNSSEC deployment in the US Research & Education and a few other communities. It also surveys the status of several other DNS capabilities, such as availability of the service over IPv6 transport, TCP transport, EDNS0 support, etc. [Joint Techs, Stanford University, Jul 2012] 2 Agenda • DNSSEC deployment monitoring project overview • Live demo of the website • New uses of DNSSEC by applications (DANE/TLSA etc) • (time permitting) [Joint Techs, Stanford University, Jul 2012] 3 DNSSEC at a glance • “DNS Security Extensions” • A system to verify the authenticity of DNS “data” using public key signatures • Specs: RFC 4033, 4034, 4035, 5155 (and more) • Helps detect DNS spoofing, misdirection, cache poisoning .. • Additional benefits: • Ability to store and use cryptographic keying material in the DNS, eg. SSHFP, IPSECKEY, CERT, DKIM, TLSA, etc .. [Joint Techs, Stanford University, Jul 2012] 4 Other surveys • SecSpider • http://secspider.cs.ucla.edu/
    [Show full text]
  • XEP-0156: Discovering Alternative XMPP Connection Methods
    XEP-0156: Discovering Alternative XMPP Connection Methods Joe Hildebrand Peter Saint-Andre Lance Stout mailto:jhildebr@cisco:com mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:hildjj@jabber:org xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2020-07-07 Version 1.3.1 Status Type Short Name Draft Standards Track alt-connections This document defines an XMPP Extension Protocol for discovering alternative methods of connecting to an XMPP server using two ways: (1) DNS TXT Resource Record format; and (2) Web Host Metadata Link format. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • DMARC Jesse Thompson, Technical Architect University of Wisconsin-Madison [email protected] Motivation → Authenticity
    Email Authenticity with DMARC Jesse Thompson, Technical Architect University of Wisconsin-Madison [email protected] Motivation → Authenticity ● Mail your institution sends isn’t accounted for ● Mail claiming to be your domain may be fraud ● Instead of filtering the bad...we start authenticating the good? Functional Motivators for Email Authenticity 1. Deliverability: Google/MS/etc starting to require 2. Policies: DHS Binding Operational Directive 18-01 3. Security: Stop abuse Build on SPF SPF = Sender Policy Framework Publish in DNS a list of servers authorized for MAIL FROM (SMTP envelope return path). Receivers consult list. https://tools.wordtothewise.com/spf/check/wisc.edu wisc.edu. 3600 IN TXT "v=spf1 ip4:144.92.197.128/25 ?all" Build on DKIM DKIM = Domain Keys Identified Mail Attach signatures to email. Public key in DNS. Receivers verify signature. https://tools.wordtothewise.com/dkim/check/wisc.edu/selector1 DKIM-Signature: v=1; a=rsa-sha256; d=wisc.edu; s=selector1; c=relaxed/relaxed; q=dns/txt; t=1126524832; x=1149015927; h=from:to:subject:date:keywords:keywords; bh=MHIzKDU2Nzf3MDEyNzR1Njc5OTAyMjM0MUY3ODlqBLP=; b=hyjCnOfAKDdLZdKIc9G1q7LoDWlEniSbzc+yuU2zGrtruF00ldcF VoG4WTHNiYwG Build on SPF and DKIM SPF Problems: ○ Users can’t see MAIL FROM / no alignment to Header From domain ○ Forwarding / mailing lists ○ DNS lookup limit of 10 ○ Inconsistent enforcement by receivers DKIM Problems: ○ Users can’t see key selector / no alignment to Header From domain ○ Message modification in transit / mailing lists ○ Key management / vendor support Protagonist → Header From domain Need to create a link between the domain and the message. dmarc.org What is DMARC? Domain-based Message Authentication Reporting and Conformance 1.
    [Show full text]
  • FAQ: DMARC for Email Service Providers Email Authentication Is Becoming a Big Deal
    FAQ: DMARC for Email Service Providers Email authentication is becoming a big deal. Here’s a guide to the key standards from ValiMail. FAQ: DMARC for Email Service Providers Port25 Evaluation Requests By Hourly Email Volume 34.22% 17.63% Less Than Greater 10K than 1M 12.09% Between 250K-1M Why email authentication matters: This is how non-authenticated email 30.24% 13.94% will look in Gmail and Outlook, starting sometime in 2016. Between Between 10K-50K 50K-250K WHAT IS DMARC? DMARC — Domain-based Message Authentication, Reporting and Conformance — is an open email authentication standard that sending domains use to block fraudulent emails. DMARC is built on top of two earlier standards — SPF and DKIM — and adds additional Port25 LinkedIn Engagement Data features like reporting, policy definition, and the notion of identity By Company Size alignment. 7.37% DOES DMARC STOP PHISHING? 201-500 Employees When configured correctly, DMARC can completely stop phishing 8.42% attacks in which the attacker sends an email with a ‘From’ address 5,001-10,000 that appears to originate from a protected domain. As this is the Employees 25.26% 10,001+ primary form of phishing attack, DMARC is a very effective tool to Employees defend customers, employees, partners, and others from phishing. 8.42% 11-50 Employees DOES DMARC HELP DELIVERABILITY? Large-scale email receivers, such as Google, Microsoft, and 8.95% 16.32% 1,001-5,000 51-200 Yahoo!, are increasingly requiring that email messages be properly Employees Employees authenticated in a DMARC-compliant way. So adding a DMARC record for a domain, in conjunction with properly configured SPF and/or DKIM records, will help ensure proper delivery.
    [Show full text]
  • DMARC: Monitor & Secure Your Email Delivery
    Guide DMARC: Monitor & secure your email delivery Chris Nagele Founder of Wildbit postmarkapp.com Read the web version. Do you know every source of email for your domain? Are spammers trying to spoof your email domain for hacking or fraud opportunities? Are you complying with the best email practices to ensure inbox delivery? These are the questions that DMARC answers, giving you full control of email delivery for your company’s domain. At Postmark, email authentication has been extremely important to us from day one. We believe that anyone should be able to easily send emails with proper infrastructure, tools, and email standards without having to pay enterprise prices. DMARC, and our support of it, is a big part of this mission. 2 What is DMARC? DMARC (Domain-based Message Authentication, Reporting & Conformance) is a standard that prevents spammers from using your domain to send email without your permission — also known as spoofing. Spammers can forge the “From” address on messages so the spam appears to come from a user in your domain. A good example of this is PayPal spoofing, where a spammer sends an email to you pretending to be PayPal in an effort to obtain your account information. DMARC ensures these emails get blocked before you even see them in your inbox. In addition, DMARC gives you great visibility and reports into who is sending email on behalf of your domain, ensuring only legitimate email is received. The good news is that DMARC is open and free for anyone to use, allowing you to secure your domain’s emails and gain control of your email delivery.
    [Show full text]
  • 1912 the Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational
    Network Working Group D. Barr Request for Comments: 1912 The Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational Common DNS Operational and Configuration Errors Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537]. 1. Introduction Running a nameserver is not a trivial task. There are many things that can go wrong, and many decisions have to be made about what data to put in the DNS and how to set up servers. This memo attempts to address many of the common mistakes and pitfalls that are made in DNS data as well as in the operation of nameservers. Discussions are also made regarding some other relevant issues such as server or resolver bugs, and a few political issues with respect to the operation of DNS on the Internet. 2. DNS Data This section discusses problems people typically have with the DNS data in their nameserver, as found in the zone data files that the nameserver loads into memory. 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious.
    [Show full text]
  • DMARC Reports
    Bootcamp Shehzad Mirza Director of Operations [email protected] [email protected] DMARC Reporting & Analysis: What Happens Next 3 DMARC DNS TXT Record • Basic: Host: _dmarc. <domainname> Value: v=DMARC1; p=quarantine; rua=mailto:<email address>; ruf=mailto:<email address>; • Complex: Host: _dmarc. <domainname> Value: v=DMARC1; p=none; rua=mailto:<email address>; ruf=mailto:<email address>; fo=1; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=reject; 4 Overview 5 1 2 3 4 6 7 5 DMARC Reports • DMARC Generates two types of reports: • Aggregate • Forensic 6 Forensic/Failure Reports (ruf tag) • Number of reports is dependent on amount of email sent • Reports will provide insiGht as to which messaGes were marked as suspicious • Concerns with privacy 7 Sample Forensic/Failure Report 8 Aggregate Reports (rua tag) • Reports sent in XML format to email of choice (can be sent to multiple addresses) • Number and lenGth of reports is dependent on amount of email sent • Allows for: • IT staff to correct any issues with valid messages being dropped by the policy • Visibility into which systems are sending email using org’s domain name (authorized and unauthorized sending IP addresses) 9 <?xml version="1.0" encoding="UTF-8" ?> <feedback> <report_metadata> <org_name>google.com</org_name> <email>[email protected]</email> <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info> <report_id>6156901232184779430</report_id> <date_range> <begin>1466121600</begin> <end>1466207999</end> </date_range>
    [Show full text]
  • What Is DMARC, SPF, and DKIM? • How to Configure • Common Mistakes • Best Practices • How Phishes Get By
    How to Prevent 81% of Phishing Attacks From Sailing Right Through DMARC, SPF, and DKIM Roger A. Grimes Data-Driven Defense Evangelist [email protected] About Roger • 30 years plus in computer security • Expertise in host and network security, IdM, crypto, PKI, APT, honeypot, cloud security • Consultant to world’s largest companies and militaries for decades • Previous worked for Foundstone, McAfee, Microsoft • Written 11 books and over 1,000 magazine articles • InfoWorld and CSO weekly security columnist since 2005 • Frequently interviewed by magazines (e.g. Newsweek) and radio shows (e.g. NPR’s All Things Considered) Roger A. Grimes Certification exams passed include: Data-Driven Defense Evangelist KnowBe4, Inc. • CPA • CISSP Twitter: @RogerAGrimes • CISM, CISA LinkedIn: https://www.linkedin.com/in/rogeragrimes/ • MCSE: Security, MCP, MVP • CEH, TISCA, Security+, CHFI • yada, yada Roger’s Books 3 KnowBe4, Inc. • The world’s most popular integrated Security Awareness Training and Simulated Phishing platform • Based in Tampa Bay, Florida, founded in 2010 • CEO & employees are ex-antivirus, IT Security pros • 200% growth year over year • We help tens of thousands of organizations manage the problem of social engineering 4 Today’s Presentation • What is DMARC, SPF, and DKIM? • How to Configure • Common Mistakes • Best Practices • How Phishes Get By 5 • What is DMARC, SPF, and DKIM? § How to Configure Agenda • Best Practices • How Phishes Get By 6 DMARC, DKIM, SPF Global Phishing Protection Standards • Sender Policy Framework (SPF) • Domain
    [Show full text]