Setting Up Gmail Security and Deliverability

0:00Now, Google Workspace is of course a whole entire suite of productivity and collaboration tools that allow an organization to work together, to accomplish things in a much more efficient way. But one of the core products or one of the core ingredients is email, or specifically in this case, Gmail, which uses the same email protocol that has existed since almost the beginning of the internet. Now, there are a lot of protocols that were around back then that are no longer used.

0:30Things like Gopher used to be a menu-based way to get through internet-hosted stuff, and that existed before the World Wide Web. There were Archie and Veronica for searching through sites. Email, oddly enough, has stuck around this entire time, and it's still something that is central to almost every business and organization when it comes to communication. Of course, it's offset by lots of other communication tools, but email is still vital. And because of its long-ago routes, email has had to build lots of security on top of what used to be a very basic and insecure protocol. And so in this skill, we're going to cover how email has evolved and what a current modern secure email system looks like and how we can figure that inside Google Workspace.

0:00Now, this might seem a little bit silly to actually say out loud, but email has two different directions that it travels. We have outgoing email and we have incoming email. Now, the first thing that we're going to configure is incoming email, meaning that if somebody sends an email to Sean at nuggetlab.org, we need to have a way that their email client or their email server knows where to send that in order for it to get to us. Now, since we're sending up Google workspace, we need to be able to tell the rest of the internet, hey, if you want to send me an email at an address at nuggetlab.org, I need you to send it to Google's mail server and they'll see that it's coming to somebody who is paying for a Google workspace account and they will deliver it, you know, that way. The way that we tell the internet where email is supposed to go for our domain is by setting up a DNS record. And hopefully that makes sense. DNS is where our domain information is stored.

1:03And we want to tell the internet where email addressed to our domain should end up. And so we create DNS records, specifically MX records, which means mail exchange. And that MX record or those multiple MX records actually tell the internet, if you want to send email to Sean at nuggetlab.org, send it to one of these email servers. And the reason I say one of these plural is because almost always not necessarily, you can just have a single MX record and a single mail server. But that's really, really not ideal. Generally, you want to have multiple servers that will accept mail for your domain and then deliver them to you. If there's an outage between, you know, the first priority email server and the client trying to send email, or if one of them's down for maintenance, lots of various reasons, you want to always have somebody listening for email that's addressed to your domain. And basically, the their mail server, the one that is sending the email that you're trying to receive is going to look do a DNS look up and they 'll look for your MX records. And the first priority one is the server they'll try first and they 'll try it. And if they

2:20get in touch with that server, they'll deliver the email to that server and it 'll all be done. If they try to get in touch with that server, and it doesn't respond, or there 's, you know, a network cut so they can't get to it or it's down for maintenance, they'll go to the next one on the priority list and try that email server and they'll go through them all until they reach the end of the list. Now, after the end of the list is reached, if they haven't gotten through to, you know, a mail server that is going to accept mail on your behalf, then things get a little bit questionable.

2:50Usually what happens is a mail server will be polite and they'll say, all right , I'll, you know, I'll hold on to this for a little while I'll keep trying and periodically, every however often it's configured for like every hour, it'll try again. It'll go down the list and try to, you know, connect to your email server. After a while though, it's going to say, you know what, I don't think this domain has an email server that is active, you know, either it only has one MX record, I tried it and it failed multiple times, or I've tried all of the MX servers on the list, and they all failed for a certain amount of time, which is not an interesting standard. There is no like standard amount of time. Eventually, they'll either just drop the email, or most likely they will send a response to the person who originally sent that email, you know, their client and say, look, I tried, it'll say message delivery failed, I tried and I just couldn't get through. So, usually at least the sender will know that it didn't get to you, but you want to have multiple mail exchange records with multiple servers, if possible, to eliminate those failed attempts to get emailed to you. Okay, so we're going to look how to set up the MX records specifically for Google Workspace and Google walks us through that in the admin panel. So I'm

4:07here, I'm logged into admin.google.com as the as an administrator for Google Workspace. We're going to go on the left hand side, you may have to click more, like if you don't see all of these options, you may have to click more, but basically we're going down to account, and then inside account domains, specifically managed domains. So we click on there, this is going to take us to all of the domains that are connected to our Google Workspace. Now there is a test one that Google sets up by default, this, you know, test dash Google A.com. But nugget lab, this is our primary domain.

4:45And this is the one that we're going to set up. Now, you'll notice that it says it's verified, we did verify it during the installation, but it's not the Gmail part is not activated. So we're going to say activate Gmail. And this is where we could do a setup MX record, which is what we're going to do, or skip the MX record setup. And this is if you have your own external email server that is going to forward mail to Google, that's not normally how it happens. Normally you want Gmail to handle all of your email. And that's what we're going to do. So we're going to pick a setup MX record, click next, and it's going to walk us through the process. So here we 'll help you set up Gmail.

5:24So all the email addresses at nugget lab.org, go to Gmail, so we're going to click continue. Activate Gmail for everyone on nugget lab. So if you have more than one user already, they may be listed here. But I'm just going to say proceed with activation because we only have the one user right now. This is where it says, we're going to use Gmail once the MX record is updated. It will sign into CloudFlare for us, but I'm going to switch to manual verification in case you are not using CloudFlare. I want to just show the what it looks like. Let's see a domain host not CloudFlare.

6:00Is there just a generic? Okay, my domain uses a different host. Click continue. I'm just doing this so I get the most generic information and we can paste it into our DNS server. Okay, so the MX record here set to default value. Priority one points to SMTP at Google.com and the TTL set it to the lowest value. Now, so what Google has done here is they have made it so we only set up a single MX record. And I know you're I know you're thinking, Sean, you just went on and on about how that's not ideal. You want to have multiple MX records that will, you know, if one goes down, well, Google here this SMTP dot Google.com. That is a front end DNS entry that on the back end points to multiple servers. And so what they've done is taken the heavy lifting off of our shoulders and they have created SMTP dot Google.com as a server, which is pointing to multiple servers on the back end. And if one goes down, the others will still get it. So if you're using Gmail, you may only have one MX record, but it's going to point to to a server, which is really a front end for multiple servers. So again, that doesn't mean that my information about having multiple MX records is not valid and very important to understand. But the reason we're

7:19not going to do it is that Google has set this up. And so it's fairly simple. Priority of one, that's a top priority. Number I said they'll go by priorities. If we only have one, the priority is one. And that's going to be there. So I'm going to now open up Cloudflare, because Cloudflare is the actual DNS host that I'm using. So anyway, here we are in Cloudflare logged into the nugget lab domain. And you'll see we have the records that I had to make to verify for Google workspace install. This is how we got our domain verified, but I need to install or set up the MX records, which will be a record.

7:54The type is going to be MX, the name, it says the default, I'm just going to use at for root, because that's what it says here use at for root. The mail server is SMTP dot, let's go over here, make sure I get it right SMTP. I'll just copy it dot Google dot com. Now capital lowercase doesn't matter in DNS, but I'll just copy exactly what they put there. The TTL, I'm just going to say the lowest is one minute and the priority they said to put as one. And this is the only one, in fact, I'll make a comment here, the only MX record required, because Google handles redundancy at on there. And there. So now that MX record is set up for the domain. All right, so if we can get rid of this, come back here, it says come back here and confirm once you have updated the code on your domain host. So I'm going to click check, and I'm going to click confirm. Now this is probably going to take a while to propagate. Oh, and look at that, it's already propagated. Good.

9:00So it says we verified and Gmail is now ready. So click done. All right, verified and Gmail activated. So now if we send an email to admin at nuggetlab.org, we should receive it in Gmail. So if I click this and then I go to Gmail, so here is just the standard stuff. But if we send an email, I'll do that in from another account real quick, in another window, and we should receive that email. And boom, there we go. Sean Powers test from personal account looks like yes, we got an account, or we got the email that I sent from an external account to admin and nuggetlab .org and it arrived.

9:40So we can tell from this that the MX record single is set up and is working. That's all there is for incoming email to be configured. Now the spam filtering is all handled by Google in their servers. We don't have to configure anything to get the Google spam filtering, which is honestly really good spam filtering. So as far as incoming email, that's all set now. Outgoing email is where things get a little more complicated. And there's a handful of protocols and tools that we can use to make sure that other sites don't see us as spam when we send email.

0:00Now, the first line of defense against lots of spam coming from your domain is to set up an SPF record. Now SPF stands for sender policy framework. And that's not terribly clear by definition alone. So basically, what happens is when you have an MX record, it says where email goes to, right, when people are trying to send email to you, they look up your MX record. And the MX record says where it is supposed to go to, when people receive email from you, they look up your SPF record to see where email should be coming from. And that's where you specify what email servers are allowed to send email that is coming from you. Now, this could be multiple email servers. You could have like, you could have an email server, you know, in the house, you could have like another redundant server or a server in another, you know, part of the country, or you could be using multiple services, like Amazon Web Services uses a specific email server to send email out. But then for personal email, it's another it can be complex. But the SPF record tells people when

1:16they receive an email from you, if it, you know, they can look to see where it came from. And then they look up on your SPF record to see if that's one of the places it's allowed to come from. Now this is a text record, or a TXT record that we're going to have to put into our DNS server. But the format, it can be confusing, but it's not really too bad. Okay, so let's look at that. This is, remember, it's a text record, and we're going to put three fields in. Now, the fields are just separated by a space. The first field, and this is required, we have to have this field, is what version of SPF we're using and secret is I've never seen anything but SPF one. So v equals SPF one. I don't think we've ever gotten past SPF one I've never seen anything else out there. So it still has to be in there. The first field is the version field and just v equals SPF one space. And then the second part is how we define which servers are allowed to send email. Now, there's a there's multiple ways that we can define what servers are allowed.

2:26You can do it by IP address. So you can say IP for colon, and then you put a specific IP address. And if you are using one specific IP address as your email server, and that's always going to be the server that is sending out email on your behalf, you could do this. If you have, as Google does, multiple email servers that may change their address over time, the more common thing is to use and include value here. So include, and then a colon, and then the domain that email is going to be coming from. Okay, so this is generally how the bulk of SPF records are formed using the include, because that allows you to use a domain instead of a specific IP address. Again , so if it changes, or if there are multiple IP addresses that are connected to a specific DNS name , using include allows you to use that DNS name. And then as long as the address that the email is sent from is, you know, resolves to the domain that you say, then everything is all set,

3:42you know, it's okay, because it's included in what domains are allowed to send email on behalf of your domain. And then the last field is the word all, but it is either preceded by another's a couple other ones. But the general to that you'll see is it's either preceded by the tilde, which is that little squiggly line, or a dash. Now, these are very different in what they mean. Tilda is almost always what's recommended. It's what Google recommends. It's what I personally recommend. What this means is, if it doesn't pass SPF, right? So it's coming from an IP or domain that is not listed. It's called a soft fail that little tilde signifies all of the email will fail SPF check, but it's a soft fail.

4:30We're saying like, it didn't pass, but I'm not saying you should throw it away. It might be valid. We may have a configuration error. Now, if you do dash or just a hyphen, all, no space here, this means, okay, I have my configuration right if you're getting an email from me, everything that doesn't pass SPF should be deleted. Now, it's up to the mail server, whether or not they do delete it, but this is kind of our recommendation to them saying, okay, my configuration's right.

5:01If you're getting an email from something that is not this domain or not the IP that I specified, it's spam, you should delete it. Whereas with the tilde, which is the recommended one is, as far as I know, everything is hunky dory on my end. So you should be getting proper SPF verified emails. So even if it's bad, you should probably keep it, but maybe market is spam and deliberate flagged is spam. Whereas the dash says, just get rid of it. That's bad. All right. So generally, this is what we do because sometimes configuration errors just happen, right? And so anyway, that's the general format for an SPF record. And Google has, I'm going to put a link right below this video. Google has the ideal SPF record that you should add to your domain in order to make it work with Google workspace. And this is the link, I mean, I included the link on the on the skill, but basically, if we're using Google's workspace only, which is what we're doing, this is what the record should look like. VS or V equals SPF one space include colon underscore SPF dot Google dot com space tilde squiggly all. Okay, I'm going to copy this.

6:16So I'm going to copy that again, that link is in the skill. And then if we come back here, again, this is my DNS or cloud flare, we're going to add a text record this time. So it's a TXT record. The domain again is at for root, because this is root level email, right, anything coming to the root level nuggetlab.org is what we want this to be, you know, specified for under do TTL, the lowest one, the content, this is what I just copied. So I'm going to paste in, and it's v equals SPF one space include colon underscore SPF dot Google dot com space tilde all. All right, so this is the record. Now, just going to click save. Now you can see we have this text record, which is the SPF record for the domain. Now it might take a little bit for this to propagate as well, not too long. And I'm going to wait until we do the other things on here. And we'll test all of the stuff that we've put in at the very end by sending an email. And then on the other end to see how how it passed if it passed SPF. And then the next thing which we're going to look at because with SPF, it is certainly possible to spoof, right? We could spoof an IP address or we could spoof a DNS entry

7:36like do man in the middle DNS stuff where it could look up the address and then have one, you know , a bogus IP listed. So it might pass SPF, but still be spam. So SPF is not the only level of protection that we're offering when we send out emails in a properly configured email system.

0:00Now SPF is a great way that you can tell anybody receiving an email from you what server it should be coming from or a list of servers that are okay for email to come from when it comes from you. But again, that information is possible to spoof. Now it's not super easy to spoof that information, but it's definitely possible to spoof the information or what if somebody compromises one of the computers or paths in between where the email is coming from and where the email is going. Then it could be rewritten in route. And then even if SPF matches the message itself could have been messed with. So like it could have been an innocent email that was sent, but then it was rewritten to something nefarious or had malware attached or something like that. And that's where the next level of security for outgoing email comes in. And what we do is use D Kim, which stands for domain key identified mail. Again, these description or the the acronyms don't really give a lot even when you know what they stand for underneath. But D Kim basically

1:15uses encryption. So public private key encryption, it uses that to sign an outgoing email. And so what happens is there is a private key stored on the email servers and they use that private key to look at the entire email and then use that private key to attach a signature using their private key, which using the public key can be verified that the message itself has not been tampered with since that signature took place. And since the private key is only known by the servers, which are allowed to send email on your behalf, it has to be signed by, you know, one of those email servers. And they're the only ones with that private key. If you have the public key, which again is distributed via DNS, then the server that receives it can look at the signature and using that public key verify, yep, sure enough, this hasn't changed. This is exactly the email that was sent from the user. And so using that cryptographic signature, you can verify that it wasn't altered during transmission. It's the same message that

2:32was sent from the server is the one received by the receiving server. And so DKIM is an extremely powerful security layer on that is added to outgoing emails from your mail server. And we set that up, again, using DNS records, but we do have to generate the private and public key. Now, just for a quick visual, you know, here is the the private key. This is only stored on the server, only the server, the mail server that you use to send outgoing mail has that. And then when you have an email, it sort of puts its, you know, stamp on there. I guess this is my digital signature. And then any server that receives it can use the public key, which is available on, on DNS, to verify that yes, that is the proper signature that was created and signed with this private key. So I know that this email came from that server and wasn 't altered along the way. I will quickly add that Google does not make it easy to rotate encryption keys. And what I mean by that is a lot of times people think that the best security practice

3:51is to rotate DKIM key pairs every six months or so. So after six months of using it, you create a new private and public key pair, you publish the new public key pair on your DNS server. And then you start signing with that new private key pair, you keep the old public key in DNS so that anybody who just hasn't opened your email yet, but was signed with the old private key can still verify it.

4:21But that best practice is difficult to do with Google because they only want to have one DKIM key active at once. And so in the interim time when you create a new key and then publish that, there might be some time where outgoing emails are not signed at all. And so most people just create the public private key pair and just leave it there. So if you're thinking, well, that's not the best security practice, you're right. Generally, we do recommend that DKIM keys are refreshed every six months. But Google doesn't necessarily recommend that and they don't offer a great way to make that happen without any interruption to service. So as long as the private key is not compromised, it should keep working, you know, indefinitely. And I just wanted to bring that up. So in case you're like, why didn't you tell us about rotating? Well, because Google doesn't really talk about rotate rotating the key pairs, even though industry standard says, generally you should rotate every six months. Now you can still do it. It's just in the interim, when like things are propagating and you're putting the new key into play,

5:36there might be some time where outgoing email isn't signed or the right keys aren't in place. So it can just be messy during that transitional time. But in order to get DKIM installed, we actually do have to do stuff here. And it's not just installing a DNS record, we have to create those keys, right? And Google has to know about them. So I'm back here in the admin panel, I'm going to go to apps this time. And inside Google workspace, if we scroll down to Gmail, so click on Gmail. And then down here, where it says authenticate email, everyone put myself over here, authenticate email is what they call setting up email authentication with DKIM, they say DK IM right there. So in here is where we set up that record. And right here, where it says generate new record, that's what we want to do, right? Because we want to generate the keys, and then it will give us the text record that we need to put in that text record will include the public key, which is, you know, publicly available. So selected domain nuggetlab.org. Yep, that's the one we want generate new record.

6:44The DKIM key bit length, the bigger, the better, like the 2048 key bit length is going to be more secure than a 1024. It's possible that the DNS provider won't support the longer one. So you'd have to use 1024. But I'm going to choose that a prefix selector is optional, but I'm going to leave in their their recommended one. And this is just so if you set up multiple DKIM records, like if you have multiple servers that are serving out DKIM authenticated emails, when you're looking at the DNS records, it's nice to be able to see which server, you know, which DKIM record is for. So the prefix selector is just for your own sake later on when you're trying to identify things. So I'm going to leave Google in there, you'll click generate. And now this is going to create the public and private key. We're not going to see the private key, though. Google keeps that to themselves, right?

7:45Google, the servers are the only ones who can see that private key. We don't want to see it. We only want the private key, or we only want the public key. Did I say private key? Google 's the only one that is a private key. We want the public key to be publicly available. And so this is what we're going to put into our record. So first of all, the DNS host name, the text record, we copy this. And then go over to our DNS. Again, we're back here, we're going to say add a record. It's again going to be a text record. But now the name is actually, it's not just at this one is going to be Google dot underscore domain key. All right, so that's the domain or that's the host name that they gave us, we're going to leave them and say time to live is one minute. And then the content, this is where we put that public key, which is right here. So I'm going to highlight this entire thing.

8:45Copy that. I'm going to paste that in. All right, so it's all pasted in the entire record is right there. And now I'm going to click save. And now this is all we need to do to get the DKIM information on the internet on the public DNS, right, with our public key in that that record, that text record, which anybody on the internet can look up. But now it's it's active. It 'll take a little while to propagate on the internet now though. And it says here, it may take up to 48 hours for the DNS changes to fully propagate. Now it doesn't normally with cloud flare, especially since I put that time to live so low. But we'll see, we won't be able to start authentication if that record is not active. But I'm going to try it. I'm going to click start authentication.

9:33Look at that. It allowed us to do that. So authentication is on using that record. So it's all set. We have DKIM configured. So outgoing email is going to not only pass SPF because we set that up, but now it's going to have a signature. Now the email itself is not going to be encrypted, but it's going to have a cryptographic signature applied to it so that it won't be able to be changed without that signature no longer matching the content. Hopefully that makes sense. We're not hiding the content of the email using DKIM. All we're doing is making sure the content of the email is not changed from what was initially sent, right? It's just it's verifying the integrity of of the email, it's not encrypting the email.

0:00Now the last layer of security or trustworthy addedness, that's not really a term, is going to be DMARC. Now DMARC stands for, I should have to look this one up. It's a domain- based message, authentication, reporting, and conformance DMARC. Mark with a C at the end. This is not something that is added to the email. This is another DNS record, this is a text record, and basically what the DMARC record does is it tells any receiving domain. So we send an outgoing email and the receiving email server gets an email from us, from one of our servers.

0:46If it doesn't pass SPF and/or DKIM, if one of those two or both of those fail, our DMARC record says, "Okay, if you get something from us that failed, here's what I would like you to do. Here is what we're designed or we are prepared for you to do in response to emails you receive that say they're from us, but are failing either SPF or DKIM." Now yes, SPF does include like that tilde all that says, you know, like, "Hey, you know, hold on to this or dash all, hey, you can get rid of this." But DMARC is a more robust methodology because it does a couple things. One, it allows the receiving email servers to have expectations about what you expect them to do if they get something that says it's from you but doesn't pass muster. It also provides another layer of trustworthiness, right? The receiving email server, if they see that you have a DMARC record configured, it means that you are expecting your SPF and DKIM efforts to be fruitful and to be

2:02working and you have instructions for, you know, receiving email servers to use if those fail. So you are actively trying to make email better. So it offers another layer of trustworthiness. But really the key with DMARC is that it allows those email servers a way to tell you if something goes wrong because everything else that we've had, all it does is give information to the receiving email servers. They get it and either SPF fails or passes, DKIM either fails or passes, and then they can decide what to do with it. Is it spam? Do I reject it? Do I market it?

2:43Spam and deliver it? With DMARC, it gives them an ability to report back to you so that you can see if something is misconfigured or if there's some third party sending all sorts of spam claiming to be you. And so that's really where DMARC shines is it gives other email servers the ability to report failures to an email address that you specify. And that is kind of like the frosting on the cupcake of email security because you're doing all of these things to make sure you're outgoing emails are secure and are validated and they've not been modified. DMARC gives those receiving servers the ability to basically tell you how you're doing. Or like I said, identify if somebody else, you know, is sending emails claiming to be you, but they obviously can't do a digital signature with DKIM.

3:44Usually where it's most beneficial though is if something is wrong with your SP F or your DKIM, you get told about it instead of just the remote servers dumping your stuff or marking it as spam. So DMARC helps everybody, but it definitely helps you to set up a DMARC record so that you can get reports on emails that are failing. Now a DMARC record looks fairly similar to an SPF record. I mean, there is a host that we use instead of just the @ symbol, but there are three fields that we're going to use now. I'm including a link in the skill just like I did with DKIM or with SPF, with SPF I think, that will show you the other options that you have. Like you can specify what to do with sub domain emails, but the basics are here. This is a required field . The first field is the version. So V equals DMARC one, just like we did with SPF one. Again, I don 't know of any other version, but this is required to be the first field in the text record that we're creating.

4:53And then the next one is P. This is the procedure. What do you want them to do if they get something that doesn't pass SPF or DKIM? The options are none reject or quarantine. And this may sound counterintuitive, but most recommendations, especially when you're first starting, is to make this none, which means you're not expecting the receiving email server to reject or quarantine the email if it doesn't pass SPF or DKIM. You're just saying, no, no, I'm still setting things up or I'm not positive. I haven't configured properly. So for right now, I don't want you to do anything out of the ordinary with the actual email you receive. You know, if it, you know, if it gets marked as spam internally, so be it. But don't just get rid of it altogether.

5:48So generally, we'll do P equals none, especially for a while at first, until you're confident that your DKIM and your SPF is validated properly and emails are going out properly, then you could change your P to something like reject or quarantine. But leave any as none is fine too. The golden part here, the really important part, if you will, is this RUA field. So RUA equals and then mail to colon and email address. This is where we're asking the receiving email server to send information about emails they receive that do not pass SPF and DKIM. So if they get an email that says it's from us, but either DKIM or SPF or both fail, this is what we want them to do. We want them to tell us by sending a mail to whatever email address we specify. Now normally you wouldn't do this to an actual user account. It would be like an alias or, you know, some monitored account that you can go into. This is our only email address right now. So I'm saying, you know, send it all to

7:03admin@nuggetlab.org. But this is what a DKIM record looks like. We're going to add one into DNS again. There's nothing to configure inside the Google admin console. It's just a text record that we create. But we do have to make sure that it is formed properly. And you can look in that link that I put for more information about DMARC, but it's not too difficult to do. So let's get our our DNS server one more time and we're going to add one more text record. Okay, so back here again, I'm going to say add record. This is again going to be a text record TXT. Now the name here is important.

7:41We don't just put the ad we do underscore DMARC. So underscore DMARC.nuggetlab. org is going to be the record that we put in here. All right, so I'm going to say one minute. And then the content, this is where we put that content that we just talked about in that in that slide, right? So the first is going to be V equals DMARC one. And then a semicolon, a space P for what procedure or do we want them to do? I'm going to say equals none. Okay, don't want them to do anything.

8:25But and then semicolon space, R U A equals mail to colon admin at nuggetlab.org . Okay, so that is going to be our DMARC record. Going to click save. And now that's in place, we should see that right there in place. And now we should start getting reports if email servers are getting faulty or, you know, not validated with DKM or SPF records that say they're coming from us . All right, so ideally we don't want to get reports. But if we get, you know, if things go wrong, we should now get reports from mail servers. Now the only thing left to do is send an email from our account to an outside address and see what happens. So let's do that. Let's send an email to an outside address from our nuggetlab.org Google workspace and see what the email headers look like. All right, so here we are back at our Gmail inbox. This is the admin at nuggetlab.org. I'm going to compose an email. I'm going to send it to my personal email address. So Sean at brain of Sean.com.

9:39Yes, it's outside of my organization. See if I'm valid as a subject. I hope so. All right, so then I'm going to click send. So it's sent to my personal email address, which now I guess the whole world knows, but that's okay. What then we're going to do is go to my email and look at the headers of that. All right, and this is the email as it arrived in my inbox here. I'll try to make this a little bit bigger. This is a message ID, but it looks like to Sean at brain of Sean.com. Yes, that's a subject. And now we can see right here SPF it passed with an IP of 104 blah blah blah.

10:25So what this mean, what that means is this IP address resolved to the include that we did in our SPF record, right? So the SPF record is obviously in place and working and it passed because that is the, you know, that IP address is part of the Google domain that they had us include. Okay, also the D Kim past, which means that our public key is publicly available on the internet. And it was properly signed by our outgoing email server with the private key that Google workspace has in a past and a D mark passed, which of course, I mean, it passed, meaning that they're not going to really do anything. We said for them not to do anything if it failed, but it didn't fail. So everything is set up. This is basically just their way of telling us that D mark is set up and properly configured. So everything is set up and working. We know our MX records work because we set that up in the first, you know, the first thing we did in this scale. So now we can be confident that when we send and receive emails using Google workspace, it's going to be the least likely that it will be flagged as spam because of how we have set up our server and

11:45with and those specific DNS records that pertain to email.

0:00Okay, there's not any really exact way to do this, but we'll say I'm gonna put myself over here So I can use myself in the in the image. Let's say that I want to send an email To my uncle Joe who is over here? Uncle Joe is wearing a mumu, but nonetheless uncle Joe is over there and I want to send him an email now uncle Joe has an email server Uncle Joe is a little bit older It's probably like an AOL.com server and I have my server over here, which is Gmail calm we'll say all right and so if I want to send an email to uncle Joe I type out my email all right, so I have my email and it's very Very poignant. It's it's a very good email. I then deliver this or I Submit it it might just be in a web browser, but I'm done I click send and it goes to the gmail.com email server now this email server has a particular IP address and That's just you know part of what it is Let's say its IP address is 1.2.3.4, which it is certainly not but let's say it

1:18is and the first thing it does is it the the email server takes my email and it adds a digital signature to it Which is the d Kim you know it uses the private d Kim key which is stored on the email server and It digitally signs it it kind of puts its stamp on this Email that says you know this is the the d Kim verification signature, okay, and then My server says okay. It's addressed to uncle Joe over at AOL.com So what my what the gmail.com server has to do is look up the DNS Entry the MX records for AOL.com. Okay, so gmail Looks up the records for AOL.com. Just the MX records. That's okay The MX record is like mail dot AOL.com or whatever and so then it takes my Digitally signed email and it sends it to uncle Joe's email server, which happens to be whatever was in the MX record and then this email server Says okay. I got an email address for my user uncle Joe

2:38So I'm gonna look I'm gonna say okay. Did it come from a Proper place it's you know Whatever it's gmail dot com right it came from gmail dot com So if I if this server looks up the DNS record The SPF record for gmail dot com. It says okay. Did it come from a server that 's listed in the SPF record and if gmail dot com is the Address that it's using and it came from that address. So yes, so then it would say okay check SPF passes That's good and then it says okay I see that the email has a digital signature. So this goes over to DNS again And this time it grabs the DKIM public key and it uses this public key To verify whether or not this digital signature was actually signed By the server that has the private key and if so it says yep that signature checks out I use the private key that I found in the DNS record for gmail dot com And it passed now since both of those past it just delivers the email to uncle

3:55Joe and then uncle Joe gets it It doesn't go in a span folder because both SPF and DKIM both passed But if one of those failed then the server would say all right SPF didn't pass it came from an IP address not listed in SPF So now it looks back to the DNS records at gmail dot com for a d mark record And it says okay, I had a failure. What do I do and it looks up and you know in our case the D mark record might say None so then it might still pass it to uncle Joe But it might be listed as spam uncle Joe might have to check his spam folder because One of them like the SPF did not pass And along with you know, maybe marking it as spam but passing it along This server will also Send a report to whoever is listed in the d mark record and saying, you know, this is like a Whoa, something went wrong. I got this email or got these emails They said they were from you, but they didn't pass all the tests that I run on emails And so that's kind of the life cycle of an email when you include things like SPF DKIM and DMARC into the process

5:13It's totally fine if your explanation was a little bit different, but just make sure that you got all of the points That we talked about and you explained what they do how they function and what function they actually provide