Better Email with SPF, DKIM, and DMARC

Jim Wagner, Technology Coordinator

Arcadia Valley R-II School District

Ironton, Missouri

jwagner@avr2.org

​

​

​

Last updated July 2020

Introduction

• Audience
• Email system administrators with just about any experience level
• Our focus will be on G Suite, but the tools we’ll discuss are applicable to other email systems as well
• As of July 2020 fewer than 10% of Missouri school districts use all three tools we’ll be discussing, and about one-third use none of them
• Purpose
• Get good messages delivered: Make sure that legitimate messages from our users get delivered to inboxes
• Block bad messages: Stop forged emails that appear to be from our domain

​

Have your users experienced any of these problems?

• Legitimate messages they send get misclassified as spam. Maybe you dealt with it by whitelisting all messages from your domain. This is a bad idea because it allows malicious messages through.
• Legitimate messages sent to Google groups are held as spam and may need admin approval for delivery.
• They receive emails, probably malicious, that appear to be from a legitimate address in your domain but that the user didn’t actually send
• Users receive bounce messages from undeliverable messages that they didn’t actually send

​

How did email get to be such a threat?

Internet email was first used by a small, trusted group of researchers. That group has expanded to billions of people of all kinds bringing us

• Message spoofing/forgery
• Spam
• Viruses, worms, ransomware, and other malware via attachments and links
• Phishing

What’s the weakest link in data security?

​

Our users, of course. They

• Manage passwords poorly
• Click on email links and attachments
• Install questionable apps
• Give apps access to their data
• Divulge private information

User education is critical, but it’s hard

• Choosing good passwords and using password managers
• Know what phishing is
• Know how to spot phishing emails
• Be cautious of any emails with attachments or links, especially those from unknown senders or with a generic message body.
• Can I tell from the context that the message came from a sender I know and that it’s meant for me?
• Know what do if an email is or may be a phishing attempt
• Understand that email forgery is real and often easy. �Our goal as email admins is to make it harder.
• Be careful when installing apps and add-ons
• Encourage use of Gmail clients, which have additional security features

Some things we can’t fix.

Then there are things we can do to protect our users and our data.

G Suite Toolbox Check MX Tool

• Is your G Suite domain configured to Google’s recommended settings?
• Which email integrity and protection features do you have enabled?

https://toolbox.googleapps.com/apps/checkmx/

​

MX Tool Sample Output

The report on our domain originally looked something like this.

3 Admin Tools for User Protection and Email Integrity

SPF, DKIM, DMARC

• Are defined in IETF RFCs - Not Google-specific
• Operate with DNS TXT records
• Require no training or action on the part of end users

Google and other major mail providers already analyze messages with these tools, but it’s up to each sending domain to configure them to reap the benefits.

​

​

Why SPF, DKIM, and DMARC?

• Simply put, SPF, DKIM, and DMARC are technical measures used to distinguish which messages that appear to be from your domain are legitimate and which ones are not
• If your domain has none of these measures in place there is nothing in emails from your domain that insures or disproves their legitimacy, which can cause various serious problems for your users and others

​

Increased Email Integrity with SPF+DKIM+DMARC

• Spammers are probably less likely to try to forge emails from domains with these protections in place
• We no longer seem to receive forged messages from our domain
• Fixed a problem in which one of our users whose legitimate messages to our staff mailing list were being blocked after her account was compromised
• No reports of legitimate messages from our users being misclassified as Spam

​

SPF - Sender Policy Framework

• Specifies which third-party organizations/systems/networks are permitted to send email on behalf of your domain
• Must account for all such third parties
• All G Suite organizations must include Google
• Student information systems
• Student/parent/community notification systems
• H.R. systems
• SPF records can contain, among other elements
• IP addresses or ranges in CIDR format
• “A” records from DNS
• “Includes” - references to other SPF records
• Must end with an action to take for senders that aren’t approved - soft fail (~all) is recommended
• Your tech partners will usually provide information that needs to be included for them in your SPF record

SPF - Sender Policy Framework

• Google says G Suite organizations should have an SPF record in place
• Google recommends using ~all to softfail all non-approved sources as in these sample TXT records:
• Basic - Google servers only: v=spf1 include:_spf.google.com ~all
• Example with allowances for additional sources: �v=spf1 ip4:1.2.3.4 ip4:192.168.0.1/16 a:server.Arecord.org include:_spf.google.com ~all
• For Tyler SIS hosted use include:spf.sisk12.com
• As long as you choose soft fail (~all) instead of hard fail (-all) setting up SPF should be fairly low risk

SPF - Sender Policy Framework

DNS lookups

• Any server name in an SPF record requires a DNS lookup
• This includes any “include” options and any name that is contained within another include record
• There is a maximum of 10 DNS lookups permitted in an SPF record and all of its subrecords (includes)
• This can get tricky if you have a lot of permitted third parties. Google’s include alone uses up 4 lookups (its include has 3 includes in it)
• SPF record check tools like this one can help you see whether you’re under the limit

​

Take your SPF live

• Once you build your SPF record it needs to be published to DNS to take effect
• The third party (often MOREnet in Missouri) who manages your DNS
• Publish yourself if you manage your own
• There is nothing to do in the G Suite admin console

​

SPF Caveats - With Encouragement

• Of SPF, DKIM, and DMARC, SPF can be the trickiest to set up.
• Need to account for all third-party networks permitted to send emails for your domain
• If you include names (as opposed to only IP addresses/netblocks) you can have no more than 10 lookups in your SPF record. Use an SPF record analyzer to check.
• Don’t let concern about having a perfect SPF record stop you from creating one. You can improve it later if needed.
• DMARC reporting can help you find legitimate third-party sources that you forgot.

DKIM - DomainKeys Identified Mail

• The easiest of the three tools to set up (on G Suite)
• Digitally signs mail to attest that
• The message came from the given domain
• The message content is unmodified
• DKIM is extremely easy to set up with G Suite (Search for “Authenticate email” in the admin console)
• Google admin console generates the DNS TXT record for your domain
• Add it to your domain's public DNS records as a TXT record of the form google._domainkey.your_domain.org "v=DKIM1; k=rsa; p=M3IBIjaNBzkq...”
• Wait for DNS propagation, then turn on email signing in the Google admin console
• Check your record with G Suite Toolbox Dig tool
• DKIM does not cause blocking on its own, and so is a small risk to set up. There’s no reason not to do it.

​

Implement DKIM Signing for Devices

• G Suite users who authenticate to Google via web, app, etc., will have their messages properly DKIM signed
• For devices like faxes & scanners Google offers options for sending directly through Google’s servers
• G Suite SMTP relay
• Authentication is provided by IP addresses set in the Google Admin console. (“SMTP relay service” - more on next slide)
• May send from non-existent addresses (fax@domain.org)
• Gmail SMTP server
• Requires authenticating with a Google account
• In both cases daily message limits apply

Configure G Suite SMTP Relay Service

• Allows devices to send email without needing an actual G Suite account/address
• Search for “SMTP Relay” in the admin console
• Customize options for
• Allowed senders
• Choose “Only accept mail from the specified IP addresses” and add your IP range(s). Any mail that comes from these addresses is trusted as coming from your domain.
• Optionally require SMTP authentication and/or encryption

​

DMARC - Introduction

• Domain-based Message Authentication, Reporting and Conformance
• The most interesting and powerful of these 3 tools
• Builds on SPF and DKIM, both of which should be in place first
• Receiving mail servers can examine the sending domain’s DMARC policy and take appropriate action based on the message
• Not every receiving mail system honors DMARC (the major ones do), and those that do have some discretion in how they do so

DMARC - Why use it?

• Provides control over forged messages that appear to come from your domain, which can
• Protect your users and others. Forged messages are almost always malicious
• Reduce email backscatter - bounce messages sent to your users as a result of undeliverable spam sent by forging their addresses
• Prevent unpleasant messages to your users (“Stop spamming me!”)
• Protect your domain’s reputation. Why would you want bad guys sending spam that appears to be from your domain?
• Adds reporting not available with SPF or DKIM; can help identify legitimate third-party sources to include in your SPF record

​

DMARC - Why use it?

Without DMARC and its reporting feature you have no idea to what extent your domain is being forged (abused), much less have any control over it. It can be a real eye opener.

Over two very atypical days in July 2020, Yahoo reported receiving over 444,000 emails that appeared to be from our domain, which has only about 1,000 users. Essentially all of those messages were forgeries, malicious in some way. Thanks to DMARC those forged messages to Yahoo were blocked.

​

DMARC DNS TXT Record Format

• Name of text record: _dmarc.your_domain.org
• Sample value: "v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:dmarc_reports@domain.org"
• v=DMARC1; DMARC version. Always DMARC1
• p=(policy); Requested action for messages from domain.org that fail DMARC check. Servers have discretion on exactly how to handle them.
• none; Send a report. Take no further action.
• quarantine; The receiving server may send the message to spam, hold it, or further process it in some way
• reject; Reject the message outright
• sp=(policy); Requested action for subdomains of domain.org
• pct=(number); Percentage of messages to be affected by the policy. Allows for gradual testing. If omitted default is 100.
• rua=(mailto:address); Address to send aggregate reports. Recommend to use a special account for this purpose.

DMARC Policy Record Examples

• Report only - Does not affect mail flow�"v=DMARC1; p=none; rua=mailto:dmarc_reports@domain.org"
• Moderately aggressive - Quarantine all failing messages from the domain, reject those from subdomains�"v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc_reports@domain.org"
• Aggressive - Reject all failing messages�"v=DMARC1; p=reject; rua=mailto:dmarc_reports@domain.org"

​

• When a mail system that supports DMARC receives a message it checks DNS for the From domain’s DMARC policy
• If a policy exists, DMARC passes if either SPF or the DKIM tests pass with alignment, that is, the SPF/DKIM domain is the same as the From field
• If both SPF and DKIM fail outright or because of non-alignment, DMARC fails

Headers of DMARC-Passed Message

Received: by 10.114.82.136 with SMTP id i8csp330009ldy;� Thu, 29 Sep 2016 06:54:14 -0700 (PDT)�X-Received: by 10.107.205.65 with SMTP id d62mr2848545iog.221.1475157254397;� Thu, 29 Sep 2016 06:54:14 -0700 (PDT)�Return-Path: <xxxxx@avr2.org>�Received-SPF: pass (google.com: domain of xxxxx@avr2.org designates 2607:f8b0:4001:c0b::22a as permitted sender) client-ip=2607:f8b0:4001:c0b::22a;�Authentication-Results: mx.google.com;� dkim=pass header.i=@avr2.org;� spf=pass (google.com: domain of xxxxx@avr2.org designates 2607:f8b0:4001:c0b::22a as permitted sender) smtp.mailfrom=xxxxx@avr2.org;� dmarc=pass (p=QUARANTINE dis=NONE) header.from=avr2.org�Received: by mail-it0-x22a.google.com with SMTP id r192so174728442ita.0� for <yyyyy@avr2.org>; Thu, 29 Sep 2016 06:54:14 -0700 (PDT)�DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;� d=avr2.org; s=google;� h=mime-version:in-reply-to:references:from:date:message-id:subject:to;� bh=CV0gT45fS+rXEYE2qoK7YWlUiPgVO1Hk1fgu09Qq21E=;� b=cLigjs4sViPtNAxj1zJ3/1gvetGOLyLQKN046Z2mWeu3JIS0yORqP5u6hWycRGonKh� Kc1T8NrSbMTZEO0sfEzzgOn1+tXblSmEqWpoVh5WTsGoVbrAxt57cr/kfhcWXkta5K//� tnmSrt6EjKa02RKMBLYrXk8WnXalY6fOl9COY=�

Headers of DMARC-Quarantined Message

Received: by 10.114.10.227 with SMTP id l3csp1878602ldb;� Mon, 29 Aug 2016 18:29:31 -0700 (PDT)�X-Received: by 10.194.123.228 with SMTP id md4mr678908wjb.91.1472520571146;� Mon, 29 Aug 2016 18:29:31 -0700 (PDT)�Return-Path: <xxxxx@avr2.org>�Received: from ks209126.kimsufi.com (ks209126.kimsufi.com. [94.23.240.148])� by mx.google.com with ESMTPS id eu7si35351789wjc.142.2016.08.29.18.29.26� (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);� Mon, 29 Aug 2016 18:29:31 -0700 (PDT)�Received-SPF: softfail (google.com: domain of transitioning xxxxx@avr2.org does not designate 94.23.240.148 as permitted sender) client-ip=94.23.240.148;�Authentication-Results: mx.google.com;� spf=softfail (google.com: domain of transitioning xxxxx@avr2.org does not designate 94.23.240.148 as permitted sender) smtp.mailfrom=xxxxx@avr2.org;� dmarc=fail (p=QUARANTINE dis=QUARANTINE) header.from=avr2.org�Received: from localhost (localhost.localdomain [127.0.0.1])� by ks209126.kimsufi.com (Postfix) with ESMTP id DEFA46F22F82;� Tue, 30 Aug 2016 00:19:14 +0200 (CEST)

• No DKIM headers are present, so DKIM implicitly failed
• SPF FAIL + DKIM FAIL = DMARC FAIL

Sample DMARC Aggregate Records

-<record>�-<row>�<source_ip>2607:f8b0:400d:c0d::22a</source_ip>�<count>16</count>�-<policy_evaluated>�<disposition>none</disposition> PASS�<dkim>pass</dkim> ALIGNED�<spf>pass</spf> ALIGNED�</policy_evaluated>�</row>�-<identifiers>�<header_from>avr2.org</header_from>�</identifiers>�-<auth_results>�-<dkim>�<domain>avr2.org</domain> = header_from�<result>pass</result>�<selector>google</selector>�</dkim>�-<spf>�<domain>avr2.org</domain> = header_from�<result>pass</result>�</spf>�</auth_results>�</record>

-<record>�-<row>�<source_ip>208.117.52.23</source_ip>�<count>1</count>�-<policy_evaluated>�<disposition>quarantine</disposition> FAIL�<dkim>fail</dkim> BECAUSE NOT ALIGNED�<spf>fail</spf> BECAUSE NOT ALIGNED�</policy_evaluated>�</row>�-<identifiers>�<header_from>avr2.org</header_from>�</identifiers>�-<auth_results>�-<dkim>�<domain>mobymax.com</domain> ≠ header_from�<result>pass</result>�<selector>smtpapi</selector>�</dkim>�-<spf>�<domain>email.mobymax.com</domain> ≠ header_from�<result>pass</result>�</spf>�</auth_results>�</record>

​

Google’s Handling of DMARC-Quarantined Messages

​

​

​

​

​

​

(As of October 2016. Attachments were still accessible.)

DMARC Reports

• Some mail providers including Google send XML reports of how they act on your domain’s messages
• There are services that process DMARC XML reports into human-readable data. Using such a service can be useful for analysis when starting to use DMARC but may be unnecessary later.
• dmarcian.com: Also free tools for DMARC and SPF record inspection, creation, etc.
• dmarcanalyzer.com: They may keep your data indefinitely
• dmarc.postmarkapp.com: Claims service is free; keeps raw data for 9 months, some metadata indefinitely

DMARC Implementation

• DMARC has the potential for much greater effect on your mail delivery than do SPF or DKIM.
• Adopt a gradual approach, beginning with reporting only. Move on to quarantine when the logs look good. Eventually move to a reject policy if you want.
• Adjust your SPF policy as needed to cover all legitimate third-party sources. Larger institutions with more systems may find this trickier than smaller ones.
• In general, for third-party mail sources don’t worry about DKIM. It’s easier to cover these sources with SPF.
• Remember that DMARC passes if either SPF or DKIM pass with alignment

Summary - 3 Tools for Better Email

• SPF: Identifies networks permitted to send mail as your domain
• DKIM: Digitally signs messages to confirm that they came from your domain and that they are unmodified
• DMARC: Gives you reporting of and control over messages that appear to be from your domain - stop forgeries of your domain and the problems they can cause

Email Integrity Requires Cooperative Effort

• Many strategies we’ve covered, including SPF, DKIM, and DMARC help protect our users and others from abuses of our own domain, not from other domains
• By implementing these strategies you help your users and the rest of the Internet
• The more organizations use these protections the better off we all are

​

Thank you!

Following this slide are

• Google tools and help links
• Resources for SPF and DMARC
• Info on other Gmail security options

​

​

Resources

• https://toolbox.googleapps.com - G Suite Toolbox
• Check MX - A great way to check for email issues on your G Suite domain
• Dig - for DNS record lookups

Google support links

• G Suite Security Checklist - https://support.google.com/a/answer/7587183
• G Suite SMTP options - https://support.google.com/a/answer/176600
• SPF - https://support.google.com/a/answer/33786
• DKIM - https://support.google.com/a/answer/174124
• DMARC - https://support.google.com/a/answer/2466580

​

Resources

SPF

• openspf.org - Deploying SPF, best practices, record syntax, mistakes to avoid. Site closed in February 2019 but is viewable via the Internet Archive
• SPF record generators
• https://mxtoolbox.com/SPFRecordGenerator.aspx
• https://www.spf-record.com/generator
• https://www.spfwizard.net/
• SPF record checkers
• https://dmarcian.com/spf-survey/
• https://www.dmarcanalyzer.com/spf/checker/
• https://www.kitterman.com/spf/validate.html

​

Resources

DMARC

• https://dmarc.org/ - Information on practically every aspect of DMARC
• DMARC record generators
• https://app.dmarcanalyzer.com/dns/setup
• https://dmarcian.com/dmarc-record-wizard/
• https://mxtoolbox.com/DMARCRecordGenerator.aspx
• DMARC record checkers
• https://dmarcian.com/dmarc-inspector/
• https://mxtoolbox.com/dmarc.aspx

​

Other Security Options in Gmail

G Suite Email Safety Settings

Apps > G Suite > Gmail > Safety

• Attachments - Actions: Warn, move to spam, or quarantine
• Links and external images - Actions: On/Off
• Spoofing and authentication
• Actions: Warn, move to spam, or quarantine
• Two options of note
• Protect against inbound emails spoofing your domain
• Requires that SPF or DKIM be configured
• Is better done with DMARC
• Protect against any unauthenticated emails
• Affects any message not authenticated by SPF or DKIM
• Don’t choose an action stronger than a warning or a lot of mail will be blocked

More G Suite Security Options

• Protect students by allowing them to communicate only with specified domains (“Restrict delivery”)
• American colleges and universities based on https://github.com/Hipo/university-domains-list
• Selected sites such as exam companies
• Check Require sender authentication
• In “Spam” keep Bypass spam filters list to a minimum; do not include your own domain or bypass internal senders
• Encourage all staff to use Google “2-step verification” to prevent accounts from being compromised
• Require some staff to use Google 2-step verification
• Those who can post to student mailing lists (Google groups)
• Those with Google admin rights

OAuth/API Options in the Google Admin console

Via OAuth users can just give an application access to portions of their G Suite account data: Gmail, Drive, etc. Neither passwords nor 2-step verification matter. These present numerous possible legal and security challenges.

On May 3, 2017 the world saw the first large scale phishing attack to exploit Google OAuth. Recipients received an email with a link to a page that prompted the user to allow the “Google Docs” app access to their email. That “Google Docs” was actually a malicious third-party app to which victims gave full control of their email, allowing the attack to spread.

OAuth/API Options in the Google Admin console

​

G Suite admins can create a whitelist of trusted OAuth apps via G Suite under Security > API Permissions.

• This could virtually eliminate the possibility of users giving a malicious app access to their G Suite data.
• Could be a management headache
• Only one whitelist for entire Google domain
• Google announced that as of 7/8/19 apps with access to Gmail must be approved by Google or the organization

​

Google Password Alert Extension for Chrome

Google’s description:

If you enter your Google Account password or Google for Work password into anywhere other than Google's sign-in page, you’ll receive an alert, so you can quickly change your password if needed. ��Password Alert also checks each page you visit to see if it's impersonating Google's sign-in page, and alerts you if so.

This extension can be force-installed for users.