user email from express-jwt authentication

My client-side authenticates the user and then sends that authorization header to my server API, which then uses the express-jwt to authenticate.
I want this authentication method to return the users unique email so I can then check if it exists in the database or not, and make a user accordingly. I have read the docs for ages and searched and can’t find I way. I have given the scope and tried adding rules, changing the audience to /userinfo.
Currently my server’s auth check middleware is:

import * as jwt from 'express-jwt';
import * as jwtAuthz from 'express-jwt-authz';
import * as jwksRsa from 'jwks-rsa';

if (!process.env.AUTH0_DOMAIN || !process.env.AUTH0_AUDIENCE) {
  throw 'Make sure you have AUTH0_DOMAIN, and AUTH0_AUDIENCE in your .env file'

export const checkJwt = jwt({
  secret: jwksRsa.expressJwtSecret({
    cache: false,
    rateLimit: true,
    jwksRequestsPerMinute: 5,
    jwksUri: `${process.env.AUTH0_DOMAIN}/.well-known/jwks.json`

  // Validate the audience and the issuer.
  audience: `${process.env.AUTH0_DOMAIN}/userinfo`,
  issuer: `${process.env.AUTH0_DOMAIN}/`,
  algorithms: 'RS256']

export const checkScopes = jwtAuthz('read:messages']);
export const checkScopesAdmin = jwtAuthz('write:messages']);

And the req.user object i receive when passing the check is:

{ iss: '',
  sub: 'auth0|5990adc9d742451dc3b7ba39',
     '' ],
  azp: 'h4bn4MKkelzz9EDTh4EYFcapFIAzw1pl',
  exp: 1502661451,
  iat: 1502654251,
  scope: 'openid profile read:messages write:messages' }

I want this response to contain the user’s email so I don’t have to make yet another call to the server for the user’s profile information.

If you have an API for which you want to provide authorized access based on the premise of an access token then you should define your own API in the API’s section of the Dashboard and register it with your custom identifier. This means the middleware used to validate the received access token will be using this identifier as part of validation - you’re currently using the /userinfo audience identifier which is incorrect.

Having done this, the client application that is interested in gaining access to the API on behalf of a given end-user should state the previously configured identifier as the value of the audience parameters used in the authentication/authorization request.

The above will mean an access token suitable to be sent to your API can be issued to the client application. By default, that access token will contain the user identifier within the sub claim (currently, the issued access token would be a JWT). However, you can include additional information in the access token by leveraging custom claims; see the reference documentation on how to include custom claims in the access token.