07 Apr Part 2 | Email authentication – why you need to do your bit!

Hello!

My name is Guy Ellis, Head of Deployment and Support at Appscare, the Google division of Netpremacy, a leading Google Premier Partner across EMEA. This is the second in a series of “takeover” blog posts I am writing around securing a Google Apps environment – why this is so important and how this can be achieved.

If this is the first blog post of mine you have read, I’d suggest starting at the beginning; 2FA – Why is it so important?

This second post is around email authentication – why you need to do your bit!

Email for a number of years has become centric to most organisations and how they communicate both internally and externally.  As a result of this, email has also become one of the most abused communication standards, exploited for;

• Phishing
• Spam
• Malware

A number of RFC’s (internet engineering task force defined technical standards) have appeared over the years to try and combat these issues.  Many have been poorly understood, badly implemented or simply ignored by mail administrators.  A number of large organisations (including Google, Microsoft, Yahoo, Bank of America) worked together to contribute to build a standard to combat some of these issues; DMARC

How does DMARC work?

Domain-based Message Authentication, Reporting and Conformance (DMARC) allows an administrator to define what happens to messages which have met any of the following criteria;

• Not originated from a known/approved source
• Been tampered with during transport (including attachments)

Additionally, DMARC allows a domain administrator to monitor and report on email sources purporting to be sending from domains under their control.

DMARC works with two existing standards to provide the authentication elements;

• Sender Policy Framework (SPF) – proves that the sending server (IP address) is known to an organisation
• Domain Keys Identified Mail (DKIM) – proves that a sending mail server knows a private cryptographic signature as well as proving that a mail has not been tampered with during transmission

Understanding the standards in further detail

SPF is a standard which is deployed and used by most organisations.  The mechanism is simple – I will describe this using netpremacy.com as the example:

1. Netpremacy.com publish a TXT DNS record.  The record contains the following string:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:164.138.224.133/30 include:mail.zendesk.com -all

v= – This is the version of the SPF standard used, in this case version 1
Include: – This allows us to include SPF records for other hosts.  We are including Google Apps, Mailchimp and Zendesk
ip4: – This allows us to include specific IP ranges in the record (for example, web servers)
-all – this specifies that the record is an“hard fail”

2. An employee sends an email to an @gmail.com recipient

3. The receiving Gmail server will perform a DNS lookup to the @netpremacy.com domain to retrieve the SPF record.  It will cross reference the IP addresses listed in the SPF record to the IP address which is delivering the mail.  If the sending server is listed in the record (or included records) then delivery will continue.  If the server is not listed, then a hard fail will apply – most administrators will choose to configure this to apply a weighting to the message that this is SPAM

For information showing all of the possible SPF statements, I’d recommend the following as a great resource: http://www.openspf.org/SPF_Record_Syntax

DKIM tends to be adopted by fewer organisations than SPF, probably because of the perception that this is more complex to implement (hint – it shouldn’t be!).  DKIM works by signing headers in a message, this is then checked by the receiving MTA by validating against the public key.  Let’s take a look at an example of a DKIM signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
d=netpremacy.com; s=google;
h=sender:mime-version:from:date:message-id:subject:to
:x-original-sender:x-original-authentication-results:precedence
:mailing-list:list-id:x-spam-checked-in-group:list-post:list-help
:list-archive:list-unsubscribe;
bh=YY++zS3S1/oLJZfX1B7PeWaLsV0J33WhxtG0rKGpXKo=;
b=BeXOF64P1rDYeZbPl/nteRLc9GEMa8SO7TDFKPtlOM2uM4ED1R7JU9Wr2Yi3CNlpvy
dR0LCMu2t7oPGB9QNiCFkTudKWMRCoASLdwaHDyXIBiXkbIpS9wB0sOAT2DIS32K00sx
jcYAgg0wz5FS6H1qNK7vo6/oHyW5Br7MGb2l0=

Included within the DKIM header are the following tags:

v –  The version of the DKIM signature, currently only version 1 is a standard
a –  The signing algorithm used, in our case rsa-sha with 256 bit length
c – The canonicalization used for the signature
d –  The domain used to host the public part of the key
s –  This is the selector used (selectors allow for multiple keys to exist under a single domain)
h – These are the headers which have been signed with the signature

Following the tags is the signature itself.  When a message is received, and the DKIM-signature header above exists the following process will take place:

1. The receiving MTA will perform a lookup of the public signature using the selector and domain fields.  In our case: google._domainkey.netpremacy.com (selector._domainkey.domain.com)
2. Once the public signature has been collected, the signed headers are checked using the defined signing algorithm, a pass validates that the headers have not been tampered with.  If the headers have been modified (for example, the from address has been changed) then DKIM would fail – again it is up to an administrator to define what to do with this scenario

DMARC puts the control of what to do when these authentication methods fail into the control of the sending domain administrator, rather than the receiving domain administrator.  DMARC is published as (yet another!) DNS record. Let’s take a look at the record for netpremacy.com:

v=DMARC1; p=reject; pct=100; rua=mailto:x0bpxh9v@ag.dmarcian.com; ruf=mailto:x0bpxh9v@fr.dmarcian.com;

v – The version of the DMARC standard used
p – The policy specified (none, quarantine, reject)
pct – The percentage of messages this policy should apply to (used during rollout)
rua – The email address to send the aggregate reports to
ruf – The email address to send the forensic reports to

Our policy defines that should authentication fail entirely (i.e. SPF and DKIM fail) that the message will be outright rejected.  In addition to this, any mail servers receiving mail with a from header of @netpremacy.com will send an XML report, showing an aggregate view of which server sent the message, which authentication methods passed and if a message has passed DMARC alignment.  This is extremely useful to capture which hosts are sending mail from your domain name and ensuring that valid hosts are authenticating mail correctly.

The following chart outlines the three typical authentication scenarios once these three technologies are implemented as above:

There are two key points to take away from the authentication flow above:

1. A mail which has been successfully authenticated (passed DMARC) is STILL subject to regular SPAM checks.  DMARC allows an administrator to define what should happen to a message which fails, a message which passes is still subject to SPAM checks and organisational policies
2. Multiple authentication methods should be used to ensure comprehensive delivery (i.e. deploy both SPF and DKIM for all your sending gateways)

How do I go about deploying this?

Firstly, congratulations on getting this far into the post – if you have just skipped to this section, shame on you!  There are a few things I’d recommend getting clear before embarking on a mail authentication project;

1. Ensure you have sponsorship in the business.  You may well uncover systems which are sending email that IT have never been aware of.  HR, Marketing, Finance – all may have platforms which send email – you will need to work with these teams and their suppliers
2. Ensure you are aligned with your IT change process – there will be multiple changes required to your DNS to complete this

So, on to the technical how do I deploy this – I am making the assumption that you are maintaining SPF records, but are not signing mail with DKIM and have no DMARC records;

1. The first thing you should do is configure DMARC in report only mode.  DMARC in report only mode (v=DMARC1; p=none; rua=emailreports@domain.com)  Implementing in report only mode will allow you to analyse where your mail is originating from, and make an educated decision as to which are likely genuine sources of mail
2. When these sources have been identified, firstly ensure they are added to your SPF record if they do not exist first
3. You then want to ensure that all of your mail sources are also signing with DKIM, you have a number of options available.  In order of preference;
   1. Sign with DKIM directly on the sending MTA – you will need to publish the public part of the DKIM signature on your external DNS
   2. Send via a relay which will sign with DKIM (Google Apps provides an SMTP relay service – but be aware of the volume limitations)
   3. Tell them to stop spoofing your domain!  Send with a from address of a domain under their control instead
4. Once you have identified all mail sources, and ensured they are authenticating correctly, you can start to enforce a DMARC policy.  We recommend communicating to the organisation at this stage;
   1. What is happening
   2. Why it is happening
   3. How should any unusual messages be reported
5. When rolling out, first use a p=quarantine rule, start with a small percentage of messages (pct=5) increasing this every 24-48 hours until you reach 100%
6. Once the quarantine rule has hit 100%, change this to a p=reject rule – consider starting with a lower percentage and increasing again
7. Ensure you continue to monitor XML reports periodically post roll-out – it can be quite insightful!

Your DMARC rollout should not be rushed – analysing the aggregate XML reports is by far the most time consuming task & requires an insight into your business to analyse effectively.  Consider as well email sources which are infrequent – payslips, HR updates etc.  You can configure many of your systems (steps 2 & 3) whilst continuing to collect and analyse XML reports.

Watchpoints / Notes from the field

• You must ensure that when signing with DKIM and using DMARC that the from header is the same as the domain used (d=) in the signature.  If this is not the case, your mails will fail DKIM alignment.
• You must ensure that the envelope from and header from domains are the same, if this is not the case SPF alignment will fail.  For scenarios where SPF alignment fails, DKIM alignment must pass for the message to be delivered.
• Multiple DKIM signature headers are allowed – a signature for each organisation involved in a message.  A good example of this are Google calendar notifications, whereby there should be both a google.com DKIM signature and a googleappsdomain.com DKIM signature.
• Most DMARC compliant receivers do not send Forensic reports back due to the additional load this would place on their infrastructure (forensic reports are simply reports with even more detail provided) – do not be alarmed if you only receive aggregate reports.
• Processing XML reports manually is time consuming.  I can’t recommend https://dmarcian.com highly enough to automate this process – they offer a two week trial & the cost afterwards is very reasonable (usual caveat – no affiliation, please do your own research into vendors!)
• Vendors seem to come up with some remarkable excuses as to why they cannot comply with some of these standards – be prepared to both stand your ground and persist with your requests
• There will be a very small percentage of legitimate mail which do not make it to their destination due to bad practices by receiving administrators (for example, forwarding and modifying the message simultaneously, breaking both DKIM and SPF).  Unfortunately, this is unavoidable, however on a more positive note this behaviour is on the decline since many of the large email providers have implemented a reject DMARC policy.
• The SPF specification limits the maximum number of DNS lookups per SPF check to 10, Dmarcian provide another handy tool to validate your record is correct: https://dmarcian.com/spf-survey/netpremacy.com
• If you would like immediate confirmation that authentication is passing, simply generate a test email to: check-auth@verifier.port25.com and wait for the response.

Further Reading

This post turned into a bit of a brain dump of a lot of lessons learned rolling out DKIM, DMARC and SPF with some of our clients over the past year or so!  As I have highlighted throughout a number of invaluable resources;

• Google DMARC rollout guide
• DKIM standards
• SPF syntax

As always, if you do have further questions please don’t hesitate to get in touch!  Please also keep your eye out for Part 3 – policies and reports – what should I be aware of?

Cheers!  Guy.